Hallo Zusammen, wenn an einer Mikrocontrollerschaltung eine LED für Debugging-Zwecke vorhanden ist, kann man diese auch zur Datenübertragung verwenden. Oben ist eine einfache Schaltung für den Datenempfang gezeigt, die eine Gleichlichtunterdrückung erlaubt. Hier der Code für die Datenübertragung: sender - https://github.com/ChrisMicro/LedDataTransmission/blob/master/sender/signal.c empfänger - https://github.com/ChrisMicro/LedDataTransmission/blob/master/receiver/decoder.c Getestet wurde das Ganze mit einem Attiny13 als Sender und einem Atmega328p ( Arduino Uno ) als Empfänger und den Bauteilwerten R1=20K R2,R3=100K C1=50nF Die Datenrate liegt bei ca. 4000Baud. Im ersten Anlauf habe ich Wert auf die Übertragungssicherheit gelegt, deshalb ist das Ganze noch nicht auf Geschwindigkeit optimiert. Mit einer optimierten Empfangsschaltung und verbesserter Software könnte es aber auch mit bis zu 1MBit/s gehen.
Route_66 schrieb: > Wozu soll das Zeug gut sein? Steht doch da: "wenn an einer Mikrocontrollerschaltung eine LED für Debugging-Zwecke vorhanden ist, kann man diese auch zur Datenübertragung verwenden."
>Wozu soll das Zeug gut sein? Wenn Du als Bastler immer den Debugger oder einen seriellen Adapter an Deine Schaltung anschließen kannst, wirst Du das Verfahren eher nicht brauchen. Man könnte sich eher folgendes Szenario vorstellen: Nehmen wir an, Du bist bei einem Hersteller günstiger Kaffemaschinen angestellt und Du möchtest bei den Rückläufen Debug-Daten und den Fehlerzustand auslesen. Vielleicht möchtest Du auch wissen, wie oft die Maschine gelaufen ist und wie hoch die höchste Temperatur war. Dein Chef verbietet Dir aber, irgendwelche Hardware in die Kaffemaschine einzubauen, weil das Geld kostet. Dann kannst Du einfach die LED mit dem beschriebenen Verfahren ansteuern und die Informationen raus blinken lassen. Die Geschwindigkeit ist so hoch, dass die Kunden gar nicht sehen können, dass Informationen übertragen werden. Du musst einfach nur das Interface mit SFH300 den paar Widerstände und einem Arduino-Uno für 20 Euro bauen, und schon hast Du das Debug-Interface. Die Geschwindigkeit reicht sogar aus, um gleich den ganze Speicher raus schreiben zu lassen.
Hier gibt es den Thread zur Optimierung der Analogschaltung des Empfängers: Beitrag "schneller Lichtsensor mit Led ?"
Sehr nette Idee Chris! Darauf muss man erst mal kommen :-) Mit den Delay-Funktionen beim Senden kostet es aber etwas viel CPU-Zeit. Um die 4000 Baud reichen für das meiste ja auch schon aus. Der größte Vorteil ist wohl, dass man das Gerät nicht öffnen muss oder einen Stecker vorsehen muss um ein paar Debug-Infos zu bekommen.
> Sehr nette Idee Chris! Darauf muss man erst mal kommen :-) Danke, freut mich :-) > Mit den Delay-Funktionen beim Senden kostet es aber etwas viel CPU-Zeit. Eigentlich wollte ich die Senderoutine als State-Machine ausführen, dann könnte man sie in einen 8Khz Interrupt packen. Das belastet den Prozessor dann weniger. Oft hat man ja sowieso irgendwo einen zyklischen Timerinterrupt, in den man das Senden mit einhängen könnte. Ein 1KHz Interrupt würde noch für 500Bit/s reichen. Damit wäre die Prozessorlast noch geringer.
>Wiso kann man nicht eine UART-Ausgabe mit Standard-Baudrate verwenden?
1. Weil die Debug-LED nicht immer an der UART hängt
2. Weil die Baudrate für die Übertragung nicht immer genau genug ist (
siehe Attny und interner RC-Oscillator), mein Protocoll macht eine
Bitlängenmessung und stellt sich auf den Sender ein
3. Weil das UART Signal ohne besondere Maßnahmen nicht
gleichspannungsfrei ist ( dann läuft der Kondensator zur
Gleichlichtunterdrückung weg )
4. Mein Protokoll ist speziell für ungenaue Schaltschwellen des
Mikrocontroller-Digitaleingang gemacht.
Man könnte vielleicht auch die Uart verwenden, wenn man die
Empfangsschaltung anders auslegt und eine genaue Zeitbasis hat und eine
sehr gute optische Ankopplung zum Sender macht ( Fremdlicht abschirmen
).
Vor ein paar Jahren habe ich mal was ähnliches gemacht, allerdings mit einer IR-LED, der UART hat damit bis 2400 Baud gut funktioniert. PC-Seitig brauchte es nur wenige Bauteile und könnte man sicher noch optimieren. Es gibt auch andere als ATTiny, z.B. STM32 der hat genügend UARTS.
Datenübertragung und Programmierung mittels IR wird beim ASURO-Roboter verwendet. Dazu wird die UART verwendet und dieser Baustein: http://www.mikrocontroller.net/part/SFH5110 Die IR-LED muss mit 36kHz moduliert werden. Durch die Verwendung von IR mit der 36kHz Modulation hat man zwei Vorteile bezüglich der Störunterdrückung: 1. der IR-Filter unterdrückt sichtbares Licht 2. die Trägerfrequenz von 36kHz kann gefiltert werden Diesen Beitrag in der Codesammlung soll dazu dienen zu zeigen, wie man die in einer gegebenen Schaltung vorhandene Standard-LED zur Datenübertragung mit einer sehr einfachen Empfangsschaltung nutzen kann. Mich würde es freuen, wenn von euch jemand das Verfahren mal ausprobieren könnte um es ein wenig zu testen. Als Hardware kann man beliebige Mikrocontroller verwenden, oder wenn man gar nichts anderes hat, zwei Arduinos. Hast Du die IR-LED mit dem obigen Empfänger betrieben?
Es waren Standard Fototransistoren und IR LED's FSH320 und SFH421. Die Empfänger Schaltung hatte noch einen kleinen Mosfet als Verstärker und für sauberere Flanken. Und es waren Sender und Empfänger auf einer Platine, das Sende-Signal wurde beim Empfänger wieder heraus gefiltert, so dass das Sende Echo nicht am PC wieder an kam. Damit waren Firmware-Updates möglich ohne das Gerät auf zu schrauben, denn das ganze war eingebaut hinter Glas und es gab keine Möglichkeit für einen Stecker.
>Die Empfänger Schaltung hatte noch einen kleinen Mosfet als Verstärker >und für sauberere Flanken. Klingt interessant, vielleicht kannst Du Deine Schaltung offen legen ?
Marius S. (lupin) Benutzerseite >Mit den Delay-Funktionen beim Senden kostet es aber etwas viel CPU-Zeit. Du hast Recht, die Delay-Funktionen fressen die ganze Rechenzeit beim Senden, deshalb habe ich jetzt eine State-Machine realisiert: https://github.com/ChrisMicro/LedDataTransmission/blob/master/sender/senderSTM.c Die Funktion
1 | sendFrame_S(data,datalen) |
kann einfach in eine Interrupt-Routine gepackt werden. Die Daten sind übertragen, wenn die Funktion "FRAMEREADY" zurück gibt. Exemplarisch kann man die Funktion auch in einer "While"-Schleife aufrufen, dann verhält sie sich gleich wie die normale Sende-Funktion:
1 | do
|
2 | {
|
3 | delayMicroseconds(BITTIME_US/2); |
4 | }while( sendFrame_S( data, datalen) != FRAMEREADY ); |
Am delayMicroseconds kann man sehen, mit welcher Rate die Interrupt-Routine aufgerufen werden muss: mit der Hälfte der Bitzeit.
Hi chris, Sowas wollte ich auch schon immer mal umsetzen. Bis jetzt war nur der leidensdruck immer zu gering. Ich mache öfter was mit Kapazitiven Tastern. Dabei ergibt sich beim debuggen öfter das Problem, das sich die Werte massiv verändern, wenn keine galvanische Trennung zum Debugger mehr da ist. Wenn ich was neues habe um es einzusetzen, melde ich mich bei dir! Vielen Dank, Kille
>öfter das Problem, das sich die Werte massiv verändern, wenn >keine galvanische Trennung zum Debugger mehr da ist. Dass die galvanische Trennung der optischen Datenübertragung zum Hauptvorteil dieses Threads werden könnte, ist mir noch gar nicht aufgefallen. >Wenn ich was neues habe um es einzusetzen, melde ich mich bei dir! Mein Ziel war, das der Code einigermaßem selbsterklärend ist. Es freut mich aber, dass Du es eventuell gebrauchen kannst. Deine Fragen könnten helfen, die Beschreibung zu verbessern. Mittlerweile kann als Empfänger auch eine rote ultrahelle LED benutzt werden, wenn eine Datenrate von ca. 1500 Bits ausreicht und eine kräftige ultrahelle LED als Sender dient. Damit reduziert sich der Aufwand für den Empfänger auf 1 Bauteil.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.