Datenverwaltungsprogramm für Atmel-Mikrocontroller (Ankündigung)

[Philipp H. (anobit)]

Moin moin.

Ich möchte hier eben Bescheid geben, dass ich gerade an einem Programm 
zum einfachen debuggen vom Mikrocontrollern (ohne teure Hardware) sitze. 
Ich werde hier kurz den (vorraussichtlichen, da gerade in 
Entwicklung/Implementierung) Stand der Dinge angeben. Wenn euch etwas 
einfällt, was noch unbedingt fehlt oder Ideen zur Umsetzung habt, bitte 
ich euch mir diese mitzuteilen.

Grundlage für diese Programme ist ein simples Übertragungsprotokoll auf 
der seriellen Schnittstelle. (Mit Adressierung und Checksumme etc)
Die Daten (Quellcode für den Mikrocontroller und die 
Windows(/Linux)-Programme)) werden von mir nach fertigstellung zum 
Download freigegeben.

1 eigenständiges 'kleines' Programm:
DAViELF:  Programm, welches die .elf-Datei eines bestehenden Projektes 
ausliest, sich dort die Variablen-Adressen heraussucht und diese über 
die rs232 auslesen/setzen kann (über eine mögl. einfache 
Benutzeroberfläche)
Vorteil: Kein aufwändiges Programm zur Datenverwaltung notwendig.
Nachteil: Derzeit nur RAM-Variablen

{2 zussammengehörige Programme:
DAVie: [Deiwie] Programm, welches die mit DAGe (siehe unten) erstellten 
Variablen verwendet, und diese über ein Benutzerinterface auf den 
Mikrocontroller überträgt/ausliest (derzeit per rs232). Dabei sollen die 
Daten nach Wunsch auch graphisch angezeigt werden können.

DAGe: [Deidsch]  Programm zur Anlegung von Variablen an speziellen 
Speicherstellen im Mikrocontroller. So sollen auch Special-Function 
Register über die rs232 (beschrieben und) ausgelesen werden können. Auch 
das ROM kann so adressiert werden. Es wird hierfür eine .h generiert, in 
der die Variablen als adressen definiert sind.
}

Am nähesten an einer Funktionstüchtigen Version ist derzeit DAViELF.
Die Adressen und Namen der Globalen- und Static-Variablen der .elf 
werden über avr-nm ausgelesen und angezeigt. Leider weiß ich noch nicht 
so recht, wie ich an den Variablen-Typen (und damit die länge in Byte) 
kommen soll, ohne den quellcode zu durchsuchen. (In der ersten Version 
muss der User das im Zweifel von Hand eingeben ;-))

DAGe ist auch ziemlich fortgeschritten (Verwaltung von Variablen und 
Source-Generierung funktionieren), allerdings vorerst ohne DAVie 
sinnlos.

Schreibt mal, was ihr davon haltet. Oder ob ihr sowas ähnliches schon 
kennt. Ich bis dato nicht...
(Ich hoffe nicht, denn dann hab ich mir locker 2 Wochen arbeit umsonst 
gemacht ^^)

Viele Grüße,
AnoBit

[me, myself and i (Gast)]

Im kommerziellen Umfeld kenne ich sowas unter "XCP" und "CANape". Bei 
www.vector.com solltest du noch mehr Informationen finden.

Was mich interessieren würde ist, wie D verhinderst, dass Werte, die Du 
über Deine Software via RS232 auf den Controller überträgst, nicht im 
nächsten Zyklus vom normalen Anwenderprogramm (bzw. der 
Controller-Hardware) überschrieben werden?

[Philipp H. (anobit)]

me, myself and i schrieb:
> Im kommerziellen Umfeld kenne ich sowas unter "XCP" und "CANape". Bei
> www.vector.com solltest du noch mehr Informationen finden.
>
> Was mich interessieren würde ist, wie D verhinderst, dass Werte, die Du
> über Deine Software via RS232 auf den Controller überträgst, nicht im
> nächsten Zyklus vom normalen Anwenderprogramm (bzw. der
> Controller-Hardware) überschrieben werden?

Gar nicht ;-) Ich weiß ja nicht, was der Anwender machen will.
Das schreiben selber ist mehr für Parameter u.A. gedacht, was vom 
eigentlichen Programm idR. nicht geändert wird.
Ich denke an der Stelle ist es das einfachste, wenn der User sich selber 
darum kümmert, ob die Variable einen neuen Wert bekommen hat.
Das schreiben in die Variable selbst sollte natürlich atomar passieren, 
damit da kein Unsinn drinn steht.

[Coder (Gast)]

Grundsätzlich ist das eine nette Idee für Situationen, in denen man 
einen Debugger nicht benutzen. Übrigens sind Debugger nicht so extrem 
teuer; siehe z.B. den AVR Dragon. Und sei vorsichtig mit 
Hardware-Registern; wie war das noch mit Receive Buffer der UART?


I.d.R. mache es so, ueber UART (Hard- oder Software) Daten auf den PC 
uebertrage.

[Plapperer (Gast)]

Man sollte in die CPU eingebaut einen Tracebuffer mit 
Triggermoeglichkeiten haben. Hat's aber nicht. Daher. Ein AVR Debugger 
ist eh nur fuer Trivialitaeten. Unter Echtzeitbedingungen geht alles 
nicht mehr. Ich debug jeweils als Teil der Applikation. Man muss 
natuerlich das Debuging als Teil der Entwicklung sehen und auch so 
planen und einbauen. Wenn man schnelle Echtzeitdaten, zB verborgene 
Regelparameter, sehen will, kann man ja einen aufsteckbaren OktalDAC 
verwenden, und periodisch updaten. Das Oszilloskop visualisiert dann die 
Signale.

[oldmax (Gast)]

Hi
So etwas ähnliches hat mein OpenEye bereits gemacht.... allerdings nur 
für Assembler. Hab ich vor ca. 2 Jahren hier mal veröffentlicht.
Gruß oldmax

[Weingut P. (weinbauer)]

wie ist das ... macht doch eigentlich nur Sinn, wenn der DAtentransfer 
nicht über die üblichen Hardwareschnittstellen laufen, sondern auf 
beliebige freie Pins gelegt werden, weil, wenn im Programm die 
UART-Interrupts schon verwendet werden die Kommunikation mit der 
Diagnosesoftware dann gestört oder die Anwendung nicht ihren Zweck 
erfüllen kann.
Also Software-UART oder Software-I2C wäre dann sinnvoller, oder?

[oldmax (Gast)]

Hi
Nun, es kommt darauf an. Wenn du nur zur Laufzeit die Werte in den 
Variablen sehen willst, reicht eventuell die RS232. Klar, sie sollte 
nicht von einem anderen Prozess benötigt werden, aber wenn's nicht 
Zeitkritisch ist, kann auch damit gearbeitet werden. Allerdings ist dann 
schon ein Protokoll erforderlich, das die Datenziele unterscheidet.
I.d.R. ist es auch nicht erforderlich, jede Änderung in den Variablen 
mitzubekommen. Oft reicht es, die Jobflags zu untersuchen, um 
herauszufinden, warum das Ergebnis vom Erwarteten so unterschiedlich 
ist. Für mich hat OpenEye gute Dienste geleistet. Sicher kann einiges 
verbessert werden, aber ich hab auch nicht den Ehrgeiz, nun etwas 
besonders hochwertiges an Software kostenlos zu verbreiten.
Gruß oldmax

[Philipp H. (anobit)]

Ich schon ;-)

Bzw, ich benötige sowas für eigene Projekte. Und wenn ich es schon 
schreibe, kann ich es auch Anderen zur Verfügung stellen.

Die erste Version wird die Daten über ein einfaches uart_putc senden.
Das lässt sich dann aber ja rel. einfach auf andere Bussysteme (Hard 
oder software) umschreiben.

Das Protokoll sieht derzeit so aus:

1.Byte: Adressierung und länge. (beides max. 15, jeweils ein halbes 
Byte)
2.Byte: Instruktion (lesen/schreiben/reset usw)
3. - vorletztes Byte: Daten für die Instruktion (Speicheradresse usw.).
letztes Byte: CRC

In meinen eigenen Projekten werde ich die Parse und Sende-Routinen in 
ein Timer-Generiertes 10ms-Interrupt packen.
Bei mir wird später die ganze Kommunikation nur über dieses Protokoll 
laufen, also brauche ich 'nur' einen Hardware-Uart.
Ich werd zusehen, dass man bei der veröffentlichten Version genug 
Einstellmöglichkeiten über defines etc hat.

Grüße,
AnoBit

[Jörg W. (dl8dtl) (Moderator)]

Atmel hat sowas auch schon gemacht.  Nennt sich debugWIRE, und da sie
Zugriff aufs Hardwaredesign haben, konnten sie gleich noch die
/RESET-Leitung dafür missbrauchen. ;-)

Letztlich ist debugWIRE aber eigentlich auch nichts großartig
Anderes als ein einfaches Monitorprogramm, welches hart in den
Controller eingebaut ist.  Irgendwo in einem Dokument (ich glaube,
AVR067) findet man dafür auch noch den Begriff "MonCom".

Nachteil: das Protokoll ist nicht offengelegt, man braucht daher
ein JTAGICEmkII, AVR Dragon oder JTAGICE3, um damit zu arbeiten.

Vorteil: es gibt bereits benutzbare Debugger dafür. ;)

[oldmax (Gast)]

Hi
>Bzw, ich benötige sowas für eigene Projekte. Und wenn ich es schon
>schreibe, kann ich es auch Anderen zur Verfügung stellen.

Na ja, auch aus diesem Grund ist OpenEye öffentlich.... aber eben nur 
eine Applikation, wie ich sie brauche, einfach ohne groß Gedönse und 
nicht wie sie andere gern hätten.
Gruß oldmax

[auelem (Gast)]

gdbserver