Hi, ürsprunglich vermutete ich das Problem woanders daher hier ein neuer Thread. Der Versuch den AVV (ATMega128 mit 16MHz) mit RS232 funktioniert nicht wie in dem Datenblatt angegebenen Baudraten. Bsp: Programm ----------- $baud1 = 9600 Open "COM2:" For Binary As #1 Print #1 , "Hello World" Close #1 End ----------- Funktioniert mit Windows Hyper Terminal wunderbar. Bei $baud1 = 19200 geht es auch Bei $baud1 = 4800 geht es auch Bei $baud1 = 2400 geht nichts Bei $baud1 = 1200 kommt Schrott Selbstverständlich habe ich die passenden Baudraten in Hyper-terminal eingegeben. Ich gehe auch nicht davon aus das es etwas mit der oft Diskutierten Genauigkeit auf sich hat, den im Compilierungsprotokoll mit $baud1 = 2400 steht: ---------------------- ... FLASH USED : 2 % BAUD : 9600 Baud XTAL : 16000000 Hz BAUD error : 0.16% BAUD1 : 2400 Baud BAUD1 error : 0.08% .... ----------------------- Interessant aber vielleicht nicht von Belang ist das wenn man bei den Compile Optins/Communications 2400 Baud bei 16 MHz einträgt erscheint "not possible". Übrigens bei allen Baud raten < 4800. Hat Bascom da einen internen Teiler falsch definiert oder was kann hier Abhilfe schaffen? Schönen abend noch Peter
Probier doch mal, das USART per Hand auf die gewünschte Baudrate einzustellen. Wenn du dann zu funktionsfähigen Ergebnissen kommst, dürftest du ein Bascom-Bug gefunden haben.
Hi, Der AVC wird mir einem externen Quartz getaktet. Aber wie kann ich das USART "manuell" einstellen??? Gruß Peter
über die Konfigurationsregister (direkt setzen). Vielleicht stellst Du beim Register suchen im Datenblatt auch fest, daß diese Baudrate nicht unterstützt wird.
>2400 Baud bei 16 MHz einträgt erscheint >"not possible". Übrigens bei allen Baud raten < 4800. Da hat er Recht, das ist nicht possierlich, äh möglich.:-) Das liegt nicht an Bascom, denn auch das kann den inneren Aufbau des AVR nicht ändern. ;-) MfG Paul
Paul Baumann wrote: >>2400 Baud bei 16 MHz einträgt erscheint >>"not possible". Übrigens bei allen Baud raten < 4800. > > Da hat er Recht, das ist nicht possierlich, äh möglich.:-) Doch, sollte gehen. 2400 Bd sogar mit 0 % Fehler bei gesetztem U2X, 4800 Bd mit -0,1 %. Wenn das nicht reicht...
Versuch's mal damit, das wird nur noch wackliger, weil nur noch die halbe Zeit zum Abtasten zur Verfügung steht. (Beschreibung zu UC2X im Datenblatt Mega 128) 2400 Baud=16 Mhz/(8*832)+1 UBRR=832 In UCSRA muß noch das Bit für UC2X gesetzt werden. Nicht alles, was theoretisch funktioniert, geht auch in Natura zuverlässig. MfG Paul
Danke für den Tip, ich als Dummer BASCOM Anwender bin nicht wirklich fit mit diesen direkten Registern. wenn ich es Richtig verstanden habe muss ich in Adresse $99 "01000000" (64 da LB) und in Adresse $98 "00000011" (768 da HB) schreiben Das sind dann die 832 für den Teiler. Right?? Gruß Peter
VIELEN DANK!! Scheint ein echter BASCOM Bug zu sein. Folgender Code: ------------------------- $baud1 = 9600 ... Open "COM2:" For Binary As #1 '++++++++++++++UBRR auf 416 setzen+++++ Out $0099 , &B10100000 'LB 128 + 32 Out $0098 , &B00000001 'HB 256 '+++++++++BAUDRATE ist jetzt 2400!!++++++++ Print #1 , "Hello World" Close #1 -------------------------------------- funktioniert. D.h. Die vom Compiler generierten Werte einfach manuelle überschreiben. Nochmals Dank & einen schönen Abend
Für Eure Mühe habe ich nachgeschaut... Compiliert mit $Baud = 2400 steht im UBRR Low Byte der richtige wert "10100000" im UBRR High Byte leider "00000000" statt "00000001" Compiliert mit $Baud = 9600 werden beide Register richtig beschrieben... So long Peter
Hi Sieht so aus, als ob BASCOM UBRRH intern nicht benutzt. Das würde auch die 'Aussage' 'not possible' erklären. MfG Spess
spess53 wrote: > Sieht so aus, als ob BASCOM UBRRH intern nicht benutzt. Das würde auch > die 'Aussage' 'not possible' erklären. Das wäre allerdings ein ziemlich übler Bug. Wäre wieder ein schöner Anlass für die BASCOM-Basher...
> Das wäre allerdings ein ziemlich übler Bug. Wäre wieder ein schöner > Anlass für die BASCOM-Basher... Hier braucht man nichts zu bashen, BASCOM hat doch schon ein Eigentor kassiert, das reicht.
Gast wrote: > Hier braucht man nichts zu bashen, BASCOM hat doch schon ein Eigentor > kassiert, das reicht. Eben, ein Eigentor ist meist Anlass zur offenen Schadenfreude...
Klaus wrote:
> Johannes M. -> Basic Hasser? -> ja
Nö. Ich selber bin absolut kein pauschaler BASCOM-Hasser.
Das darf man nicht so eng sehen. Und immer ruhig durch die Hose atmen.
...du denkst wohl es gaebe nur ein 16 MHz Quarz . Der Fehler liegt wohl in deiner unflexiblen Haltung bzw mangelnden Erfahrung...
> ...du denkst wohl es gaebe nur ein 16 MHz Quarz . > Der Fehler liegt wohl in deiner unflexiblen Haltung > bzw mangelnden Erfahrung... 1) Nein 2) versteh ich nicht 3) kann sein.
Kann den Code mangels angeschlossenem M128 nicht testen, weis aber nicht wo das Problem beim Options Dialog liegt, musst halt auf eine aktuelle Version updaten.
UBRRH gibt es nicht bei allen AVRs, daher wird CONFIG von BASCOM es nicht unterstützen. Im Übrigen sind die AVRs dermaßen unterschiedlich mit Hardwarefeatures ausgestattet, dass mit CONFIG ein Großteil der Features gar nicht unterstützen kann. Der größte Fehler im BASCOM-Konzept ist das ja Implementieren der CONFIG-Anweisung für Hardware, die sich im AVR befindet (Timer, ADC, U(S)ART, usw.). Dies hält die Nutzer davon ab, sich die Bit- und Byte-Namen der I/O-Register aus dem Datenblatt herauszusuchen und die Werte direkt zuzuweisen. Das hält sehr viele Benutzer sogar davon ab, überhaupt mal ins Datenblatt des verwendeten AVRs zu schaun. Nein, ich kritisiere nicht die CONFIG-Anweisung in Verbindung mit Softwaremodulen wie LCD-Treiber usw., da ist das schon sinnvoll. Aber so etwas wie CONFIG PORT, CONFIG TIMER, CONFIG ADC, CONFIG UART (oder wie immer das genannt wird) braucht die Welt nicht, das ist eher kontraproduktiv. Ich habe nichts gegen BASIC allgemein, aber mit BASCOM kann ich mich bei den knappen Ressourcen der AVRs beim besten Willen nicht anfreunden. Ein kleines schlankes Tiny-BASIC hätte mich aber vermutlich überzeugt, so mit den Möglichkeiten, oft gebrauchte Variablen in Registern zu halten, schnellen Interrupts (ohne sinnfreie Sicherung unbenutzter Register) und Verzicht auf viel unnötigen Ballest. Aber nun ist es eh' zu spät, nun werkele ich in ASM. Und das ist gut so! ...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.