Problem mit Programm für AVR

Arne Rossius schrieb:

Hast du die Zeitspanne ausreichend dimensioniert. Die Uebertragung eines Bits dauert bei 9600baud ueber 1000 CLK (10MHz). Da kann man sich bei Warteschleifen verschaetzen.

Meinst du ^ mit Dach? Hat dieses nicht einen hoeheren ASCII Wert?

servus thomas

Hallo,

so kompliziert?

Alternativen:

- Benutze einen Teil des Bytes als Befehlscode und einen Teil als

aber besser als warten ist es bestimmt

einen Fehler zu suchen, lohnt IMHO den Aufwand nicht. Falls Du

/Jan-Hinnerk

Ich kenne den anderen Part natürlich nicht. Im allgemeinen ist es aber nicht einfach langsam genug zu sein. Ich denke da nur an alte PC-Spiele, die auf schnelleren Rechnern nicht mehr benutzbar waren ;-(

Ist klar. Falls das für Deine Anwendung ein Problem ist entfällt die Lösung.

Wo ist das Problem mit einem Byte mehr? Langsamer dürfte es eigentlich kaum werden. Die zusätzliche Übertragungszeit liegt auf jeden Fall unter Deiner Wartezeit. Falls Dein Sender einen FIFO hat dauert es da auch nicht länger. Außerdem sparst Du Dir das Senden eines zweiten Bytes für das Lesen, sparst hier also Zeit und Aufwand.

Das könnte dann so aussehen:

0000 0000 -> Eingänge lesen 1000 xxxx -> Ausgänge 0-3 auf xxxx setzen 1100 xxxx -> Ausgänge 4-7 auf xxxx setzen

Falls es für Dich wichtig ist, daß die Ausgänge gleichzeitg geändert werden, kannst Du auch die Werte vom ersten Schreiben zwischenspeichern.

Und Du hast noch jede Menge Möglichkeiten das Protokol zu erweitern. z.B.

1000 xxxx -> out = xxxx 1001 xxxx -> out = out OR xxxx 1010 xxxx -> out = out AND (NOT xxxx) 1011 xxxx -> out = out XOR xxxx

Ich meinte natürlich count ;-)

/Jan-Hinnerk

Ich habe keine Ahnung, wo man sowas lernen kann. Auf jeden Fall sollte man nicht von C-Compilern generierten Code als Vorbild nehmen. IMHO haben die AppNotes von Atmel leider oft ähnliche Qualität.

Da helfen wohl nur Erfahrung und gesunder Menschenverstand.

Mal ein paar kurze Tipps zu einem Teil Deines Codes:

Nie in Kommentaren die Befehle übersetzen. Wenn der Leser nicht weiß, daß "inc" inkrementiert oder das "count" ein Counter ist, kann er den Code sowieso nicht verstehen.

Entweder den Sinn erklären oder (falls es zu offensichtlich ist) lieber ganz weglassen. Im Gegensatz zu Hochsprachen passiert oft weniger pro Zeile, d.h. man braucht auch weniger Kommentare.

"ok" ist ein sehr schlecht gewählter Name. Er gibt keine nützliche Information und führt sogar ein bißchen in die Irre: Es ist nicht "nicht OK", wenn der Sprung nicht ausgeführt wird ;-)

IMHO ist der "cpse"-Befehl meistens eher verwirrend. Er spart hier auf jeden Fall keine Zeit.

Kommentare sind hier gut (IMHO ist Pseudo-Code eine tolle Sache)

Nun das ganze in etwas aufgeräumter Form:

main_loop: tst outp ; if something to output: breq dont_output out PORTB,last ; output it! clr outp ; blah dont_output: ldi last,0 ; blah

ldi count,200 ; wait approx. 200*256*3 cycles clr temp ; that is ??? ms @ ??? MHz wait: dec temp brne wait dec count brne wait rjmp main_loop

Ich benutze gerne Leerzeilen, um Funktionsblöcke voneinander zu trennen.

Ich hoffe, daß bringt Dich ein bißchen weiter.

/Jan-Hinnerk

Lade Dir von Atmel die Befehlsbeschreibung runter (nicht so leicht zu finden):

Den Rest per Mail (wird doch langsam etwas off-topic)

/Jan-Hinnerk