Hey Leute, ich hab ein buch vom Franzis Verlag,in dem Code-Beispiele für
uC in Assembler stehen. Unter anderem eins,wo der uC Daten seriell mit
9600 Baud versendet. Der Code sieht wie folgt aus:
1
;RS232, Empfangen und Senden mit 9600 Baud bei 1,2 MHz
2
3
.include "tn13def.inc"
4
5
.def A = r16
6
.def Delay = r17
7
.def Count = r18
8
9
;Port B
10
.equ senden = 1
11
12
13
14
rjmp Anfang
15
Anfang:
16
sbi ddrb,senden ;Datenrichtung
17
18
19
20
ldi A,65
21
rcall WrCOM
22
23
24
25
Ende:
26
rjmp Ende
27
28
29
WrCOM: sbi portb,senden ;Senden
30
ldi Delay,38
31
32
D4: dec Delay
33
brne D4
34
ldi Count,8
35
L2: sbrc A,0
36
rjmp OFF
37
rjmp ON
38
ON : sbi portb,senden
39
rjmp BitD
40
OFF: cbi portb,senden
41
rjmp BitD
42
BitD: ldi Delay,38
43
D5: dec Delay
44
brne D5
45
lsr A
46
dec Count
47
brne L2
48
cbi PORTB,senden
49
ldi Delay,38
50
D6: dec Delay
51
brne D6
52
ret
In dem obigen Beispiel sendet der uC einfach nur ein A. Jetzt brauche
ich aber für eine andere Schaltung einen uC der nicht mit 9600 sondern
mit 19200 Baud sendet. Jetzt sitzte ich seit Tagen an den paar Code
Schnipseln und versuch sie zu verstehen,aber blicke einfach nicht durch.
Ich mein,der uC arbeitet ja mit 1,2Mhz das heißt der macht alle 0,833
mikrosekunden nen Takt. Und bei 9600 Baud brauch ich ja alle 104
mirkosekunden ein Signal . Aber wie hängt das jetzt im obigen Code
zusammen?
Ich steh echt vor ner Wand und bin um jeden Tip wirklich dankbar.
Wie gesagt, ich möchte einfach den obigen Code so umschreiben das der uC
mit 19200 Baud anstelle der momentanen 9600 sendet. Vielen Dank schonmal
im vorraus, Mfg GreenArrow
Hey, Green Arrow,
die 19200 Baud sind das doppelte von den 9600......
Soweit ich den Code-Schnipsel verstanden habe, ist es ein Soft-Uart.
Also Doppelte Baudrate (19200) bedeutet delay bzw. Bitdauer von 9600
Baud halbieren. Versuche doch mal statt "ldi Delay,38" "ldi Delay,19"
Falls es Probleme gibt auch mal 18 bzw 20 ausprobieren........
Schönen Sonntag
Miraculix
Hallo,
Du hast aber das Prinzip einer solchen seriellen Übertragung verstanden,
also den Aufbau mit Startbit, Datenbits, Stopbit?
Dann solltest Du den Codeschnipsel auch nachvollziehen können und z.B.
mal passend kommentieren.
Spätestens dann solltest Du es herausgefunden haben und auch die
Probleme, die prinzipiell in dieser Art Programmierung stecken, erkannt
haben.
Ich benutze sowas als Debug-UART, kann man machen, man sollte aber
wissen, was man tut.
Deshalb gibt es von mir jetzt keine konkrete Antwort mit Programmzeile
sowieso ändern usw.
Gruß aus Berlin
Michael
Der code selber braucht auch noch etwas zeit. Das Delay wird also auf
etwas weniger als die Hälfte zu reduzieren sein. Grob geschätzt von 38
auf etwa 16 oder 17. Kann man entweder von Hand aufsummieren wie schnell
das geht, oder man nutzt den Simulator von AVRStudio.
Hey Miraculix, erstmal vielen Dank für die schnelle Antwort. Das mit dem
halbieren war auch mein ertser Gedanke. Aber irgendwie klappt das nicht
richtig. Ich überprüfe die Ergebnisse immer indem ich den uC an den PC
anschließe ihm strom gebe und dann über einen Serial-Port Sniffer
auslese was ankommt.
Wenn ich den Wert von 38 auf 19 setze kommt zwar was mit 19200 am PC
an,aber leider sind das nicht die Werte die ankommen sollen. Wenn ich
das Register A so lade das der text "text" seriel verschickt werden
soll. Klappt das mit dem Wert 38 bei 9600 tadelos. Wenn ich aber dann
die 38 auf 19 halbiere kommt nicht mehr "text" an sondern "ÿÿÿ". Wenn
ich aber den Wert auf 18 oder 20 setzte kommt gar nix mehr an. Also
müsste ich ja mit 19 schon verdammt nah dran sein,nur leider noch nicht
nah genug :-(
Mfg GreenArrow
Hab grade den Beitrag von Ulrich gelesen und siehe da, mit 17 klappt es
tadelos!!! Hätt ich das mal ehr Probiert! Vielen Dank!!!
@ Michael U.
Das Prinzip hab ich schon weitestgehend verstanden,doch leider blick ich
trotzdem nicht ganz durch. Ich bin Anfänger was das Programmieren von uC
angeht und habe mir ja Extra das Franzis Lernpaket gekauft,doch leider
lässt einen das auch manchmal im Regen stehen. Naja, ich werde versuchen
mir so viel es geht anzueignen und dann werde ich hoffentlich bald mehr
verstehen!
Nochmals vielen Dank!!! GreenArrow
Hallo green arrow,
daß der Wert 17 von Ulrich besser paßt ist recht einfach zu erklären,
(hätte selber besser länger nachgedacht).
Der µP benötigt für das Setzen bzw. Löschen des TxD-Signals immer gleich
lang.
Die Signaldauer, d.h. die Zeit bis zum nächsten "Umschalten" oder nenne
es die Bit-Dauer wird über das "Delay" gemacht. Somit muß, weil die
"Umschaltzeit gleich bleibt" das Delay bei verdoppelter Baudrate etwas
kürzer sein als nur die Hälfte. Deshalb 17 statt 19.
Und noch ein Tipp:
Wenn der ATmega mit internem RC-Oszillator läuft, kann es schon mal
vorkommen daß der z.B. durch veränderte Versorgungsspannung und oder
Temperatur bedingt "davon läuft", damit meine ich daß der Oszillator
nicht mehr mit 1,2 MHz läuft und logischerweise auch die Baudrate etwas
"daneben" liegt, sofern der Empfänger tolerant genug ist, merkt es
keiner...
(Hatte vor einiger Zeit das Problem gehabt, war aber mit automatischer
Baudrateerkennung zu lösen)
Nochmal schönen Sonntag
Miraculix
P.S. Es gibt keinen blöden Fragen (keine Regel ohne Ausnahme) sondern
nur dumme Antworten.......
Thread beobachten
Seitenaufteilung abschalten