hi,
es geht mal wider um die kommunikation meines atmega8 mit meinem pc.
problem: der aufbau stimmt soweit, es werden zeichen nurückgesendet.
aaaber: es wird nicht jedes zeichen zurück geschickt.
wenn ich ein 'a' tippe, soll ein a zurückgeschickt werden, bei 'd' der
wert des debug-registers ausgegeben werden
folgendes meine ich im hyperterminal beobachtet zu haben:
wenn ich hyperterminal oder die verbindung frisch öffne, dann wird das
erste zeichen fast nie 'beantwortet'. dann läufts einige zeit ganz gut,
wenn ich nicht zu schnell tippe. wenn ich dann aber die buchstaben
schneller nacheinander tippe, verschluckt er öfters welche.
ich meine, dass es etwas mit der routine zur verarbeitung der eingaben
zu tun hat und mit dem rxc-interrupt, ich selbst finde aber nicht den
fehler.
ich habe nur wirklich das nötigste aus dem quelltext gelöscht, damit
keine fehlerquelle übersehen wird
vielen dank an alle, die sich das ansehen.
> cp statn, stato ; wenn sich seit letzter messung nichts getan hat> brne start_capt>> sbrs flags, 0
Wieso 0?
Das müsste doch Bit 1 sein, dass dir den Empfang eines Zeichens
anzeigt.
Müsste das nicht eigentlich
sbrC flags, 1
heissen?
@ karl heinz
müsst eigentlich so schon stimmen. ich setze das bit mit
sbr flags, 1
wobei sbr aber nicht die nummer des bits als zweiten parameter nimmt,
sondern ein bitmuster, welches bit er setzen soll. d.h wenn ich sbr
flags, 0x01 und sbrs flags, 0 aufrufe, verarbeite ich information aus
dem gleichen bit.
zu srbs und sbrC:
wenn das nullte bit in flags gesetz ist, möchte ich das wieder löschen
(cbr flags, 1) und dann in co_sw eintreten (rcall com_sw). sollte also
imho auch stimmen
hab ich einen befehl mal wieder nicht durchschaut? oder was? :-o
Du hast recht. Da komm ich immer durcheinander, wann man eine
Maskie angiebt und wann eine Bitnummer :-) Muss immer nachschauen.
Dann seh ich auch nicht wo das Problem liegen würde.
Hi, du hast die Baudrate mit '.equ UBRRVAL = CLOCK/(BAUD*16)-1'
berechnet.
Probier's mal mit '.equ UBRRVAL = CLOCK/(BAUD*16L)-1' (die 16 als long),
sonst wird die Baudrate falsch berechnet.
schau doch mal nach dem Max232; ich hatte mal ein ähnliches Problem,
weil einer der Kondensatoren nicht richtig angeschlossen war; Dein
Problem sieht so aus, als wenn dem MAX zwischendurch die Puste ausgeht
...
Gruss, Ingo.
nein, der Kondensator an V+ muß mit der anderen Seite an GND. Die
anderen unbenutzten Eingänge des MAX232 solltest Du fest definieren;
damit der sich nix einfangen kann.
Gruss, Ingo.
> Die> anderen unbenutzten Eingänge des MAX232 solltest Du fest definieren;> damit der sich nix einfangen kann.
Das ist nicht nötig. Der Chip hat eingebaute Pullups auf der TTL- und
Pulldowns auf der RS232-Seite.
so. ich hoffe, ich habe das jetzt gelöst. folgendes hab ich gemacht:
nachdem ingo (DANKE @ ingo) mich darauf gebracht hatte, dass es nicht
unbedingt ein software problem sein muss. habe ich einfach den atmega8
mal aus seiner fassung genommen und die pins für den µC am max232
überbrückt.
und siehe da: wenn ich die zeichen langsam eingebe kommen sie häufiger
zurück, als wenn ich sie schnell eingebe
=> es war schon mal klar, dass es ein hardware problem ist.
wo suchen? na dort wo es am offensichtlichsten ist. an den ausgängen des
max232 auf der rs232-seite hatte ich nämlich eine selbstgebaute
kabelpeitsche hängen (bestehend aus einer d-sub 9 buchse und einem rs232
-> usb konverter, was bei meinen anfänglichen tests auch ganz gut
funktionierte)
also den koverter von der peitsche geknipst und siehe da: jetzt kommt
wirklich jedes zeichen zurück :-)
hoffentlich wars das :)
