Steuerung externer Geräte (eigenbau)

[jfheins]

ja also das Problem was ich bei dem Würfel oder der Doppelhelix sehe, ist die Ansteuerung...

Ein paar LED's kann man noch über den COM Port ohne µC ansteuern (direkt an die Datenleitungen hängen, ggf. mit externer Spannugnversorgung+Transistor) danach braucht man eben einen µC mit möglichst vielen IO Pins. Dann hängt an jedem IO Pin eine LED und man kann per Software den PIN entweder auf +5V oder auf Masse schalten.

Das Ding: http://www.atmel.com/dyn/products/pr...bfamily_id=760 (habe da jetzt einfach mal irgendwas mit vielen IO Pins rausgesucht, k.A. wie teuer der ist) hat 86 IO Pins macht bis zu 86 LED's die man damit steuern kann.
Das Löten auf der Platine wird dann wahrscheinlich etwas haarig, aber irgendwo muss man Kompromisse machen

Dann brauchst du natürlich noch einen Lötkolben, die LED's und eine Möglichkeit, Platinen zu fertigen.

@ulilüding: Hab ich da was verpasst? Wenn man 64 LEDs unabhängig steuern will, braucht man doch auch 64 Pins, oder nicht? Es sei denn, man schaltet immer nur eine LED zur Zeit, aber dann erscheinen die LEDs sehr dunkel
Ah man könnte natürlich noch mehr kleine schwarze Krümel (aka IC's) verbauen. Aber dafür bin ich zuwenig Elektrotechniker...

[himitsu]

Klar, wäre es besser z.B. den Cube per µC anzusteuern, denn der PC ist ja kein Echtzeitsystem und je nach Auslastung kann es auch immer mal kurz "hängen".

So kann man den µC eine "vordefinierte" Bildsequenz abspielen lassen,
aber via PC hast du dann noch die Möglichkeiten auch Live-Daten einfließen zu lassen, wie z.B. deine grade gehörte Musik.

PS: selbst ohne Live-Daten muß auch irgendwie das Programm (quasi die Firmeware) auf deinen µC.

Wie gesagt, es gibt einige Anschlußmöglichkeiten und tausende verschiedene Steuereinheiten und dazu dann noch unzählige varianten dach auch noch programmseitig anzusteuern,
aber alles hat irgendwo gewisse Grenzen/Vorteile/Nachteile, welche sich je nach Verwendungszweck stark unterscheiden.

Bezüglich der LEDCubes gibt/gab es in der DP auch schon einige größere und interessante Threads.


[add]
Wenn man jede LED flimmerfrei und gleichzeitig direkt ansteuern will, dann brauchst man pro LED eine Datenleitung.

Für 64 LEDs kann man aber auch 16 (2x8) Leitung nehmen und darüber eine 8x8-Matrix ansteuern.
Es reichen auch 8x3 Leitungen, wenn man es binär kodiert, also 2^3 * 8 = 64.

Oder gleich Seriell, z.B. über ein 64-bittiges Schieberegister, dann braucht man nur 2 Leitungen, aber je mehr man es "komprimiert", um so weniger Daten bekommt man schnell übertragen und um so langsamer ist die Ansteuerung.
Auch muß man aufpassen, daß es nicht zu sehr flimmert.

[ulilüding]

Hi,
wie schon von himitsu bemerkt, eine 8x8 Matrix tut es. Da sind dann immer 8 LEDs zugleich an (nicht nur eine!), wenn sie denn leuchten sollen. Den Rest besorgt unser Auge. 25 Bilder pro Sekunde hält das Fernsehen für ausreichend. Mit LEDs habe ich aber auch bei 50Hz noch Flackern gesehen, zumindest mit PWM für die Helligkeit. Daß die LEDs dunkel erscheinen weil sie nur 1/8 der Zeit Strom bekommen kompensiert man, indem sie in dieser Zeit eben entsprechend mehr Strom bekommen. Das ist gängige Praxis, und sie sind genauso hell wie mit ~20mA Dauerstrom.
Für ein ausreichend schnelles Timing muß man den uC schon ausgefuchst programmieren. Und die Matrixverschaltung und die dann hohen Ströme (kann ein uC-port nicht mehr) ist zusätzliche Elektronik vonnöten. Für die Kommunikation mit dem PC muß man sich was einfallen lassen, daß diese das Timing nicht stört (Interrupt eher nicht, wie er schon heißt UNTERBRICHT er ja was, und bitte nicht die Darstellung). Wenn es über Spaßgebastel hinausgehen soll, ist das eine recht anspruchsvolle Aufgabe.
LG Uli

[himitsu]

Fernsehn, also das Röhrenfernsehn, arbeitet mit einer nachleuchtenden Fluoreszenzschicht.
Beim LCD- und LED-TV wird das Bild mehrmals aufgefrischt, als nur die 25 Hz des Videosignals.
(eigentlich 50 Hz, da es 2 Halbbilder sind ... jeweils die geraden und dann die ungeraden Bildzeilen)

Und LEDs leuchten nicht nach. (leider)

[jfheins]

Zitat von himitsu:

Und LEDs leuchten nicht nach. (leider)

Man könnte ja zu jeder LED einen kleinen Kondensator parallel schalten
Darf natürlich nicht zu groß werden, sonst regiert die LEd nicht mehr schnell aufs ausschalten.

[mschaefer]

Moin, moin,

wenn es etwas groesser sein darf. Tauche wieder in den invisible Workmode.

[blackfin]

Eine gute Anlaufstelle für so etwas ist auch immer das microcontroller.net
Die haben da mehrere LED-Cube Projekte, unter anderem auch das hier, mit Bauteile-Liste, Lötanleitung, Platinen-Schemata, C-Firmware Code usw.

Falls du noch überhaupt nie etwas mit Microcontrollern am Hut hattest, ist auch die C-Control I von Conrad ein guter Einstieg in die Materie.
Die Dinger basieren zwar auf einem alten Motorola, der über ein Basic-Derivat programmiert wird und sie sind nicht sonderlich schnell, jedoch sind sie ein sehr guter Einstieg in die Welt der MCUs und deren Schnittstellen.
Einen (grösseren) LED-Cube würde ich damit jedoch nicht in Angriff nehmen, dafür ist das Ding zu lahm

Apropos Schnittstellen:
Bei Hobby-Projekten kommt hier eigentlich meist eine RS232-Verbindung zum PC zur Verwendung. (Bei einigen speziellen Projekten auch manchmal MIDI oder Parallel)
Um RS232 via USB zu koppeln, gibt es z.B. den bei Hobby-Bastlern beliebten FT232 Chip von FTDI, der einen schnellen, nativen USB-RS232-Konverterchip darstellt und über downloadbare Treiber Geschwindigkeiten bis zu 480MBit bereitstellt.

Und zur Programmiersprache für die MCU's:
Assembler wird inzwischen auch im Hobby-MCU-Bereich immer mehr durch C verdrängt. Das liegt daran, dass moderne MCU's oft einen für Hochsprachen optimierten Kernel haben, C-Programme leichter umzuschreiben / zu warten sind, die Taktraten der MCU's inzwischen so hoch sind, dass man auch etwas "un-optimiert" ans Ziel kommt und zuguterletzt auch das interne Speicherangebot moderner MCUs (ROM / RAM) inzwischen so gross ist, dass man nicht mehr zwingend auf kleine ASM-Firmwares angewiesen ist. Ausserdem sind moderne MCUs mit vielen I/O-Pins und grossem Speicher inzwischen auch für Bastler in geringen Stückzahlen erschwinglich.
Sicher gibt es auch da noch genug Puristen und für Geschwindigkeits-kritischen Code nimmt man ASM teilweise immer noch, aber generell ist eher C die erste Wahl.
Die meisten Hobbyisten schreiben ihre Firmware inzwischen erstmal als Prototyp komplett in C und optimieren dann hier und da mit ASM den Code.

[himitsu]

C-Control II > wird vorwiegend in C und ASM programmiert und kann sogar sowas wie Multithreading.

Die CC1 kann man in CCBasic programmieren (ich glaube es gab auch einen C-Compiler und der interne EPROM hat noch ein bissl platz für etwas ASM)
oder über eine GUI-Klickbunti-Fuzzy-Steuerung.
PS: Was an den CCs nicht so schlecht ist, daß man kaum/keine externe Komponenten mehr braucht.
Es ist auch schon eine Firmeware vorinstalliert, über welche man seine Programme direkt laden kann.

Gut, die Teile sind nicht all zu schnell und etwas teurer, als soein kleiner tinyAVR, aber als Pascal/Delphi-Programmierer ist man im CCBasic auch schnell drin.
Für solche LEDCubes ist die CC1 doch etwas lahm, um damit die LEDs direkt anzusteuern.


Schade daß es den C-Control-Vorgänger nicht mehr gibt.
Ein keiner 8-beiniger IC, mit 6 Analog/Digital-IO-Pins, incl. knuffigem EEPROM und was man sonst noch so brauchte.

[blackfin]

Ja, die C-Control 2 ist wesentlich "schneller" und vielseitiger als die 1er...basiert ja auch auf einem komplett anderen Modell / Chip.
Allerdings ist für den Einstieg meiner Meinung nach (wenn man noch gar keine Ahnung von MCUs hat) auch die Lernkurve steiler. Deswegen hatte ich die 1er als Einstieg vorgeschlagen.
Teuer, das stimmt. Es gibt viele leistungsfähigere Boards auf dem Markt, die wesentlich günstiger sind (z.B. die Evaluierungs-Boards von AVR oder PIC), allerdings sollte man da meiner Meinung nach schon etwas Vorkenntnisse mitbringen, da man sonst fast erschlagen wird von Fachbegriffen
Diese Boards sind eher etwas für Leute, die sich bereits in MCUs eingelesen haben, jedoch einen neuen Typ ausprobieren wollen.

Edit:

Zitat:

Schade daß es den C-Control-Vorgänger nicht mehr gibt.
Ein keiner 8-beiniger IC, mit 6 Analog/Digital-IO-Pins, incl. knuffigem EEPROM und was man sonst noch so brauchte.

Aber es gibt z.B. die BasicStamps, die sind auch was für den Einstieg

[shmia]

Wenn's etwas kosten darf: USB-PIO
Das Teil habe ich persönlich getestet, es hat auf Anhieb funktioniert und ist ziemlich einfach (ActiveX) anzusteuern.
Der Anschluss über USB hat den Vorteil, dass man es an jedes Notebook anstecken kann, die ja heutzutage keine RS232-Schnittstelle mehr haben.
Preis incl. Versand (Vorrauskasse) ~66Euro.