www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Nur Halbe angegebenen Baudrate mit UART @ ATmega8


Autor: Anna-zaira Engeln (nanalisa)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich möchte einfachste Daten von meinem ATmega8 zum PC senden. Das klappt 
auch so weit mit angehängtem Programm über eine normale 
MAX232-Schaltung.

Was mir nun Stirnrunzeln verschafft, ist die Tatsache, dass ich zwar in 
der main.c eine Baudrate von 19200 angebe, im PC aber nur mit 9600 
empfangen kann, sonst kommt Schrott raus. Er scheint also tatsächlich 
mit 9600 zu senden, aber wieso!?

Das ist auch so bei anderen Übertragungsraten. Trage ich in der main.c 
9600 ein, muss ich im Terminal 4800 angeben und so weiter...

grübel

Jemand ne Idee?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann fehlt entweder die Definition von F_CPU oder sie ist falsch, d.h. 
entspricht nicht dem tatsächlichen Takt.

Autor: Anna-zaira Engeln (nanalisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das war's super!!! DANKE!!

War im makefile falsch eingetragen, hat aber bisher nicht weiter 
gestört, warum auch immer...

:-/

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anna-zaira Engeln wrote:

> War im makefile falsch eingetragen, hat aber bisher nicht weiter
> gestört, warum auch immer...

F_CPU wird gebraucht um die korrekte Baudrate per UBR einstellen zu 
können.

Siehe Code:
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden

Grundsätzlich ist ein korrekt eingestelltes F_CPU nicht zwingend von 
nöten, da es nur dort benötigt wird, wo man die Systemtaktung wissen 
muss. Das ist z.B. bei der Berechnung des UBR-Wertes der Fall. Aber auch 
die ganzen _delay_xxxx() funktionen benötigen ein korrektes F_CPU, um 
auch die gewünschten pausenzeiten liefern zu können.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ber auch die ganzen _delay_xxxx() funktionen ..

Die benützt man ja auch nicht.. ;-)

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Lipinsky wrote:
>>ber auch die ganzen _delay_xxxx() funktionen ..
> Die benützt man ja auch nicht.. ;-)

Ansichtssache, oder? Ich meine, was würdest du denn einem Anfänger 
empfehlen, der gerade seine ersten Gehversuche macht und eine LED 
blinken lassen möchte? Dem käme eine kompliziertere Timer-Lösung nicht 
gerade zur hilfe...

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ansichtssache, oder?
Pass schon. Aber:

>denn einem Anfänger empfehlen
Lieber am Anfang richtig quälen, damit wirds danach richtig..

Autor: Ralli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uih,

wie macht ihr denn die komplizierten Timerlösungen,
ohne den CPU-Takt zu kennen?

Nehme doch an, dass hier keine Klugschei... verbreitet wurden?

;-) Ralli

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nehme doch an, dass hier keine Klugschei... verbreitet wurden?

Nein. Der muss schon bekannt sein. Anders geht das nicht. Es war nur 
gemeint, dass delays bei "fortschrittlicheren" Programmierern verpöhnt 
sind.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Immer noch Quatsch. Verpönt sind manchmal sehr lange Delays im grossen 
Millisekundenbereich. Delays im Mikrosekundenbereich sind normal und oft 
nicht zu vermeiden, sind sogar in Interrupt-Routinen nicht immer 
vermeidbar.

Aber auch ein _delay_ms(500) hat seine Berechtigung, beispielsweise in 
der Initialisierung von irgendeinem Device, wenn das dafür nun einmal 
vorgeschrieben ist und das Programm sowieso nichts besseres vorhat.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Delays im Mikrosekundenbereich
Das ist ok.

>Aber auch ein _delay_ms(500) hat seine Berechtigung, beispielsweise in
>der Initialisierung von irgendeinem Device, wenn das dafür nun einmal
>vorgeschrieben ist und das Programm sowieso nichts besseres vorhat.
Das ist Unsinn. Da gibt es gewöhnlich ein Init_fertig-Bit oder sowas. 
Das wird dann gepollt. Aber ein delay(ms) ist mM grindsätzlich zu 
vermeiden...

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Lipinsky wrote:
> Das wird dann gepollt. Aber ein delay(ms) ist mM grindsätzlich zu
> vermeiden...
Weil?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn im Datasheet drin steht, dass man nach Powerup oder Reset 0,5s zu 
warten hat bevor man das Device mit Anfragen belästigt, dann steht im 
entsprechenden Intialisierungscode bei mir ebendies _delay_ms(500) drin. 
Andere Lösungen schaffen künstliche und unnütze Abhängigkeiten 
beispielsweise von einem Timer-Modul wenn das sonst in diesem Modul 
nirgends benötigt wird.

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt mir alles eher nach einem Überzeugungskrieg als um eine 
fachkundige Diskussion.

Beispielsweise muss allerdings ganz ehrlich sagen, daß mir _delay_xx() 
in Interruptroutinen aus meiner Überzeugung herraus äusserst zu wieder 
sind. Dennoch müssen sie nicht zwangsläufig der falsche Weg sein.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lässt sich nicht immer vermeiden, Wenn beispielsweise in einer 
Interrupt-Routine ein SPI-Device angesprochen wird und zwischen CS und 
dem Transfer 0,5µs Pause verlangt wird, dann ist ein entsprechendes 
Delay dort korrekt untergebracht und in der Dimension meist kein 
Beinbruch. Manche neigen dazu, hier statt dessen NOPs reinzuhängen - 
aber grad das ist eine böse Falle.

Aber natürlich will ich hier nicht einer Inflation von Delays das Wort 
reden, erst recht nicht solchen in Interrupt-Handlern. Die meisten 
solchen Delays in Anfänger-Code sind schlichtweg Unfug.

Ich bin nur etwas allergisch auf lippys Dogmatismus.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich bin nur etwas allergisch auf lippys Dogmatismus.

Das sollte eher als meine Überzeugung gemeint sein.
Aber so lässt sich das betrefflich erklären:
>>Die meisten solchen Delays in Anfänger-Code sind schlichtweg Unfug.

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niels,
laß die Berechnungsroutine für die Baudrate einfach weg.
Setzte 23 ein für 3,868 MHz (STK500) Board, 25 bei 4 MHz, dann gehts mit 
9k6 .
Jetzt kommts aber:
Das Include File muß m8515....heißen nicht nur 8515 sdonst erkennt er 
den
16 Bittigen Init String für die Serielle nicht.
UBBRH UBBRL umgekehrte Reihenfolge etc etc.

Im Manual vom ATMegaxxx steht auch drin, wie man URSEL Bit setzt.
Geht nur über Umwege.

Im 8-Bittigen UART Setup Modus sind die Baudraten halbiert bzw. 
verdoppelt. Kommt drauf an, wie man das sieht.



Gruß
von Gustav

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. wrote:

> Manche neigen dazu, hier statt dessen NOPs reinzuhängen -
> aber grad das ist eine böse Falle.
>

Warum?

Grüße
Björn

Autor: Karl B. (gustav)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal durchklickern


http://www.avr-praxis.de/forum/showthread.php?t=178

schau mal hier, das Paßfoto ist neu- der Mann alt.....


....-))

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Björn Wieck wrote:

>> Manche neigen dazu, hier statt dessen NOPs reinzuhängen -
>> aber grad das ist eine böse Falle.
>
> Warum?

_delay_us(0.5) ist immer mindestens eine halbe Mikrosekunde, egal ob der 
Controller mit 4MHZ oder mit 70MHz läuft.

Ich neige dazu, Treiber für Funkmodule, Sensoren etc. für irgendwelchen 
Bausteine, vor allem externe, möglichst vom Controller unabhängig d.h. 
leidlich portabel zu gestalten.

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. wrote:

> _delay_us(0.5) ist immer mindestens eine halbe Mikrosekunde, egal ob der
> Controller mit 4MHZ oder mit 70MHz läuft.

unter ASM ist das aber nicht egal meine ich.
Oder hast Du ein Macro dafür das die Umrechnung übernimmt?

Grüße
Björn

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Björn Wieck wrote:

> unter ASM ist das aber nicht egal meine ich.
> Oder hast Du ein Macro dafür das die Umrechnung übernimmt?

Selbstverständlich, wenn ich mal auf Anwendungsebene in Assembler 
arbeite, was nicht so häufig ist.

Die Delay-Routinen der avr-libc sind letztlich auch in Assembler, plus 
Umrechnung in C. Der Assembler wird zwar vielleicht keine 
Fliesskommarechnung mögen, aber ganzzahlig rechnen kann er. Weshalb ich 
meist auf die Möglichkeit verzichte, Delays wie 0.5 zu verwenden, und 
entweder dann _delay_us(1) reinschreibe, oder eine Variante 
_delay_ns(500) erfinde.

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.