So, Weihnachten ist rum. Bachelorarbeit geht voran. Der Himmel ist blau, die Wiesen grün und im Internet findet man alles. Unter anderem auch veraltete Datenblätter.
So schieben wir nicht zuerst das LSB sondern das MSB in das FIFO Register der Treiber. So was muss einem doch gesagt werden... Nun ja, war dann gestern mal wieder beim Fabi und hab am Oszi überprüft ob die realen Timings mit denen der Simulation übereinstimmen. Diese haben gepasst. Aber warum wurden dann die LEDs mal heller und dunkler obwohl sie mit der Erhöhung des Indexes in der logarithmischen Tabelle doch stetig heller werden sollten?
Eine kurze Diskussion über das LSB und das MSB förderte dann die beiden verschiedenen Datenblatt Versionen zum Vorschein. Meines (das von 2006) und das vom Fabi (das von 2009) unterscheiden sich in der Schiebereihenfolge und der Leistungsfähigkeit. So kann der Treiber bei Vdd von 3,3V bis 70mA pro Ausgang treiben und nicht nur 45mA. Somit können wir die 3 Stribes parallel an den Ausgang klemmen ohne einen FET zwischen basteln zu müssen.
Ach ja, meine Ausgänge schalten nun auch so wie sie sollen, kleiner Verdreher beim Indizieren des Arrays gewesen.
Jetzt implementiere ich die Stromanpassung über das Konfigurationsregister des Treibers.
Samstag, 29. Dezember 2012
Donnerstag, 20. Dezember 2012
3x3x8x8=....???? A Haufen Zeug!!!
So wir waren gestern wieder fleißig. Einige chaotische Lötereien, Messaufbauten und die Vernichtung eines Baumkuchens stehen zu Buche.
Das ist unsere Treibertestplatine mit zwei LED-Stribes die auf 2x2 LEDs in Originalabstand (professionel fixiert mit Tesa ;)) modifiziert wurden. Bis dahin war eigentlich alles recht ordentlich und überschaubar.
Ein, zwei Käbelchen mehr und eine zweite Treiberplatine schaut dann schon nicht mehr so aufgeräumt aus. Aber was soll man sagen, es funktioniert und das ist das Wichtige bei den Testaufbauten. Zumindest solange der GrayClock Pin auch Verbindung zum Lötpad und somit zum FPGA Ausgang hat.....
Die Ansteuerung der Treiber übers FPGA läuft nun auch schon. Zumindest wenn wir nur Einsen oder Nullen schicken. Aus dem vorbelegten RAM kann ich aktuell noch nicht definiert auslesen. Morgen nochmal drüber schaun wo der Fehler steckt. Egal, denn eine Farbe reichte aus um mit dem Plexiglas zu testen wie die Streuung bei voller Helligkeit ist.
So sah es aus als ein Stribe bei 20mA blau leuchtete. Die LEDs hatten ungefähr einen Abstand von 5cm zum Plexiglas. Die Helligkeit war leider nicht zu unserer Zufriedenheit. Also mussten wir näher ran oder aber mehr LEDs pro Pixel verwenden... Aber wenn dann richtig dachten wir. So entschieden wir uns für beide Lösungen, gleichzeitig... Also 9 LEDs pro Pixel direkt am Plexiglas. Bekommen somit eine 3x3 Punkte Matrix pro Pixel. Eine sehr anschauliche Lösung
Die Kamera hat auf die LEDs fokusiert, deswegen ist alles andere schwarz. Das normale Raumlicht war nebenbei immer noch an. Das nächste Bild zeigt ein Pixel wenn die Kamera auf etwas anderes fokusiert. Fazit nach ungefähr einer Minute halten und immer mal wieder hinschauen, man wird blind sollte man auf Dauer auf den Rahmen starren ;) Ich hab auf alle Fälle nur noch neun Punkte gesehen. Allerdings waren die LEDs zu dem Zeitpunkt schon wieder aus...
Ein arbeitsreicher Tag gestern gewesen.
Morgen noch ein letztes Mal vor dem Weltuntergang an die FH gehen und vllt noch den Fehler in der FPGA Implementierung finden. Dann kann man wenigstens mit ruhigem Gewissen den Weltuntergang feiern.
Das ist unsere Treibertestplatine mit zwei LED-Stribes die auf 2x2 LEDs in Originalabstand (professionel fixiert mit Tesa ;)) modifiziert wurden. Bis dahin war eigentlich alles recht ordentlich und überschaubar.
Ein, zwei Käbelchen mehr und eine zweite Treiberplatine schaut dann schon nicht mehr so aufgeräumt aus. Aber was soll man sagen, es funktioniert und das ist das Wichtige bei den Testaufbauten. Zumindest solange der GrayClock Pin auch Verbindung zum Lötpad und somit zum FPGA Ausgang hat.....
Die Ansteuerung der Treiber übers FPGA läuft nun auch schon. Zumindest wenn wir nur Einsen oder Nullen schicken. Aus dem vorbelegten RAM kann ich aktuell noch nicht definiert auslesen. Morgen nochmal drüber schaun wo der Fehler steckt. Egal, denn eine Farbe reichte aus um mit dem Plexiglas zu testen wie die Streuung bei voller Helligkeit ist.
So sah es aus als ein Stribe bei 20mA blau leuchtete. Die LEDs hatten ungefähr einen Abstand von 5cm zum Plexiglas. Die Helligkeit war leider nicht zu unserer Zufriedenheit. Also mussten wir näher ran oder aber mehr LEDs pro Pixel verwenden... Aber wenn dann richtig dachten wir. So entschieden wir uns für beide Lösungen, gleichzeitig... Also 9 LEDs pro Pixel direkt am Plexiglas. Bekommen somit eine 3x3 Punkte Matrix pro Pixel. Eine sehr anschauliche Lösung
Die Kamera hat auf die LEDs fokusiert, deswegen ist alles andere schwarz. Das normale Raumlicht war nebenbei immer noch an. Das nächste Bild zeigt ein Pixel wenn die Kamera auf etwas anderes fokusiert. Fazit nach ungefähr einer Minute halten und immer mal wieder hinschauen, man wird blind sollte man auf Dauer auf den Rahmen starren ;) Ich hab auf alle Fälle nur noch neun Punkte gesehen. Allerdings waren die LEDs zu dem Zeitpunkt schon wieder aus...
Ein arbeitsreicher Tag gestern gewesen.
Morgen noch ein letztes Mal vor dem Weltuntergang an die FH gehen und vllt noch den Fehler in der FPGA Implementierung finden. Dann kann man wenigstens mit ruhigem Gewissen den Weltuntergang feiern.
Montag, 17. Dezember 2012
Der ADC arbeitet
Letzten Donnerstag habe ich mir eine Adapterplaine für den ADC von SOT-23 auf 2,54 mm Rastermaß (DIP) gelötet, um ihn auf einem Steckbrett testen zu können. Hier das nicht sonderlich schöne, aber funktionierende Ergebnis:
Beim ADC handelt es sich um den ADCS7476. Er ist zwar nicht ganz günstig, bietet aber einige Vorteile und hat folgende Daten:
Heute warn wir wieder fleißig. Mein Ziel war es heute erste Analogwerte mit dem ADC einzulesen.
Im FPGA wird im Block "ADC" aus dem 100 MHz Systemtakt mit Hilfe eines Zählers ein 20 MHz Takt für den ADC generiert, wobei dieser zurzeit Asynchron ist: 2 Systemtakte high, 3 Systemakte low.
Zu beginn wird CS auf "0" gesetzt (low active) und dadurch der ADC Vorgang gestartet. Nach 3x "0" an SDATA folgen die 12 Datenbits. Anschließend wird CS wieder auf "1" gesetzt und nach insgesammt 20 Takten beginnt das ganze von neuem.
Nachdem der VHDL Code geschrieben wurde kam ein erster Test im Simulator... nach ein paar Fehlerkorrekturen im ADC Block und Erweiterung der Testbench mit Testdaten an SDATA sah das Ergebnis wie folgt aus:
Da die Simulationsergebnisse wie gewünscht aussahen habe ich gleich einen provisorischen Testaufbau zusammengesteckt. Bit 12 bis Bit 5 sollen an den 8 LEDs angezeigt werden (ganz links sind 4 LEDs zu sehen). Über ein Poti kann ein beliebiger Wert zwischen 0V und 3,3V an VIN gelegt werden.
Mit dem Oszi wurden SCLK (blau), CS (grün) und SDATA (gelb) aufgezeichnet:
Auf dem Oszi hat der ADC wunderbar funktioniert. Evtl. muss noch ein wenig an SCLK gearbeitet werden, damit hier steilere Flanken erziehlt werden.
Die 8 LEDs auf dem Evaboard haben auch fast richtig geleuchtet, nur irgendwo hat sich ein Fehler eingeschlichen und die 8. LED blieb dunkel. Die 7. LED stellte das MSB des ADC Wertes dar. Somit wurden nur Bit 12 - Bit 6 angezeigt. Hier muss ich Morgen nochmal ran und auf Fehlersuche gehen.
Beim ADC handelt es sich um den ADCS7476. Er ist zwar nicht ganz günstig, bietet aber einige Vorteile und hat folgende Daten:
- Serieles Dateninterface
- 1MS/sec
- 12 Bit Auflösung
- Betriebsspannung 3,3V und 5V
- CLK bis 20 MHz
Heute warn wir wieder fleißig. Mein Ziel war es heute erste Analogwerte mit dem ADC einzulesen.
Im FPGA wird im Block "ADC" aus dem 100 MHz Systemtakt mit Hilfe eines Zählers ein 20 MHz Takt für den ADC generiert, wobei dieser zurzeit Asynchron ist: 2 Systemtakte high, 3 Systemakte low.
Zu beginn wird CS auf "0" gesetzt (low active) und dadurch der ADC Vorgang gestartet. Nach 3x "0" an SDATA folgen die 12 Datenbits. Anschließend wird CS wieder auf "1" gesetzt und nach insgesammt 20 Takten beginnt das ganze von neuem.
Nachdem der VHDL Code geschrieben wurde kam ein erster Test im Simulator... nach ein paar Fehlerkorrekturen im ADC Block und Erweiterung der Testbench mit Testdaten an SDATA sah das Ergebnis wie folgt aus:
Da die Simulationsergebnisse wie gewünscht aussahen habe ich gleich einen provisorischen Testaufbau zusammengesteckt. Bit 12 bis Bit 5 sollen an den 8 LEDs angezeigt werden (ganz links sind 4 LEDs zu sehen). Über ein Poti kann ein beliebiger Wert zwischen 0V und 3,3V an VIN gelegt werden.
Mit dem Oszi wurden SCLK (blau), CS (grün) und SDATA (gelb) aufgezeichnet:
Auf dem Oszi hat der ADC wunderbar funktioniert. Evtl. muss noch ein wenig an SCLK gearbeitet werden, damit hier steilere Flanken erziehlt werden.
Die 8 LEDs auf dem Evaboard haben auch fast richtig geleuchtet, nur irgendwo hat sich ein Fehler eingeschlichen und die 8. LED blieb dunkel. Die 7. LED stellte das MSB des ADC Wertes dar. Somit wurden nur Bit 12 - Bit 6 angezeigt. Hier muss ich Morgen nochmal ran und auf Fehlersuche gehen.
Freitag, 14. Dezember 2012
Mikrofonverstärker mit OP
Ein Nachtrag zum Labortag vom Donnerstag 13.12. (erstellt am 17.12.)
Nachdem ich letstes mal mit einem einfachen Verstärker aus 2 Transistoren versucht habe das Signal des Mikrofons zu verstärken, habe ich diesmal einen einfachen OP eingesetzt. Die Versorgungsspannung der Mikrofone und der gesamten Schaltung wurde auf 3,3V gesenkt, um später die Spannung direkt auf den ADC geben zu können.
Die Verstärkung ist enorm und die Spannungsankoplung des Mikrofons über den OP scheint besser zu sein, als die Stromankopplung über die Bipolartransistoren. Im folgenden Bild ist die Verstärkung mittels OP zu sehen (gelb Eingang, grün Ausgang):
Leider hat sich gezeigt, dass die billigen Elektret-Kondensatormikrofone eine große Streuung haben, wodurch sich trotz gleichem Verstärkungsfaktor beim OP ein unterschiedliches Bild am Ausgang des OPs ergibt:
Auf dem Steckbrett waren 2 Mikrofone im Abstand von ca. 9 cm angebracht. Obwohl die Verstärkung für beide Mikrofone gleich eingestellt war, geht die grüne Kurve in die Begrenzung, die gelbe allerdings nicht. Der gemessene zeitliche Versatz von 268µs entspricht bei einer Schallgeschwindigkeit von 343 m/s mit 9,2 cm ziemlich genau dem Mikrofonabstand.
Die Frage ist jetzt, ob man mit "Software" auf dem FPGA die Streuung der Mikrofone erschlagen sollte oder die Verstärkung einstellbar macht und für jedes Mikrofon per Hand am Anfang abgleicht.
Als nächstes will ich den Verstärkungsfaktor über ein Poti variabel gestalten. Die Ergebnisse dieses Versuchs werden die oben genannte Frage dann hoffentlich schnell klären.
Nachdem ich letstes mal mit einem einfachen Verstärker aus 2 Transistoren versucht habe das Signal des Mikrofons zu verstärken, habe ich diesmal einen einfachen OP eingesetzt. Die Versorgungsspannung der Mikrofone und der gesamten Schaltung wurde auf 3,3V gesenkt, um später die Spannung direkt auf den ADC geben zu können.
Die Verstärkung ist enorm und die Spannungsankoplung des Mikrofons über den OP scheint besser zu sein, als die Stromankopplung über die Bipolartransistoren. Im folgenden Bild ist die Verstärkung mittels OP zu sehen (gelb Eingang, grün Ausgang):
Leider hat sich gezeigt, dass die billigen Elektret-Kondensatormikrofone eine große Streuung haben, wodurch sich trotz gleichem Verstärkungsfaktor beim OP ein unterschiedliches Bild am Ausgang des OPs ergibt:
Auf dem Steckbrett waren 2 Mikrofone im Abstand von ca. 9 cm angebracht. Obwohl die Verstärkung für beide Mikrofone gleich eingestellt war, geht die grüne Kurve in die Begrenzung, die gelbe allerdings nicht. Der gemessene zeitliche Versatz von 268µs entspricht bei einer Schallgeschwindigkeit von 343 m/s mit 9,2 cm ziemlich genau dem Mikrofonabstand.
Die Frage ist jetzt, ob man mit "Software" auf dem FPGA die Streuung der Mikrofone erschlagen sollte oder die Verstärkung einstellbar macht und für jedes Mikrofon per Hand am Anfang abgleicht.
Als nächstes will ich den Verstärkungsfaktor über ein Poti variabel gestalten. Die Ergebnisse dieses Versuchs werden die oben genannte Frage dann hoffentlich schnell klären.
Donnerstag, 13. Dezember 2012
Das Kreuz mit dem Logarithmus
Es ist ein neuer Tag im Labor. FPGA-Implementierung steht an. Die Ansteuerung des MBI5030 läuft mit einem Grayscaleclock von 6,25 MHz, da somit die Teilung des 100 MHz FPGA-Clocks bequem mit Hilfe eines 4 Bit Vektors zu bewerkstelligen ist. Für den Dataclock läuft es genauso, lediglich mit 5 Bit und einer Frequenz von 3,125 MHz. Dadurch erreichen wir bei 12-Bit Betrieb der Treiber und 192 Kanälen pro Rahmen eine Bildwiederholrate von 737 Hz.
Sollte genügen um kein Flackern zu sehen ;)
Wenn wir EMV Probleme auf unserer Datenleitung bekommen, haben wir auch noch genug Luft um die Frequenz zu senken. Und wenn das auch noch keine Besserung bringt, dann teilen wir unsere Datenleitung auf und schieben die Bits parallel raus.
Intern arbeiten wir mit 8 Bit für die einzelnen Farbwerte. Die Treiber wollen allerdings 12 Bit haben. Und dann ist die Lichtstärke der Dioden auch nicht linear zur Stromaufnahme... Die Lösung des Problems: im FPGA eine logarithmische Wertetabelle mit 256 12-Bit Werten. Einfach, aber sehr effektiv.
Sollte genügen um kein Flackern zu sehen ;)
Wenn wir EMV Probleme auf unserer Datenleitung bekommen, haben wir auch noch genug Luft um die Frequenz zu senken. Und wenn das auch noch keine Besserung bringt, dann teilen wir unsere Datenleitung auf und schieben die Bits parallel raus.
Intern arbeiten wir mit 8 Bit für die einzelnen Farbwerte. Die Treiber wollen allerdings 12 Bit haben. Und dann ist die Lichtstärke der Dioden auch nicht linear zur Stromaufnahme... Die Lösung des Problems: im FPGA eine logarithmische Wertetabelle mit 256 12-Bit Werten. Einfach, aber sehr effektiv.
Donnerstag, 6. Dezember 2012
Mikrofone unter Spannung
Heute kam eine Reichelt Bestellung mit Messleitungen, 10 Mikrofonen, ein paar schneller OPs und allerlei anderer toller Sachen. Das Auspacken war - wie bei jeder Reichelt Bestellung - fast wie Weihnachten ;) So können wir dann hoffentlich auch zwischen Weihnachten und Neujahr daheim weiter arbeiten.
Wie der Christian schon geschrieben hat, war gestern wieder ein Labortag für uns. Während er die ersten Versuche mit den LEDs machte, habe ich ein paar Messungen mit 2 einfachen Elektret-Kondensator Mikrofonen gemacht.
Das 1. Bild zeigt den Phasenversatz, wie er beim Aufzeichnen eines Klatschens entsteht, wenn der Schall zuerst das eine, dann das andere Mikrofon erreicht. Hier waren die Mikrofone jeweils mit einem 11 kOhm Widerstand in Reihe an 10V DC. Die Spannung wurde direkt an den Mikrofonen gemessen.
Der Laufzeitunterschied beträgt 270µs, was bei einer Schallgeschwindigkeit von 343 m/s einem Mikrofonabstand von 9,3 cm entspricht. Die Mikrofone hatten bei dem Messaufbau einen Abstand von ca. 11 cm, allerdings war die Schallquelle nicht genau auf einer Geraden mit den beiden Mikrofonen. Zu beachten ist, dass beim gelben Signalverlauf die 1. und 2. Amplitude annähernd gleich ist. Solche Fälle sind bei der späteren Laufzeitauswertung auf dem FPGA zu berücksichtigen.
Im 2. Bild wurde die Messspannung am Mikrofon mit einer einfachen Verstärkerschaltung aus 2 Transistoren verstärkt. Der grüne Signalverlauf zeigt die gemessene Spannung am Mikrofon, der gelbe Signalverlauf die Spannung am Verstärkerausgang. Bei dieser Messung wurde ein Fingerschnipsen aufgezeichnet. Die Versorgungsspannung wurde auf 5V DC reduziert.
Soweit zum gestrigen Laborbesuch. Bis Mitte Januar wollen wir einen funktionierenden Stand unserer LED Matrix haben. Es liegt also noch viel Arbeit vor uns.
Wie der Christian schon geschrieben hat, war gestern wieder ein Labortag für uns. Während er die ersten Versuche mit den LEDs machte, habe ich ein paar Messungen mit 2 einfachen Elektret-Kondensator Mikrofonen gemacht.
Das 1. Bild zeigt den Phasenversatz, wie er beim Aufzeichnen eines Klatschens entsteht, wenn der Schall zuerst das eine, dann das andere Mikrofon erreicht. Hier waren die Mikrofone jeweils mit einem 11 kOhm Widerstand in Reihe an 10V DC. Die Spannung wurde direkt an den Mikrofonen gemessen.
Der Laufzeitunterschied beträgt 270µs, was bei einer Schallgeschwindigkeit von 343 m/s einem Mikrofonabstand von 9,3 cm entspricht. Die Mikrofone hatten bei dem Messaufbau einen Abstand von ca. 11 cm, allerdings war die Schallquelle nicht genau auf einer Geraden mit den beiden Mikrofonen. Zu beachten ist, dass beim gelben Signalverlauf die 1. und 2. Amplitude annähernd gleich ist. Solche Fälle sind bei der späteren Laufzeitauswertung auf dem FPGA zu berücksichtigen.
Im 2. Bild wurde die Messspannung am Mikrofon mit einer einfachen Verstärkerschaltung aus 2 Transistoren verstärkt. Der grüne Signalverlauf zeigt die gemessene Spannung am Mikrofon, der gelbe Signalverlauf die Spannung am Verstärkerausgang. Bei dieser Messung wurde ein Fingerschnipsen aufgezeichnet. Die Versorgungsspannung wurde auf 5V DC reduziert.
Soweit zum gestrigen Laborbesuch. Bis Mitte Januar wollen wir einen funktionierenden Stand unserer LED Matrix haben. Es liegt also noch viel Arbeit vor uns.
Mittwoch, 5. Dezember 2012
LED Tests
So da unsere Bestellung aus China noch nicht da ist, hat ein lieber Kommilitone ein paar Reste seiner LED-Stribes geopfert. Von denen haben wir nun 4 Teilstücke an 12V geklemmt um mal nach der Helligkeit zu sehen, da die gleichen LEDs verbaut wurden die wir geliefert bekommen.
Also reinschauen kann man nicht mehr, müssen dann aber mal schauen wie sehr das Plexiglas streut. Mit einem Blatt Papier war es fast etwas dunkel. Dennoch sollten uns 4 LEDs pro Pixel reichen.
Also reinschauen kann man nicht mehr, müssen dann aber mal schauen wie sehr das Plexiglas streut. Mit einem Blatt Papier war es fast etwas dunkel. Dennoch sollten uns 4 LEDs pro Pixel reichen.
Dienstag, 4. Dezember 2012
Schritt für Schritt
Langsam aber sicher geht es voran. Sitzen gerade im Labor und machen erste Laufzeitmessungen mit 2 Mikros. Eines haben wir schon auf den Friedhof geschickt ;) aber in der Gruschelkiste waren ja noch mehr...
Erste Schwierigkeiten, wie unterscheiden wir Klatschen von normalen, lauten Umgebungsgeräuschen?
Die zweite Testplatine mit unseren MBI5030 LED Treibern haben wir auch gelötet, um mal die Reihenschaltung der FIFOs zu testen. Jetzt arbeite ich mich durchs Datenblatt und fange dann an die Ansteuerung auf dem FPGA zu implementieren.
Erste Schwierigkeiten, wie unterscheiden wir Klatschen von normalen, lauten Umgebungsgeräuschen?
Die zweite Testplatine mit unseren MBI5030 LED Treibern haben wir auch gelötet, um mal die Reihenschaltung der FIFOs zu testen. Jetzt arbeite ich mich durchs Datenblatt und fange dann an die Ansteuerung auf dem FPGA zu implementieren.
Montag, 26. November 2012
Robotik gibt es auch noch...
So der erste Versuch für die Robotikvorlesung steht am Donnerstag an. Das Programm ist nun fertig. Ein, zwei kleine Verbesserungen werden wir morgen noch einbinden, aber danach ist wieder volle Leistung in der Bachelorarbeit angedacht.
Platinen zum basteln haben wir nun schon für unsere LED Treiber. Schön geeignet zum Kabel anlöten. Ein Layout für unsere Pixel gibt es auch schon. Wenn nun noch unsere 3000 SMD 5050 LEDs aus China ankommen werden wir erste Hardwaretests starten. Paar Litzen verlöten, ans FPGA hängen und mal sehen, wie hell wir es bekommen.
Hoffentlich können wir dann noch schlafen wenn der Rahmen irgendwann als Uhr in unseren Zimmern hängt.
Bei 64 Pixeln mit je 4 LEDs bei 20mA können wir vllt doch die Sonne aufgehen lassen wann wir es wollen :D
Platinen zum basteln haben wir nun schon für unsere LED Treiber. Schön geeignet zum Kabel anlöten. Ein Layout für unsere Pixel gibt es auch schon. Wenn nun noch unsere 3000 SMD 5050 LEDs aus China ankommen werden wir erste Hardwaretests starten. Paar Litzen verlöten, ans FPGA hängen und mal sehen, wie hell wir es bekommen.
Hoffentlich können wir dann noch schlafen wenn der Rahmen irgendwann als Uhr in unseren Zimmern hängt.
Bei 64 Pixeln mit je 4 LEDs bei 20mA können wir vllt doch die Sonne aufgehen lassen wann wir es wollen :D
Freitag, 23. November 2012
Pi funktioniert
Heute kamen ein paar Micro-USB Kabel mit der Post, denn beim Raspberri Pi (kurz Pi) war leider keins dabei.
Noch schnell das Raspbian wheezy von http://www.raspberrypi.org/downloads heruntergeladen, mit dem Tool Win32DiskImager auf SD Karte gespeichert, ins Pi rein und schon kann ich meinen ersten Blogeintrag von meinem Pi aus erstellen :)
Das Pi ist per WLAN USB Dongle ans Internet angebunden. Am 2. USB Port ist ein USB Dongle für die Kabellose Maus bzw. Tastatur.
Der erste Eindruck ist nicht schlecht, nur der Bootvorgang dauert leider recht lange. Daher müssen wir später in unseren LED-Rahmen auch ohne Pi die Anzeige ansteuern, um den Bootvorgang zu überbrücken.
Noch schnell das Raspbian wheezy von http://www.raspberrypi.org/downloads heruntergeladen, mit dem Tool Win32DiskImager auf SD Karte gespeichert, ins Pi rein und schon kann ich meinen ersten Blogeintrag von meinem Pi aus erstellen :)
Das Pi ist per WLAN USB Dongle ans Internet angebunden. Am 2. USB Port ist ein USB Dongle für die Kabellose Maus bzw. Tastatur.
Der erste Eindruck ist nicht schlecht, nur der Bootvorgang dauert leider recht lange. Daher müssen wir später in unseren LED-Rahmen auch ohne Pi die Anzeige ansteuern, um den Bootvorgang zu überbrücken.
Freitag, 16. November 2012
Ihre Bestellung wurde versendet.
Heute kam von Farnell die Versandbestätigung und mein Raspberry PI ist zu mir unterwegs. Am Montag soll es ankommen. Der Christian hat seins schon, es kann also bald richtig los gehn!
Geplant ist, die gesamte "Grafik" (sofern man bei angepeilten 8x8 Pixel Auflösung davon reden kann...) auf dem Raspberry PI zu berechnen. Anschließend sollen die Bilddaten an das FPGA übergeben werden. Das FPGA wiederum steuert dann die LED Treiber und somit die einzelnen Pixel an. Umgedreht wird auf dem FPGA die Auswertung der Schallquellen durchgeführt und die aufbereiteten Informationen dem Raspberry übergeben.
Geplant ist, die gesamte "Grafik" (sofern man bei angepeilten 8x8 Pixel Auflösung davon reden kann...) auf dem Raspberry PI zu berechnen. Anschließend sollen die Bilddaten an das FPGA übergeben werden. Das FPGA wiederum steuert dann die LED Treiber und somit die einzelnen Pixel an. Umgedreht wird auf dem FPGA die Auswertung der Schallquellen durchgeführt und die aufbereiteten Informationen dem Raspberry übergeben.
Dienstag, 13. November 2012
Worum es geht
Ziel ist es eine RGB-LED Matrix zu entwickeln, die auf vielfältige Weise gesteuert werden kann.
Die Entwicklungsarbeit ist in zwei Bachelorarbeiten aufgeteilt:
Die Entwicklungsarbeit ist in zwei Bachelorarbeiten aufgeteilt:
- Ortung einer Schallquelle mittels FPGA um ein embedded System zu steuern
- Dekodierung eines Videosignals mittels FPGA und anschließender Anzeige auf einer RGB-LED-Matrix
Der Anfang ist getan
Nun ist es endlich soweit. Die Idee die seit einiger Zeit in unserem Kopf herumgeistert wurde zu Papier gebracht und in Themen für zwei Bachelorarbeiten unterteilt.
Die erste Hürde, nämlich die Unterschrift des Prüfungskommissionsvorsitzenden, ist nun genommen und die Anmeldungen liegen unterschrieben in unseren Rucksäcken.
Die erste Hürde, nämlich die Unterschrift des Prüfungskommissionsvorsitzenden, ist nun genommen und die Anmeldungen liegen unterschrieben in unseren Rucksäcken.
Abonnieren
Posts (Atom)