Hi Leute, ich bin neu hier und beschäftige mich erst seit Kurzen im Rahmen meiner Doktorandenstelle mit Microcontrollern. Wir arbeiten gerade an einer Studie / einem Experiment, bei dem über Java via Seriellem oder Parallelem Port 16 LEDs und 16 Lautsprecher angesprochen werden sollen. Erfahrung in Sachen Programmierung habe ich, mit Microcontrollern nun aber gar nicht bzw. arbeite mich da nebenbei etwas en. Nun hilft mir aber ein Dipl.-Ing., der die Dinger programmieren kann, doch würde ich gerne auch parallel schonmal noch ein paar Lösungsvorschläge einholen. Nun wäre die Frage: Welche(n) Controller würdet ihr für folgende Anforderungen empfehlen? - 16 LEDs sollen angesteuert werden, die in Ihrer Helligkeit verändert werden sollen - Die LEDs werden zu Beginn nur einfarbig sein, später sollen RGB-LEDs zum Einsatz kommen. - 16 Lautsprecher (ca. 15 Watt jeweils) werden angesteuert - Es soll ein reiner Ton (also eine bestimmte Sinuswelle) abgespielt werden können - zusätzlich soll auch ein "weißes Rauschen" (also alle Frequenzen gleichzeitig) abgespielt werden können. - Beide Signale sollten bereits im Controller (in welcher Form auch immer) gespeichert sein Die LEDs und Lautsprecher sollen gleichzeitig (und nicht-gleichzeitig) und zeitlich sehr genau angesteuert werden. Generelle Frage: Inwiefern ist es möglich, ein Signal, das aus dem Parallelport kommt, in ein Tonsignal umzuwandeln? Ist das viel Aufwand bzw. Kostensintensiv? Bisher wurde, wenn ich das richtig verstanden habe, pro LED ein Controller (AtMega8 glaube ich) genutzt, um eine Pulsweitenmodulation durchzuführen. Nun sollen entsprechend 16 Controller für die LEDs verbaut werden. Gibt es da noch eine Alternative? Wie würdet ihr so etwas aufbauen? (Ich gebe gerne noch genauere Informationen, weiß aber nun nicht genau, was da noch hilfreich wäre)
Ralf S. schrieb: > Bisher wurde, wenn ich das richtig verstanden habe, pro LED ein > Controller (AtMega8 glaube ich) genutzt, um eine Pulsweitenmodulation > durchzuführen. Nun sollen entsprechend 16 Controller für die LEDs > verbaut werden. Das lässt sich locker mit einem einzigen Controller erledigen. Beim Thema RGB kommt es dann ein bisschen auf den LED-Typ an. Zur Lautsprecheransteuerung kann ich wenig sagen, da wirst du noch andere Bauelemente brauchen, weil die üblichen Mikrocontroller nicht 16 x 15 Watt Leistung bringen.
>Zur Lautsprecheransteuerung kann ich wenig sagen, da wirst du noch >andere Bauelemente brauchen, weil die üblichen Mikrocontroller nicht 16 >x 15 Watt Leistung bringen. Für jeden Lautsprecher habe ich bereits einen Verstärker. Der Informatiker / Ing. meinte, er würde pro LED den internen Taktgeber nehmen, da das besser sei, als wenn man den Controller die Pulsweite für jede LED einzeln berechnen lassen würde. (Kann natürlich nur das weitergeben, was ich meine verstandenzu haben)
Ralf S. schrieb: > Der Informatiker / Ing. meinte, er würde pro LED den internen Taktgeber > nehmen, da das besser sei, als wenn man den Controller die Pulsweite für > jede LED einzeln berechnen lassen würde. (Kann natürlich nur das > weitergeben, was ich meine verstandenzu haben) Wenn der betreffende Inform./Ing. derjenige ist, der das alles dann bauen muss, solltest du ihm vielleicht ein bisschen Freiheit lassen. Controller sind relativ billig, und wenn es um eine Einzelanfertigung geht, sind die Ingenieur-Stunden sowieso viel teurer als die Hardware. Falls du aber das Ziel hast, Hardwarekosten zu sparen, weil du eine Serie auflegen willst, wirst du nicht drum herumkommen, die Gesamtsteuerung in einen einzigen Controller zu pressen. Von der Leistung her ist das ohne weiteres möglich. Wahrscheinlich reicht sogar ein einfacher ATmega324A - oder ein entsprechender PIC. Den "internen Taktgeber" kann man ja nicht nur für eine LED, sondern auch für alle verwenden. Ich seh da keinen Widerspruch.
16 LED gleichzeitig direkt ansteuern kann u.U. wegen des Maximalstroms des µC problematisch werden. Kann man aber simpel mit 2 Treiber-IC (2x8) lösen.
usuru schrieb: > 16 LED gleichzeitig direkt ansteuern kann u.U. wegen des Maximalstroms > des µC problematisch werden. Kann man aber simpel mit 2 Treiber-IC (2x8) > lösen. Ja, bei Power-LEDs muss man da sicher aufpassen, aber bei normalen LEDs geht das problemlos, notfalls schaltet man 8 gegen GND und 8 gegen VCC.
Alternativ könnte man für die LEDs auch einen LED-Treiber benutzen. Ich habe letzt den TLC5940 verwendet. Der kann direkt 16 LEDs steuern und er verbraucht nicht allzu viele Pins am µC. Weiterer Vorteil ist, dass man mehrere (also für RGB 3 Stück) leicht kaskadieren kann und somit bei erweiterung keine zusätzlichen µC-Ausgänge benötigt werden. Mit Lautsprecherkram kenne ich mich leider auch nicht aus aber je nach verwendetem µC sollten dann noch genug Pins übrig sein um jeweils einen mit einem Verstärker zu verbinden.
Das hört sich irgendwie nach Multisensorik an. Irgendwas mit dem Gehirn? Wenn ja, darf ich fragen welche Stadt?
Ralf S. schrieb: > Die LEDs und Lautsprecher sollen gleichzeitig (und nicht-gleichzeitig) > und zeitlich sehr genau angesteuert werden. Was ist mit "genau" gemeint? Sekunden, Millisekunden, Mikrosekunden?
Für Audio ist der dsPIC33FJ128GP802/804 sehr praktisch. Der enthält bereits einen Stero Audio DAC. Ihr braucht nur noch einen OpAmp pro Kanal, zB MCP6002, und dann kommt Ton raus, und zwar in ordentlicher Qualität. Für die Leds solltet Ihr tatsächlich zu passenden Led-Treiberbausteinen wie dem erwähnten TLC5940 (es gibt noch andere aus der TLC59*-Reihe) greifen. fchk
16 RGB LEDs sind ja eigentlich 48 LEDs. Wenn die 16 LEDs alle noch verschiedene Farben darstellen sollen können, dann brauchst da 48 PWM-Ausgänge. Da schlucken Standard-RGB-LEDs dann schon zusammen einen guten Ampere. Bei den Atmels darf man zwar einen Pin mit 20 mA belasten, was prinzipiell für eine LED reicht, aber alle Pins zusammen durften glaube ich nicht mehr wie 200mA verbrauchen. Ich glaube ich hätte mir da je einen Atmega für jede Farbe geholt. Also einen für die 16 blauen, einen für die 16 grünen und einen für die 16 roten LEDs. Und dann einen 4. Atmega, welcher die Kommunikation mit dem PC übernimmt, RGB-Farbcodes für die 16 RGB-LED entgegennimmt, dann den passenden DutyCycle für jede LED berechnet und diese dann per I2C an die 3 anderen Atmegas sendet. 100 Hz reichen ja locker aus, damit so eine LED nicht flackert. Da kannst dir dann einfach per Software 16 PWM-Ausgänge für die LEDs basteln. An die 16 Ausgänge dann halt zwei 8er-Transistor-Arrays. Ist dann vielleicht nicht die billigste Lösung, aber definitiv recht einfach. Für die Atmegas findest hier genug Tutorials (PWM, I2C Master/Slave, LED Fading, ...), die kann man gut Löten und die 3 Atmels mit den LEDs tun ja das gleiche. Da kannst die gleiche Hardware und Software gleich drei mal verwenden. Für Audio ist ein Atmel aber nicht wirklich toll. Da macht ein ARM sicher eine bessere Figur. Sonst halt statt dem 4. Atmel, welcher als Master arbeitet, einen anderen uC nehmen. Mit I2C kannst dich ja auch zwischen verschiedensten uCs unterhalten. Dann kann der auch gleich die Audioausgabe mitübernehmen.
Vielen Dank schonmal für die Rückmeldung! Ich werde das mal mit dem Ing. durchsprechen. Zu den LEDs: Es werden immer nur maximal 2 oder 3 an sein. Alle 16 auf keinen Fall. >Für Audio ist der dsPIC33FJ128GP802/804 sehr praktisch. Der enthält >bereits einen Stero Audio DAC. Ihr braucht nur noch einen OpAmp pro >Kanal, zB MCP6002, und dann kommt Ton raus, und zwar in ordentlicher >Qualität. > >Für die Leds solltet Ihr tatsächlich zu passenden Led-Treiberbausteinen >wie dem erwähnten TLC5940 (es gibt noch andere aus der TLC59*-Reihe) >greifen. > >fchk Meinst du damit, dass ich beispielsweise auch eine Sounddatei (natürlich als Datenstrom über bspw. einen Parallelport) einspielen und den Ton wiedergeben kann? >Was ist mit "genau" gemeint? Sekunden, Millisekunden, Mikrosekunden? Millisekunden reicht aus - ein Zeitfenster von 1 bis maximal 5 ms ist in Ordnung. Je weniger, desto besser natürlich, da mir Java und Windows ohnehin noch (so gut wie gar nicht feststellbare) Verzögerungen bescheren. >Das hört sich irgendwie nach Multisensorik an. Irgendwas mit dem Gehirn? >Wenn ja, darf ich fragen welche Stadt? Richtig, es geht um Multisensorik. Ich arbeite im Fachbereich Psychologie in Hamburg.
Schaut euch mal die WS2803 LED Controller von Worldsemi an... sehr günstige China ware (1,50 € x 3), einfach anzusteuern (SPI) und die LED Ströme sind kein Problem... Sinustöne könne eigentlich auch alle Kontroller mit nen bissel Software + Tiefpass halbwegs gut erzeugen. Fragt sich halt nur, welche Quallität von nöten is. Ansonsten würde ich noch ein Serial zu USB verwenden um mal nen bisschen auf dem aktuellem Technikstand zu bleiben. Das Timing von 5ms sollte mit USB und Windows? noch ganz gut funktionieren.
Serielle Datenströme sind aber recht "langsam" - oder? Zumindest langsamer als Datenströme über den Parallelport. Ich möchte vermeiden, dass noch mehr Verzögerungen als Nötig hinzukommen. Zum Sound: Wenn, dann sollten entweder bestimmte Töne (Sinuskurven, "weißes Rauschen") auf dem Controller gespeichert sein oder ich sende ein Tonsignal (bspw. Sprache oder Musik) an den Controller und es wird dieser dann abgespielt.
16 Leds anzusteuernper PWM , ist schon einer mächtig unterfordert. Zur Helligkeit hast du nichts gesagt. also kann man auch nichts zum Leistungsbedarf sagen. 16 Megas dafür, da schüttel ich nur mit dem Kopf, da ist die Frage ob du den richtigen hast der es umsetzt. Außerdem ist nichts gesagt über die Synchonität. die 16 Megas müssen ja auch ihre Daten austauschen um zu wissen was sie evt manchen müssen. Die Lautspecher anzusteuern ist schon etwas schwieriger, zumal du von einem reinen Sinus geredet hast, wie "rein" muß er sein? reiner Sinus ist schon recht Komplex, brauchst du eine evt gute D/A wandler dafür. Müssen die Lautsprecher Phasensynchron sein, oder dürfen sie es sogar nicht, oder können sie es nicht weil immer nur einer an ist? Das Speichern der Töne ist kein Problem, mehr die Qualität die benötigt wird um es umzuwandeln, 1Bit , 8 Bit, 16bit oder nmehr?. Wieviel Kanale gleichzeitig aktiv sind. usw. Fragen über Fragen.
Ralf S. schrieb: > Serielle Datenströme sind aber recht "langsam" - oder? Ich würde einfach die Aufgabe dem Dipl. Ing. überlassen...
Wenn ein PC sowieso alles steuert kannst du die Audiowiedergabe auch vom PC aus machen.. Per 3,5mm Klinke aus der Soundkarte raus direkt in den Verstärker, die Lautstärke kannst du dann bequem vom PC aus steuern.
ralf_suerig schrieb: >>Für Audio ist der dsPIC33FJ128GP802/804 sehr praktisch. Der enthält >bereits > einen Stero Audio DAC. Ihr braucht nur noch einen OpAmp pro >>Kanal, zB MCP6002, und dann kommt Ton raus, und zwar in ordentlicher >>Qualität. > Meinst du damit, dass ich beispielsweise auch eine Sounddatei (natürlich > als Datenstrom über bspw. einen Parallelport) einspielen und den Ton > wiedergeben kann? Genau. Für Sinus brauchst Du ja nur eine ganze Periode, die immer wieder abgespielt wird, für weißes Rauschen ein Stück möglichst zufälliger Zufallszahlen. Das wird problemlos mit im 128k Flash Platz finden. Der DAC hat folgende Eigenschaftem • 16-bit resolution (14-bit accuracy) • Second-Order Digital Delta-Sigma Modulator • 256 X Over-Sampling Ratio • 128-Tap FIR Current-Steering Analog Reconstruction Filter • 100 ksps Maximum Sampling Rate • User controllable Sample Clock • Input Frequency 45 kHz max • Differential Analog Outputs • Signal-To-Noise: 90 dB • 4-deep input Buffer • 16-bit Processor I/O, and DMA interfaces Müssen die einzelnen Audioquellen korreliert sein, oder spielt die Phasenbeziehung zwischen den einzelnen Quellen keine Rolle? Wenn die Quellen korreliert sein müssen, dann wird das ganze deutlich komplexer. Wenn nicht, dann nimmst Du einfach pro Lautsprecher einen solchen dsPIC - die Teile sind billig. >>Wenn ja, darf ich fragen welche Stadt? > Richtig, es geht um Multisensorik. Ich arbeite im Fachbereich > Psychologie in Hamburg. Aha. Gar nicht weit weg. fchk
Frank K. schrieb: > Genau. ..., für weißes Rauschen ein Stück möglichst zufälliger > Zufallszahlen. Das wird problemlos mit im 128k Flash Platz finden. Weißes Rauschen wird man wohl kaum als fertiges Sample abspeichern. Viel einfacher ist es, ein rückgekoppeltes Schieberegister zu programmieren und damit eine PRBN-Folge zu erzeugen.
Danke für die vielen Fragen :) Also: Eigentlich ist die Sinusfunktion nur eine "Notlösung", so lange wir es nicht hinbekommen normale Sounds (also kurze Worte, ein Rauschen oder anderes) abzuspielen. Die Soundlänge wird da maximal 3 Sekunden betragen. (eher sogar eine Sekunde). Minimal ca. 20 ms. Die Tonqualität sollte dabei möglichst hoch sein. Also 16 bit sollten es schon sein, da ja auch Sprache übermittelt wird. Die Lautsprecher sollten, wenn MÖGLICH, phasensynchron sein - leider praktisch kaum möglich, da Java ja nicht 100% ig zeitgenau ist und somit immer eine bestimmte Verzögerung vorherrscht, die nicht genau definierbar ist. Natürlich könnte man dann innerhalb der Architektur noch etwas versuchen zu retten, aber der Aufwand wäre zu hoch, denke ich. Es wird (so die Planung bisher) immer nur ein Lautsprecher aktiv sein, aber dafür bspw. 20 oder 50 ms später der nächste. Aber da haben wir glaube ich nicht mehr das Problem mit der Phase... Übrigens: Ja, bei den 16 ATMegas war ich auch etwas verwirrt, aber da haben wir nun die Unklarheiten beseitigt und nun werden wir für die RGB LEDs für jede Farbe einen Controller verwenden. Sprich, 3 Controller.
Ich habe jetzt nicht alles gelesen, aber Ein STM32 hat bis zu 32 PWM Kanäle, damit könnte man viele LED's dimmen. Auf dem STM32F4DISCOVERY Board wär auch ein Audio-Ausgang drauf, ich weiß jetzt nicht wie viele Timer/PWM Ports jetzt noch frei sind. Schaue mal hier im Artikel STM32 vorbei.
@ fchk: Wo kommst du denn her? Und in welchem Fachbereich bist du tätig? Und danke für die komplexe Anmerkung - ich leite das alles immer (etwas gefiltert) an den Ing. weiter und wir diskutieren darüber, ob es auch für Experimentalbedingungen durchführbar / praktikabel ist.
Markus Müller schrieb: > Ein STM32 hat bis zu 32 PWM Kanäle, damit könnte man viele LED's dimmen. Aber keine 16 RGB (48 Einzelne) LEDs ;) Ralf S. schrieb: > Übrigens: Ja, bei den 16 ATMegas war ich auch etwas verwirrt, aber da > haben wir nun die Unklarheiten beseitigt und nun werden wir für die RGB > LEDs für jede Farbe einen Controller verwenden. Sprich, 3 Controller. Die TLC5940's sehen doch ganz gut aus und machen genau das gleiche. Warum nicht die benutzen? Da spart man sich die Programmierung von einem (zugegeben nicht sooo aufwendigem) Programm. Man könnte sich da evtl auch mit Multiplexen ein paar PWM-Ausgänge einsparen. Ralf S. schrieb: > Serielle Datenströme sind aber recht "langsam" - oder? Zumindest > langsamer als Datenströme über den Parallelport. Nicht umbedingt. Bei Wikipedia ist beim LPT-Port eine theoretische Datenrate von 4MByte/sek. Bei USB gibt es verschiedene Geschwindigkeiten. Lowspeed, Fullspeed, Highspeed, Superspeed (USB3.0). Ein PIC z.B. kann USB Fullspeed, der mit 1,5MByte/sek Brutto angegeben ist. In dem Fall wäre der LPT-Port warscheinlich schneller, doch bei Highspeed (60MByte/sek) oder Superspeed (500Mbyte/sek) wäre es anders rum. Ob Parallel oder Seriell sagt erstmal nichts über Geschwindigkeit aus. Die Frage ist nur, womit man arbeiten will und da musst du dann deinen Ing. fragen. Ohne zweifel ist USB aktueller. Wenn man ein neues Projekt auf eine sogut wie ausgestorbene Schnittstelle aufbaut, dann ist man an "alte" PCs gebunden. USB hat jeder neue PC und Laptop, bei LPT muss man oft schonmal nachrüsten oder einen Adapter USB->LPT kaufen.. Doch damit ist es nicht getestet (also gehts damit evtl garnicht) und Geschwindigkeitstechnisch wird man auch Einbuße machen. Ich würde also gucken, ob mir die Fullspeed-Geschwindigkeit ausreicht und wenn nicht, würde ich einen µC nehmen, der eine Highspeed-Schnittstelle hat. Aufjedenfall USB aus oben genannten Grund. Und Geschwindigkeitstechnisch ist zumindest bei Highspeed USB auch vorne.
Für Sprache brauch man keine 16 Bit, Sprache ist sehr anspruchslos. Wieviel man für rauschen brauch weis ich nicht, könnte trivial oder recht anspruchsvoll sein. Ich weis nur gutes reines Rauschen zu erzeugen ist nicht trivial. Ich würde evt einfach ne kleine Schaltung nehmen die die Analogsignale umschaltet, dann bauch der micro nur sagen Lautsprecher 2 du gibst jetzt Kanal n wieder, oder bist aus. er produziert dann auf Kanal n das signal. wenn du nur einen Lautsprecher zur zeit hast brauchst du nur einen kanal. evt wenn du mehr planst je gleichzeitige Wiedergabe einen, es sei denn sie geben das gleiche wieder. es könnte auf einem ja auch ein generiertes rauschen liegen. für soetwas würde ein atmega z.B. reichen. und gleichzeitig macht er noch software pwm für die beiden leds und das steuerprogramm des Ablaufes könnte er auch koordinieren um mit <1ms zu reagieren, und hätte noch immer zeit sich zu langweilen.
Denk dran, dass Du vermutlich die Signale rampen musst. D.h. Du kannst nicht das erste Sample in voller Lautstärke abspielen, sondern brauchst eine 5 ms oder so Rampe. Von der Qualität würde ich mich nicht wuschig machen lassen. Für das meiste in dem Bereich bist Du mit 12-14 bit gut dabei.
OK, danke. Ich bin kommende Woche im Urlaub und dann rede ich mit dem Ing. nochmal im Detail darüber. Viele eurer Vorschläge hat er auch bereits übernommen oder hat die selbst (unabhängig davon) ins Spiel gebracht. Die Sache mit der Sprache und der Speicherung - da muss ich mit ihm nochmal im Detail drüber reden. @ rbs_phoenix: Die Ansteuerung von USB ist mit Java ziemlich nervig. Da gibt es X Projekte, die teilweise nicht weitergeführt werden oder die ich nicht 100% ig checke (werde mich da also noch weiter reinlesen müssen). Wir haben aber hier ein Programm, welches aus einem USB Port eine Serielle Schnittstelle simuliert, so dass ich die dann darüber ansprecher kann. Sprich, ich schicke an die Serielle Schnittstelle ein Signal, das wird dann aber an den USB Port geschickt. Das wäre zumindest ein Kompromiss zwischen der sehr einfachen Programmierung von Java -> Seriell und dem Problem, alles auf einen aktuellen technischen Standard zu heben. Danke nochmals! Gruß, Ralf
Ralf S. schrieb: > Sprich, ich schicke an die Serielle Schnittstelle ein > Signal, das wird dann aber an den USB Port geschickt. Das wäre zumindest > ein Kompromiss zwischen der sehr einfachen Programmierung von Java -> > Seriell und dem Problem, alles auf einen aktuellen technischen Standard > zu heben. Allerdings hat der RS232 eine deutlich kleinere Datenrate. Da sind dann bis 2Meter Kabellänge 115.200Baud -> 115200bit/sek empfohlen. Das sind ca 14kByte/sek (statt z.B. 1536kByte/sek bei USB Fullspeed). Darüber Sounddateien zu schicken, die Qualitativ hochwertig sind, stell ich mir stressig vor. Und du weißt nicht (kannst du aber ggf messen), welche Verzögerung die Wandlung von USB nach RS232 bringt und ob die ok ist. Wenn ich dich richtig verstanden habe, soll das ja so schnell gehen wie möglich. Ralf S. schrieb: > Die Ansteuerung von USB ist mit Java ziemlich nervig. Da gibt es X > Projekte, die teilweise nicht weitergeführt werden oder die ich nicht > 100% ig checke (werde mich da also noch weiter reinlesen müssen). Wird Java nicht unter Fans als viel besser als das nervige, alte C/C++ angesehen? ;)
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.