µ-Controller für Starter

[himitsu]

Zitat:

Ideal wäre natürlich ein regelbares Labor-Netzteil, aber die Dinger sind nicht gerade billig.

Für kleine Dinge gibt es auch diese umschaltparen Steckernetzteile recht günstig. (wenn man keine zu feine Einteilung braucht)

[Medium]

Wow Finn, danke! Ich glaube, ich stell mir das ganze auch noch viel zu komplex vor, und gehe daher mit ein wenig zu viel "oh gott, das versteh ich ja nie" da dran. Deine Shoppingliste klingt prima, und ich glaube echt, das einzig sinnvolle wird es sein, einfach mal ein Satz Dinge zu kaufen und loszulegen. Ein wenig Drumrum kann ich aus unserer Werkstatt auf der Arbeit nutzen, so dass ich immerhin ein Labornetzteil, Lötkolben, Kabel und Kleinteile - der ganze Kram drum rum, der sich läppern würde, erstmal hätte. Ich sehe mich allerdings noch nicht selbst ätzen, aber wer weiss

Der Rasberry ist dann aber wirklich ein wenig über's Ziel hinaus (und auch zu groß für meine Zwecke ) Allerdings ein starkes Projekt.

[himitsu]

Es kommt eben drauf an, was man benötigt.

Wenn du das Raspberry schon übertrieben findest:
http://www.androidmag.de/news/dual-c...uberall-dabei/
http://www.pcgameshardware.de/aid,85...plett-PC/News/

Der Vorgänger der C-Control war in einem DIL8-Gehäuse versteckt.
2 Pins für Spannungsversorgung und die restlichen 6 Pins waren softwareseitig frei belegbar, als Eingang (Spannung, TTL/Binär/Tri-State, Frequenz) oder als Ausgang (Binär/TTL/Tri-State, Frequenz, PWM) und 2 davon zusätzlich/abschaltbar über die Firmware mit RS232 vorkonfiguriert.
Taktgeber und sowas war schon integriert ... man brauchte also grundsätzlich erstmal keine externen Bauelemente. (Taster und Low-Current-LEDs konnten direkt angeschlossen werden)
Sowas gibt's eventuell auch von anderen Herstellern.

Dann gibt es teilweise einige Experimentierboards, welche nicht als nur Lochraster, sondern gleich mit vielen Steckplätzen versehn sind, wo man dann einfach alle Bauellemente und eventuell ein paar Drahtbrücken draufsteckt und nicht ständig umlöten muß.

[blackfin]

Mir ist aufgefallen, dass noch keiner wirklich darauf eingegangen ist, welchen Chip du als Einstieg überhaupt verwenden könntest...

Meiner Meinung nach ist es am einfachsten, du beginnst erstmal mit einem etwas "grösseren" Chip, der alles mögliche kann und einen ausreichenden Flash- und EEPROM-Speicher besitzt, um auch ausreichend ausprobieren zu können.

So würde ich als Einstieg zu einem 8-Bitter der ATMega- (AVR) bzw. PIC18- (Microchip) Serie raten.
Das hat den Vorteil, dass die Chips dieser Serien meist viel FLASH und Peripherie mitbringen (I2C, USART, CAN, A/D Wandler etc.)
Damit kannst du dann schonmal alle möglichen Techniken ausprobieren und weisst dann schon nach den ersten Tests viel eher, was du brauchst, wenn du dein eigentliches Projekt angehst.
Dann kannst du dir immer noch einen kleineren Chip holen (ATTiny / PIC12 / PIC16 etc.), der genau auf dein Projekt passt und genau die Peripherie mitbringt, die du brauchst, weniger Strom verbraucht etc.
Dann schrumpft das zunächst unüberschaubar anmutende Angebot an Chips auch plötzlich ganz schnell ein, wenn man weiss, was der Chip mitbringen muss

So wären denkbare Einstiegsmodelle z.B. ein
ATMEGA16-16PU
(DIL/44, 8 Bit, 16kB Flash, 512 Bytes EEPROM, 1kB SRAM, 16MHz/16 MIPS, 32 I/O Pins, 3 IRQs, 8x 10Bit A/D, Hardware USART)

oder z.B. ein

PIC18F452-I/P
(DIL/44, 8 Bit, 32kB Flash, 256 Bytes EEPROM, 1,5kB SRAM, 40MHz/10 MIPS, 32 I/O, 3 IRQs, 8x 10Bit A/D, Hardware I2C, SPI, USART, PWM)


Die "16PU" bzw. "I/P" sind dabei nur Zusatz-Angaben zu den Typen, z.B. welches Package (In dem Fall PDIP-44), welche Temperatur-Range, max. Geschwindigkeit etc.
Achte am Anfang einfach darauf, dass es ein Chip in einem DIL / DIP-Package ist (Standard-2,54mm Raster).
SMDs wie z.B. TQFP kann man am Anfang nur schwer löten und BGA-Packages gehen mit dem Lötkolben gar nicht mehr (Lötzinn-Kugeln unter dem Chip, die industriell im Reflow-Verfahren oder in Dampfphase verlötet werden)

(Ich selbst habe die meisten Efahrungen mit den PICs, allerdings sind die AVRs genauso gut und haben eine etwas saubere Architektur, kommt aber halt auch immer auf den Anwendungsfall an.
Die PICs sind meiner Erfahrung und subjektiven Meinung nach etwas "robuster", was Fehlspannung und Kurzschlüsse angeht und gerade am Anfang von Vorteil sein kann. Dafür sind die AVRs generell effizienter (Befehle / Taktzyklen) und in ASM etwas leichter zu programmieren. Wenn du C verwendest, ist es aber ziemlich egal. Gute C-Compiler gibts für beide Architekturen, soviel ich weiss, aber für AVR mehr im Freeware-Bereich als beim PIC.)

[divBy0]

Das STK500 von Atmel kann ich dir eigentlich auch empfehlen. Eignet sich ganz zum Testen, da schon 8 Taster und 8 LEDs verbaut sind.

Einen Raspberry PI habe ich bestellt, aber bis heute noch keinen bekommen.

[Medium]

Nochmals Danke Und da ich die letzte Woche zu stark mit anderen Dingen beschäftigt war, kam ich auch noch nicht dazu Tatsachen zu schaffen. Bei den eigentlichen MCUs war ich schon drauf und dran, einfach einen "Satz" verschiedener zu nehmen die in das Board passen, dass es dann mal wird, und mit allen mal rumspielen. So teuer sind die zum Glück nicht. Da ich auch nicht sooo der Lötkönig bin, käme auch eigentlich immer nur DIL/DIP in Frage, vor allem weil es vermutich nicht dumm ist einen Sockel zu benutzen so als Anfänger .

Ich schwanke nun eigentlich nur noch zwischen 2 Produkten: Dem STK500 und diesem hier, welches durch LCD und viel Lesestoff für mich zunächst nach gut angelegem Geld klingt. Ich weiss nur nicht, ob die IDE von denen was taugt. Kennt das einer? Auf der anderen Seite macht sich das STK500 einfach dadurch schon sympathisch, dass es nach "Orignal"-Version klingt, mit deren Erwerb man einfach nichts falsch macht

[totti14]

Und wenn Du dann noch bei Pascal bleiben möchtest, mit den Atmels, dann schau mal hier rein:
http://forum.e-lab.de/

Benutze ich schon seit jahren. Hier kommt man schnell zum Ziel.

[blackfin]

Zitat:

Ich weiss nur nicht, ob die IDE von denen was taugt. Kennt das einer?

Ich kenns nicht, sieht aber nach einer recht soliden "Einsteigerlösung" aus.
Wenn auch etwas teuer...auf den Boards sind Chips im Gesamtwert von ca. 10-15 Euro verbaut...wobei der Fotosensor das teuerste sein dürfte, der Rest sind Standard-Komponenten.
Gut, aber die Handbücher und die IDE sind sicher auch was Wert

Der "MultiProg" ist eigentlich auch nichts anderes als ein Board mit vielen Sockeln und nem Quartz.
Der "mySmartUSB MK2" ist dafür ganz nett...das ist genau so ein Teil, wie man sich zwar auch selbst basteln kann (z.B. mit nem MAX232 und nem FTDI FT232BM), aber man erspart sich die Lötarbeit des SMD-Chips von FTDI.
Ausserdem kann der zusätzlich zum Standard-USART auch I2C und SPI..das ist nett

Schön ist ausserdem, dass gleich 3 MCUs mit beiliegen und das Board viele Port-Pins und auch die der Peripherie nach aussen führt.
So würde ich mir an deiner Stelle trotzdem zusätzlich ein Steckboard kaufen, dann kannst du die Platine ggf. mit eigenen Bastelschaltugnen erweitern.

Wenn die IDE nichts taugt, kannst du aber auch mit dem original "AVR Studio" coden:
http://shop.myavr.de/index.php?sp=do...suchwort=dl253


Ich finde das Angebot zwar etwas teuer, aber ich denke ein ziemlich guter Einstieg.

Vom STK500 habe ich allerdings bisher auch nur gutes gehört. Ist aber auch etwas überteuert.

Zitat:

...vor allem weil es vermutich nicht dumm ist einen Sockel zu benutzen so als Anfänger...

Das stimmt allerdings...eines der ersten Dinge, die ich meistens immer mache ist, in Experimentierboards, die keinen ICSP-Port bekommen (In Circuit Serial Programmer, zwei Pins mit denen du den Chip direkt in der eigentlichen Schaltung bespielen kannst), einen vernünftigen ZIF-Sockel mit Hebel zu verbauen...schont Nerven, die Pins und das Pin-Biegewerkzeug
Auch wenn die ZIF-Sockel leider immer recht teuer sind...


P.S.
Was die MCU-Pascal-Programmierung angeht:

Ich weiss nicht, ob das so eine gute Idee ist, die Sprachen der MCUs sind in der Industrie fast ausschliesslich ASM und C.
Es ist zwar so, dass es Lösungen gibt, mit denen man für den leichteren Einstieg auch in Pascal (oder auch Basic) coden kann, aber wenn man richtig in die effiziente MCU-Entwicklung einsteigen will, sollte man zumindest C nehmen und einzelne Routinen evtl. mit ASM optimieren.
Moderne MCUs haben inzwischen oft einen Kernel, der dafür optimiert ist, dass man Großteile der Firmware in C schreibt, so dass man nicht mehr alles in ASM coden muss.
Das ist schon eine große Erleichterung im Vergleich zu den alten bzw. kleinen MCUs, die man aufgrund des kleinen Speicherangebotes auch heute noch in ASM codet.
Ausserdem ist Microcontroller-C ziemlich einfach Ich bin da sehr schnell reingekommen, auch wenn ich damals auf dem PC zuvor fast nur Delphi gecodet hatte.


P.P.S.
Wenn du mal mit dem Basteln angefangen hast und Fragen zu dem Zeug hast, kannst du mir die auch gerne per PM schreiben.
Ich bin zwar kein Profi in dem Bereich, sondern auch nur Bastler, aber vielleicht kann ich ja bei dem einen oder anderen helfen.