mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie geht ihr beim Debuggen vor?


Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe in einem Programm den Fehler, dass ein Wert aus dem EEPROM 
gelesen wird und über UART an den PC gesendet wird. Dort kommen aber nur 
Werte kleiner 64 an. Wenn im EEPROM 0xFF drinsteht, dann wird 63 an den 
PC gesendet. Steht im EEPROM an der Stelle ein Wert kleiner 63, dann 
wird der richtige Wert über UART gesendet!
Ein anderer Fehler in diesem Programm ist, dass eine LED mit einer 
ungefähren Frequenz von 1Hz mittels eines Delays in der Endlosschleife 
in der Main blinkt. Sende ich Daten über UART an den MC, dann blinkt die 
LED extrem langsamer (60sec für an und aus anstatt 1sec)???

Da ich mit dem STK500 programmiere habe ich dazu eine allgemeine Frage:
Wenn ihr einen Fehler im  Programm habt und nich wisst woran es liegen 
kann, wie geht ihr dann vor, um den Fehler zu finden?

Vielen Dank schonmal

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

prinzipiell sollte man sich nochmal den Code genau ansehen. Und nochmal 
das Funktionsprinzip ueberpruefen ob dieses auch wirklich korrekt 
umgesetzt wurde.
Erfahrung spielt beim Debuggen schon eine grosse Rolle, denn mit jedem 
Fehler den man findet, lernt man dazu.
Es gibt verschiedenen Fehler,die leichtesten sind die syntaktischen ;), 
das sind Fehler wo der Compiler meckert. Dann kommen die systematische, 
von den hast du 1 in deinem Programm(Fehler mit den Bits). Dass sind die 
wo der Compiler nicht mehr meckert, aber dafuer der Kunde :). Und dann 
kommen die ganz fiesen Fehler, dass sind dann die stochastischen, wo die 
systematik stimmt aber troztdem spinnt das Programm wegen den 
Interrupts. Passieren oft nur zufaellig und sind deswegen schwer zu 
finden. Davon hast du auch einen (deine LED) obwohl man den leicht 
findet. Das sind so die bekanntesten Fehlerklassen.
Am wichtigsten ist es immer den Code nochmal anschauen und ueberdenken 
was man da wirklich geschrieben hat. Dann auf die Variablen achten und 
vor allem die Array. (Schreibt man mehr daten in ein array als da hinein 
passen, dann schreibt der uC munter weiter im Speicher und ueberschreibt 
benachbarte Variablen im Speicher )

Fuer dein Problem mit dem UART kannst du schauen ob wirklich alle Bits 
deines Bytes uebergibts, oder ob nicht ein anderer Programmteil ein Teil 
des Bytes ueberschreibt. Denn 63 dez enspricht 00011111b (binaer), das 
bedeutet das deine obersten 3 bit von deinem Wert auf 0 gesetzt werden 
(durch ein AND irgendwo?, die Einstellung im UART?, ... )

Fuer dein Problem mit deiner LED, kann ich folgendes sagen. Da du sie in 
der Main- Schleife laufen laesst und die Zeit ueber eine Endlosschleife 
regelst, ,kann folgendes passieren. Dein Program in der "Main-Schleife" 
wird ausgefuehrt und ploetzlich moechte aber der UART ein Zeichen 
senden, dann hat der UART (ein Interrupt) Vorang (eine hoehere 
Prioritaet) vor deinem Program  und arbeitet sein Programmabschnitt(vom 
UART) ab. Wenn dieser nun sehr lang ist oder du dort auch noch 
Endlosschleifen einsetzt, dann arbeitet der Mikrocontroller die ganze 
Zeit am UART und zaehlt nicht mehr an der Endlosschleife im "main" 
weiter. Irgendwann ist er dann fertig mit dem UART und zaehlt nun noch 
zusaetzlich die Zeit deiner Endlosschleife ab. Aber halt, der 
Programmabschnitt vom UART Interrupt moechte nun nochmal senden ;).
So kann es leicht passieren das deine LED dann 1min braucht, statt 1s. 
Denn die Zeit deiner Endlosschleife in "main" und die mehrmalige Zeit 
vom dem "UART- Interrupt" (so oft er eben waerende der Endlosschleife 
senden moechte) addieren sich.

Hoffe es ist verstaendlich, wenn nicht weiterfragen.
daniel

Autor: Online Debugger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn im EEPROM 0xFF drinsteht, dann wird 63 an den
> PC gesendet. Steht im EEPROM an der Stelle ein Wert kleiner 63, dann
> wird der richtige Wert über UART gesendet!
du arbeitest irgendwo mit char, wo 'unsigned char' hin sollte.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Überprüfe mal, ob du nicht den 5Bit-Modus bei der UART eingestellt hast.

@ Online Debugger
'char' sollte eigentlich bis 127 gehen.

MfG Spess

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
korrektur zu meinem oberen Beitrag:

63 dez entspricht 00111111b (0x3F), es sind nur die obersten 2 Bit nicht 
korrekt.

daniel

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde das Programm in Einzelteile zerlegen und diese gezielt prüfen. 
Sicher, dass deine Datenquelle wirklich Zahlen > 63 erzeugt? Ich würde 
versuchen einen hart verdrahteten Wert zu übermitteln und alle nicht 
benötigten Programmteile auszublenden.

Wenn das dann immer noch nicht geht einfach die USART-Routine neu 
schreiben und wenn die funktioniert mit der alten vergleichen.

Wenn das Problem verschwindet liegt's an der Datenbeschaffung, für die 
uns hier noch ein paar Infos fehlen...

Viel Erfolg

Kai

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Überprüfe mal, ob du nicht den 5Bit-Modus bei der UART eingestellt hast.

6 Bit meintest du vermutlich :)
Wehe daran liegt's - na gut, kann ja auch versehentlich passieren.

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@bushobbyentwickler
Debuggen ist das Lösen eines Problems durch das Aufteilen in einzelne 
kleine Probleme (Teile und Herrsche).

Teil dein Problem in einzelne kleine Aufgaben auf:
1) Stell erst mal sicher, dass die serielle Schnitte funktioniert. Sende 
ein Zeichen vom PC zum AVR ändere die Bits (z.B. incrementieren, 
decrementieren, interiteren) und  schick das Zeichen zurück.
2) Wenn das geht, kommt das EEPROM dran....
3) Wenn das geht, ...

Alles gleichzeitig zum Laufen gekommen ist meines Wissens das letzte Mal 
bei Frankenstein (und das Ergebnis war nicht gut!).

Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten!

Zu dem Problem mit UART:
Ich habe mal probiert sonstwo in dem Programm einfach nur das Byte 0xFF 
rauszuschicken. Am PC kommt da nur '?' (0x3F) an.

Ich hab echt keine Ahnung woran es liegt...

Im ganze Programm schick ich hin und wieder Daten an den PC, allerdings 
nur kleine Werte (also nie über 63) deshalb fällt mir der Fehler jetzt 
erst auf...

Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier meine Funktionen, dies betrifft:
void UART_Init(void)
{
  DDRD = (1 << PD1) | (0 << PD0); 

  UCSRB |= (1 << RXCIE) | (0 << TXCIE) | (1 << RXEN) | (1 << TXEN);

  // Baudrate: 19200bps bei 8MHz
  UBRRL = 25;
  UBRRH = 0;
}


void UART_send_char(unsigned char data)
{
  while (!(UCSRA & (1<<UDRE)))
  {
    ;  // warten, bis UDR leer ist
  }
  UDR = data;
}

Sieht doch eigentlich gut aus oder?

Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab jetzt mal im HyperTerminal angeschaut was der MC scickt: y mit 
Doppelpunkt also 0xFF!!!!

Dann liegt der Fehler wohl an der Windows-Anwendung. Da verwende ich 
Visual Basic (2008) mit der integrierten COMport-Komponente. Dann wird 
da wohl irgendwo der Fehler liegen, obwohl eigentlich alles richtig 
eingestellt ist...

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht zeigt VB die nicht darstellbaren Zeichen (also 0xFF) nur 
einfach als '?' an.

Autor: John Go (johngo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich empfehle unbedingt einen richtigen Debugger zur Unterstützung der 
Fehlersuche. Ich weiß nicht, mit welchem Mikrocontroller du arbeitest, 
ich verwende z.B. den AVR Dragon für den Atmega168. Da kannst du dann 
den C-Sourcecode Zeile für Zeile durchsteppen, Variablen anschaun und 
ändern, und du kannst richtig "sehen" wohin das Programm läuft - 
wunderschön! Ohne Debugger ist es oft echt sehr sehr mühsam, es ist wie 
ein Tappen im Dunkeln und Raten, was das Programm wo vielleicht tut. 
Warum sich das Leben unnötig schwer machen, der Dragon kostet nicht die 
Welt!

Autor: dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Passt deine Baudrate wiklich ???

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bushobbyentwickler wrote:
>
> void UART_Init(void)
> {
>   DDRD = (1 << PD1) | (0 << PD0);
> 
>   UCSRB |= (1 << RXCIE) | (0 << TXCIE) | (1 << RXEN) | (1 << TXEN);
> }
> 
> 
>
> Sieht doch eigentlich gut aus oder?

eine 0 irgendwohin zu schieben ist absolut sinnlos, da es immer eine 0 
bleiben wird, und "irgendwas oder 0" immer "irgendwas" bleibt.

(logische) linksschiebeoperationen kann man sich auch wie eine 
multiplikation mit einer 2er-potenz vorstellen, also

umgekehrt "entspricht" eine rechtsschiebeoperation einer 
ganzzahldivision durch eine zweierpotenz.

zum thema uart:
besorg dir das programm "portmon" (afair von sysinternals), damit kannst 
du die komplette kommunikation über die serielle und parallele 
schnittstelle(n) aufzeichnen.
da du mit hyperterminal bereits "richtigere" daten empfangen hast als 
mit vb, check mal die baudraten- und formateinstellung der vb-komponente 
und rechne nochmal nach, ob der uC wirklich eine brauchbare baudrate 
erzeugt...

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel F. wrote:

> eine 0 irgendwohin zu schieben ist absolut sinnlos, da es immer eine 0
> bleiben wird, und "irgendwas oder 0" immer "irgendwas" bleibt.

Nicht "sinnlos" sondern "wirkungslos". Es ist hier durchaus sinnvoll, da 
es dokumentiert, dass beispielsweise der RX Interrupt ausgeschaltet 
bleibt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:

> Nicht "sinnlos" sondern "wirkungslos". Es ist hier durchaus sinnvoll, da
> es dokumentiert, dass beispielsweise der RX Interrupt ausgeschaltet
> bleibt.

Dann müsste man aber immer alle 8 Bits hinschreiben.

Außerdem ging es hier um eine »|=«-Operation, dann bleibt der
Rx-Interrupt trotzdem eingeschaltet, sofern er es vorher schon war.
In diesem Kontext also wirklich sinnlos.

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Daniel F.

1 x 2 = 4, das hat was ;-)

Das Schieben einer 0 ist zur Dokumentation sinnvoll
und kostet keine Rechenzeit, weil das ja der Compiler schon ausrechnet.


Großbuchstaben sind im Deutschen anerkannte Hilfsmittel zur 
Textdarstellung.
Sie verringern die Lesbarkeit eines Textes nicht im Mindesten.
Ähnlich wie z.B. auch Umlaute und Doppelkonsonanten.

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
'tschuldigung, hatte vorher 1 << 1 - da habe ich wohl vergessen, die 2 
in 4 zu ändern

aja, und das mit der Kleinschreibung ist wohl z.t. auch Schuld meiner 
Professoren - die schreiben auch alles klein ;-)

Autor: JensG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ bushobbyentwickler (Gast)
> Ich hab jetzt mal im HyperTerminal angeschaut was der MC scickt: y mit
> Doppelpunkt also 0xFF!!!!

Das ist ein allgemeines Problem, wobei ich mir immer noch nicht sicher 
bin, wie die Logik dahinter ist in manchen Windowskomponenten.
wie Du schon selbst schreibst, kommt im Terminal das 0xff als y mit 
Diaeresis  ÿ an, was also der Codierung entsprechend der 
Windows-Codepage 1252 entspricht. Eigentlich müsste das immer so sein, 
und wäre auch logisch. Allerdings scheint dies auch vom benutzten Font 
abzuhängen, ob dies dann richtig angezeigt wird, oder als Fragezeichen 
(ein beliebtes Ersetzungszeichen unter Windows, mit 0x3F codiert), oder 
in manchen Programmen gar als einfaches Kästchen (was nach reinem 
Anzeigeproblem ausschaut).
Beispiel: Datei mit hex werten ff 30 9f 39 3f 30 unter Windows
Problem bei mir (mit WinXP) scheint zumindest das 9f zu sein in einigen 
Programmen.
Wordpad (write) und notepad zeigen alles richtig an (ÿ0Ÿ9?0)
Der Lister im Total Commander zeigt dagegen ein Kästchen anstelle des 
großen Y mit Diaeresis an. Kopiere ich diesen verunstalteten String ins 
Notepad, wird's plötzlich wieder richtig angezeigt (was aber auch nichts 
generell sicherstellt). Scheinbar schießt der eingestellte Font hier 
quer, oder die vom Programm benutzten Runtime-Libs eincompilierter Code 
taugen an der Stelle nicht viel. Die VB Libs scheinen da also auch 
irgendwie ihr eigenes Ding zu drehen.
Wenn Du die Möglichkeit hast, die empfangenen Bytes erstmal als Hex 
anzuzeigen, dann kannst Du ja damit erstmal die empfangenen Daten 
checken.

Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das (0 << TXCIE) hab ich drin, weil ich zum Debuggen den TX-Interrupt 
ausgestellt habe, also kein Stress!!! ^^

Den Portmon werde ich mal ausprobieren. Wie gesagt: In Hyperterminal 
kommt das richtige Zeichen an, nur in meiner Visual Basic - Anwendung 
nicht.

Bei der Komponente ist Baudrate, Anzahl Daten- und Stopbits sowie 
Parität auch richtig eingestellt...

Stelle ich im MC und in der Anwendung eine andere Baudrate (z.B. 9600) 
ein, habe ich genau das gleiche Problem, dass die empfangenen Zeichen 
nur Werte von 0 bis 63 haben können!

0011 1111 = 63
-> sieht halt schon sehr danach aus, dass die letzten beiden Bits (LSB 
kommt in UART ja zuerst oder?) verdaddert werden...

Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[quote]Wordpad (write) und notepad zeigen alles richtig an (ÿ0Ÿ9?0)
Der Lister im Total Commander zeigt dagegen ein Kästchen anstelle des
großen Y mit Diaeresis an. Kopiere ich diesen verunstalteten String ins
Notepad, wird's plötzlich wieder richtig angezeigt (was aber auch nichts
generell sicherstellt). Scheinbar schießt der eingestellte Font hier
quer, oder die vom Programm benutzten Runtime-Libs eincompilierter Code
taugen an der Stelle nicht viel. Die VB Libs scheinen da also auch
irgendwie ihr eigenes Ding zu drehen.
Wenn Du die Möglichkeit hast, die empfangenen Bytes erstmal als Hex
anzuzeigen, dann kannst Du ja damit erstmal die empfangenen Daten
checken.[/quote]

Ich habe das betreffende Zeichen schonmal mit Str(Asc(...)) umgewandelt 
und in einer MsgBox anzeigen lassen. Und da steht dann der Dezimalwert 
63.

Aber ein interessanter Gedanke. Vielleicht entspricht in dem 
Zeichensatz, der von der Comport-Komponente verwendet wird das 
Fragezeichen '?' dem Wert 0xFF, und bei der Umwandlung mit Asc(...) wird 
nach dem dem ASCII-Wert des Zeichens (und nicht nach dem Wert im von der 
COM-Komponente verwendeten Zeichensatz) gesucht?!?

Autor: JensG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaube, 0xff entpricht in keinem Zeichensatz einem Fragezeichen (im 
Gegenteil, in den meisten Codepages ist dort sogar gar kein Zeichen oder 
ein Steuerzeichen). Aber vielfach wird da '?' einfach als 
Ersetzungszeichen verwendet von manchen Win-Komponenten (möglicherweise 
auch in VB), vermutlich einfach in der Annahme, daß das ohnehin kein 
gültiges Zeichen wäre (vielleicht aus historischen Gründen, wo noch 437 
und 850 intensiv genutzt wurden, wo 0xFF ein Sonderzeichen war)
VB enthält wohl immer noch solche Relikte ....

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google einfach mal nach OCCONSOLE
oder schau da vorbei
http://www.elektronikladen.de/occonsole.html

Das Teil ist super, läuft ohne Installation vom USB-Stick
und hat den Binär-Modus, wo ein FF als FF angezeigt wird.
Wird leider nicht mehr weiterentwickelt :(

Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Teil ist wirklich super!!!

Also der MC sendet 0xFF, dann liegt es 100%ig an der VB-Komponente.

Autor: bushobbyentwickler (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also hier mal ein Bild von den Einstellungen der SerialPort-Komponente.
Weiß jemand, was hier der Auslöser sein könnte, dass die ReadExisting 
63d zurückgibt obwohl 255d gesendet (und mit einem Terminal-Programm) 
empfangen wurde?

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt denn eine 62d an, wenn du 254d übermittelst? Nicht, dass die 63d 
gar nichts mit den übertragenen Bytes zu zun hat.

Autor: bushobbyentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab gestern die Lösung gefunden.

Wenn ich den InPuffer der VB-Komponente mit der Funktion ReadExisting 
auslese, enthält der zurückgegebene String nur Werte zwischen 0 und 63 
(wieso auch immer).

Lese ich den Puffer dagegen byteweise mit ReadByte aus, dann werden 
Werte von 0 bis 255 ausgegeben!

Es gibt auch noch eine Funktion ReadChar, die allerdings wie 
ReadExisting nur Werte von 0 bis 63 ausgibt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.