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.
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.
LedLightDetectorCircuit.png
(2,9 KB)
