Hallo liebe Mikrocontroller.net Gemeinde :) Zunächst einmal vorab, dies ist mein erster Forumbeitrag, also seid nicht zu hart :D Zu meinem Vorhaben: Ich habe vor, alles (das wichtigste) was der MC (Atmega2560, sollen aber auch mehrere werden) macht, über UART auf den PC zu schicken. Sollte ja, solange es Text bzw ASCII bleibt, kein Problem sein. Und zwar soll das eine Debugschnittstelle werden. Und sicherlich gibt es andere Möglichkeiten, würde mich aber gerne auf diese Konzentrieren, da ich vorhabe im laufenden Betrieb dauerhaft von mehreren Mikrocontrollern die Daten auszulesen. Jetzt zu der eigentlichen Frage: Ich möchte Text und Variablen schicken (z.b. "Es wurden 9,4V erkannt"), ist das ohne weiteres Möglich? Gibt es Protokolle in denen man von einem ASCII zu einem Integer Wert und zurück wechseln kann?
Prinzipiell ist das möglich. Meist wandelt man auf dem µC schon alles in ASCII. Ein standardisiertes gemischtes Protokoll ist mir nicht bekannt. Du kannst Dir aber gerne eines ausdenken. Ich weiss ja auch nicht, in welchen Sprachen Du programmieren willst und wie leistungsfähig Deine µC minimal sind. Sprich bei wenig Speicher bieten C-Compiler abgespeckte Varianten des (s)printf Befehls an, mit dem man z.B. auf Rechnern der Leistungsklasse Raspi solche Ausgaben erzeugen würde. In Assembler wird das ganze natürlich beliebig kompliziert. Ach halt, mir fällt doch gerade ein Standardprotokoll ein : XCP. Läuft über diverseste Schnittstellen, kann Werte auslesen und ändern. Auf µC Seite ist nur ein minimaler Treiber notwendig. Um es richtig bequem zu haben, benötigst Du jedoch zu jeder Softwareversion eine standardisierte Beschreibungsdatei, was wie wo im Speicher stecht.
@fop: Danke erstmal für deine Antwort. Ich programmiere mit C und beschreibe aktuell einen Atmega328PB, sowie einen Atmega2560. fop schrieb: > Meist wandelt man auf dem µC schon alles in > ASCII Ja klar, kann man machen bzw finde ich ASCII auch leichter zu senden. Aber woher weiß denn das Terminal dann dass die ersten 10 Bytes jeweils Buchstaben sein sollen und der nächste ein Zahlenwert?
Steven D. schrieb: > woher weiß denn das Terminal dann dass die ersten 10 Bytes jeweils > Buchstaben sein sollen und der nächste ein Zahlenwert? Muss es ja nicht, auch Ziffern kannst du als ASCII senden. Du musst eben selbst umrechnen oder (s) printf verwenden.
printf() itoa() // braucht weniger Speicher Das Gegenstück wäre scanf() und atoi()
Vergiss einfach float wenn moeglich. Also nit 7.4 V, sondern eher grad den ADC wert, der kann im PC dann ja verrechnet werden.
Ein "richtiges" Debugprint benutzt endweder das Semihosting des JTAG oder einen UART der ohne Interrupts auskommen sollte. Das kann auch ein Soft-UART sein. Da muss man dann u.U. die Interrupts waehrend der Ausgabe sperren. Darueber solltest du erst einmal nachdenken. Und Romane wie > "Es wurden 9,4V erkannt" gibt man darueber im allgemeinen auch nicht aus. Ich habe schon Beispiele gesehen, wo zeitkritsche Software mit so etwas debuggt werden sollte. Mit den Debugausgaben war das Timing dann voellig kaputt. Und nur, weil derjenige zu doof war, das mit dem vorhandenen Debugger der auch eine Laufzeitausgabe von Variablen, Speicher, etc. konnte, zu realisieren.
Steven D. schrieb: > Ich möchte Text und Variablen schicken (z.b. "Es wurden 9,4V erkannt"), > ist das ohne weiteres Möglich? > Gibt es Protokolle in denen man von einem ASCII zu einem Integer Wert > und zurück wechseln kann? Mache es folgendermaßen: 1. Definiere Dir Messages mit Platzhaltern, z.B. 1="Eingang %fV" 2="Ausgang hat Zustand %d" 3="Temperatur an Port %d ist %f°C" Jetzt schickst Du über den UART nur die Nummer der Message, die Anzahl der Parameter und die Parameter selber, alles binär. Der PC empfängt das, hat eine Liste mit den Texten und kann aus dem jeweiligen Text plus den Parametern eine aussagekräftige Klartextmitteilung machen. Das hat den Vorteil, dass nur sehr wenig Daten über die Schnittstelle müssen und das man einfach die Sprache wechseln kann, indem man die Datei mit den Texten austauscht. Dieses Verfahren wird z.B. bei der Ereignisanzeige von Windows verwendet. fchk
Hi So ein solches Projekt hab ich in einem Buch beschrieben, allerdings unter Assembler. Das PC Programm ist VB und liefert, wenn die Kommentarzeilen vollständig sind, Werte im Format Byte mit Bitauflösung, Integer mit bis zu 32 Bit und Char Das Buch kannst du kostenlos Downloaden bei Makerconnect.de in der Rubrik FAQ Vielleicht gelingt dir die Erweiterung auf C. Mir war das VB Programm bisher eine große Hilfe. Zumal auch möglich ist, bei Durchlauf bestimmter Programmschritte die zu diesem Zeitpunkt gültigen Variableninhalte zu versenden. Also, nimm dir Zeit, das Werk hat knapp 1000 Seiten Viel Spass Gruß oldmax
Vielen Dank erstmal für die ganzen Antworten! Ich werde nach und nach eure Lösungsansätze probieren. Frank K. schrieb: > er PC empfängt das, hat eine Liste mit den Texten und kann aus dem > jeweiligen Text plus den Parametern eine aussagekräftige > Klartextmitteilung machen. Das verstehe ich nicht ganz, da müsste ich dann zusätzlich am PC eine Software dafür schreiben oder? Das wäre mir zu umständlich ^^ Vielleicht für später mal. Larry schrieb: > Darueber solltest du erst einmal nachdenken. Über was genau? Ich habe weder JTAG, noch Interrupts in meinem UART.. Larry schrieb: > Ich habe schon Beispiele gesehen, wo zeitkritsche Software > mit so etwas debuggt werden sollte. Ja dass es damit Probleme geben kann, ok. Aber das ist ja alles nicht Teil des Themas :P
Steven D. schrieb: > Das verstehe ich nicht ganz, da müsste ich dann zusätzlich am PC eine > Software dafür schreiben oder? Ja. Oder du lernst die Codes auswendig.
Steven D. schrieb: > Gibt es Protokolle in denen man von einem ASCII zu einem Integer Wert > und zurück wechseln kann? Ich glaube, diese Stelle in deinem Post ist verwirrend. In der Regel macht man entweder ASCII ( "Es wurden 9,4V erkannt") oder "binärdaten" (z.b. ein Startbyte, ein Byte msgID, n Bytes Nutzdaten je nach msgID, 2 Bytes Checksumme, ein Stoppbyte) Das kann man auch mischen, ist aber so wie saure und Milchgetränke zu mischen. ASCII kann mit jedem Terminalprogramm mitgelesen werden, im einfachsten Fall sogar ohne (copy com1 > log.txt). Binärdaten erfordern eine spezielle Auswertung.
A. S. schrieb: > Ich glaube, diese Stelle in deinem Post ist verwirrend. Meine Traumvorstellung ist eine Funktion für alles: debug("ADC1: 9.4V"); So benutzt und alles im Terminal dementsprechend ausgegeben. Ich hatte einen kleinen Denkfehler, da Integer bzw. einzelne Ziffern ja auch im ASCII sind... Man muss es eben nur einzeln senden
Steven D. schrieb: > debug("ADC1: 9.4V"); naja, da brauchst Du zusätzlich sowas wie printf mit %f oder %d. Sonst kommt die 9.4 nicht in den Text.
Steven D. schrieb: > Frank K. schrieb: >> er PC empfängt das, hat eine Liste mit den Texten und kann aus dem >> jeweiligen Text plus den Parametern eine aussagekräftige >> Klartextmitteilung machen. > > Das verstehe ich nicht ganz, da müsste ich dann zusätzlich am PC eine > Software dafür schreiben oder? Genau so ist es. Das Problem, was Du nämlich oft hast, ist, dass das Logging Deinen Programmablauf ziemlich verlangsamen kann, wenn Du mal etwas mehr Meldungen hast. Daher willst Du die Datenmenge, die über den Debugport geht, minimieren, so weit es nur irgendwie geht. Und das ist genau der Ansatz dafür. > Das wäre mir zu umständlich ^^ Vielleicht für später mal. Wirst schon merken. fchk
Hi Freunde, hab früher jede Menge uC's für Messgeräte programmiert, Renesas, PIC's und Atmels (von der 88er-Serie bis zu den Mega256er-Modellen) ... prinzipiell ist eine RS232/RS485-"Nabelschnur" zu Debugzwecken immer das Erste gewesen, das ich implementiert habe, und wenn's auch nur um Datalogging ging. Implementiert hatte ich immer zuerst (auf der uC-Seite) eine serielle Komm. mit den entsprechenden UART-Settings und den dazupassenden Interrupts inklusive den sscanf() oder sprintf()-Routinen, auf PC-Seite bin ich teilweise noch mit dem MS-DOS Kermit gefahren, das ist (oder war) immerhin skriptprogrammierbar und ziemlich flexibel. Das Erste ist immer, "hört Dich der uC und sagt es Dir auch" ... der Rest ist Fingerarbeit. VG
> > Ich habe schon Beispiele gesehen, wo zeitkritsche Software > > mit so etwas debuggt werden sollte. > Ja dass es damit Probleme geben kann, ok. Aber das ist ja alles nicht > Teil des Themas :P Man kann versuchen die Realitaet auszublenden. Um so heftiger wird man damit auf die Nase fallen. > eine serielle > Komm. mit den entsprechenden UART-Settings und den dazupassenden > Interrupts inklusive den sscanf() oder sprintf()-Routinen Spaetestens wenn der Controller keinen oder keinen freien U(S)ART mehr hat, wird das wohl nichts. Je einfacher ein Debugprint realisiert ist, um so besser stehen die Chancen, dass er nicht die Anwendung stoert. Aber jeder wie er mag.
Larry schrieb: > Und Romane wie >> "Es wurden 9,4V erkannt" > gibt man darueber im allgemeinen auch nicht aus. > > Ich habe schon Beispiele gesehen, wo zeitkritsche Software > mit so etwas debuggt werden sollte. Was hast du gegen Romane? Also wenn man etwas als Mensch lesen will, ist eine menschlich lesbare Botschaft genau das Richtige. Ob das nun exakt so wie oben "Es wurden.." ausgegeben wird oder etwas anders "Batt: 9.4V" ist Geschmackssache. Und du hast schon Beispiele gesehen... Ich hab z.B. meinen USB Treiber durchaus mit der Seriellen als Kommunikationsweg in Gang gesetzt. Dazu sind ein paar Maßnahmen nötig, aber es geht - im Gegensatz zum Versuch, sowas dreist per JTAG/SWD-Debugger machen zu wollen. Stichwort: postmortem-debug. Steven D. schrieb: > Ich möchte Text und Variablen schicken (z.b. "Es wurden 9,4V erkannt"), > ist das ohne weiteres Möglich? Ja.
1 | String_Out("Es wurden ", toUART1); |
2 | FF_Out(&UBatterie, 3, 1, toUART1); |
3 | String_Out("V erkannt\r\n", toUART1); |
Nimm dir den Beitrag von MadMatt zu Herzen. Er hat genau den richtigen Punkt getroffen: Zuerst die Firmware soweit aufbauen, bis daß man irgendwie seriell mit dem PC kommunizieren kann, dann erst kommt alles weitere. Auch ich bin mit dieser Methode seit langen Jahren gut gefahren - und wenn man sich noch einen kleinen Kommandointerpreter einbaut, dann kann man auch für diverseste Zwecke sich mal eben ein kleines Spezialkommando schreiben, um irgendwas spezielles (je nach Anwendungsfall) damit zu tun. W.S.
MadMatt schrieb: > bin ich teilweise noch mit dem MS-DOS Kermit gefahren, das ist (oder > war) immerhin skriptprogrammierbar und ziemlich flexibel. Mir wird ganz warm ums Herz... Damit habe ich für eine (die) damals größte "private" Baufirma in DE, ein komplettes weltweites System aufgebaut, mit welchem Buchhaltungsdaten über ein zentrales UNIX System (SNI MX500) (C-Kermit) mit selbst programmierter Modemshell ( Modem Getty) eingesammelt wurden und an eine BS 2000 für weiter betriebswirtschaftliche Auswertungen übermittelt wurden. Das war damals Hightech ;-) Gedankt hat man es mir nie wirklich;-(
Das war 1993! Ein Kumpel hatte einen Modemzugang zur Uni Darmstatt und von dort ging es per Internet in die weite Welt........
Dr House schrieb: > Ein Kumpel hatte einen Modemzugang zur Uni Darmstatt und von dort ging > es per Internet in die weite Welt........ An der Columbia Universität gabs dann den Sourcecode und ich compilierte den dann auf den Siemens Nixdorf Unix Rechnern. Die Siemens Leute (Vertrieb und Sytemingenieure) lachten mich aus, aber nicht mehr als alles lief ;-). Als wir dann auch noch Drucketreiber für die Ansteuerung von HP500 Tintenstrahlern und Epson Druckern programmierten, brach für die Vertriebler die Welt zusammen. Die Siemensdrucker kosteten damals alle so um die 10.000 DM!! Da ging im Hintergrund dann auf GF Ebene so richtig die Post ab. Abwerbeversuche hielt ich standhaft durch..
W.S. schrieb: > Und du hast schon Beispiele gesehen... Ich hab z.B. meinen USB Treiber > durchaus mit der Seriellen als Kommunikationsweg in Gang gesetzt. Dazu > sind ein paar Maßnahmen nötig, aber es geht - im Gegensatz zum Versuch, > sowas dreist per JTAG/SWD-Debugger machen zu wollen. Stichwort: > postmortem-debug. Mal wieder keine Ahnung von garnichts und ne Allergie vor Debuggern? Cortex-M mit SWD kommt meist mit Trace. Selbst ohne Trace gibts das hier: https://www.segger.com/products/development-tools/systemview/
> "Es wurden 9,4V erkannt" > Was hast du gegen Romane? Wenn das mit troedeligen 9600 baud aus der Leitung tropft, braucht das knapp 23 ms. Fuer sowas muss man dann eine Queue und alle damit verbundenen Mechanismen bereitstellen. Und wenn dann noch mehr geloggt wird, wird die dann irgendwann wohl ueberlaufen. Das mag im Einzelfall nicht stoeren, aber im allgemeinen wird man damit frueher oder spaeter irgendwo anecken. Genau aus diesem Grund, stellen Controller/DSPs auch Mechanismen bereit, die Bandbreite des Logs signifikant zu steigern. Die muss man dann halt kennen und einsetzen. Hat man das nicht zur Verfuegung, hilft eben eine gewisse Sparsamkeit. Dafuer bevorzuge ich eben z.B. Soft-UARTs. Bei kurzen Mitteilungen und entspechender Geschwindigkeit, z.B. 230 kbaud. Zum Senden brauchen die nicht notwendigerweise einen Interrupt, koennen fast auf jedem Pin Daten ausgeben, und greifen damit nur minimal in das System ein. > ich bin mit dieser Methode seit langen Jahren gut gefahren Ja, ich auch.
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.