ZitierenWie kommst Du darauf?Zitat von JoeM1978
@MagicWSmoke
Hab mir gerade deinen code genauer angeschaut ... das "rcvd_char = UDR" muss ich glaub ersetzen durch "rcvd_char = inkey()"
und
"Incr db_index" ... soweit ich mich erinner gibts kein "Incr (Var)" in Bascom. Da fall ich selber immerwieder drauf rein.
OK muss mich selber berichtigen... Incr (Var) ... gibt es doch... es war i++ was nicht geht.
JAAAA... Microchips kann man essen... aber der Geschmack ist furchtbar.
Wie kommst Du darauf?
OK. habs in der Bascom-hilfe dann letztendlich doch gefunden UDR ist das Data-Register vür UART.
Also lese ich damit direkt aus dem Register.
Was mich stutzig macht... mit "On Urxc Uart_get_char" im Header spuckt er mir ne fehlermeldung aus,
wenn ich serialin configurieren will...
liest er dann also jedes einzelne zeichen sofort über die isr aus ?
Dann ist also hier nix mit Buffer verwenden drinn wenn ich das recht sehe.
JAAAA... Microchips kann man essen... aber der Geschmack ist furchtbar.
Das würdest Du auch im Datenblatt finden.
Klar, verwendet ja auch den selben Interrupt.Was mich stutzig macht... mit "On Urxc Uart_get_char" im Header spuckt er mir ne fehlermeldung aus,
wenn ich serialin configurieren will...
Sobald ein Zeichen eintrifft, wird die ISR aufgerufen, das UDR gelesen und passend verarbeitet, gepuffert wird's in buff().liest er dann also jedes einzelne zeichen sofort über die isr aus ?
Dann ist also hier nix mit Buffer verwenden drinn wenn ich das recht sehe.
Das ist genauso eine gepufferte Empfangsroutine, wie sie Bascom per gepufferten Serialin aufbaut, nur eben darauf spezialisiert, einen bestimmten Datenblock zu empfangen.
ok... also ist das sozusagen wie der gepufferte Empfang... nur eben "manuell".
Dann muss ich aber nochmal was hinterfragen...
bei 9600baud, meinst da könnte es passieren, das während dieser "manuellen Bufferroutine" ein zweites Zeichen schon ankommt ?
Würde das in einer "warteschleife hängen oder einfach verworfen werden ?
JAAAA... Microchips kann man essen... aber der Geschmack ist furchtbar.
Ich würd' eher sagen eine andere Version des gepufferten Empfangs.
Keine Chancebei 9600baud, meinst da könnte es passieren, das während dieser "manuellen Bufferroutine" ein zweites Zeichen schon ankommt ?
9600 Baud sind 9600 Bits pro Sekunde, ein Zeichen sind mit Start- und Stopbit rund 10 Bits, also sind's rund 960 Zeichen pro Sekunde, das sind etwas mehr als 1 mS für ein Zeichen.
In dieser Zeit hat der µC ca. 8000 Takte zur Verfügung, meine gepufferte Routine braucht so ca. 140-200 Takte pro Aufruf.
Bei 400000 Baud würdest Du an Grenzen stoßen.
Ohne Handshake gehen Zeichen verloren, wenn der UART-Puffer voll ist und nichts mehr aufnehmen kann.Würde das in einer "warteschleife hängen oder einfach verworfen werden ?
joa... und da die routine eh sofort bei jedem zeichen aufgeht sollte das kein problem sein.
Jetzt muss ich nur aufpassen, das ich bei anderen ISR keine gravierenden Verzögerungen reinbekomm.
Denn dann könnte es doch seltsame auswirkungen haben, je nachdem welche ISR höherer priorität hat.
Betreffs deinem Code... die Array buff() und data_block() ...
Gibts eine schnellere möglichkeit ein Array zu löschen als eine For_Next-Schleife ?
Denn wenn ich unterschiedlich lange Messages Empfange wäre es schon störend, wenn der Inhalt der vorherigen noch drinn steht.
JAAAA... Microchips kann man essen... aber der Geschmack ist furchtbar.
Sobald eine ISR aktiv ist, sind alle anderen gesperrt, d.h. eine Endlosschleife in einer anderen ISR kann alles blockieren.
Eine Priorität gibt's nur dann, wenn mehrere Interruptanforderungen anstehen und Interrupts erlaubt sind, dann wird derjenige mit höchster Priorität zuerst ausgeführt.
Memcopy() mit entsprechender Option ist recht schnell. Aber das ist unnötig, stört doch nicht, wenn da was drinsteht. Du musst nur wissen, wie lange die Nutzdaten tatsächlich sind.Gibts eine schnellere möglichkeit ein Array zu löschen als eine For_Next-Schleife ?
Wenn Du hier die Länge in eine zusätzliche Variable kopierst, weißt Du das immer.
Code:tmp = memcopy(buff(1) , data_block(1) , db_index) data_block_len = db_index
Dann ist also innerhalb der ISR ein "Disable Interupts"... undEine Priorität gibt's nur dann, wenn mehrere Interruptanforderungen anstehen und Interrupts erlaubt sind, dann wird derjenige mit höchster Priorität zuerst ausgeführt.
ind der letzten Zeile "Enable Interupts" sowieso nutzlos, da das automatisch gesperrt ist.
Die aktuelle Datenblock-Länge zu speichern ist eine Möglichkeit. Stimmt.
In die Gegenrichtung... also Daten senden mach ich am einfachsten über?Print"{irgendwas}";
oder wäre es sinnvoll das ebenfalls über das Register zu schicken ?
Ich hab gelesen, das das UDR das Register ist für I/O ... also sprich für beide Richtungen.
Ist das Problematisch, wenn Während dem Senden daten empfangen werden ?
Das gibt doch dann nur durcheinander vermute ich mal.
JAAAA... Microchips kann man essen... aber der Geschmack ist furchtbar.
Man kann auch Interrupts in einer ISR extra erlauben, "nested interrupts", aber das ist nicht ungefährlich und hat 'ne Menge Tücken.
Print ist problemlos benutzbar, nur mit allem wie Input usw. würdest Du Probleme haben, weil sich die URXC sofort die Daten greift. Geht aber trotzdem, einfach den Interrupt verbieten.
Nein, ist kein Problem. Schreibt z.B. ein Print auf das UDR, so hat das keinen Einfluss auf daraus gelesene Werte, das wird wie zwei unterschiedliche Register unter einem Namen behandelt.
Berechtigungen
Lesezeichen