Hallo zusammmen, möchte gern Sensordaten mit dem AVR Studio 5 in eine Textdatei schreiben und stoße auf das Problem, dass der Compiler fopen nicht kennt. Wie kann man alternative Textdateien öffnen?
Bescxhreibe genauer, wass Du machen willst. AVR Studio ist dazu gedacht, Programme für AVR Mikrocontroller zu scrheiben, die also nicht vom PC sondern vom Mikrocontroller ausgeführt werden. Sicher hat dein Mikrocomputer weder ein Betriebssystem noch ein entspreches Speichermedium (z.B. Festplatte). Darum hast Du auch keinen fopen() Funktion zur Verfügung.
JTAGice3 schrieb: > Hallo zusammmen, > möchte gern Sensordaten mit dem AVR Studio 5 in eine Textdatei schreiben > und stoße auf das Problem, dass der Compiler fopen nicht kennt. > Wie kann man alternative Textdateien öffnen? was willst du? mit dem AVR Studio 5 erzeugt man programme für einen µC diese kennen überhaupt kein Dateisystem - die haben oft nicht mal ein Betriebsystem. mit dem AVR Studio 5 kann man bestimmt keine Sensordaten irgendwohin schreiben, das ist eine etwicklungumgebung!
Ich möchte zum testen meine Sensordaten, welche per SPI vom µC verarbeitet werden in eine Textdatei schreiben. Hatte vollkommen vergessen, dass mein Entwicklungs PC nicht mit meinem µC verbunden ist (ausgenommen ISP-Schnittstelle zum beschreiben).
Besteht die Möglichkeit per UART in SPI Mode und nem RS232-USB converter die Daten vom Sensor direkt in meinen Entwickler PC zu bekommen welcher dieser dann in ein Textdatei schreibt? Oder vielleicht was einfacheres?
JTAGice3 schrieb: > Besteht die Möglichkeit per UART in SPI Mode und nem RS232-USB converter > die Daten vom Sensor direkt in meinen Entwickler PC zu bekommen welcher > dieser dann in ein Textdatei schreibt? und wozu SPI? UART -> RS232 -> USB -> PC > Oder vielleicht was einfacheres? kommt darauf an was du da hast. Wenn dein µC netzwerk hat, kannst du es auch per netzwerk verschicken. Wenn du eine SD-Karte dran hast kannst du dort die Daten anlegen.
Hi Peter, hab nur SPI und UART zur Verfügung und es müssen die Sensordaten in eine Textdatei auf meinem Entwickler PC landen.
@ JTAGice3 (Gast) >Besteht die Möglichkeit per UART in SPI Mode und nem RS232-USB converter >die Daten vom Sensor direkt in meinen Entwickler PC zu bekommen welcher >dieser dann in ein Textdatei schreibt? Kann man machen. >Oder vielleicht was einfacheres? Schreib deine Daten in den EEPROM, den kann man per ISP auslesen.
Hi
>Anders gesagt Sensor(SPI)->PC(USB)->Textdatei
Wie kommt denn SPI zum USB? Sag jetzt nicht Programmer.
MfG Spess
spess53 schrieb: > Wie kommt denn SPI zum USB? Sag jetzt nicht Programmer. > > MfG Spess Was meinst du mit Programmer? Die Daten per ISP oder debugWire irgendwie in den PC über USB schicken?
UART und SPI sind zwei völlig unterschiedliche Dinge. Du kannst eine UART Schnittstelle nicht im SPI Modus betreiben. Warscheinlich möchtest Du Daten über die UARt Schnittstelle ausgeben, dann mit einem USB-UART (z.B. FT232 oder Silabs CP2201 oder Prolific PL2303) an den PC übertragen und dann auf dem PC mit einem Programm in eine Datei schreiben. Schau Dich mal nach dem Begriff "Terminalprogramm" um. In Windows XP gibt es z.B.l das HyperTerminal, es kann die empfangenen Daten auch in eine Datei schreiben. Hammer Terminal kann das auch. Richtig Komfortabel wird es aber erst, wenn Du Dir dazu ein Programm selbst schreibst. Unter Linux kann man das auch mit Board-Mitteln (Shell-Script) machen.
JTAGice3 schrieb: > spess53 schrieb: > > >> Wie kommt denn SPI zum USB? Sag jetzt nicht Programmer. >> >> MfG Spess > > > Was meinst du mit Programmer? > Die Daten per ISP oder debugWire irgendwie in den PC über USB schicken? MAAAN ordne mal deine Gedanken. Ist ja nicht zum aushalten. Was laberst du immer von SPI? Spess hat den Verdacht dass du meinst du könntest die Daten über deinen ISP-Programmer schicken (welcher mit dem Controller über SPI kommuniziert). DAS GEHT NICHT. Einfachste Möglichkeit (wurde aber auch schon gesagt, nur du ignorierst es), dein Controller sendet die Daten via USART, also seriell (RS232) und dein PC empfängt das entweder über eine native RS232 Schnittstelle (wenn vorhanden) oder du nimmst einen USB-RS232 Adapter, am besten direkt einen USB-TTL Adapter damit du keinen Pegelwandler am Controller brauchst. Alternativ, wenn nur wenige Messwerte: Schreib sie in den EEPROM vom Controller, den kannst du einfach mittels deines Programmers auslesen und bekommst so die Daten. Und wenn du mit diesen Infos nix anfangen kannst, dann fang kleiner an. Du würfelst hier alles durcheinander, hast keinen Durchblick. Ändere das! gruß cyblord
Hi >Du kannst eine UART Schnittstelle nicht im SPI Modus betreiben. Dann lügen die AVR Datenblätter in dem Kapitel 'USART in SPI Mode'. MfG Spess
spess53 schrieb: > Hi > >>Du kannst eine UART Schnittstelle nicht im SPI Modus betreiben. > > Dann lügen die AVR Datenblätter in dem Kapitel 'USART in SPI Mode'. > > MfG Spess Damit bekommt man aber eine SPI Schnittstelle. Die bringt einem doch nix um mit dem PC zu kommunizieren.
Hi >Damit bekommt man aber eine SPI Schnittstelle. Die bringt einem doch nix >um mit dem PC zu kommunizieren. Das weiss ich. Sollte nur eine Richtigstellung sein. MfG Spess
Die USART Schnittstelle kannst Du in SPI Modus betreiben. Eine UART Schnittstelle jedoch nicht. JTAGice3 sprach von einer UART Schnittstelle.
@JTAGice3 (Gast) >Wäre das dann eine Echtzeitlösung? Dein AVR liest die Daten per SPI aus dem Sensor und schickt sie nett in ASCII formatiert an den UART. Der wird per FT232 & Konsorten über USB in einen virtuellen COM-Port gewandlet und kann einfach per Terminalprogramm empfangen werden. Das Terminalprogramm kann die empfangene Daten in eine Textdatei schreiben. Fertig.
Danke für die ganzen Ideen. Leider sind es viele Sensorwerte und der EEPROM hat nur 100k Schreibzyklen. Das kann ich nicht machen. Ich werd die Idee mit der UART und dem Terminalprogramm versuchen.
JTAGice3 schrieb: > Ich werd die Idee mit der UART und dem Terminalprogramm versuchen. Wenn du die Daten ein bisschen hübsch formatiert ausgibst, kannst du deine Werte evtl. z.B. mit LogView auch gleich als Live-Graphik verfolgen und nebenbei in eine Datei mitschreiben. Vom HEX-Format müßtest du dich dann allerdings wahrscheinlich verabschieden.
Hallo zusammen, hab jetzt folgende Konstellation: SPI Sensordaten an µC, per UART über UART-USB-Adapterkabel an USB-Port vom Entwickler PC mit Terminalprogramm. Leider kommen falsche Hex-Daten an. Daraufhin hab ich mir gedacht einfach ein einfaches UART-Programm zum Test zu schreiben und zu sehn, ob das Terminalprogramm immer noch falsche Daten anzeigt. Dummerweise der Fall. Liegt es vielleicht daran, dass ich lediglich die Tx Leitung an den PC weitergebe?
JTAGice3 schrieb: > Test zu schreiben und zu sehn, ob das Terminalprogramm immer noch > falsche Daten anzeigt. > > Dummerweise der Fall. > > Liegt es vielleicht daran, dass ich lediglich die Tx Leitung an den PC > weitergebe? Nein. Es liegt eher daran, dass dein Baudrate nicht stimmt. Siehe die anderen Threads, die jetzt gerade zum gleichen Thema 'Hilfe, meine UART funktioniert nicht' laufen.
JTAGice3 schrieb: > Leider kommen falsche Hex-Daten an. Was heißt das genau? > Daraufhin hab ich mir gedacht einfach ein einfaches UART-Programm zum > Test zu schreiben Zeigen. > Liegt es vielleicht daran, dass ich lediglich die Tx Leitung an den PC > weitergebe? Nein. Bei korrekter Konfiguration reicht die Tx-Leitung vom Controller zum PC.
JTAGice3 schrieb: > Hier das Programm. Läuft über den internen Quarz. Kann sein, das ich das überlesen habe, aber: Welchen AVR verwendest Du genau? Abhängig davon, muss das hier: > UCSR0B &= ~(UMSEL00); //asynchronous ->UART > UCSR0B &= ~(UMSEL01); korrigiert werden.
Hatte ich noch nicht erwähnt. ATmega 328p Die Codezeilen initialsieren ihn als UART, so wie gewünscht. Datasheet S.203 http://www.atmel.com/Images/8271s.pdf
JTAGice3 schrieb: > ier das Programm. Läuft über den internen Quarz. Und was soll da deiner Erwartung zufolge ankommen? 0xEB? Das ist kein Ascii-Zeichen. Du musst ein 'E' und ein 'B' senden, wenn du das so dargestellt haben möchtest. Sonst gibt es nur Karos oder Herzchen. mfg.
JTAGice3 schrieb: > Die Codezeilen initialsieren ihn als UART, so wie gewünscht. Ganz sicher nicht. Mal davon abgesehen, dass UMSEL00 und UMSEL01 laut Deinem verlinkten Datenblatt im Register USCR0C liegen, solltest Du Dir mal anschauen, wie einzelne Bits gelöscht werden. http://www.mikrocontroller.net/articles/Bitmanipulation#Standard_C_2 So wie Du es jetzt hast, zerschießt Du Dir den Inhalt des Konfigurationsregisters USCR0B.
Hi Thomas, ich verwende Terminal v1.9b und dort kann man sich die Daten im Hex-Format anzeigen lassen. Ich erhalte auch Hexzahlen, leider nur nicht 0xEB, sondern 0x80.
J.-u. G. schrieb: > JTAGice3 schrieb: > So wie Du es jetzt hast, zerschießt Du Dir den Inhalt des > Konfigurationsregisters USCR0B. natürlich UCSR0B &= ~(1<<UMSEL00); //asynchronous ->UART UCSR0B &= ~(1<<UMSEL01); hab die 1<< vergessen. Anfängerfehler.
@J.-u. G. Leider behebt es meinen Fehler nicht. Denkst du, dass ich die UART geschrottet habe?
Mist hab grad gesehn, dass es UCSR0C sein muss. Kann man durch meine 2 Codezeilen das UCSR0B zerstören?
Hi
>Kann man durch meine 2 Codezeilen das UCSR0B zerstören?
Nein.
MfG Spess
JTAGice3 schrieb: > Kann man durch meine 2 Codezeilen das UCSR0B zerstören? Kann schon sein. Das sieht man aber sofort denn das brennt ein Loch ins Chipgehäuse. Jetzt vergiss mal dieses Umsel-Zeugs. Das ist alles per default richtig eingestellt. Das einzige, was du einstellen musst ist die Baudrate und den Sender. Wenn es dann nicht geht, ist deine Baudrate falsch. mfg.
JTAGice3 schrieb: > Kann man durch meine 2 Codezeilen das UCSR0B zerstören? Keine Angst, damit kann man den Controller nicht zustören. Das das richtige Register UCSR0C ist, hast Du ja jetzt rausgefunden. Allerdings erklärt das nicht den beobachteten Fehler, denn zufällig führt auch Deine fehlerhafte Initialisierung, zu einer funktionierdenden UART. Bleibt als wahrscheinliche Ursache, dass Dein Controller doch mit einer falschen Geschwindigkeit taktet.
JTAGice3 schrieb: > Wo aber liegt jetzt der Fehler? Programm noch mal korrigieren. Alle Bits in den richtigen Registern? Sind die BIts überhaupt notwendig? Machen sie das (laut Datenblatt) was man möchte? Stimmt die Baudrate? Ist die µC Frequenz richtig? Läuft der µC auch wirklich mit dieser Frequenz? Irgendwo da hast du einen Fehler (ich geh mal davon aus, dass der MAX232 wegen falscher Kondensatoren nicht in der Spannung einbricht. Kann man aber auch testen: µC aus dem Sockel. Mit einem Drahtstück Tx und Rx brücken und auf dem PC auf der Tastatur klimpern. Alles was man klimpert geht per Kabel bis zum Sockel und die Brücke schickt es gleich wieder zurück, so dass es angezeigt wird. Damit weiß man, dass die Hardware in Ordnung ist) Und vergiss den Unsinn mit 'du hast den Chip geschrottet'. So schnell gehen die nicht kaputt.
JTAGice3 schrieb: > Hier das Programm. Läuft über den internen Quarz. Es gibt keinen "internen Quarz"! Das ist ein ungenauer RC-Oszillator.
Ich stelle im Terminalprogramm die richtige Baudrate ein, richtiges Frameformat. Meine Baud Formel im Code ergibt 25, welches laut Datenblatt bei einem 8MHz osc den Wert 25 haben muss. Hatte sogar den Registerinhalt von 25 im UBRR0 anzeigen lassen. Im AVR Studio 5 bei den Fuses steht bei SUT_CKSEL: INTCOSC_8MHZ_6CK_14CK_65MS Ich erkenne daraus nur, dass er den internen mit 8MHz betreibt.
Ist der denn so ungenau, dass er nicht ausreicht für eine einfache UART Übertragung?
JTAGice3 schrieb: > Im AVR Studio 5 bei den Fuses steht bei > > SUT_CKSEL: INTCOSC_8MHZ_6CK_14CK_65MS > > Ich erkenne daraus nur, dass er den internen mit 8MHz betreibt. Und was macht das CKDIV-Häkchen? mfg.
JTAGice3 schrieb: > Ich erkenne daraus nur, dass er den internen mit 8MHz betreibt. Und zum gefühlt 6 Millionen 8 hundert tausend 3 hundert 5 und neunzigsten mal. Es gibt keinen internen Quarz sondern nur einen internen RC-Oszillator. Und ob der mit 8Mhz schwingt oder ein paar Kiloherz daneben kann kein Mensch ohne Messinstrumente sagen. Spielt normal auch keine Rolle, ausser bei der UART. Wenn du Glück hast, ist er nahe genug an den 8Mhz, so dass alles klappt auch ohne dass du ihn kalibrierst. Kann also sein, muss aber nicht. Mit einem Quarz bist du auf der sicheren Seite.
Hat der Controller ne CLKDIV8 Fuse? Die muss raus. Sonst läuft er mit 1 MHz statt mit 8.
Karl Heinz Buchegger schrieb: > Wenn du Glück hast, ist er nahe genug an den 8Mhz, so dass alles klappt > auch ohne dass du ihn kalibrierst. Kann also sein, muss aber nicht. Mit der richtigen Baudrate funktioniert das bei Zimmertemperatur mit einem Byte allemal. Aber aus 0xEB wird beim Senden mit 1/8 der Empfängerbaudrate 0x80. mfg.
cyblord ---- schrieb: > Hat der Controller ne CLKDIV8 Fuse? Die muss raus. Sonst läuft er mit 1 > MHz statt mit 8. Thomas Eckmann schrieb: > Aber aus 0xEB wird beim Senden mit 1/8 der Empfängerbaudrate 0x80. Hab jetzt die CLKDIV8 weggenommen, leider immer noch falsche Übertragung. Statt 0xEB erhalte ich 0x0A. Wenn man bei 0xEB = 11 1010 11b die 2 Einsen links und rechts entfernt erhält man 1010b was zufällig 0x0A. Ist das ein Zufall?
JTAGice3 schrieb: > Ist das ein Zufall? Ja. Dein Programm funktioniert. Nimm ein vernünftiges Terminalprogramm, stell die Baudrate richtig ein sende ein lesbares Zeichen. mfg.
Thomas Eckmann schrieb: > Dein Programm funktioniert. Nimm ein vernünftiges Terminalprogramm, > stell die Baudrate richtig ein sende ein lesbares Zeichen. > > mfg. Hab jetzt ein weiteres Terminal Programm probiert welches die gleichen Ergebnisse liefert wie Terminal v1.9. Wenn ich mit dem Oszi vor dem Serial-USB Converter Kabel, also direkt am TX pin vom µC, erhalte die richtige Hex-Zahl, oder auch Buchstaben im 8N1 Format. Das Problem scheint also komplexer zu sein. Anscheinend liegt es am Converter-Kabel. Irgendjemand ne Idee?
JTAGice3 schrieb: > Das Problem scheint also komplexer zu sein. > Anscheinend liegt es am Converter-Kabel. Dann muss das aber defekt sein. Ein RS232/USB Konverter hat nur eine Aufgabe: von +12V RS232 (also nicht dem TTL Derivat) auf USB umzusetzen. Und bis jetzt hat das auch noch jeder Konverter gemacht. Wenn er es nicht tut, dann erfüllt er nicht seine Aufgabe und ist defekt. > Irgendjemand ne Idee? Irgendwie glaub ich nicht so recht an die 'Konverter-defekt' Hypothese. Praktisch immer stellt sich raus, dass das Timing falsch ist und zu 99% liegt das daran, dass der µC nicht mit der Taktfrequenz läuft, die der Programmierer glaubt und mit der er seine Konstanten ausgerechnet hat.
Karl Heinz Buchegger schrieb: > Praktisch immer stellt sich raus, dass das Timing falsch ist und zu 99% > liegt das daran, dass der µC nicht mit der Taktfrequenz läuft, die der > Programmierer glaubt und mit der er seine Konstanten ausgerechnet hat. Mein Oszi zeigt mir am Tx Pin vom µC das Richtige an. Also muss es am Converter-Kabel liegen.
JTAGice3 schrieb: > Mein Oszi zeigt mir am Tx Pin vom µC das Richtige an. Das das richtige Bitmuster rauskommt, glauben wir Dir gerne. Aber kommen die Flanken auch zu den richtigen (vom PC erwarteten) Zeitpunkten?
spontan schrieb: > Tausch es doch einfach aus. Hab ich gemacht, ändert sich leider nichts. hab jetzt den Treiber nochmal neu gemacht, aber jetzt erscheint das Connector Kabel nicht mehr in der Taskleiste als USB mit grünem Häkchen.
J.-u. G. schrieb: > JTAGice3 schrieb: > Das das richtige Bitmuster rauskommt, glauben wir Dir gerne. Aber kommen > die Flanken auch zu den richtigen (vom PC erwarteten) Zeitpunkten? Wie kann ich das prüfen?
JTAGice3 schrieb: > Wie kann ich das prüfen? Indem Du mit dem Oszi die Bitdauer misst. Gemäß: http://de.wikipedia.org/wiki/RS-232#Datenrahmen_und_Timing sollte bei einer Baudrate von 19.200 die Übertragung eines Bits ca. 52µs dauern.
J.-u. G. schrieb: > Indem Du mit dem Oszi die Bitdauer misst. Gemäß: > http://de.wikipedia.org/wiki/RS-232#Datenrahmen_und_Timing > > sollte bei einer Baudrate von 19.200 die Übertragung eines Bits ca. 52µs > dauern. Hab ich grad geprüft. Die Bitdauer entspricht ca. 52µs.
JTAGice3 schrieb: > Hab ich grad geprüft. Die Bitdauer entspricht ca. 52µs. Dann weiß ich auch nicht mehr weiter. Eine Sache macht mich stuzig: JTAGice3 schrieb: > Wenn ich mit dem Oszi vor dem Serial-USB Converter Kabel, also direkt am > TX pin vom µC, erhalte die richtige Hex-Zahl, oder auch Buchstaben im > 8N1 Format. Was ist das für ein Konverterkabel? Übliche seriell-USB-Konverter können mit dem TTL-Pegel des AVR nichts anfangen. Dieser muß erst mittels MAX232 gewandelt werden.
J.-u. G. schrieb: > Was ist das für ein Konverterkabel? http://www.delock.de/produkte/S_61856/dokumente.html Ich kann anhand des Datenblattes nicht sehn, für welche Spannungen es ausgelegt ist.
Hi >Ich kann anhand des Datenblattes nicht sehn, für welche Spannungen es >ausgelegt is Das ist für eine richtige RS232. Also nicht TTL. MfG Spess
das ist ein übliches adapterkabel -> max232 (oder vergleichstyp) notwendig
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.