massive led debugging

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 ;-)

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

> 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.

>> 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.

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