Archiv verlassen und diese Seite im Standarddesign anzeigen : [gelöst] Einfache IR-Kommunikation für den RP6
radbruch
22.07.2007, 12:33
Hallo
Da mich das Kabelgewurschtel nervt, suche ich nach einer einfachen Möglichkeit, vorerst nur Daten mit IR vom RP6 zum PC zu senden. Später auch zurück, aber immer schön einen Schritt nach dem anderen. Ziel ist dann eine Erweiterung für die Lib, aber das wird wohl noch etwas dauern. Hier mein erster kleiner Versuch in dieser Richtung:
// Sendet einzelne Zeichen mit 2400 Baud über die IR-Dioden.
// Das ist noch eine frühe Beta-Version zur allgemeinen Erheiterung ;)
// Leider funktioniert das so bei mir nur im Ultranahbereich.
// (Empfänger liegt auf der Diode!). Um die nervige Nabelschnur
// loszuwerden muss ich wohl noch ein bisschen tüfteln. mic 22.7.07
#include "RP6RobotBaseLib.h"
#define BAUD_2400 2400 //IR speed - 2400 Baud
//#define UBRR_BAUD_2400 ((F_CPU/(16*BAUD_2400))-1) // ergibt einen Fehler?
#define UBRR_BAUD_2400 (((F_CPU/16)/BAUD_2400)-1)
uint8_t i;
void IRwriteChar(uint8_t zeichen)
{
UBRRH = UBRR_BAUD_2400 >> 8; // Setup UART: Baudrate ist 2400
UBRRL = (uint8_t) UBRR_BAUD_2400;
cli(); // Bitte nicht stören!
PORTD &= ~IRCOMM; // IR-LEDs D3+D4 ausschalten
if (UCSRA & (1<<TXC)) UCSRA=1<<TXC; // Flag löschen falls gesetzt
while (!(UCSRA & (1<<UDRE))); // Warten bis Register leer (mit cli()!)
UDR = (uint8_t)zeichen; // Zeichen reinschreiben
while (!(UCSRA & (1<<TXC))) // Solange noch nicht alle Bits
{ // rausgeschoben sind, erkenntlich
statusLEDs.LED2=1; // an LED2, lauschen wir, was an
if ((PIND & (1<<PD1)) && 1) // TX rausgeht und steuern damit
{
statusLEDs.LED1=0; // die LED1 und
PORTD &= ~IRCOMM; // die IR-LEDs D3+D4 ;)
}
else
{
statusLEDs.LED1=1;
PORTD ^= IRCOMM;
}
updateStatusLEDs();
}
sei(); // Enable Global Interrupts // wir haben fertig
sleep(10);
// ACHTUNG! TXC-Flag schreiben bedeutet löschen!
// Und zwar mit = weil so ohne Wirkung auf andere Flags
// Normales Setzen mit | würde andere Flags mitlöschen!
UCSRA=1<<TXC;
statusLEDs.LED2=0; // und das zeigen wir auch
updateStatusLEDs();
UBRRH = UBRR_BAUD_LOW >> 8; // Loaderterminalbaudrate setzen
UBRRL = (uint8_t) UBRR_BAUD_LOW; // Setup UART: Baudrate is Low Speed
}
int main(void)
{
initRobotBase();
setLEDs(0b111111);
mSleep(100);
setLEDs(0);
powerON();
while(true)
{
for (i='a'; i<='z'; i++)
{
IRwriteChar(i);
}
IRwriteChar('\n');
IRwriteChar('\r');
mSleep(200);
}
return 0;
}
Das ist aber noch eine Vorbetaversion und soll nur zeigen, wie es im Ansatz funktionieren könnte.
Gruß
mic
[Edit]
Nun ist mir auch klar, warum das nicht richtig funktioniert: Es fehlt noch die 36kHz-Trägerfrequenz!
[Edit2]
Thread-Titel geändert
radbruch
30.07.2007, 10:49
Hallo
Nachdem ich mich nun etwas durch das Datenblatt und die Lib gekämpft habe, erscheint die Lösung unglaubwürdig einfach:
// Die Funktion IRwriteChar() sendet ein Zeichen über die IRCOMM-LEDs zum PC.
// Die Baudrate wird zum Senden auf 2400 Baud eingestellt. Das Zeichen wird dann
// mit dem UART ausgegeben. Dabei "lauscht" die Funktion am TX-Pin des ATMega32
// und schaltet den IRCOMM-Pin. Da die TX-Pegel invertiert sind, werden bei TX==1
// die IRCOMM-LEDs ausgeschaltet, bei TX==0 wird ein mit 36kHz moduliertes Signal an
// denn LEDs erzeugt. Da der Timer2 schon im CTC-Mode läuft und weil der IRCOMM-Pin
// zufällig auch der OC2-Pin ist, wird dazu einfach der Timer2-Ausgang aktiviert und
// auf togglen eingestellt.
// Mit dem asuro/yeti IR-Transceiver können die gesendeten Zeichen nun über
// mehrere Meter Entfernung empfangen werden. mic 30.7.07
#include "RP6RobotBaseLib.h"
#define BAUD_2400 2400 //IR speed - 2400 Baud
#define UBRR_BAUD_2400 (((F_CPU/16)/BAUD_2400)-1)
uint8_t i; // Hilfsvariable
void IRwriteChar(uint8_t zeichen)
{
PORTD &= ~IRCOMM; // IRCOMM-LEDs ausschalten
UBRRH = UBRR_BAUD_2400 >> 8; // Baudrate auf 2400 setzen
UBRRL = (uint8_t) UBRR_BAUD_2400;
UDR = (uint8_t)zeichen; // Zeichen ins Senderegister des UARTs
while (!(UCSRA & (1<<TXC))) // Solange das Schieberegister nicht leer
{
if (PIND & TX) // ist, lauschen wir am TX-Pin
{
TCCR2 &= ~(1 << COM20); // und schalten OC2 und IRCOMM-LEDs aus
PORTD &= ~IRCOMM;
}
else
{
TCCR2 |= (1 << COM20); // oder togglen mit 36kHz ;)
}
}
UCSRA=1<<TXC; // TXC-Flag setzen bedeutet löschen!!!
PORTD &= ~IRCOMM; // IRCOMM-LEDs ausschalten
UBRRH = UBRR_BAUD_LOW >> 8; // RP6Loaderbaudrate setzen
UBRRL = (uint8_t) UBRR_BAUD_LOW;
}
int main(void)
{
initRobotBase();
setLEDs(0b111111);
mSleep(100);
setLEDs(0);
powerON();
while(true) // endlos das Alphabet senden
{
for (i='a'; i<='z'; i++)
{
IRwriteChar(i);
}
IRwriteChar('\n');
IRwriteChar('\r');
mSleep(200);
}
return 0;
}
Das könnte man nun z.b. in der writeChar()-Funktion einbinden und dann wahlweise normal oder Infrarot senden. Vorteil wäre, dass man dann alle writexxx()-Funktionen der Standart-Library verwenden könnte. Aber das muss ich noch überdenken, denn im Moment ist es noch eine blockierende Funktion die vielleicht das Task-System stören könnte.
Der nächste Schritt ist nun aber das Lesen und damit die bidirektionale IR-Kommunikation. Wenn alles fertig ist, können die Roboter auch untereinander funken. Oder der RP6 mit dem asuro oder was weis ich noch alles.
Gruß
mic
radbruch
06.08.2007, 22:42
Hallo
Jetzt habe ich erstmal ein blockierendes Lesen fertig:
#include "RP6RobotBaseLib.h"
#define BAUD_2400 2400 //IR speed - 2400 Baud
#define UBRR_BAUD_2400 (((F_CPU/16)/BAUD_2400)-1)
uint8_t i; // Hilfsvariable
void IRwriteChar(uint8_t zeichen)
{
UBRRH = UBRR_BAUD_2400 >> 8; // Baudrate auf 2400 setzen
UBRRL = (uint8_t) UBRR_BAUD_2400;
if (UCSRA & (1<<TXC)) UCSRA=1<<TXC; // TXC-Flag löschen falls gesetzt
UDR = (uint8_t)zeichen; // Zeichen ins Senderegister des UARTs
while (!(UCSRA & (1<<TXC))) // Solange das Schieberegister nicht leer ist,
{
if (PIND & TX) // lauschen wir am TX-Pin
{
TCCR2 &= ~(1 << COM20); // und schalten OC2 und IRCOMM-LEDs aus
PORTD &= ~IRCOMM;
}
else
{
TCCR2 |= (1 << COM20); // oder toggeln mit 36kHz ;)
}
}
UCSRA=1<<TXC; // TXC-Flag setzen bedeutet löschen!!!
TCCR2 &= ~(1 << COM20); // toggeln ausschalten
PORTD &= ~IRCOMM; // IRCOMM-LEDs ausschalten
UBRRH = UBRR_BAUD_LOW >> 8; // RP6Loaderbaudrate setzen
UBRRL = (uint8_t) UBRR_BAUD_LOW;
}
uint8_t IRreadChar(void)
{
uint8_t zeichen=0; // Speicher für die einzelnen Bits
uint8_t bitnr; // Nummer des aktuellen Bits
uint8_t bitwert[8]={1,2,4,8,16,32,64,128};// Die Werte der Bits (lsb kommt zuerst)
/*
Baudrate Bitlänge
300 Baud 3,33 ms
2400 Baud 417 µs // sleep(4) dauert etwa 400us
9600 Baud 104 µs // mit sleep(3) beim Startbit wird der
38400 Baud 26,04 µs // Fehler kompensiert ;)
*/
while(PINB & ACS); // Blockierend auf Startbit warten
sleep(3); // Lesemoment ca. auf Mitte Startbit
for (bitnr=0; bitnr<8; bitnr++) // Die Bits in einer Schleife einlesen
{
sleep(4); // ca. in der Mitte des Bits lesen
if (PINB & ACS) zeichen+=bitwert[bitnr];
}
sleep(8); // es kommen noch 2 Stopbits
return zeichen;
}
int main(void)
{
initRobotBase();
setLEDs(0b111111);
powerON();
mSleep(300);
setLEDs(0);
while(1)
{
i=IRreadChar(); // Zeichen einlesen
IRwriteChar(i+1); // und als ascii+1 zurücksenden
}
return 0;
}
Eine Timeout-Erweiterung und eine vernüftige Einbindung in die Library wären nun die nächsten Schritte.
Beim Senden wird nun zuerst das TXC-Flag gelöscht, falls es gesetzt war. Nach dem Senden wird nun auch das Toggeln ausgeschaltet, dann sollten die IRCOMM-LEDs auch ausbleiben.
Gruß
mic
[Edit]
Nicht sehr elegant, aber es funktioniert nun auch mit Timeout:
#include "RP6RobotBaseLib.h"
#define BAUD_2400 2400 //IR speed - 2400 Baud
#define UBRR_BAUD_2400 (((F_CPU/16)/BAUD_2400)-1)
uint8_t i; // Hilfsvariable
void IRwriteChar(uint8_t zeichen)
{
UBRRH = UBRR_BAUD_2400 >> 8; // Baudrate auf 2400 setzen
UBRRL = (uint8_t) UBRR_BAUD_2400;
if (UCSRA & (1<<TXC)) UCSRA=1<<TXC; // TXC-Flag löschen falls gesetzt
UDR = (uint8_t)zeichen; // Zeichen ins Senderegister des UARTs
while (!(UCSRA & (1<<TXC))) // Solange das Schieberegister nicht leer ist,
{
if (PIND & TX) // lauschen wir am TX-Pin
{
TCCR2 &= ~(1 << COM20); // und schalten OC2 und IRCOMM-LEDs aus
PORTD &= ~IRCOMM;
}
else
{
TCCR2 |= (1 << COM20); // oder toggeln mit 36kHz ;)
}
}
UCSRA=1<<TXC; // TXC-Flag setzen bedeutet löschen!!!
TCCR2 &= ~(1 << COM20); // toggeln ausschalten
PORTD &= ~IRCOMM; // IRCOMM-LEDs ausschalten
UBRRH = UBRR_BAUD_LOW >> 8; // RP6Loaderbaudrate setzen
UBRRL = (uint8_t) UBRR_BAUD_LOW;
}
uint8_t IRreadChar(uint16_t timeout)
{
uint8_t zeichen=0; // Speicher für die einzelnen Bits
uint8_t bitnr; // Nummer des aktuellen Bits
uint8_t bitwert[8]={1,2,4,8,16,32,64,128};// Die Werte der Bits (lsb kommt zuerst)
/*
Baudrate Bitlänge
300 Baud 3,33 ms
2400 Baud 417 µs // sleep(4) dauert etwa 400us
9600 Baud 104 µs // mit sleep(3) beim Startbit wird der
38400 Baud 26,04 µs // Fehler kompensiert ;)
*/
if (timeout)
{
startStopwatch1(); // Stopuhr starten
setStopwatch1(0); // vorsichtshalber zurücksetzen
while(PINB & ACS)
if (getStopwatch1() >= timeout) // bei Timeout Zeichen null zurückgeben
return 0;
}
else while(PINB & ACS); // Blockierend auf Startbit warten
sleep(3); // Lesemoment ca. auf Mitte Startbit
for (bitnr=0; bitnr<8; bitnr++) // Die Bits in einer Schleife einlesen
{
sleep(4); // ca. in der Mitte des Bits lesen
if (PINB & ACS) zeichen+=bitwert[bitnr];
}
sleep(10); // es kommen noch 2 Stopbits
return zeichen;
}
int main(void)
{
initRobotBase();
setLEDs(0b111111);
powerON();
mSleep(300);
setLEDs(0);
while(1)
{
i=IRreadChar(500);
if (i) IRwriteChar(i+1);
}
return 0;
}
radbruch
08.08.2007, 12:06
Hallo
Ich habe jetzt meine Library upgedatet (Stand 7.8.07) und seltsamerweise erhalte ich jetzt einen Fehler beim Kompilieren. Ursache ist folgender Hinweis in der Datei RP6RobotBase.h:
/************************************************** ***************************/
// IRCOMM pin:
// ### WARNING!
//
// #define IRCOMM (1 << PIND7) // Output
//
// ### DO NOT USE THIS PIN BY YOURSELF!
// ONLY LET THE INTERRUPT ROUTINE OF THE LIBRARY
// CONTROL THIS PIN!
// The IR LEDs must be controlled by a modulated
// signal with minimal 5kHz or higher
// modulation frequency!
// Nominal modulation frequency is 36kHz!
// YOU MAY DAMAGE THE IRCOMM IF YOU USE IT
// IN ANY OTHER WAY!
// Only use this macro to make sure IRCOMM is
// turned off:
#define IRCOMM_OFF() PORTD &= ~(1 << PIND7);
// NEVER try to control IRCOMM by yourself if you
// do not know what you are doing!
// Always use Timer based modulation control!
/************************************************** ***************************/
Hintergrund ist der Widerstand R6 vor den IR-Dioden D3/D4. Der hat nur 10 Ohm und wird im Dauerbetrieb extrem heis. Möglicherweise kann der RP6 durch falsche Ansteuerung des IRCOMM-Pins dauerhaft Schaden nehmen.
Das wusste ich bei den ersten Versionen meiner Funktionen noch nicht und habe deshalb ziemlich unvorsichtig den IR-Pin manipuliert. Die aktuelle Version moduliert die LEDs mit den geforderten 36kHz und schaltet nach dem Senden die LEDs auch aus. Trotzdem muss ich leider darauf hinweisen, dass die Verwendung meiner Funktionen auf euer eigenes Risiko geschied!
Ich werde das Projekt jetzt erstmal auf Eis legen und abwarten, ob irgendwelche negativen Berichte über die Verwendung gepostet werden. Da ich selbst die Funktionen seit Tagen ohne Schaden am RP6 verwende, biete ich euch auf euer eigenes Risiko noch den Quellcode meiner letzten Version an.
Mit den im Quellcode beschriebenen Änderungen in RP6uart.h und RP6uart.c sind nun noch die Funktionen void IRuartON(void) und void IRuartOFF(void) dazugekommen. Damit schaltet man die Baudraten und die writeChar()-Umleitung ein oder aus. (Ausführliche Doku für Interessierte im Quellcode)
Gruß
mic
Hi radbruch,
das ist eine tolle Idee!
Hab's auch versucht. Leider ohne Erfolg bisher... :-(
Ich verwende ein Notebook (ohne ser. Schnittstelle) und habe 3USB Anschluesse. An einem steckt der RP6-USB Programmieradapter. Das klappt auch gut (sonst waere der Rest obsolet *g*).
An einem zweiten USB-Port habe ich den ASURO-USB-IR Adapter stecken. Der wird wahlweise auch vom RP6Loader erkannt. Beides gleichzeitig scheint nicht zu funktionieren (auch mit einem anderen Terminalprogramm z.B. Hyperterminal nicht).
Ohne den RP6Loader mit Adapter sehe ich aber die zweiten (Kontroll-) Ausgaben (tee) nicht.
Im Hyperterminal oder im RP6Loader sehe ich nur kurz eine Reihe von nicht darstellbaren Zeichen. Das koennten die vom RP6 uebertragenen Zeichen sein.
Wie ist denn das genaue Setup? Welches Terminalprogramm (z.B. HTerm?) mit welchen Einstellungen brauche ich?
Kann ich parallel den RP6Loader mit Adapter und den ASURO-USB-IR_Adapter verwenden? (Fuer erste Tests waere das hilfreich.)
Hast Du vielleicht noch ein paar Tipps? :-)
mfg
KaY
radbruch
12.09.2007, 16:46
Hallo
Ich verwende das Win-Hyperterminal. Die Parameter sind 2400,8,1,none. Die "Kontrollausgaben" im RP6-Loader-Terminal dürften nicht lesbar sein weil die Baudrate zu klein ist, man sieht aber, ob überhaupt was vom RP6 gesendet wird. Das ist eigentlich ein ungewollter Effekt, lässt sich aber nicht vermeiden, weil beim IR-Senden der USART den Datenstrom erzeugt und die Funktion IRwrite() dabei nur am TXD-Pin lauscht. Beim Loader-Terminal ist die Baudrate fest eingestellt und viel zu hoch für IR-Kommunikation. Die Bitlänge ist dann so kurz, dass man die 36KHz nicht mehr draufmodulieren kann. Deshalb läuft die IR-Kommunikation nicht mit Loader-Terminal.
Kannst du mit dem asuro-Transceifer die Daten sehen, die mit dem Win-Terminal gesendet werden (Weisblatttest)? Senden die IR-LEDs des RP6 (Digicam-Test)? Welche IRwrite()-Version verwendest du? Die Version vom 6.8.07 schaltet bei jedem zu sendenden Zeichen die Baudrate auf 2400 und wieder zurück, bei der Version vom 8.8.07 muss man selbst mit IRuartON() auf 2400 Baud umschalten und mit IRuartOFF() wieder die Loaderbaudrate einstellen. Zum Testen würde ich die Version vom 6.8.07 empfehlen.
Gruß
mic
roboterheld
12.09.2007, 21:51
eine einfache lösung habe ich :
1 atmega8 mit max , tsop und irdiode für den pc. am notebook(pc) habe ich ein serialadapter.
kann gut mit dem rp6 über ir kommunizieren.
Ein neuer Treiber wirkt Wunder ... :-)
Nun tut's wie's soll. Danke fuer eure Hilfe!
carlitoco
08.09.2009, 16:48
ich werde das mal mit nem thinkpad t43 und linux versuchen
gruss
carlitoco
08.09.2009, 16:54
ach vermaledeit ! Das Risiko von dem du (radbruch) oben sprichst, dass der widerstand heiss wird und ev. schaden nimmt möchte ich nur ungern eingehen.
Was heisst das konkret? Der RP6 kann nicht dauerhaft mit einem anderen IR-fähigen Gerät kommunzieren?
danke & gruss
radbruch
08.09.2009, 17:34
Hallo
Nicht nur der Widerstand, auch die restliche Elektronik könnte beschädigt werden. Allerdings hat es mein RP6 schadlos überlebt (auch die ersten Tests ohne Trägerfrequenz) und solange die 36kHz anliegen wird vermutlich auch nichts zerstört werden. Weil ich, wie eigentlich immer, zuviele gleichzeitige Baustellen offen habe, wurde dieses Projekt von mir bisher nicht weitergeführt. Nachbau ist zwar erwünscht, geschied aber (wie immer!) auf eigene Gefahr.
Mein ThinkPad (ein T23) hat nur eine IRDA-Schnittstelle, damit funktioniert es NICHT! Man benötigt einen IR-Transceiver wie er z.B. beim asuro verwendet wird.
btw ist das "Verfallsdatum" dieses Threads inzwischen wohl deutlich überschritten ;)
Gruß
mic
Das hab ich irgendwo in irgendeinem anderen Thread auch schon ausführlich erläutert... find ich aber grad nicht mehr ;)
Wenn mit 36kHz moduliert wird kann das natürlich beliebig lange laufen.
Die RP6Lib macht ja genau das - die könnte man auch dementsprechend abändern das statt RC5 zu senden am UART Pin gelauscht wird (s. ISR (TIMER2_COMP_vect) alles in der if(ircomm_pulse) Bedingung und den beiden else zweigen muss geändert werden)...
Das hätte auch den Vorteil das das ACS weiterhin verwendbar bleibt, da hier auch direkt die synchronisation damit erledigt wird und der Timer2 ja sowieso auf jeden Fall für das ACS benötigt wird.
Wenn Du also sicherstellen kannst, dass die IR LEDs stets nur ein moduliertes Signal erhalten ists kein Problem.
Die IR Dioden sind für den IMPULS Betrieb gedacht. Man kann die für eine gewisse Zeit mit sehr hohem Strom betreiben um die Reichweite zu steigern.
Wenn Du aber den IRCOMM Pin dauerhaft anschaltest dann nehmen die IR Dioden nach kurzer Zeit Schaden. Der Widerstand ist auch auf Pulsbetrieb ausgelegt weil die IR Dioden das auf Dauer sowieso nicht anders überstehen würden.
MfG,
SlyD
TigerWolf
10.04.2012, 19:04
Hallo,
ist das eigentlich hier der aktuellste Thread zum Thema "IR Kommunikation? In anderen Threads wird oft auf diesen hier verlinkt ...
Ich versuche gerade herauszufinden, wie der Code funktioniert. Wenn ich das richtig sehe, wird beim Lesen das Timing durch aktives Warten mit "sleep(4);" erledigt. Dazu 2 Fragen:
(1) Wenn man mit anderen Baudraten arbeiten will, muss man hier den Wert ändern (z.B. "sleep(8);" für 1200 Baud), richtig?
(2) Mich wundert, das hier die Interrupts nicht ausgeschaltet werden. "sleep(4);" könnte doch von einem Interrupt unterbrochen werden, und dann stimmt das Timing nicht mehr oder?!? Andererseits lassen ja die folgenden Antworten darauf schließen, dass die Methode funktioniert.
Kann mich hier wer mal schlau machen?
mfg
TigerWolf
Hallo Tigerwolf,
guck dir mal das hier an : http://www.rn-wissen.de/index.php/RP6_-_Morse-Code
da ist wohl einiges an Wissen um die IR Kommunikation mit eingeflossen.
Gruß Rolf
radbruch
10.04.2012, 21:53
Hallo
Es ist der aktuellste Thread, weil es der einzige ist.
Vielleicht die Antwort auf die zweite Frage zuerst: Wenn man die Interrupts ausschaltet, wird die ISR für sleep() nicht mehr aufgerufen.
In der Lib für die Base findet man folgende ISR: Externer INT0 und INT1 für die Encoder, INT2 fürs ACS, Timer1_comp als Zeitgeber für sleep() und die Stopwatches, Power-on-Warnung und die Motorregelung. Letztlich noch die Timer2_comp für die ACS-Impulse. Da die IR-Kommunikation blockierend ist, können wir das ACS als Störquelle ausschließen. Wenn dann noch die Antrieb stören sollten, könnte man die auch kurz anhalten. Eine kleine Verzögerung bei den sleep()s stört aber nicht wirklich:
Zu 1: Die Bitdauer bei 2400 Baud ist 417µs, sleep(1) dauert 100ms. Ähnlich wie bei Himmel und Hölle haben wir zehn Felder hintereinander (Start-, 8 Daten und Stopbit) mit je 417 Länge und wir müssen so durchspringen, dass wir jedes Feld genau einmal treffen. Einzige Einschränkung: Wir haben nur 100er als Sprungweite. Beim ersten Sprung mit 300 trifft man das dritte Viertel (im Abstand von 300 von der Vorderkante) des Startbits und alle weiteren mit 400 treffen dann die einzelnen Datenbits. Da die Feldlänge aber nicht unseren Sprungweiten entspricht, landen wir mit jedem Sprung um den Unterschied (hier 17) kürzer. Das summiert sich dann auf 11*17 und ist weniger als die 300 die wir zu Beginn noch Abstand zum Feldanfang hatten. Verwirrt? Ich auch.
Bei 1200 Baud beträgt die Bitdauer 834µs. Durch einfaches Verdoppeln der Werte würde sich dann sleep(6) als Startverzögerung anbieten und sleep(8) zum Weiterspringen. Da man mit sleep(8) aber auch noch mit 34µs reserve auf das Startbit treffen würde, wäre sleep(7) als Startverzögerung wohl optimal.
Um nun nochmals auf die Interrupts zurückzukommen: Da die sleep()s eh nicht genau in die Feldlänge passen, stört eine kurze Verlängerung der Verzögerung durch die Ausführung einer ISR nicht.
Gruß
mic
Der Trick mit Sleep() ist schon alt:
https://www.roboternetz.de/community/threads/45403-NIBObee-Erweiterungen/page4?p=444597#post444597
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.