Hallo Zusammen, da sich an sehr vielen MC-Schaltungen eine Testled befindet, habe ich mir überlegt, diese für Debuggingzwecke zur Datenübertragung zu verwenden. Das ist besonders dann sehr nützliche, wenn man an keine Hardwarepin herankommen kann. Nach ersten Abschätzungen komme ich mit der Schaltung auf eine Datenrate von 2-10 kBit/s. Die Codierung des Signals soll möglichst gleichspannungsfrei damit der Kondensator auf die Mittenspannung läuft. Im Anhang meine Schaltung.
Angehängte Dateien:
-
LedDebugSchematic.jpg
7,4 KB
10kHz ist ganz schön viel Flimmer an einem Pin eines µCs, der eigentlich was anderes macht. Die Idee finde ich aber witzig. Weder Relevanz noch Realisierbarkeit kann ich wirklich einschätzen. dranbleiben.
>10kHz ist ganz schön viel Flimmer an einem Pin eines µCs, der eigentlich >was anderes macht. Im Moment mach ich die Test gerade mit einer blockierenden Funktion. Damit lassen sich die 10kHz locker erreichen. Man könnte sich vorstellen, dass der MC nach einem harten Software-Fehler in den Debug Mode wechselt und seine Information zyklisch ausgibt. Dann wäre das mit der blockierenden Funktion keine Problem. Ansonsten fällt mir noch ein Interrupt mit ca. 4kHz ein, der das Protokoll fährt. Dann käme man noch auf ca. 1kB/s. Das reicht für Debug-Informationen eventuell aus. >Die Idee finde ich aber witzig. Danke :-)
rava schrieb: > Realisierbarkeit kann ich wirklich einschätzen. Das geht ganz gut, wir haben das im Betrieb aber versteckt und nicht über lange Zeit. rgds
rava schrieb: > Die Idee finde ich aber witzig. Ja witzig ist das. Wenn ich aber an die In Circuit Programmierung herankomme um das Programm für das 'LED debugging' aufzuspielen, wozu brauche ich dann noch die LED ? Die Idee wäre aber gut geeignet um in gewollt abgeschotteten Systemen Daten zu 'leaken'. Das Netzwerkdevice das der Kunde zunagelt bis zum Rand überträgt seine Daten über die Power LED. Hmm, ich kleb hier gleich mal alle Power LEDs ab ...
>Wenn ich aber an die In Circuit Programmierung herankomme um das >Programm für das 'LED debugging' aufzuspielen, wozu brauche ich dann >noch die LED ? Der LED-Debugger muss als Standard schon in die Software eingebaut sein. Durch die schnelle Datenübertragung sieht man mit bloßem Auge nicht, dass Informationen herausgepulst werden. Hey, da fällt mir gerade ein: Das könnte man ja sogar mit Autorücklichtern machen ;-)
Angehängte Dateien:
In der jetzigen Konfiguration braucht das Signal etwa 8ms Einlaufzeit. R1=20K R2=100K R3=100K C=50nF
chris_ schrieb: > Hey, da fällt mir gerade ein: Das könnte man ja sogar mit > Autorücklichtern machen ;-) Ist schon in der Mache http://www.golem.de/news/optische-datenuebertragung-schnelles-wlan-soll-aus-der-lampe-kommen-1210-94903.html 73
Angehängte Dateien:
-
ledDebugFSK-Signal.jpg
23 KB
> Autorücklichtern machen ;-) >Ist schon in der Mache >http://www.golem.de/news/optische-datenuebertragun... Das klingt sehr interessant. Es ist aber nicht explizit die Automobilindustrie erwähnt. Werden dafür normale LEDs verwendet? Ich könnte mir vorstellen, dass man für die hohen Datenraten spezielle LEDs braucht. Im Anhang das Signalbild meines Versuchsaufbaus mit uralt 20mA LED und der Fototransistorschaltung von oben mit SFH300. Mein jetziges Programm verwendet FSK als Modulationsverfahren. Bit=0 ==> Schwingung mit T=400us Bit=1 ==> Schwingung mit T=200us Damit werden im Schnitt 4KBit/s erreicht. Interessant wäre die maximal erzielbare Übertragungsrate aus Sicht der Strecke. ( Entschuldigung für die schlechte Bildqualität, ich habe hier am Standort leider nur das alte Oszi und nur die Laptop Webcam. )
chris_ schrieb: > > Werden dafür normale LEDs verwendet? Ich könnte mir vorstellen, dass man > für die hohen Datenraten spezielle LEDs braucht. Mit normaler NRZ-Modulation geht das mit gar keiner LED - auch nicht mit RC-LEDs. Deswegen nimmt man komplexe Modulationsverfahren. Prof. Haas nimmt offensichtlich OFDM. Dann geht das auch mit "normalen" LEDs.
chris_ schrieb: > Ich könnte mir vorstellen, dass man für die hohen Datenraten spezielle > LEDs braucht. Für die LED ist eine hohe Datenrate kein Problem. Der Empfänger macht da schon mehr Kopferbrechen... > Mein jetziges Programm verwendet FSK als Modulationsverfahren. Ich würde einfach eine handelsübliche Soft-SIO auf den Pin loslassen. Mit einem halbwegs durchdachten Empfänger (die paar Widerstände reichen da natürlich nicht aus) und einer brauchbaren Kopplung könnte man dann direkt ein Terminalprogramm zur Auswertung verwenden. Oder man setzt auf ein Standardinterface wie IRDA-SIR, für das es gleich fertige USB-Schnittstellen geibt...
>> Mein jetziges Programm verwendet FSK als Modulationsverfahren. >Ich würde einfach eine handelsübliche Soft-SIO Daran habe ich auch schon gedacht, es würde die Software ziemlich entlasten. Allerdings hatte ich schon öfters das Problem der "gegebenen, unveränderbaren Hardware". Dort gibt es meisten Debug-Leds, die sich per Software ansteuern lassen. Deshalb muss das Debugging nur mit Software möglich sein.
chris_ schrieb: > Deshalb muss das Debugging nur mit Software möglich sein. Aber du schreibst doch selber, dass nur die Senderichtung nur im Fehlerfall nötig ist und dafür dann 100% der Rechenleistung zur Verfügung steht. Und wenn das so ist, dann ist eine Soft-SIO ganz simpel zu implementieren: ein paar delay_us() und fertig...
Die Kunst ist meistens nicht die Sendeseite, sondern die Detektionsseite. Bis so etwas zuverlässig funktioniert, schätze ich mal 8-16 Stunden.
Der Code für den Sender ( erst mal ein Attiny 13 ) findet sich hier: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=146
>Ist schon in der Mache >http://www.golem.de/news/optische-datenuebertragun... Das scheint ja ein großes Thema zu sein: http://www.led-wlan.de/ Irgendwo gab es einen Artikel über die Datenübertragung mit nur einer LED als Sender und Empfänger. Leider finde ich diesen nicht mehr. Hat jemand einen Link?
>Irgendwo gab es einen Artikel über die Datenübertragung mit nur einer >LED als Sender und Empfänger. Leider finde ich diesen nicht mehr. Hat >jemand einen Link? Nach einigem Suchen habe ich den Artikel wieder gefunden, er ist tatsächlich in der Mikrocontrollernetz Artikelsammlung ( http://www.mikrocontroller.net/articles/Lichtsensor_/_Helligkeitssensor ) verlinkt: http://www.merl.com/reports/docs/TR2003-35.pdf Die erreicht Datenrate dort liegt bei 250 Bit/s bidirektional. Es werden 2 Pins pro LED gebraucht. Ich frage mich, ob es auch mit einem Pin geht.
Man kann doch gleich den seriellen Port (nur Tx) dazu nutzen. Da kann ich eine LED dran hängen oder ein USB-UART Kabel oder beides. Zwischen den Übertragungen leuchtet die LED dann von ganz alleine. Und wenn ich sie blinken lassen will, mach ich das einfach. Man kan den Pin ja auch "manuell" toggeln, wenn man will. Worin liegt der Vorteil eines eigenen Übertragungsprotokolls?
Wenn du rs232 hast, dann sieht man dies an der Led. Hast du hingegen z.B. so ein Uebertragungsprotokoll: 1= invert 4uS Pause invert 0= invert 2uS Pause invert und man benutzt auch eine langsame Datenrate, also mit Pausen von >= 52 uS, dann sieht man es so gut wie nicht. Auch hast du dann keine Probleme mit Interrupts usw, da diese dann nur fuer 2-4uS gesperrt werden muessen, bzw auch nicht, im Interrupt setzt du ein Flag und wenn waehrend der Datenausgabe ein Interrupt passiert wiederholst du einfach das Bit, dies Angenommen Interrupt dauert laenger als 2uS, andernfalls waehlt man andere Zeiten.
>Worin liegt der Vorteil eines eigenen Übertragungsprotokolls? 1. Wenn bei einem bestehenden Gerät die Schaltung schon vorgegeben ist, man nur die Software beeinflussen und die LED nicht am UART Ausgang hängt. 4. Das von mir verwendete Protokoll hat eine Baudratenschätzung. Dadurch können auch Mikrocontroller mit ungenauer RC-Zeitbasis als Sender dienen ( Wie im Beispiel der Attiny13 ) 2. Das Protokoll ist gleichspannungsfrei, dadurch wird die Empfangsschaltung extrem einfach 3. Das Protokoll ist so gemacht, dass jeder digitale Eingangspin eines Mikrocontrollers zum Empfang verwendet werden kann. Weitgehend unabhängig von der Schaltschwelle des Pins 5. Wird das Signal direkt von der Uart erzeugt, wird das Empfangssignal sehr umgebungslichtabhängig und der Empfänger muss sehr nahe an der Sendediode sein. Das ist nicht bei jedem Gerät möglich. Code: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=146
Thread beobachten
Seitenaufteilung abschaltenBitte 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.