Archiv verlassen und diese Seite im Standarddesign anzeigen : Adressierung von 64 LED´s
Hallo Leute..
Für meine Matura muss ich unteranderem ein Abschlussprojekt machen.
In Planung ist ein Touchpad bestehenden aus 64 oder mehr Led´s. Der ein oder andere wird sicher das Video schon kennen (http://mrl.nyu.edu/~jhan/ledtouch/index.html) und auch dessen Betriebsweise.
Für alle anderen: LED wird verpolt und der "Kondensator" in der LED geladen. Am µC wird auf Tristate geschaltet und dann die Zeit gemessen wie lange es braucht bis der Pin auf 0 gezogen wird, die Zeit ist abhängig von dem einfallenden Licht.
Im Anhang ist ne skizze wie es ungefähr später aussehen soll.
Aber vorerst haben wir das Problem mit den vielen verbrauchten Pins, da theoretisch pro LED 2 Pins gebraucht werden. Ideal wäre es jetzt einen Zeilen und einen Spalten IC zu verwenden, Funktioniert auch soweit nur sobald man ein LED umpolt beginnen alle anderen logischer Weise auch zu leuchten, wie kann man sowas vermeiden ?
Hat jemand eine Idee welches Konzept man da verfolgen sollte ?
Danke im vorraus ;)
http://img134.imageshack.us/img134/6301/ledmatrixky8.th.jpg (http://img134.imageshack.us/my.php?image=ledmatrixky8.jpg)
the_Ghost666
28.09.2006, 12:26
Also zur Ansteuerung von 64 LEDs kannst du einige ICs von Maxim-ic.com verwenden, zb MAX7219. Diese werden gemultiplext, sodass das IC mit 8 Leitungen 64 LEDs ansteuern kann. Das kannst du dann seriell über 3 Leitungen steuern. Mhh puh, aber ich denke nicht, dass du dann noch die helligkeit messen kannst...
aber das würd mich sehr interessieren, hast du weitere quellen zu der funktionsweise als fotodiode?
ansonsten fallen mir noch ein : Schieberegister oder Multiplexer-Bausteine
http://www.merl.com/projects/LEDcomm/
Hier ist der Arbeitsbericht welcher wirklich sehr gut geschrieben ist, aber leider nur mit 1ner LED.. aber wie ich das mit 64 mache und wie das in dem Video funktioniert..
Beim Multiplexer sehe ich das Problem das ich ws Zeitverschiebung haben werde... ich muss ja die leds rl hochfrequent durchschalten
SprinterSB
28.09.2006, 15:44
Also eigentlich braucht man die LEDs nicht zu verpolen. Wenn Licht drauffällt, dann entsteht eine Spannungzwischen Anode und Kathode, wobei Anode=+ und Kathde=-. Ganz gut ist es, wenn man nicht wartet, bis sie auf LOW gezogen hat, sondern wenn man gegen einen Analogwert vergleicht, der knapp unter VCC/über GND ist.
So was ähnliches hab ich mal gemacht (Helligkeitsmessung mit LEDs "während" diese leuchten). Ich denkk mal du willst was ähnliches machen?
Hier mein Projekt: Im PDF findest du auch den Schaltplan der Uhr. Darauf wiederum eine Tabelle, die sagt, wie die Ports geschaltet werden müssen (LED an/aus, Messen, etc).
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=22760
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=160444
Mit MUX wird das ganze nicht einfacher, falls es mit MUXer überhaupt noch geht...
Hm mal schaun ob ich das richtig verstehe...
Du hängst Anode UND Kathode auf Vcc ? Anode lässt du auf Vcc und legst das Signal an den Analog Komperator. Welcher als Vergleichswert eine Schwellenspannung von knapp unter Vcc hat...
Ich denke soweit stimmts.
Gemessen wird dan die Zeit zw Umschalt und dem Trigger vom Komperator.
Jetzt aber was ich nicht kapier... Wie funktioniert das.. du machst ja wenn der Spannungsteiler knapp unter Vcc liegt, die Zeit zum messen ja extra klein oder ?
Das eigentliche Problem ist doch nicht das Messverfahren für die einzelnen LEDs...
edit:
bzw. das Verfahren an sich steht ja onehin schon fest, so unterschiedlich sind die beiden Varianten nun wirklich nicht
Es stellt sich eher die Frage wie man alle 64 benötigten Helligkeitswerte mit vertretbarem Aufwand messen kann. (schnell, und mit einer vernünftigen Auflösung)
SprinterSB
28.09.2006, 16:29
Ja, ich hänge A und K auf VCC, und zwar 3 LEDs (D.A8-D.C8) parallell. Im Endeffekt arbeitet es also wie nur mit einer LED. Duch A=K=VCC Entlade ich die LEDs (als C betrachtet). Danach lasse ich die K los (high-Z) und die A bleibt bei VCC. Wenn K < U0 < VCC ist (U0 ~ VCC-100mV) nehme ich die Zeit.
Je kleiner die Zeit ist, desto besser. Bei Dunkelheit würde K nie unter U0 fallen. Von daher wäre eine C-Messung (in Sperrichtung) vorzuziehen und deutlich schneller. Allerdings hab ich das nicht hingekriegt :oops:, wahrscheinlich wegen parasitärer Kapazitäten (Matrix, µC, ...). Ausserdem nutzt es nix, die Kapazität C zu kennen. Man braucht ja die Kapazitätsänderung ΔC mit der Helligkeit. Und die dürft deutlich unter C sein.
Mir ist jetzt aber auch unklar, wie ich das in einer Matrix mit mehreren Messungen machen würde. Während du an einer Spalte misst, muss eine Nebenspalte ja leuchten, damit Licht in die Mess-Spalte reflektiert und detektiert werden kann, was ein MUX eigentlich ausschliesst.
hmm angenommen ich nehme 4 avrs jeder einen teil des panels und hänge alles direkt daran ?
€dit
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=129509#129509
genau so hatte ich es ursprünglich vor.. ich denke das ist auch rein Hardwaretechnisch mit dem geringsten Aufwand verbunden. Oder was meint ihr ? Gerade bei so ner großen Anzahl an LED´s wirds mit AC schwer zu realisieren...
solong..
Naja, überlegen wir doch erstmal was benötigt wird...
(dabei gehe ich davon aus daß die erste beschriebene Messmethode zum Einsatz kommen soll)
das wären nämlich wenn ich mich nicht sehr irre:
64 digitale Ausgänge und 64 digitale Ein-/Ausgänge
Nun ist es aber so, daß jeweils 7 der 8 Spalten einfach nur gleichmäßig leuchten müssen (denn die Matrix soll ja nicht als Display sondern als Touchpad verwendet werden). Das reduziert den Hardwareaufwand schonmal erheblich, denn damit brauchen wir nurnoch 8 Ausgänge und 64 Ein/Ausgänge. 8 Ausgänge sind mir aber immernoch zuviel, also benutzen wir einen geeigneten Decoder, wodurch wir am Controller selbst nurnoch 3 Pins benötigen.
Jetzt müssen wir versuchen die 64 Ein-/Ausgänge etwas zu reduzieren...
Auch hier gilt wieder: 7 der 8 Spalten leuchten einfach in der Gegend rum, nur an einer Spalte wird gemessen. Aber wie wird denn nun gemessen? Wenn ich das nicht völlig falsch interpretiert habe laden wir die Diode auf, und messen dann wie lange es dauert bis sie sich soweit entladen hat, daß der Eingang das als "Low" interpretiert.
Also weiter im Text...
wir wollen jeweils nur 8 LEDs gleichzeitig messen, da sollte es doch möglich sein das auch mit nur 8 Ports zu erledigen, oder?
Die Anoden werden ja allein schon durch die erste "Sparmaßnahme" korrekt angesteuert, bleiben noch die 64 Kathoden, von denen 56 einfach nur an "Low" hängen müssen.
Wir müssen also nurnoch in der Lage sein die 8 Kathoden einer Spalte wahlweise an GND oder an 8 digitale Ein/Ausgänge am µC zu hängen.
Gruß,
Felix
Hmm so wie ich deinem Text entnehme, übersiehst du aber das ich die LED´s auch noch verpolen muss... aufladen =! leuchten... leider
Also eigentlich habe ich auch daran gedacht...
In der pdf-Datei sind doch 3 mögliche Zustände beschrieben:
1. Emitting
2. Reverse Bias
3. Discharge
praktischerweise sind die Zustände 2 und 3 aus sicht der Anode aber völlig identisch, denn sie liegt in beiden Fällen auf GND.
edit:
und genau das erreichen wir ja mit dem Decoder (ok, evtl. muss noch ein 8x Inverter dahinter), die Anoden in einer Spalte hängen an GND, alle anderen an VCC. Mit dem Controller müssen wir nurnoch aussuchen welche Spalte wir einlesen möchten
http://img330.imageshack.us/img330/6749/led3kr.gif
jop.. aber trotzdem müssen wir 1mal umschalten... kann schon sein das deine idee stimmt.. aber irgendwie komm ich da nicht dahinter...ich steh gerade auf der leitung
Jo, habe meinen post nochmal editiert der war zugegebenermaßen etwas knapp...
ich bin inzwischen übrigens der Meinung daß es möglich sein dürfte die benötigten Ein/Ausgänge auf 4 zu reduzieren + die 3 Ausgänge zur Spaltenauswahl natürlich. (was bedeuten würde, daß das ganze Ding nur einen einzigen Port belegt)
achso jetzt weis ich was du meinst ](*,)
du willst also mit einem baustein einfach die anode zw + und - umschalten.. richtig ? hmm naja aber auf die spalten hast noch vergessen :D muss ja jedes led einzeln auslesen ! ;)
Genau, die Anoden einer Spalte (ich gehe von spaltenweisem auslesen aus, aber das ist ja letztendlich völlig wurscht), hängen an einem 1/8-Decoder der 3 Eingänge hat und 8 Ausgänge. Je nachdem welche Binärzahl an den Eingängen anliegt wird einer der 8 Ausgänge auf High geschaltet, während alle anderen Low bleiben. (bzw. umgekehrt, je nach Typ)
Was den Rest angeht, also das eigentliche Auslesen der einzelnen LEDs, da bin ich noch am tüfteln, aber ich komme der Sache näher
hmm und was ist wenn wir pro spalte dann auch noch nen AC verwenden und ich die leds pro reihe mit nem bitshifter durchschalte ?
€ Also die andere Messmethode... und eben anstatt den tastern den bitshifter
the_Ghost666
28.09.2006, 19:23
schonmal überlegt einfach den herrn anzuschreiben, der dieses video gemacht hat, ob er zusätzliche infos rausrücken kann?
jo.. ist ja auch schon drausen ;) aber selbst machen ist lustiger :D
Zum Messen der der LEDs braucht man ja einen kapazitätsarmen hochohmigen Eingang. Daher wird man hier nicht die Anschlüsse zusammenschalten können.
Evtl. kommt man mit 8x 74HC245 weiter.
(ich müsste nachsehen, ob man jetzt HCT, AC; ACT oder so nimmt..das sind aber Details)
"Input": von der LED zum Controller
"Output": vom Controller zur LED
Ein Baustein wird jeweils auf "Input" geschaltet, und gibt das Signal von 1 LED-Zeile an 8 Portbits mit Softpull-UP (oder down? habs nicht im Detail überlegt) weiter. So kann man die Zeit messen, denn irgendwann triggert ja auch der Baustein.
Die anderen 7 Treiberbausteine werden als Output gesteuert, und reagieren auf den Softpulldown, geben einen GND raus, die LEDs leuchten.
Man braucht also dann:
8 IO-Ports
8 Ausgänge für die Richtung des Treibers
wahlweise 3 Ausgänge + Decoderbaustein
8 Ausgänge für die Spalten..
Macht dann 19 oder 24 E/A
8 bzw. 9 billige TTL-Bausteine
Sigo
Also ich bin nach einigem probieren auch beim 245 gelandet, allerdings benötigt man da noch ein bischen zusätzliche Logik wenn ich das richtig sehe.
So ich fasse jetzt mal zusammen wie weit wir derzeit gekommen sind,
Zuerst Ansteuerung von Anode: Mithilfe eines Decoders wird mit Hilfe von 3 Bit 8 LED´s auf Gnd bzw Vcc gezogen. Aber wie schalte ich Zeilenweise weiter ? oder für jede Zeile einen Decoder ? wären 12 für die Ansteuerung der Anode...
Bei Messverfahren A also mit 2 Pins, kann ich es ja direkt Anschliessen, ein AVR unterstützt ja Tri-State oder ? -> Schlecht....
Bei Messverfahren B mithilfe eines Analog Comperators, könnte ich den Comperator einfach immer eine LED mit hilfe des 74HC245 weiterschieben. sind 8 Pins ( ein AC je Zeile) -> 20 Pins
Also wäre Möglichkeit B am besten oder ? wie man auf 19 kommt weis ich nicht ;)
Hmm, ich glaube das ist so nicht ganz korrekt...
Alle bisherigen Lösungen gehen vom simultanen Einlesen einer ganzen Spalte aus (also 8 LEDs gleichzeitig). Für die Anode(n) braucht man nur einen einzigen Decoder, wobei jeder der 8 Ausgänge an einer Spalte hängt. (die Anoden einer Spalte sind alle miteinander verbunden)
Die Kathodenseite ist komplexer, da bidirektional. Dafür wird der 74245 benötigt, wobei ich der Meinung bin daß das ohne zusätzliche Logik noch immer nix wird. Aber das hab ich bald raus
edit:
also ich hätte jetzt zumindest schonmal eine Lösung mit 16x 74HC245
(da die bei Reichelt nur knappe 30 Cent kosten, könnte höchstens der Platzbedarf noch ein Problem darstellen)
8 LED´s gleichzeitig auslesen ist meiner Meinung nicht möglich ohne eine Zeitliche verschiebung reinzubekommen... Noch dazu das es nicht nur ein "EIN" und "AUS" gibt sondern eben auch 50% 10% usw...
hängt jetzt alles an einem Decoder muss ich praktisch immer die komplette Zeile ausschalten. Ich weis nicht wie du das realisieren willst.. ich stehe denk ich auf der Leitung und bin zu sehr auf meine Lösung fixiert.. wobei ich gerade merke das ich mit 20 auch nicht auskommen werde ;) hab den Bitshifter vergessen....
Hi Felix, wieso denn 16x?
Ich komme auf 8x 74245 für an kathoden.
OK, ein bischen Logik (1-3 TTLs) braucht man noch, oder eben mehr Ausgänge..
Sigo
ok, man braucht nicht unbedingt 245er...
aber es muss noch irgendwas mit Tristate Ausgängen (ich habe jetzt mal 244er genommen) an die Leitungen zwischen den LEDs und den 245ern. Nämlich ganz einfach weil man (wenn die LEDs leuchten sollen) irgendwoher ja ein GND bekommen muss, das aber den Auslesevorgang nicht beeinflusst.
Die Lösung die ich jetzt habe benötigt genau 12 Pins am Controller (3xSpaltenauswahl, 1xDirection, 8xDatenbus) wenn man mit Polling arbeitet, und 13 (+ einen weiteren Logik-IC) wenn man einen Interrupt bekommen möchte, sobald eine LED entladen ist.
an ICs brauche ich:
8x 74HC245
8x 74HC244
2x 74HC04
1x 74HC138
Naja, ich habe den Schaltplan mal angehängt, und hoffe nichts essentiell Wichtiges übersehen zu haben.
(auf 6 der 8 LED-Spalten habe ich aus offensichtlichen Gründen verzichtet)
8 LED´s gleichzeitig auslesen ist meiner Meinung nicht möglich ohne eine Zeitliche verschiebung reinzubekommen... Noch dazu das es nicht nur ein "EIN" und "AUS" gibt sondern eben auch 50% 10% usw...
Hi, ich denke, dass das schon geht.
Alle 8 werden gleichzeitig auf Entladen gestellt.
Nun liest du in einer Schleife den Port als Byte aus, wenn sich das Byte ändert, dann schreibst du dir den Schleifenzählerstand und den Bytewert des Ports weg. Da es nur (max) 8 Änderungen geben kann, bekommst du 8 Werte oder vorher Timeout (schleife durchlaufen). Natürlich kann man auch einen Timer auslesen...
oder einen der neuen ATmegas nehmen, bei denen jedes Portbit einen Interrupt auslösen kann mit dem man dann einen Timer ausliest...
Dito die anderen Zeilen.
Wenn alle druch sind, kannst du "in Ruhe" die Bits aus den Bytes rausklamüsern, skalieren und auch ausgeben..
So langsam bekomme ich Spaß an dem Projekt
Echt klasse!
Sigo
Die 7 74245er, die nicht gerade auslesen, können doch auch ne "0" ausgeben..und die LEDs ans leuchten bringen...
Der aktive 74245 macht zuerst die "1" zum aufladen, dann liest er die LEDs aus..
der 74138 wird nicht reichen, um gleich alle LEDs anzumachen. Da braucht man dann schon etwas mehr POWER.. evtl. 2 4-fach MOSFET-Treiber oder auch 2x L293 dahinter hängen...
Sigo
Aber wie sollen denn die 245er eine 0 machen?
Laut Datenblatt haben die nur 3 Betriebsmodi:
1. Daten von A nach B
2. Daten von B nach A
3. Tristate
edit: stimmt, der eine 138er ist für die LEDs zu schwach...
auf solche Details habe ich bei dem Schaltplan aber noch nicht so geachtet
Du kannst du mit dem Port ein "O" ausgeben und die dann von B nach A ausgeben...
das Teil hat Gegentaktausgänge
;-)
OK, das war n Gedankenfehler. Der Port hat ja schon zu tun...und kann keine Null ausgeben..
hihi
OK
Ich freu mich über das große Interesse an dem Projekt. Bin jeder Hilfe dankbar... Ich werde es soweit es mir von der Schule her erlaubt ist auch hier alles öffentlich dokumentiern ( und ich denke doch das es erlaubt ist ;))
Danke Felix, das hilft mir sehr weiter. Wie ihr sicher bemerkt habt habe ich Probleme mit den IC´s vorallem weil ich selten welche einsetzen musste ;), aber das ist ja der Sinn des Projektes das man mal was anderes lernt...
Ich versuche mal die Schaltung zu verstehen:
der xxx138 denk ich wird zu schwach sein für soviele LED´s zu treiben...
oder liege ich da falsch ? mal drüberrechnen...
Der xxx244 dient dazu die Leitungen auf GND zu ziehen oder ? also so das der xxx245 ignoriert wird. Mit der Richtung kann ich aber auch umpolen... bzw lesen (danke für den Hinweis mit den Bytes, ich war immer noch in Gedanken bei 10x10 Leds und habe vergessen das ich ja auf 8x8 runter bin :)).
aber was macht der xxx04 ? und warum brauch ich von dem nur 2 ?? Tippfehler ?
Edit: hmm Inverter ? Flankengenerator ?
Edit... Ah und einen Verpolungsschutz ist ja da auch noch drin :) =D> =D> seh ich ja jetzt erst... kann also nicht Vcc - Vcc hängen ;)
Danke Felix, das hilft mir sehr weiter. Wie ihr sicher bemerkt habt habe ich Probleme mit den IC´s vorallem weil ich selten welche einsetzen musste ;), aber das ist ja der Sinn des Projektes das man mal was anderes lernt...Die Bezeichnungen weiss ich auch nicht auswendig, ich habe nur eine ungefähre Vorstellung davon was es so gibt und wie das evtl. heissen könnte. Ich dachte mir z.B. daß für die Ankopplung der Kathoden an den µC ein bidirektionaler Bustreiber vielleicht geeignet sein könnte, und über 5 Ecken bin ich dann beim 245 gelandet. (Man muss also keineswegs die ganze 74er Reihe auswendig kennen)
der xxx138 denk ich wird zu schwach sein für soviele LED´s zu treiben...
oder liege ich da falsch ? mal drüberrechnen...Da brauchst du nicht drüberrechnen, denn wie sigo bereits erwähnt hat ist der Decoder allein natürlich viel zu schwach. Da muss auf jeden Fall noch ein Treiber dran der den nötigen Strom liefern kann.
Der xxx244 dient dazu die Leitungen auf GND zu ziehen oder ? also so das der xxx245 ignoriert wird. Mit der Richtung kann ich aber auch umpolen... bzw lesen (danke für den Hinweis mit den Bytes, ich war immer noch in Gedanken bei 10x10 Leds und habe vergessen das ich ja auf 8x8 runter bin :)).Ja, die 244er sind leider nötig da die 245er wirklich nur reine Bustreiber sind. Hätten die 245er auch noch einen Puffer mit drin, dann könnte man sicher auf diese "Krücke" verzichten (wären immerhin 8 ICs weniger, also lohnt es sich evtl. nach Alternativen zum 245er zu suchen).
Natürlich kann man statt der 244er auch 245er an diese Stelle setzen, das würde ich ganz einfach vom Preis abhängig machen.
Es gibt also 3 verschiedene Situationen:
244 Enabled (=> Kathoden auf Low), 245 Tristate
244 Tristate, 245 Enabled & Direction A->B
244 Tristate, 245 Enabled & Direction B->A
aber was macht der xxx04 ? und warum brauch ich von dem nur 2 ?? Tippfehler ?
Edit: hmm Inverter ? Flankengenerator ?der 74xx04 ist ein 6x Inverter, den ich benötige da die 244er und 245er immer abwechselnd Enabled sein sollen. Wenn die Spalte "inaktiv" ist, also nicht ausgelesen wird, liegt der Enable Eingang vom 245 auf High (= Tristate) und der Enable Eingang vom 244 durch den Inverter automatisch auf Low (= Enabled).
Achja, und ich brauche 2 davon weil in einem IC leider nur 6 Inverter sind und nicht 8.
edit: also wenn ich das richtig sehe könnte man statt der 244/245 Kombination auch 8x 74652 "Registered Transceivers" nehmen.
(stellt sich nur die Frage ob man die Dinger bei den gängigen "Elektronikdealern" bekommt)
Gruß,
Felix
Hi,
als Treiber für die Anoden kannst du z.B. den 4469 nehmen,
siehe hier: http://www.micrel.com/_PDF/mic4467.pdf
Den gibts auch noch von vielen anderen anbietern, ist recht verbreitet.
Du bräuchstest 2 Stück davon.
Die MOSFET-Treiber haben ca. 10 Ohm Innenwiederstand, bei 1W Verlustleistung, kannst du also max. ca. 0,3A Dauerstrom treiben, für 32 LEDs, das sind knapp 10mA pro LED..
Alternative wäre 4 x TSC 1427 oder TSC4427 (da sind jeweils 2 Treiber pro Gehäuse).
Der kann pro Gehäuse ca. 700mW vertragen. Bei ebenfalls ca. 10 Ohm Innenwiderstand , die ja dann nur 16 LEDs versorgen müssten, wäre hier ca. 15mA dauerstrom drin. Und die Teile arbeiten ja "nur" 7/8 der Zeit.
Evtl. kannst du auch 8 Stück nehmen und immer 2 parallelschalten..
Es gibt auch noch Bausteine die niederohmiger sind, aber auch teurer.
Last but not least würden auch 2 "Good Ole" L293 oder L298 gehn..die kosten aber mehr Spannungsabfall wg. der Darlingtonendtstufe.
Mir erscheint die Sache jetzt rund. Es reizt mich auch, das man zu machen. Das Video ist ja echt stark!
Und, man könnte die 64 LEDs ja auch prima rund um einen Bot anordnen.. säh cool aus und wär ne tolle Stoßstange mit Richtungserkennung.........der Akku wirds nich so toll finden..
Sigo
Mir erscheint die Sache jetzt rund. Es reizt mich auch, das man zu machen. Das Video ist ja echt stark!
Und, man könnte die 64 LEDs ja auch prima rund um einen Bot anordnen.. säh cool aus und wär ne tolle Stoßstange mit Richtungserkennung.........der Akku wirds nich so toll finden.Jo, ich würde auch gern mal sowas basteln, oder was meinst du wieso ich gestern stundenlang daran rumgehirnt habe ;)
Also was die LED-Treiber angeht haben wir ja genug Auswahl, welchen man verwendet hängt dann nurnoch von den LEDs und der Verfügbarkeit ab.
Hast du eine Ahnung ob man diese 74652er irgendwo bekommt?
Der kann nämlich nicht nur einfach A an B durchreichen bzw. umgekehrt, er kann auch vorher gespeicherte Daten an A und/oder B ausgeben.
(und das ist ja genau das was uns beim 245 gefehlt hatte)
Gruß,
Felix
HI, den 74HCT652 gibts bei BÜrklin für schlappe 2,77 EUR/Stk. 10er-Preis...bzw. 3,46EUR/Stk 1er Preis
Also wohl doch lieber Feld-Wald-Wiesenbausteine nehmen...
Sigo
Hmm, evtl. wär doch ne modulare Lösung mit 8x ATmega8 oder 4x
ATmega32 besser....
Man könnte soviele LEDs wie man will betreiben, macht 1 kleine Platine und die gleich in Serie, dito einfache Software mehrfach genutzt...schön modular..., wie oben von Bubi angedacht..
hihi
Sigo
;-)
SprinterSB
29.09.2006, 15:45
So ganz sehe ich noch nicht, was die Bustreiber bei einer C-Messung helfen sollen. C-Messung wollt ihr über t-Messung machen. t ergibt sich duch die exponentielle (Ent)ladekurve bis U einen bestimmten Wert über/unterschreitet. Das verwendet man am µC für einen Input-Capture (IC).
"Von Hand" auf die Ports zu schauen wird zu langsam/ungenau sein für diese Größenordnungen, auch wenn man in Assembler arbeitet. IC-Kanäl hat man auf AVR aber maximal 2 (oder so). Man muss also alle 8 LEDs einer Zeile nacheinander durchmessen. Ven der Geschwindigkeit her ist das kein Problem, für ne Messung vergehen eh nur ne handvoll µC-Takte.
Die Bustreiber sind IMHO sehr störend für die Messung. Deren Kapazitäten addieren sich zu Werten, unter denen der zu messende C-Hub locker verschwindet, vor allem wenn man noch die Streuung der steilflankigen Treiber bedenkt.
Ich würd sowas versuchen, zunächst mal mit einer LED pro µC-Port. Wenn das funzt, kann man immer noch schauen, ob MUX zu machen ist. Das Problem ist nicht der MUX an sich, sondern die Parasitären C. Und von denen hat man um so mehr, je mehr Komponenten man verbaut.
(A)---|>|--o---R1---µC
|
|
R2
|
|
(0)
R1 ist ein normaler Vorwiderstand für die LED wenn diese leuchten soll (A=HIGH, µC=LOW).
Zum Messen wird der µC-Port auf HIGH gelegt, A auf LOW und die D über R1 geladen. Dann aktiviert man den IC und lässt den Port los (high-Z) die D entlädt sich über R2. Den IC macht man zB bei VCC/2. Die IC-Zeit ist ein Maß für C. Danach kommt die nächste LED dran.
Dazu bräuchte man in der Version einen µC pro Zeile, vorausgesetzt ein µC hat
-- mindestend einen IC mit einen Input-MUX 8:1 davor
-- Ports die den LED-Strom versenken können
Vom Platz her ist das nicht mehr bzw. weniger als mit Bustreibern zu MUXen.
R1 im Bereich von ein paar 100 Ohm (Abhängig von LED), R2 im Bereich von MΩ.
Der MUX sollte nicht das Problem sein, ob ich eine Komplette Zeile einlese oder eine einzelne Led sollte wie oben beschrieben doch egal sein oder ?
Viel problematischer sehe ich das Problem mit den xxx245 Bustreibern, da gib ich dir recht das das Problematisch werden könnte, aber der ist doch sowieso überflüssig da AVR´s doch Tri-State schalten können oder nicht ?
Ich habe bis jetzt 8051 verwendet wo das eben nicht ging.
oder übersehe ich wieder was... ( ich mag die IC´s nicht ;) )
mfg
@SprinterSB
Naja, schau dir doch mal die .pdf Datei an...
da hängt die LED einfach nur zwischen zwei digitalen Ein/Ausgängen am µC. Es ist garnicht nötig die LED über einen Widerstand zu entladen, das übernimmt das einfallende Licht (Photoeffekt). Man lädt die LED und wartet dann einfach bis die Photonen die Ladung so weit runtergeprügelt haben, daß die Spannung vom Digitaleingang als "Low" interpretiert wird.
So habe ich den Artikel zumindest verstanden...
Im Klartext heisst das, daß nur die Kapazitäten zwischen den LED-Kathoden und dem 74HC245 Probleme verursachen könnten.
(denn der 245 übenimmt ja quasi die Spannungsmessung, alles was dahinter kommt, ist völlig unempfindlich)
Gruß,
Felix
Seh ich (fast) wie Felix, bez. 74245.
Allerdings stimmt es auch, dass die Kathode dann 2 Eingänge sieht, und nicht nur 1, da ja noch der andere Baustein (74244 oder auch 74245) drann hängt, sodass da schon mehr Kapazitäten im Spiel sind.
Ich gebe aber auch zu, dass mir mittlerweile die reine x-fach µController-Lösung mehr und mehr gefällt, da ich schon immer vor Schaltungen mit mehr als 3 mal 74xxx fies war.
Die Idee, mit 1 oder 2 Capture-Eingängen ca. 16 LEDs gemultiplext zu messen, find ich auch sehr gut. Zumal man ja die Platine dann gleich x-mal bauen kann...schöööön modular...und man spart sich auch die teuren Treiber für die Anoden, da das ja die normalen Ports schaffen..
Gibts Erfahrungen, welche LEDs am besten geeingnet sind? Farbe?
Infrarot?
Sigo
SprinterSB
29.09.2006, 16:58
Solche Messungen dauern dann *sehr* lange (im Vergleich zu einer C-Messung, die in ein paar µC-Takten fertig ist).
Ich bekomm ausserdem ne sehr starke Streuung rein wenn ich so messe. Auch bei einer U-Messung wird man die Zeit messen, bis U(t)=U_thres. Problem ist nur: je dunker desto wart. Wenn es komplett dunkel ist wartest du bis du schwarz wirst...
Auch hier sind parasitäre Effekte unangenehm, weil die Zeit länger wird wenn mehr Kapazität gefüllt/geleert werden muss. Wie fix sich ne LED leerrauscht weiß ich auch net, müsste man mal testen...
Angeblich Rote-Leds in klarem Gehäuse.... aber genaue Messungen kommen am Mittwoch.. ;) da bekomm ich das Oszi :)
das mit 8 µC war auch meine erste Idee.. einfach jede Zeile ein µC und alles is egal :) aber naja ich muss auch eine Alternative finden... es muss doch irgendwie gehen :) und ich denke auch das der Plan so funktionieren sollte, wobei ich den letzten Bustreiber (xxx245) weglassen würde... erkennen den Sinn von dem einfach nicht...
Sprinter, wegen Dunkel würd ich mir keinen Kopf machen, es gibt ja noch Timeouts...
Sigo
Ich hab hier mal was erstellt zur vorstellung und zum test von eagle \:D/ :D
http://img182.imageshack.us/img182/6657/cft3.th.jpg (http://img182.imageshack.us/my.php?image=cft3.jpg)
Ein µC pro Reihe.. (ich hab jetzt irgendeinen Port genommen !!!) im Master Slave Betrieb gesteuert über I²C... jeder µC hat zugriff auf den MUX und kann "seine" Zeile weiterschalten. Wenn Freigabe kommt.. bei 2-3 € je Baustein ideal oder ? Programmiert wird ausserhalb mit nem eigenen Board...also ISP brauch ich nicht.
€dit...: http://www.csd-electronics.de/data/pdf/ATMEGA48.pdf
Verstehe ich das richtig und ich kann jeden Pin als eigenen Interrupt Eingang verwenden ? oder bin ich doch irgendwie wieder eingeschränkt ? Mit so nem µC unt 8 Interupts bin ich eigentlich perfekt bedient. Vorallem mit dem Preis bei 1.50€ ...
SprinterSB
29.09.2006, 22:41
-- I2C sollte an die I2C-Pins (SDA, SCL)
kommt drauf an, was du messen willst. wenn die ein "normaler digitaler I/O reicht... wenn du Zeiten genau messen willst brauchst du nen Input Capture (IC). ADC0-ADC5 kannst du dahin verdrahten, AIN1 glaub auch und ICP1 sowieso. Damit hättest du 8 IC-Ports (wenn du kein HW-I2C nutzt).
Messen musst du ohnehin sequenziell. Ich glaub nicht, daß dir die PCINT der neueren AVR wie ATmega4/8/168 viel bringen für deine Sache.
Also so wie ich dem Arbeitsblatt entnommen habe reicht ein normaler I/O Pin.. Ich gehe jetzt davon aus das ich einfach solange warte bis die Spannung mir den Pin auf 0 zieht. Und die Zeit von loslassen des Pins bis zur Änderung messe ich, bzw Stoppe ich wenn ein Interrupt kommt. Das wäre meine Prinzipielle Idee.
Ich hab hier nur graue Theorie, wie und was und obs überhaupt reicht muss man versuchen. Ich komme erst nächste Woche dazu zu testen.
Zu i2c :) ich hab da garned draufgeachtet das es eigene i2c pins gibt ;) bin noch gewohnt das Software mässig zu realisiern :D
€dit.. oder warte mal.. Kann es sein das meine Infos falsch waren und ich garned jeden Pin auf Tri-State setzen kann ?....Für das wäre doch der ICP da ?
Wieder falsch.. Flankengetriggerter Interupt :( naja aber war ja na drann ;)
Solche Messungen dauern dann *sehr* lange (im Vergleich zu einer C-Messung, die in ein paar µC-Takten fertig ist).
Ich bekomm ausserdem ne sehr starke Streuung rein wenn ich so messe. Auch bei einer U-Messung wird man die Zeit messen, bis U(t)=U_thres. Problem ist nur: je dunker desto wart. Wenn es komplett dunkel ist wartest du bis du schwarz wirst...
Auch hier sind parasitäre Effekte unangenehm, weil die Zeit länger wird wenn mehr Kapazität gefüllt/geleert werden muss. Wie fix sich ne LED leerrauscht weiß ich auch net, müsste man mal testen...Naja, wir sollten uns erstmal die Frage stellen wie schnell die Messung überhaupt sein muss...
Angenommen wir wollen bei dieser 8x8 LED Matrix eine "Framerate" von 25fps, dann wären das 40ms für für die gesamte Matrix bzw. 5ms pro Spalte. Damit das ganze etwas störsicherer ist könnten wir natürlich auch jeweils 2 Messungen mitteln, dann bleiben noch 2,5ms pro Spalte. Und ich kann mir nicht vorstellen daß das nicht ausreichend ist.
Für erste Tests würde ich einfach mal eine LED mit Vorwiderstand zwischen zwei ports hängen, und die Zeit messen die sie bei völliger Dunkelheit zum entladen braucht (die dürfte nur vom Innenwiderstand des Messpins abhängig sein).
@mehrere µCs
sicher ist das auch eine Möglichkeit, wie man es realisiert ist letztendlich Geschmackssache. (evtl. könnten die Kosten noch eine Rolle spielen)
Gruß,
Felix
Na, tote Hose hier? ;)
also ich habe inzwischen mal eine grüne LED (leider mit diffusem Gehäuse) an einen AVR gehängt, und das funktioniert schonmal garnicht sooo schlecht. Momentan wird die LED 2ms geladen und dann gleich ausgelesen (Timeout nach 1ms).
Die Schaltung reagiert selbst in den unmöglichsten Situationen noch auf Licht, z.B. wenn man die LED umpolt oder sogar wenn man eine zweite LED in beliebiger Polung parallel schaltet. (Daß dabei die Empfindlichkeit massiv in den Keller geht versteht sich von selbst)
Die Schaltung reagiert empfindlich auf Berührungen der Kathode, bei einer konkreten Realisierung sollte man das also beachten (Stichwort: parasitäre Kapazitäten)
kurz gesagt: tolle Sache das...
eine LED, ein Widerstand, zwei Drähte, fertig.
Und hier kommt noch ein spitzen Blockbuster, den ich extra für euch angehängt habe :mrgreen:
(benötigt DivX)
... öhm - nettes Vid :-) ... also würde ausreichen, eine Led eines 7-Segments zum Lichtmessen zu nehmen ... geht es denn auch mit dem Vor-R daß zum sonstigen Ansteuern?
Also ich habe die LED mit Vorwiderstand zwischen zwei Ports gehängt. Prinzipiell hätte ich mir den Widerstand für die Helligkeitsmessung auch sparen können, aber er ist nötig wenn man die LED auch als LED benutzen will. (sie kann ja abwechselnd leuchten und die Helligkeit messen)
Ne nix tote hose :)
Nur hatte keinen Sinn ohne konkrete Tests.. ;)
So ich versuch mich dann auch mal drann.
Mal schaun was rauskommt ;) achja nettes vid :D
Morgen gehts dann weiter, mal mit Lehrer besprechen und genauer festlegen wie mans jetzt macht... :)
hmm ich bekomms ned zusammen.. irgendeinen fehler hab ich drinnen...
kannst du mal dein Programm posten Felix bitte ?
wäre sehr nett...
mfg
edit hier mal meins.. : aber nix besonderes sondern einfach nur abgearbeitet wies im bericht steht
DDRC = (1<<0);
PORTC = (0<<0);
DDRB = (1<<5);
PORTB = (1<<5);
delay_ms(10);
DDRB = 0;
PORTB = 0;
i=0;
while(PORTB & (1<<5) == (1<<5))
{
i++;
delay_us(100);
}
printf("lol:%d\r\n", i);
Achso und hier mal der aktuelle Schaltplan
http://img516.imageshack.us/img516/8153/ledmatrixaj1.th.jpg (http://img516.imageshack.us/my.php?image=ledmatrixaj1.jpg)
Also wenn du die LEDs wirklich multiplexen möchtest, wirst du auf die 74xx245 nicht verzichten können. Die sind nötig um die inaktiven Spalten vom Controller zu trennen. Wenn du die LEDs aber nicht multiplexen möchtest, sondern die Kathoden direkt an den µC anschliessen, dann kannst du nicht nur auf die 74245 verzichten, sondern auch auf die 74244 und 7404.
Naja, hier mal mein Programm das allerdings etwas komplizierter ist, da ich Interrupts verwendet habe (T0 Overflow, T1 Overflow und T1 Input Capture).
#include <avr/io.h>
#include <avr/interrupt.h>
volatile int timestamp = 0;
void init(void)
{
//2ms: TCCR0 = 0x04; TCNT0 = 0x83;
TCNT0 = 0x06;
//1ms: TCCR1B = 0x01; TCNT1 = 0xC180;
TCCR1A = 0x00;
TCNT1 = 0xC180;
TIMSK = 0x25;
TIFR = 0x00;
GICR = 0x00;
GIFR = 0x00;
MCUCR = 0x00;
sei();
}
SIGNAL (SIG_INPUT_CAPTURE1)
{
timestamp = ICR1;
}
SIGNAL (SIG_OVERFLOW1)
{
//T1 stop
TCCR1B = 0x00;
TCNT1 = 0xC180;
//reverse bias
DDRD = 0x60;
PORTD = 0x40;
//T0 start
TCCR0 = 0x04;
}
SIGNAL (SIG_OVERFLOW0)
{
//T0 stop
TCCR0 = 0x00;
TCNT0 = 0x83;
//discharge
DDRD = 0x20;
PORTD = 0x00;
//T1 start
TCCR1B = 0x01;
}
int main(void)
{
init();
DDRC = 0xFF;
PORTC = 0x00;
//reverse bias
DDRD = 0x60;
PORTD = 0x40;
//T0 start
TCCR0 = 0x04;
for(;;)
{
PORTC = timestamp >> 8;
}
}
Als Controller habe ich einen ATmega32 verwendet, die Kathode der LED kommt an PD6(ICP1), die Anode an PD5 (hätte sie aber bei meinem ersten Test auch genausogut direkt an GND hängen können). Damit klar ist wie die LED angesteuert wird, habe ich in den Kommentaren die Bezeichnungen aus der pdf-Datei benutzt. (also "reverse bias" für den Ladevorgang und "discharge" für die Messung)
arg stimmt, seh ich erst jetzt, dank dir.. :) Sonst hab ich ja immer GND Potential am µC.
Zum Programm hmm ich sehe jetzt keinen Unterschied du hast auch nichts besonderes drinnen. Hmmm morgen mal ein anderes µC Board versuchen... irgendwas passt nicht... Dank dir erstmal ich melde mich wieder
http://img512.imageshack.us/img512/9982/ledmatrixbn0.th.jpg (http://img512.imageshack.us/my.php?image=ledmatrixbn0.jpg)
ich lande immer wieder bei deinem layout :) kann nix optimiern..
scheint perfekt zu sein... gratuliere ;) aber vl finde ich nen baustein der auf masse ziehn kann :D
So, eine Messung mit HIlfe eines Oszi hat NICHT funktiniert.
Dazu mal eine Frage: hast du das LED kurz leuchten lassen ? angeblich MUSS das sein ?! Bei dem Oszi versuch konnten wir zwar ein Kurve sehn aber keinen Unterschied in der Geschwindigkeit ...
Also bei meinem Test verwende ich die LED nur zur Messung, sie wird zu keinem Zeitpunkt in Durchlassrichtung betrieben. Möglich daß das Verfahren besser funktioniert wenn man die LED zwischen den Messungen auch einschaltet, aber nötig ist es definitiv nicht. (Ich habe beim ersten Test darauf verzichtet um das Programm möglichst einfach halten zu können)
Was ich allerdings feststellen musste:
ich habe hier 3 Arten von LEDs, nämlich rot diffus, grün diffus und blau klar. Die Messung funktioniert aber nur bei den grünen LEDs, und das obwohl die blauen aufgrund des klaren Gehäuses eigentlich besser geeignet sein sollten. Bei direkter Bestrahlung mit einem roten 1mW Laser zeigte keine der LEDs eine Reaktion (obwohl die grüne ein diffuses Gehäuse hat ist definitiv ein erheblicher Anteil des Lichts auf dem Kristall gelandet), bei einem grünen 5mW Laser reagierte nur die grüne LED.
Für erste Tests halte ich es daher für essentiell notwendig die Schaltung auf ein Minimum zu reduzieren, um die Anzahl möglicher Fehlerquellen klein zu halten. (heisst im Klartext: LED + Vorwiderstand direkt am Controller, ohne weitere Elektronik dazwischen)
ich lande immer wieder bei deinem layout Smile kann nix optimiern..
scheint perfekt zu sein... gratuliereDanke für die Blumen, aber das würde ich so nicht behaupten...
Meine Lösung hat zwar den Vorteil, daß nur wenige Ports am µC benötigt werden, ist aber deutlich unflexibler als die Variante mit mehreren µCs bei der jede LED einen Pin belegt. (außerdem entstehen Geschwindigkeitsprobleme, wenn die Anzahl der LEDs so groß wird daß es nicht mehr ausreicht nur 8 parallel auszulesen)
Gruß,
Felix
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.