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?
Dann fehlt entweder die Definition von F_CPU oder sie ist falsch, d.h. entspricht nicht dem tatsächlichen Takt.
Ja, das war's super!!! DANKE!! War im makefile falsch eingetragen, hat aber bisher nicht weiter gestört, warum auch immer... :-/
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:
1 | |
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.
Gast
#1023762
>ber auch die ganzen _delay_xxxx() funktionen ..
Die benützt man ja auch nicht.. ;-)
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...
Gast
#1023836
>Ansichtssache, oder? Pass schon. Aber: >denn einem Anfänger empfehlen Lieber am Anfang richtig quälen, damit wirds danach richtig..
Gast
#1024052
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
Gast
#1024087
>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.
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.
Gast
#1024111
>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...
Matthias Lipinsky wrote: > Das wird dann gepollt. Aber ein delay(ms) ist mM grindsätzlich zu > vermeiden... Weil?
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.
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.
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.
Gast
#1024233
>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.
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
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
Hier mal durchklickern http://www.avr-praxis.de/forum/showthread.php?t=178 schau mal hier, das Paßfoto ist neu- der Mann alt..... ....-))
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.
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
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
Bitte melde dich an, um einen Beitrag zu schreiben.