Steuerung externer Geräte (eigenbau)

[Fussel9]

Was ich mich schon seit langem Frage: Wie werden eigentlich externe Geräte von Programmen angesprochen, sei es ein Plotter dessen Motoren bewegt werden, ein LCD-Display dessen Segmente erleuchten oder einfach nur eine LED-Leiste bei der man die einzelnen Lampen an- und ausschalten könnte...
Nun habe ich mich vergangene Tage mit jemandem unterhalten der in einem solchen Bereich arbeitet und der hat mir irgendwas von Assembler erzählt und mir jede Menge begriffe um die Ohren geschleudert die ich natürlich nicht kannte ;D .
Nu hab ich mich mal schlau gemacht (Wikipedia) und Assembler scheint eine Sprache zu sein die für solche Dinge gedacht ist, aber wie es aussieht greift die Sprache immernoch auf ein Betriebssystem oder zumindest auf das DOS zurück (Falls die Architektur mit DOS arbeitet, sonst eben auf Entsprechendes):

Code:

Hello World in Assemblersprache (NASM für MS-DOS) [Bearbeiten]

ORG 100h ; Startoffset auf 100h setzen (Startpunkt für COM-Programme)
 
mov ax, cs ; Wert des Codesegmentregisters in Register ax übertragen
mov ds, ax ; Datensegment auf Wert von ax setzen
 
mov ah, 09h ; DOS-Funktion zum Schreiben von Text
mov dx, Meldung ; Adresse des Textes
int 21h ; DOS-Funktion ausführen
 
mov ax, 4C00h ; DOS-Funktion um das Programm zu beenden
int 21h
 
Meldung: db "Hello World" ; Unser Text
         db "$"             ; Markiert das Ende der Zeichenkette

ich gehe mal davon aus das man daher eine platine braucht die einen prozessor oder sowas hat die diese befehle oder parameter auflösen kann...

Ich geh jetzt mal wirklich vom einfachsten Beispiel aus:
Ich habe 5 LED's die ich über ein Programm steuern möchte.
Kann mir jemand erklären wie sowas funktionieren würde,
welche Bauteile ich benötige und
wie der Computer signale von externen Sensoren empfangen kann?
(zu letzterem: z.B. ein Bewegungssensor um die LED's zu steuern)

[Bernhard Geyer]

Zitat:

Zitat von Fussel9 (Beitrag 1102211)

... aber wie es aussieht greift die Sprache immernoch auf ein Betriebssystem oder zumindest auf das DOS zurück (Falls die Architektur mit DOS arbeitet, sonst eben auf Entsprechendes)

Windows ME war das letzte Windows das einen DOS-Kern hatte. Ab NT/2000 wirst du nicht mehr direkt ohne einen Treiber zurecht kommen.

Für spielereien in diese Umfeld bieten Conrad&Co. fertige Platinen mit denen man relativ einfach PC-SW schreiben kann um selbst zusammengestellt Elektronik steuern kann.

[Fussel9]

Hey, ja sowas wäre natürlich super,
wonach genau muss man den da so suchen um nicht in der Flut von angebotenen Platinen unterzugehen.

Sind bei sowas Anleitungen dabei oder gibt es empfehlenswerte Seiten im Netz?

Zitat:

...fertige Platinen mit denen man relativ einfach PC-SW schreiben kann...

was genau ist den PC-SW ... da findet die Wikipedia auch nix...

[himitsu]

Innerhalb des PCs isses egal, da man in der Regel fast ganicht mehr direkt mit der externen Hardware "redet".
Oftmals werden Schnittstellen-DLLs und Treiber angesprochen und das geht mit jeder Sprache (C++ C# Delphi BASM ......).

Wie in der externen Hardware gearbeitet wird, hängt von dieser ab und ob da z.B. ein Mikrocontroller drin steckt.

Manchmal schaltet man extern auch nochmal eine µC dazwischen, welcher vom PC die Befehle bekommt und die eigentlich Hardware anspricht.


Diese µC kann man mit vielem befüllen.

Also die Programme innerhalb des PC-Programmierprogramms können Vieles sein.
Von ASM, über C++, sogar Basic, Pascal und Anderes existert ... je nach µC oder ob es sogar eine größere CPU, ala x86-er Architektur.

[jfheins]

Das Zauberwort heißt Microcontroller ;)

Wenn es nicht nur ein paar LED's sind, sondern etwas mehr Logik ausgelegert werden soll, kannst du einen Mikrocontroller programmieren der das übernimmt. Den programmiert man üblicherweise mit C (oder Assembler) und kann mit einem Computer über RS232 kommunizieren.

[Fussel9]

Zitat:

Zitat von himitsu (Beitrag 1102228)

Innerhalb des PCs isses egal, da man in der Regel fast ganicht mehr direkt mit der externen Hardware "redet".
Oftmals werden Schnittstellen-DLLs und Treiber angesprochen und das geht mit jeder Sprache (C++ C# Delphi BASM ......).

Nur wenn ich selbst ein Element baue, dann kann kein Treiber dafür existieren oder?

Zitat:

Zitat von jfheins (Beitrag 1102229)

Das Zauberwort heißt Microcontroller ;)

Wenn ich mir jetzt den kaufen würde (Link) was müsste ich den dann damit machen?

Ich hab ja keine Ahnung wie sowas funktioniert...
Sagen wir mal, um die Logik komplexer zu machen, Ich bau mir jetzt einen Bilderrahmen voll mit LED's und mit einem Lichtsensor ja nach Helligkeit soll er andere Bilder zeigen.

wie muss der Mikrocontroller verbaut werden, was muss man haben um den controller mit einem rechner zu beschreiben ect ect

[ulilüding]

HI Fussel9,
eine Möglichkeit ist, Deine LEDs in Spalten und Zeilen aufzuteilen und dann über PWM in der Helligkeit anzusteuern. Das kann ein Mikrocontroller sehr leicht, wenn er genug Ports hat. Über eine Schnittstelle (z.B. RS-232, Danke jfheins) kannst Du dem Mikrocontroller sagen, welche LED wie hell leuchten soll. Die Programmierung dazu = Daten berechnen und über COMx ausgeben ist Pipikram. Die Schwieriglkeiten liegen im Timing des Mikrocontrollers. Der ist mit einer akzeptablen Bildfolge und Taktrate für das PWM schnell am Ende, wenn Du viele Spalten und Zeilen hast. Da wird dann mehr Elektronik nötig, z.B. Latches für col oder row. Wieviel LEDs und wie schnell hast Du denn so gedacht?
LG Uli

[himitsu]

Zitat:

Nur wenn ich selbst ein Element baue, dann kann kein Treiber dafür existieren oder?

Wieso?

Also, RS232 (serieller Anschluß) unterstützen viele µC .. dann braucht man nur noch ein Kabel.

USB und Co. kann man heutzutage auch relativ leicht nehmen.

PS: Es gibt dann PC-intern Serial-zuUSB-Brücken, welches praktisch Treiber sind, die Daten über den USB-Anschluß auf einen seriellen Port weiterleiten.

User es gibt DLLs/Treiber, welche die Kommunikation über USB und einen externen IC zu einem µC bereitstellen.

Man könnte auch über PCI, FireWire, WiFi, Bluetooth oder sonstwie gehn.

Was nun geeignet ist, das hängt davon ab, was für Möglichkeiten zur Verfügung stehen, wie der Geldbeutel aussieht, wie schnell die Übertragung sein muß und über welche Entfernung es gehn soll.
Außerdem ist wichtig was und wie es gesteuert werden soll.

[Fussel9]

@Uli: Puh... das war nur nen simpless beispiel wo man einen eingabewert für die ausgabe verarbeiten müsste
wenn ich sowas in der richtung mal wirklich bauen würde dann liefe es eher auf ne doppelhelix oder nen würfel raus
also bei der doppelhelix zwei stränge mit ka 4 zwischen Strängen (72 LED's
oder bei nem würfel vielleicht so keine Ahnung 12 streifen fürs grundgerüsst und 16 zwischen streifen die ein gitter über und durch das gerüsst ziehen ( so 8 Led's pro Strang---224 LED's)

und dann ginge es bei der Helix eher darum das das Teil Bewegungen darstellen kann wie einen Aufwärtsstrom bis zu einer On/Off- Geschwindigkeit von 1/6 bis 1/8 Sekunde

Bei dem Würfel ging es dan eher um die Farbspiele oder langsame Bewegungen aber eben auch die Möglichkeit jedes einzelne LED steuern zu können. Ich denke du kannst dir vorstellen wie so ein Teil aussehen würde... (ja ich weiß das es die Dinger fertig zu kaufen gibt, aber das würde ja keinen Spaß machen)

PS: @himitsu: Wäre schon cool wenn ein programm auf meinem Rechner dem Qube die Befehle über Funk oder Bluetooth oder wie auch immer senden würde aber mit nem Mikrocontroller würde das teil selbstständig arbeiten (hab ich jetz zumindest so verstanden)

[ulilüding]

Nehmen wir als Beispiel einen PIC im 40-pol-Gehäuse. Der kann problemlos über 2 Ports 8x8 = 64 LEDs steuern. Weitere pins werden zwar für serialCom und Deinen Lichtsensor (?? AD-Wandler mit Fotozelle über I2C, SSI oder sowas) gebraucht, lassen aber den Rest auf 72 LEDs wohl zu. Die Kommunikation ist über einen virtualComPort an USB einfach zu gestalten. Dein Programm sendet an den PIC die Helligkeitswerte für die LEDs und bekommt als Antwort den Meßwert des Lichtsensors. Da Du an 8 Bilder pro Sekunde denkst ist das vom Timing her recht unkritisch. Wie die Werte im PC-Programm verknüpft werden sollte keine Schwierigkeit darstellen. Für den Zeitablauf rate ich aber vom mmTimer (oder gar der Timer-Komponente) ab, das läuft nicht rund. Am besten ein eigener thread mit Hardware-Zeitmessung über QueryPerformanceFrequency und ..Counter.
Leider wirst Du Dich ordentlich in die microcontroller-Programmierung reinknien müssen. Da gibt es zwei Philosophien. Hochsprache: leicht zu schreiben und zu debuggen, der Kerl (compiler) macht aber gerne auch schon mal das, was er will = schlechte timing-Kontrolle. Maschinencode im Texteditor (assembler): ggf. nicht portierbar, debuggen am ehesten mit Oszi per pin und überhaupt recht hardware-nah, nicht jedermanns Sache. Vielleicht findest Du speziell für diese Aufgabe ja jemanden, die molzitec GmbH in Münster z.B. (www.molzitec.de) macht sowas sehr professionell. Ansonsten Handbücher wälzen und in kleinen Schritten viel ausprobieren. Viel Erfolg
LG Uli

[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 :mrgreen:

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 :gruebel:
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. :wink:

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:

Zitat von himitsu (Beitrag 1102301)

Und LEDs leuchten nicht nach. (leider)

Man könnte ja zu jeder LED einen kleinen Kondensator parallel schalten :stupid:
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 :-D

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

[generic]

Üblich ist die Ansteuerung via RS232 oder USB.

Die Atmel 8-Bit Risc Microcontroller verfügen über eine USART und können zumindest schon mal RS232 vom Protokoll her sprechen. Die elektrischen Pegel passen noch nicht. Diese können mit ein MAX232 einfach umgewandelt werden.
Die andere Variante ist es die o.g. MC zu nehmen und ein Low-Cost USB Interface dran bauen.
http://www.obdev.at/products/vusb/index.html

Die MC von Atmel kann ich empfehlen. Einsteiger-Sets sind günstig genau so wie die Programmierer dafür. Ein bekanntes Einsteiger Projekt ist arduino.
http://de.wikipedia.org/wiki/Arduino-Plattform

@shmia -> Besserwissen an:
Inklusive schreibt man übrigens mit k und nicht mit c.
incl. ist die Abkürzung für das englische Wort "inclusive".
Das schleicht sich langsam in den Duden - habe ich das Gefühl.

[Fussel9]

Zitat:

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

... apropos erschlagen von Fachbegriffen :D (verweiß auf letztere Antworten)

Also was ich jetzt erstmal suchen würde ist irgend ein Einsteiger-Set mit Anleitung (sowohl für den Zusammenbau als auch die Programmierung)
folgendes sollte gegeben sein:
- Ich möchte die Firmware selbst schreiben
- Ich möchte Werte ausgeben (sprich Strom an eine Stelle verteilen //LED oder Motor ect.)
- Ich möchte Werte empfangen (Lichtsensor/Drucksensor etc.)
und
- Es sollte einen Preis von 50€ nicht weit überschreiten

__________________________________________________ _______________________________________________

Es muss ja nicht gleich ein Cube sein, erstmal würde ich gerne verstehen wie so ein Chip überhaupt funktioniert und was man wie verbaut ect.

Wäre schon wenn da jemand konkrete Angebote hätte (Conrad oder sonstige Versandhäuser)
Leider weiß ich nicht wo man da am besten sucht bzw. wonach.
THX

[blackfin]

Wie ich bereits sagte, schau dir für den Einstieg mal die "C-Control I" von Conrad an:
Das "C-Control Plus Set" hier (Main Unit + Schnittstelle zum PC + Programmier-Umgebung und -Beispiele) kostet 51,24 €
(ziemlich sicher gibts die gebraucht bei bekannten online-Auktionshäusern auch noch wesentlich günstiger.)

Voraussetzung: Ein Windows-PC (XP / 2000, ob es unter Vista / 7 läuft leider keine Ahnung) mit serieller Schnittstelle (RS232) und ein kleines Standard-Steckernetzteil, das 5V und mindestens 30mA liefern kann
(eher etwas mehr, da die 30mA schon alleine für die C-Control gebraucht werden und deine Peripherie (LEDs) ja auch noch Strom braucht.
Aber die meisten Standard-Steckernetzteile vom Laden nebenan können eh so um die ~200-500mA bei 5V).

Ich hatte damit früher selbst mal angefangen und war ziemlich zufrieden für den Einstieg.
Mit dem Bausatz kommst du ziemlich leicht in die MCU-Materie rein und kannst dann später viel leichter selbst entscheiden, wenn du etwas fortgeschritteneres für eigene Projekte brauchst.
(Ich bin dann irgendwann mal zu den PICs gewechselt und habe damit dann ein ziemlich großes Projekt gestemmt, obwohl ich ein Jahr vorher noch keine Ahnung von MCUs hatte, siehe hier).

Edit:
Als Zusatz würde ich dir für den Anfang noch ein Steckboard wie z.B. dieses hier (gibts wo anders sicher noch billiger) empfehlen, um die ersten Mini-Schaltungen stecken zu können, dazu noch ein paar Steckbrücken / Drähte, ein paar LEDs deiner Wahl mit Vorwiderständen (für die Ausgabe) und evtl. ein paar Taster (Eingabe).
Wenn du dann damit ein bißchen gespielt hast, kannst du auch noch ein paar andere "Sensoren" kaufen (Lichtsensor, Potentiometer etc.)
Ich würde aber für den ersten Start erstmal bei LEDs und Tastern bleiben.

Wenn es dich dann "packt" (was sehr wahrscheinlich ist, wenn dich die Materie interessiert :-)), gehst du eh relativ schnell weiter.
Dann kommen (Lochraster-)Platinen statt Steckboards inkl. löten, Motorensteuerung, A/D-Wandlung usw.
Aber fang erstmal "klein" an :-)

[generic]

Für die AVR:
http://www.rn-wissen.de/index.php/AV...leicht_gemacht

Es empfiehlt sich das Atmel STK zu verwenden, dieses ist aber teurer als 50€.
Es geht aber auch ohne!