Allg. Fragen zum Debuggen von AVRs

c-hater schrieb:
> Also: HW-Debugger sind eigentlich ziemlich überflüssig...

Dein Geschwätz ist überflüssig.

Gobbel schrieb:
> 3. Ich habe gelesen dass DebugWire wohl sehr umständlich sein soll und
> man lieber sein Projekt erstmal auf nem Dickeren µC machen soll um
> ordentlich debuggen zu können und dann alles auf den kleinen µC umbauen
> soll. Stimmt das? und warum?

Beim Atmega168 und 328 dauert der Upload schon arg lange, wenn der Flash 
am Anschlag ist. Bei den kleineren Tiny ist das eigentlich kein Problem.

Ein großer Vorteil ist, daß die 3 SPI-Pins im DW frei sind. Gerade bei 
8-Pinnern, wo die Leitungen fast immer für etwas anderes benötigt 
werden. Zumindest mit dem Jtagice. Der Dragon hat da Pullups drauf, das 
stört bzw. irritiert manchmal.

Effizientes Debuggen hängt nur sehr wenig vom Debugtool ab, sondern 
hauptsächlich vom Nachdenken. Planloses Debuggen kostet viel Zeit und 
bringt nur Ratlosigkeit und Verzweiflung.

Viele erfahrene Programmierer nehmen einfach nur printf. Das läuft auf 
jeder Maschine, die Applikation wird nicht angehalten und man kann 
beliebige Filterregeln hinschreiben.
Selbst auf dem kleinen ATtiny85 hat man schnell mit Bit-Banging ein 
UART-putchar zusammen gezimmert. Man muß auch nicht das große printf 
(~1kB) nehmen, sondern kann sich was kleines aus itoa und puts basteln.

Ohne Hardwareinteraktion kann man auch simulieren. Aber z.B. einen 
PID-Regler wird man nur schwer simulieren können. Der braucht den realen 
Regelkreis und darf auch nicht beim Debuggen anhalten.

Ich wuerd auch Onchip debuggen vergessen. Denn der Prozess ist dann 
kaputt. Heisst, wenn man nicht grad am Ansteuern eines Displays ist, hat 
man externe Hardware mit einem eigenen Prozess dran haengen. Dieser 
Prozess laeuft dann weiter waehrend der Code nicht weiter laeuft. Das 
geht in den meisten Faellen nicht gut. Wie schon erwaehnt .. der Code 
schaltet eine Heizung ein, und stoppt dann. Wenn der code dann 
weitermacht, ist alles schon verdampft, resp die Messwerte beziehen sich 
dann auf einen Fall, der eigentlich gar nicht auftritt, Ueberhitzung.

Von den Tinies sollte man die Finger lassen, die haben fast alle kein 
UART, und die Kostenersparniss von ein paar Cents ist fuer Kleinserien 
undwichtig. Also besser einen Mega verwenden. Die Megas habe alle 
serielle Schnittstellen.
Dann muss man sich einmal einen robusten Treiber schreiben, und kann 
dann immer waehrend eines Prozesses debuggen. Dh die Prozessvariablen. 
Wenn der Prozess schneller ist als die Kommunikation legt man sich eben 
einen Tracebuffer an, den man auf irgend ein Signal hin, intern, oder 
extern, fuellt. Und nachher per Seriell ausliest.
Allenfalls baut man sich einen Addon-Print, der einen oder mehrere 8 
fach DACs einthaelt, auf die man dann Prozessvariablen schreibt, und mit 
einem Oszilloskop verfolgen kann.

Sapperlot W. schrieb:
> Ich wuerd auch Onchip debuggen vergessen. Denn der Prozess ist dann
> kaputt. Heisst, wenn man nicht grad am Ansteuern eines Displays ist, hat
> man externe Hardware mit einem eigenen Prozess dran haengen. Dieser
> Prozess laeuft dann weiter waehrend der Code nicht weiter laeuft. Das
> geht in den meisten Faellen nicht gut.
Sagt wer? Es gibt reichlich Anwendungen wo HW-Debugging hervorragend 
funktioniert.
Ich nutzte rund 70%HW Debugging und 30% SW-Debugging, nachdem das meiste 
was ich mache sehr HW-nah ist. Mit solchen absoluten Statements wär ich 
mal vorsichtig, wenn man nicht weiß was der andere vor hat.


> Von den Tinies sollte man die Finger lassen, die haben fast alle kein
> UART, und die Kostenersparniss von ein paar Cents ist fuer Kleinserien
> undwichtig. Also besser einen Mega verwenden. Die Megas habe alle
> serielle Schnittstellen.

Voll dabei. Für den Hobby Bastler spielen weder 1-2€/chip noch die paar 
extra mm² eine nennenswerte Rolle. Warum sich so viele den Stress beim 
programmieren antun ist mir schleierhaft.

ich nehm auch in der Regel lieber 32-Bit oder ARM-Prozessoren, weil man 
sich dann viel weniger Kopf um Datentypen oder mathematische 
Berechnungen machen muss.


> Dann muss man sich einmal einen robusten Treiber schreiben, und kann
> dann immer waehrend eines Prozesses debuggen.
Muss man nicht. Treiber für UART gibts schon fertig im Software 
Framework von Atmel.
Klickt man sich auf Atmel START die Treiber zusammen die man braucht und 
generiert sich den Code, fertig. Schon kann man mit dem eigentlichen 
Programm loslegen, ohne sich um die Zicken der HW kümmern zu müssen.
Es gibt auch einen Treiber um die Stio auf UART umzuleiten. Dann wird 
printf automatisch auf UART gesendet.

Wenn man ein Eval-board verwendet läuft was auch komplett ohne ext. 
verdrahtung.
Ich schreibe den Code eigentlich inzwischen nur noch auf Eval-Boards und 
flash dann nur für den finalen Test auf die Produkt-HW.

Die Eval Boards kosten 20-40€ und bieten eine Menge Tools zum effektiven 
Debugging. Der HW-Debugger ist sogar mit auf dem Eval Board. Man muss 
nur USB anschließen, fertig.

Hier gibts ein ganz gutes Video für Anfänger von Atmel:
https://www.youtube.com/watch?v=ZspmSNvIs80&list=PLtQdQmNK_0DS3K9jIyPPMc9m6Tjobtj3d

Die benutzen dieses Eval-Board:
http://www.mouser.de/ProductDetail/Microchip-Technology-Atmel/ATSAMD21-XPRO/?qs=sGAEpiMZZMsn4IaorHFpMP%2fArXsMMWNXI3mJBNZTqeI%3d

> Wenn der Prozess schneller ist als die Kommunikation legt man sich eben
> einen Tracebuffer an, den man auf irgend ein Signal hin, intern, oder
> extern, fuellt. Und nachher per Seriell ausliest.
> Allenfalls baut man sich einen Addon-Print, der einen oder mehrere 8
> fach DACs einthaelt, auf die man dann Prozessvariablen schreibt, und mit
> einem Oszilloskop verfolgen kann.

Dafür gibt es den Data Visualizer. Der kann einem über diverse Kanäle 
(Dig IO, SPI, i2C) Daten aus der SW ins Atmel Studio bringen.

spess53 schrieb:
> Hi
>
>>ich nehm auch in der Regel lieber 32-Bit oder ARM-Prozessoren,...
>
> Du schweifst massiv vom Thema ab:

Fragen TO:
>"3. Ich habe gelesen dass DebugWire wohl sehr umständlich sein soll und
>man lieber sein Projekt erstmal auf nem Dickeren µC machen soll um
>ordentlich debuggen zu können und dann alles auf den kleinen µC umbauen
>soll. Stimmt das? und warum?"

Genau deswegen nehm ich keine kleinen 8-Bitter wenn ich nicht muss. Ich 
weiß es gibt Leute die aus Ergeiz/Herausforderung oder was auch immer 
einen möglichst komplexen Code auf einen möglichst kleinen µC stopfen 
wollen, aber nicht alle Teilen diese Leidenschaft. Ich will für meinen 
Teil z.B. das der Code mit minimal möglichen Entwicklungsaufwand das 
tut, was ich brauche.
Ich hab zu wenig Zeit um um einzelne Bytes Ram zu feilschen, wenn ich 
für 0,50€ einfach doppelt so viel kaufen kann.


>"4. Ich bin ein Fan von tutorials, da kann man sich einlesen und alles
>ausprobieren und lernt viel....Und man braucht nicht dumm fragen. Leider
>habe ich zu dem Thema leider nichts gefunden oder wenn dann nur auf
>English, aber die dann auch teilweise sehr unverständlich. Kennt da
>einer ein Gutes Tutorial oder ne Gute Anleitung?"

Zu dem Prozessor gibts numal ein gutes Tutorial-Video.
>
> Der TO Schrieb
>
>>1. Woran erkenne ich bei den AVRs welchen Mikrocontroller ich wie
>>Debuggen kann? ...
>
> Es geht hier eindeutig um AVRs.

Ja ich weiß die AVR-Fanatiker reagieren algerisch auf ARM, PIC, STM usw.
Ein offensichtlicher Neuling muss aber nicht unbedingt in der Steinzeit 
anfangen. Gibt viele gute Alternativen. Neulinge landen nur eben immer 
bei AVR, weil die ersten 100 Ergbnisseiten bei google nix anderes 
kennen.

Es gibt auch eine Handvoll Eval-boards für AVR mit dem embedded 
Debugger, aber wenn man das Tutorial 1:1 nachmachen möchte sollte man 
vielleicht eine ähnliche Platform nehmen.

Fabian F. schrieb:
> Ich
> weiß es gibt Leute die aus Ergeiz/Herausforderung oder was auch immer
> einen möglichst komplexen Code auf einen möglichst kleinen µC stopfen
> wollen

Das dürften nur absolute Einzelfälle sein.
Vielmehr sind folgende Gründe ausschlaggebend.

1.
Man hat eine Idee und will damit nicht erst warten, bis die Platine 
geroutet, geätzt, gebohrt und bestückt ist.
Sondern man greift sich ne Rasterplatine und pappt den DIP-8,-14 oder 
-28 Sockel drauf und die geplante Peripherie. Und wenn man Fehler 
entdeckt (was die Regel ist) lötet man die entsprechenden 
Schaltungsteile einfach um. Da ist es auch kein Problem, wenn der neue 
IC eine völlig andere Pinbelegung hat und eine andere Außenbeschaltung 
braucht.

2.
Man hat mit einer Toolchain bereits Erfahrung und will sich zusätzliche 
Einarbeitungszeit für eine neue Toolchain sparen. Und auch die Zeit, um 
die Fallgruben der neuen MC-Familie kennen zu lernen.

3.
Manche fühlen sich aber einfach nur von den vielen Modies und 
Einstellungen der 32Bit-Boliden wie erschlagen.
Oftmals hat man bei denen auch nicht alle Informationen in einer 
einzigen Datasheet, wie bei den AVRs. Sondern man hat zusätzliche 
Manuals, die aber viele Derivate abdecken, d.h. die Sachen enthalten, 
die auf das konkrete Derivat nicht zutreffen.

Peter D. schrieb:

> 1.
> Man hat eine Idee und will damit nicht erst warten, bis die Platine
> geroutet, geätzt, gebohrt und bestückt ist.

Ich bin inzwischen dazu übergegangen für so was Eval-Boards zu nutzen.
Das Board an dem ich grad arbeite hat 3 20-Polige Header an denen 
Diverse IO nach außen geführt ist.
Außerdem ist oben noch ein Arduino-Shield-kompatibler Header drauf. Da 
kann man sich dann als Sandwich oben einfach eine Lochraster-platine 
drauf machen.
Hat den Vorteil, das man sich nicht jedes mal von neuem mit Vcc, ARef, 
Ozillator & Co rumärgern muss.

Wenn ich ein anderes Projekt angehe, Steck ich die Lochraster-Platine 
wieder ab und mach eine andere drauf.

> 2.
> Man hat mit einer Toolchain bereits Erfahrung und will sich zusätzliche
> Einarbeitungszeit für eine neue Toolchain sparen. Und auch die Zeit, um
> die Fallgruben der neuen MC-Familie kennen zu lernen.

Macht zu einem Gewissen grad Sinn bei einer bekannten Platform zu 
bleiben. Bis zum Sankt Nimmerleinstag dort zu verharren und alle 
Neuerungen zu ignorieren ist aber auch nicht was Wahre.
Ich hab Jahrelang mit diversen 8-Bittern von Atmel oder PIC gearbeitet. 
Der erste Schritt zu HW mit HW-treibern war auch schwierig, wenn man in 
Projekten die Zeit im Nacken hat, aber als ich mich dann privat mal 2 
Tage damit beschäftigt habe ist mir aufgefallen, dass es eigentlich 
nicht komplizierter ist (Im Fall vom CAN& Ethernet sogar viel 
einfacher).
Außerdem ist es durch die Astraktion von HW über genertische IO-Zugriffe 
super einfach Programme in Teilen oder als ganzes von einer Platform zur 
anderen zu portieren.

> 3.
> Manche fühlen sich aber einfach nur von den vielen Modies und
> Einstellungen der 32Bit-Boliden wie erschlagen.
> Oftmals hat man bei denen auch nicht alle Informationen in einer
> einzigen Datasheet, wie bei den AVRs. Sondern man hat zusätzliche
> Manuals, die aber viele Derivate abdecken, d.h. die Sachen enthalten,
> die auf das konkrete Derivat nicht zutreffen.

Es gibt auch "kleine" ARMs und 32-Bitter (z.B. SAMD10) mit einer sehr 
übersichtlichen IO. Da Passen alle Informationen in 100 Seiten. Außerdem 
muss man sich wg. der HW-Treiber ohnehin kaum mit den Registern&Co des 
µC beschäftigen.

c-hater schrieb:
> Naja, das sind halt so Sachen, die Leute machen, die eben keine Anfänger
> mehr sind. Und die wissen dann auch, dass so ein HW-Debugger bei allen
> wirklich schwierigen Problemen de facto vollkommen nutzlos ist...

Ja, aber meiner ist länger als deiner.

c-hater schrieb:
> Thomas E. schrieb:
>
>> Dein Geschwätz ist überflüssig.

> Wenn es dir vorkommt, als wäre ein HW-Debugger nützlich, hast du noch
> nie die AVRs richtig ausgenutzt, sondern nur Kinderkram damit gespielt.

Oder man hat schonmal mit Prozessoren gearbeitet die keine AVRs sind.
Von den meisten high-Power-µCs gibts keine Simulatoren.

> Das Problem ist, zu den Stimuli-Dateien zu kommen. Und auch da hilft
> leider ein HW-Debugger kein bissel, das muss man selbst mittels
> entsprechend abgeänderter Programmversionen erledigen, die die Daten der
> Fehlversuche erstmal irgendwie Richtung PC ausleiten.
Ja ich ich kann mir stundenland duzende von printfs in den Code packen 
und dann einen kompletten Fahzeugbus in Software nachprogrammieren, oder 
ich kann einfach an ein paar kritischen Punkten (z.B. Rx-Interrupt, 
watchdog interrupt, Counter-wert) ein paar Breakpoints setzen und seh in 
wenigen Sekunden wo es hängt...