Forum: Mikrocontroller und Digitale Elektronik Frage zu UART AVR Code

Falk B. schrieb:
> Bei 9600 Baud und 16 MHz CPU-Takt, dauert ein Zeichen mit
> 10 Bit stolze 1,042ms, das sind 16.666 CPU-Takte.

wow das ist viel.

wie kann man denn
delays überspringen?
Irgendwie klappt das nicht mit den breakpoints.
Sonst hätte ich die einfach übergangen.
D.h. der Debugger bleibt einfach bei _delay_ms(50) hängen..

1

#define F_CPU 8000000UL

2

#include <avr/io.h>

3

#include <util/delay.h>

4

5

int main(void)

6

{

7

        DDRB |= (1<<DDB1);

8

//PORTB=0x00;

9

    while (1) 

10

    {

11

        PORTB |= (1<<PORTB1);

12

        _delay_ms(50);

13

        PORTB &= ~ (1<<PORTB1);

14

        _delay_ms(50);

15

    }

16

}

Danke..

Falk B. schrieb:
> Dann probier es noch mal und setz die Breakpoints auf die
> Portzuweisungen.

dann kommt die Fehlermeldung, dass das Setzen nicht funktioniert.
Der Breakpoint wird dann einfach nicht gesetzt und auf das delay gesetzt 
:D

Klaus S. schrieb:
> Zum Lernen im Simulator benutzt man einfach eine eigene delay-Routine,
> die im echten Betrieb die passende Libraryroutine aufruft, im Debugmodus
> aber zurückkehrt, ohne etwas zu machen, oder eine Schleife ausführt, die
> dann einfach einen Zähler hochzählt.

Habe ich mir auch schon gedacht.
Aber es kam mir etwas umständlich vor.

Wie macht man das denn dann ?
Also ich könnte jetzt irgendwas zusammenschreiben.
Aber es gibt sicherlich eine bewährte Schreibweise dafür.
Wonach sollte ich googlen?

Danke

avro schrieb:
> dann kommt die Fehlermeldung, dass das Setzen nicht funktioniert.

Kann es sein, dass du mit einer hohen Optimierungsstufe compiliert hast?

Ich benutze normalerweise -O1, damit kommt der Debugger meistens klar. 
Ansonsten weiche ich auf -Og oder notfalls gar auf -O0 aus. _delay_ms() 
funktioniert mit -O0 allerdings nicht richtig.

Klaus S. schrieb:
> Gar nicht. Nur Hirn einschalten.

Wollte nur fragen, ob es eine Lösung gibt, um möglichst keinen Code bei 
der Simulation zu ändern.

Falk B. schrieb:
> Läuft problemlos, auch mit Optimierung -Os, siehe Anhang.

Habe meine den aktuellen Stand im Anhang.

Klaus S. schrieb:
> void my_delay(int nrofmilliseconds)
>  { while (nrofmilliseconds > 0) {nrofmilliseconds--;}
> /*Simulatorbetrieb*/
>    // _delay_ms(nrofmilliseconds); /*Arbeitsbetrieb*/
>  }

Danke sehr :)

Wenn ich die Breakpoints auf die Portausgaben setze und dann auf "Start 
Debugging" klicke werden die Breakpoints wie auf dem Bild verschoben. Es 
erscheint dazu noch die Fehlermeldung.

Ich benutze den Simulator2 mit Device ATmega328p

Der Simulator läuft auf jeden Fall viel langsamer als ein echter 
Mikrocontroller. Deswegen führt kein Weg umhin, delays in 
Größenordnungen von Sekunden durch etwas anderes zu ersetzen.

Dazu bieten sich Makros an:

1

#ifndef DEBUG

2

    _delay_ms(1000);

3

#endif

In dem Dialog "Custom compiler options", der in 
Beitrag "Re: Frage zu UART AVR Code" gezeigt wurde, 
kannst du dann das Makro definieren:

-DDEBUG

Wenn das Makro definiert ist, wird der Delay Aufruf ausgelassen (ifndef 
bedeutet "if not defined"). Mehr dazu auf 
https://wr.informatik.uni-hamburg.de/_media/teaching/sommersemester_2013/cgk-13_stabe_preprocessor_ausarbeitung.pdf

Ok.
Aber man sieht bei dem Code nicht mehr den  gelben Pfeil.
Nur wenn man den Dissembler anschaut kann man den Assembler-Code 
mitverfolgen.
Ist das normal?
Außerdem musste ich -O0 einstellen..

1

#define F_CPU 8000000UL

2

#include <avr/io.h>

3

#include <util/delay.h>

4

#define DEBUG 

5

#ifdef DEBUG

6

7

#define _delay_ms(x) 1

8

#endif

9

10

int main(void)

11

{

12

        DDRB |= (1<<DDB1);

13

//PORTB=0x00;

14

    while (1) 

15

    {

16

        PORTB |= (1<<PORTB1);

17

        _delay_ms(50);

18

        PORTB &= ~ (1<<PORTB1);

19

        _delay_ms(50);

20

    }

21

}

Kann es sei, dass du einen neueren Compiler als WinAvr2010 (avr-gcc 
4.3.3) verwendest? Ich frage, weil der Simulator/Debugger mit neueren 
Versionen öfter Probleme hatte, bis hin zum Absturz.

Wie simuliert Ihr UART normalerweise?

Oder simuliert ihr/man das gar nicht und testet das einfach direkt am 
Controller?

Wahrscheinlich sollte ich das ganze mal in Assembler schreiben um ein 
besseres Gefühl dafür zu bekommen worum es hier eigentlich geht...

Steve van de Grens schrieb:
> Gar nicht. Dafür gibt es In-Circuit Debugger, Logic Analyzer und
> Log-Meldungen.

danke sehr :)

Warum simuliert man das nicht?

kann ja sein, dass man so in manchen Fällen Zeit spart wenn man testet.

avro schrieb:
> Warum simuliert man das nicht?

Weil der Simulator die Gegenstelle mit der dein µC Kommuniziert nicht 
simulieren kann.

avro schrieb:
> kann ja sein, dass man so in manchen Fällen Zeit spart wenn man testet.

Schau Dir mal die "Stimuli" im Pdf zum AVR-Simulator an. Mit Stimuli 
kannst Du per Datei Register schreiben, lesen und loggen.

https://www.microchip.com/content/dam/mchp/documents/parked-documents/AVR-Simulator-UserGuide-DS50003042A.pdf

Für den Fall dass Dir Foren noch nicht geläufig sind: Man kann sich den 
Schubs in die richtige Richtung holen, dafür sind sie nützlich.
Und halt zum sozialen Austausch, als Wissensquelle sind sie eher vier 
minus.

Das innewohnende Problem ist, dass viele Teilnehmer tatkräftig ihr 
Unwissen verbreiten. Manchmal gezielt, aber meist weil sie's nicht 
besser wissen, jedoch mitreden wollen.

Du als Hilfesuchender müsstest bereits vorher das Wissen haben, das Dir 
zum Zeitpunk Deiner Frage noch fehlt, um die ganzen Falschinformationen 
von den Nutzinformationen auseinander zu halten.

Ein Ei vs. Henne Problem :D

https://www.microchip.com/content/dam/mchp/documents/parked-documents/AVR-Simulator-UserGuide-DS50003042A.pdf

Werde ich mir mal anschauen.
Es sieht danach aus als wäre es möglich Register zu manipulieren.
Um gezielte Tests z.B. für UART durchzuführen, müsste man jedoch genau 
wissen worauf es ankommt.

Der File Stimulator ist interessant.

Dafür müsste ich mir Beispiele anschauen.

Stefan F. schrieb:
> Weil der Simulator die Gegenstelle mit der dein µC Kommuniziert nicht
> simulieren kann.

Warum?
Eingehende Daten könnten doch digital verarbeitet werden.
Meiner Meinung nach müsste ein digitales Software-Modell dazu in der 
Lage sein,eingehende UART Nachrichten zu verarbeiten.

https://stackoverflow.com/questions/25912799/atmel-simulating-uart-comm

" In this simulator you simply can add a c/c++-testprogram which runs on 
the host in the native host fashion and connect a simulated uart to the 
simulator which runs your avr program"

 "Soft I2C"
Beitrag "Soft I2C Master"
Alleine auf einem uC ist doch dann eine solche Simulation/ Verarbeitung 
von Kommunikation per Software möglich.


Oder was meintest du?

Danke :)

Steve van de Grens schrieb:
> Bevor ich hunderte Stunden in die Entwicklung von so einem
> Modell stecke, Debugge ich mein Programm lieber direkt in der echten
> Hardware.

ja das denke ich auch, würde ich auch so machen.

Aber in manchen Fällen kann man einfachere Tests schreiben, die Zeit 
sparen können.