Hallo! Vor vielen Jahren habe ich mich als SW-Entwickler mit Mikrocontrollern beschäftigen (müssen). Danach jedoch nie wieder damit zutun gehabt. Trotzdem haben mich diese kleinen Knechte immer fasziniert. Jetzt möchte ich gerne über ein kleines Projekt wieder einsteigen, fühle mich diesbezüglich aber mittlerweile eher als blutiger Anfänger. Mit welcher Mikrocontroller-Familie sollte ich mich befassen? AVR, ARM, PIC, 8051, TI etc. etc.? Ich würde gerne vorwiegend in einer Hochsprache programmieren, vorzugsweise C. Schön wäre natürlich möglichst viel freie Entwicklungstools und die Möglichkeit des On-Chip-Debuggings mit Source-Code-Unterstützung (wie bei einem modernen ICE). Wenn ich mich schon wieder neu einarbeite und lerne, dann sollte es schon eine Familie sein, die für kleine bis größere Projekte viel Potenzial bietet und eine weite Verbreitung hat. Ich würde nur ungern den Einarbeitungsaufwand und Lernaufwand in eine unmoderne oder veraltete Familie oder Architektur stecken. Ich habe die Entwicklungs-Boards von http://www.mikroe.com entdeckt. Zum Einsteigen, Lernen und Testen scheinen diese ja ideal zu sein. Das fertige Projekt kann man ja dann auf ein kleineres Prozessormodul übertragen und im Endgerät einsetzen. Sehe ich das richtig? Könnt Ihr mir bitte helfen? Viele Grüße Bernhard
Meiner Meinung nach ist ein 8-bitter der 8051 Familie am besten zum Einsteigen... die Datenblätter sind äußerst schön gestaltet (das meiste ist aus Diagrammen & Blockschaltbildern zu erkennen) Die Programmierung ist auch nicht allzuschwer...
Achso... hab ich nicht weit genug gelesen... sry... wenn du wirklich was topaktuelles haben willst beschäftige dich mit einem ARM7... aber da wirst du uns im forum viel schreibarbeit bescheren ^^
Am Einfachsten und günstigsten in Sachen Tools sind AVR und PIC. Ich hab mal mit PIC gearbeitet, mich dann jahrelang an deren 16bit Umgebung und Registerbanking geaegert, dann auf AVR umgestiegen, und jetzt 10 Jahre spaeter aerger ich mich an den AVR. Reslistischerweise kann man beide als etwa gleichwertig betrachten. Beide brauchbar und günstig. Z.
Ein einfaches und günstiges Entwicklungsboard ist meiner Meinung nach das UCAN Startkit von Infineon für den XC164CM: http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-87188&channelPage=%2Fep%2Fchannel%2FinformationPage.jsp&pageTypeId=36102 Der XC16x-Familie ist ein 16bit-Controller und der Nachfolger für den C16x. Große Vorteile: - Sehr günstig - Umfassendes Zubehör - Einfach - Wird über USB an einer Rechner gesteckt und auch das Debugging funktioniert darüber.. Gruß jo
Ich empfehle den MSP430. Er hat eine 16-Bit Von Neumann-Architektur und ist sehr sauber und modern designet. Außerdem gibt es mit dem GCC auch einen exzellenten C-Compiler und man kann ihn über JTAG Debuggen.
ARM, in der Industrie wird viel der IXP4xxx verwendet. Durch die Beschäftigung mit dem ARM kann man dafür die Grundlagen erlernen. Ansonsten AVR ist trotzdem mein Favorit. Wolf
Die Frage ist schlicht und einfach, wie groß willst du deine Projekte machen? Reichen dafür 8051, AVR oder PIC? Dann such dir was in der Größe aus. Welche Architektur du davon wählst ist Geschmacksache. Mir kommt kein AVR oder PIC auf dem Tisch. Wenn nicht dann geh direkt zu ARM7 und vergeß die kleineren. Sonst fängst du nach einer Weile mit dem Einarbeiten von vorne an. Gruß Ralph
> Sonst fängst du nach einer Weile mit dem Einarbeiten von vorne an.
Das ist sowieso nicht zu vermeiden. Das Beste dürfte immer noch sein,
einfach mit einem (nicht zu komplexen) µC anzufangen. Spätestens nach
einem Vierteljahr weiß man ganz gut, ob dies das Richtige ist.
wenn du dich für die PICs entscheidest, lege ich dir www.sprut.de ans herzen: auch wenn dort fast alles anhand der 16er-familie erklärt ist, kann man es 1:1 auf die moderne 18er-familie übernehmen (18er-familie erleichtern einem vieles und haben all die negativen eigenschaften der 16er nicht mehr - wie z.b. die oben erwähnten bänke). ich favorisiere die 18er-PICs
Ich würde auch zu den 8-Bittern (8051, AVR) raten. Der große Vorteil ist, man kann damit schnell schnuckelige Projekte aufbauen ohne erst ne Platine machen zu müssen. So ein 20-Pinner ist schnell aufn Stück Rasterplatine draufgepappt. Und für Batteriebetrieb brauchen die Low-Voltage-Typen (1,8..5,5V) nicht mal nen Spannungsregler, ne Li- oder 2..3 AA-Zellen, fertig. Dagegen ist so ein ARM7 erstmal ne Menge Hardware-Wuselei, ehe überhaupt was läuft. Und wenn man nen 8-Bitter beherscht (in C), dann fängt man beim ARM auch nicht von vorne an. Die zusätzlichen Eigenheiten (z.B. spurious Interrupt Handler), lernt man schnell. Ich finde, das ist ja gerade der Reiz an MCs, das man viele Sachen damit aufbauen kann und dann gleich verwenden. Ich hatte früher ein 8051-Board mit Boot-EPROM und SRAM, macht überhaupt keinen Spaß, wenn man für ein neues Projekt das alte erst einreißen muß, weil man nur ein Entwicklungsboard hat. Dagegen so ein moderner 8-Bitter ist quasi das komplette Entwicklungsboard in einem Chip. Peter
Sich für eine Familie zu entscheiden und dabei zu bleiben zu wollen ist ein Ansatz - mir ist der indes zu langweilig. Natürlich sieht das anders aus, wenn man hunderte bis tausende Euros in Entwicklungssysteme investiert. Muss man aber nicht, viel geht auch mit freien Tools. Und man profitiert eher davon, wenn man nicht ewig beim Gleichen bleibt. So schlimm ist ein Umstieg nämlich garnicht. Wie Peter schon dargelegt hat: Um mal eben ein LCD an einen CAN-Bus zu hängen, ist ein ARM7 zwar auch einsetzbar, aber eigentlich viel zu komplex. Andererseits beobachte ich hier Leute, die mit den Probleme kämpfen, die ein Mega128 bei der Adressierung seines für die Architektur eigentlich schon zu grossen Speichers aufwirft. M.a.W: AVR für die kleineren, ARM für die grösseren Dinge.
> Dagegen ist so ein ARM7 erstmal ne Menge Hardware-Wuselei, ehe überhaupt > was läuft. naja, nimmt man z.b. einen atmel at91sam7xxx-typ, dann ist das auch nicht so viel bastelei. @OP: wenn du mit einem kleinen 8-bitter anfängst, dann musst du dich zwangsläufig damit auseinandersetzen, wie man möglichst effektiven und resourcensparenden code schreibt. das 'gute design' einer software, wie modularer aufbau und portierbarkeit etc. tritt damit in den hintergrund zu gunsten von laufzeiteffizienz und geringem RAM-bedarf. ein grosser controller mit z.b. 512K flash und 64K ram bietet da mehr möglichkeiten (du kannst plötzlich sinnvoll 'malloc' einsetzen, ein RTOS usw.).
Wau, ich bin baff! So viel und ausführliche Resonanz auf meine Anfrage. Ich bin total begeistert! Vielen Dank! Ich bitte um Verständnis, dass es jetzt noch mehr Fragen sind als vorher. :-) Mir ist klar geworden, dass es sehr viele, sehr gute Mikrocontroller gibt. Irgendwie scheint es aber auch eine Frage des persönlichen Geschmacks zu sein und das kann ich gut verstehen. Es kristallisieren sich für mich zwei Familien heraus, die offenbar eine große Fangemeinde besitzen und somit auch viel "freie" Anwendungserfahrung existiert - AVR und ARM. Irgendwie sind mir die ARMs sympathischer, aber das ist nur ein Bauchgefühl, nachdem ich mich ein wenig eingelesen habe. Die AVRs reizen durch Ihre Einfachheit, dem Beginn bei niedrigen Leveln und offenbar sehr guten "Basteleigenschaften". Ich bin jetzt wieder auf Mikrocontroller aufmerksam geworden, da ich ein kleines Projekt für eine befreundete Firma lösen möchte (Hobby). Ein zentraler Steuerrechner soll über einen Bus (I2C?) in zwei abgesetzten (je 10m und mehr), identisch aufgebauten Geräten eine größere Anzahl (je Gerät bis zu 48) Relais steuern (über I2C I/O-Port-Expander). Der Steuerrechner soll über ein Display verfügen, der den Betriebsszustand/Einstellungen der Endgeräte anzeigt. Der Steuerrechner soll die Möglichkeit der Fernbedienbarkeit über eine IR-Fernbedienung bieten. Zu diesem Projekt hätte ich noch ein paar HW-Fragen, aber dazu mache ich wohl besser einen eigenen Thread auf. Das wäre mein Einstiegsprojekt. Sicherlich mit allen genannten Mikrocontrollern (leicht?) lösbar. Ich habe im Internet gesucht und bin u.a. über MyAVR.de gestolpert. So habe ich mich über die AVRs/ATmegas informiert. Ich hatte mich jetzt schon fast entschieden, aber als ich mich über die ARM-Prozessoren informierte, kam mir, wie gesagt, einfach die Idee, dass es vielleicht eine Familie gibt, die von kleinen bis größere Projekte alles gut abdeckt und ich nicht jedesmal neu lernen muss oder investieren muss. Was für mich wichtig ist, sind preisgünstige, möglichst freie aber leistungsfähige Tools, die auch das In-Chip-Debugging auf Source-Code-Level (vorzugsweise C) komfortabel beherrschen (Breakpoints, Conditional Breakpoints, Variablen/Registerzustand, Einzelstep etc.). Unterstützen das die freien Tools für AVR und ARM? Ein bisschen Assembler für kleine und effiziente Unterroutinen ist natürlich o.k. und meist notwendig. Peter Dannegger (peda) hat für mich aber einen entscheidenden Punkt erwähnt: die unkomplizierte Anbindung von HW an den Prozessor. Wenn ich für einen ARM jedesmal eine Platine machen (lassen) muss, um man ein paar Relais oder Taster anzubinden, dann ist das nicht so toll. Ein schneller Testaufbau auf einem Steckbrett sollte schon möglich sein. Ich habe aber vereinzelt gesehen, dass es auch von den ARM-Prozessoren kleine sog. Tiny-Module gibt (40pin), die man z.B. auch auf einem Steckbrett einsetzen kann. Oder ist das bei den ARMs schon wesentlich komplizierter als bei den AVRs? Muss man denn bei einem ARM immer mit viel Grundaufwand rechnen? Eine Batterielösung für Mini-Projekte kommt bei ARM wohl nicht in Frage? Welche Probleme müsste ich aufgrund des 3.3V-Designs beim ARM erwarten? Ich möchte natürlich zuerst gerne kleine Projekte lösen, vielleicht auch einmal ein paar Sensoren und eine kleine Steuerung. Aber auch größere Projekte z.B. die Anbindung eines Grafikdisplays für eine benutzerfreundliche Bedienerführung würde mich interessieren. Ich denke spätestens wenn es an eine MPEG-Dekodierung oder ähnliches geht, muss es dann doch ein leistungsfähigerer Prozessor sein. Wäre es denn so, dass wenn ich mit einem ARM7 klarkomme, ein Umstieg auf einen ARM9 oder höher dann weniger Probleme bereitet? Wäre es ein Fehler, mit der ARM7-Architektur statt AVR einzusteigen, um nach oben ein wenig mehr Leistungsreserven zu haben als mit der AVR-Architektur? Ist der Einarbeitungsaufwand bei den ARM sehr viel größer als bei den AVR? Was haltet Ihr von den Entwicklungs-Boards BigAVR oder EasyARM von http://www.mikroe.com ? Für mein Projekt würde ich gerne im fertigen Gerät einen kleinen, preisgünstigen ARM einsetzen (wenn es das gibt). Möglichst ein Tiny-Modul, um den Entwicklungsaufwand rund um dem Prozessor gering zu halten. Ich entwickle auf einem "großen Board/Prozessor" z.B. EasyARM und übertrage die Firmware später in die Zielhardware. Ist das bei den ARMs ein Problem? Welche Bezugsquellen kennt Ihr für preisgünstige ARM Tiny-Module? Wäre das Interrupthandling bei den ARMs wirklich so schwierig zu verstehen oder bekommt man das leicht in den Griff? Ihr merkt schon, ich bin noch unentschlossen, tendiere aber irgendwie zu den ARMs. Vielleicht könntet Ihr mir bitte noch ein paar Einsichten liefern und meine Fragen, soweit möglich, bitte beantworten. Nochmals vielen Dank!
> Bus (I2C?) in zwei abgesetzten (je 10m und mehr) Der normale I2C hört bei ~1m auf. Es gibt zwar Verlängerungsmöglichkeit, aber empfehlenswert ist das eigentlich nicht. Sowas ist die Domäne von RS485 (single master) und CAN (multi master). Man kann mittels solcher Module konsequent auf ARM setzen. Wenn es egal ist, dass ein LPC2103- oder SAM7S-Modul so ab dem zehnfachen eines Mega8 kostet. > MPEG-Dekodierung Wenn das auch noch in Echtzeit erfolgen soll, dann sind alle hier im Forum üblichen Microcontroller aus dem Rennen. Das läuft dann auf ein paarhundert MHz oder Spezialhardware hinaus, in jedem Fall aber unfreundliche BGA-Gehäuse oder entsprechende Module.
>Ich würde gerne vorwiegend in einer Hochsprache programmieren, >vorzugsweise C. spiel erst mal ein bisschen mit assambler, z.b. mit einem pic (gratis tools...)... wenn du die grundsätzliche funktionsweise verstanden hast, würd ich erst anfangen mit C zu programmieren...
Sandro wrote: >>Ich würde gerne vorwiegend in einer Hochsprache programmieren, >>vorzugsweise C. > > spiel erst mal ein bisschen mit assambler, z.b. mit einem pic (gratis > tools...)... > > wenn du die grundsätzliche funktionsweise verstanden hast, würd ich erst > anfangen mit C zu programmieren... Um einen Controller vernünftig programmieren zu können, muss man kein Assembler können. Eine Multiplikation in Assembler stellt sich grundlegend anders da, als in C und es hilft der Entwicklung kein wenig, wenn ich mir die Multiplikation in Assembler anschaue. Weiterhin hilft es mir wenig, mich mit dem Paging beim PIC auseinander zu setzen. Das sind üble Altlasten und bescheren nicht selten stundenlanges Suchen. Man sollte von der veralteten Meinung wegkommen, nur derjenige könne einen µC gut programmieren bzw. beherrschen, der Assembler kann. Das ist Hinterhofdenken und wirklich nicht mehr zeitgemäß. Der Trend geht ganz klar zu grafischer Programmierung, bei der man sich um die Lösung kümmert und nicht um den Code. Ein Paradebeispiel ist der Sigma-DSP von ADI. Man kann in wenigen Minuten eine komplette Signalverarbeitung mit z.B. 8 Audiokanälen fertigstellen. Ich möchte dich mal sehen, ob du das in Assembler in weniger als einer Woche schaffst. Assembler empfiehlt sich wirklich nur dann, wenn es auf das letze Byte ankommt oder auf das taktgenaue Timing.
Steven Wetzel wrote: > Der Trend geht ganz klar zu grafischer Programmierung, bei der man sich > um die Lösung kümmert und nicht um den Code. Ein Paradebeispiel ist der > Sigma-DSP von ADI. Man kann in wenigen Minuten eine komplette > Signalverarbeitung mit z.B. 8 Audiokanälen fertigstellen. Grafische Programmierung wird immer als super einfach dargestellt, isses aber nur solange, wie auch die Projekte einfach sind. Du kannst praktisch nur solche Sachen machen, die der Entwickler der grafischen Tools vorausgedacht hat. Sobald die Applikation aber ein bischen umfangreicher wird, bist Du schnell am Ende. Eine mittlere Applikation aus etwa 10.000 C-Zeilen kannst Du unmöglich mehr grafisch überblicken. Peter
Heuzutage kosten nano-ITX Rechnern mit alles "on-board" weniger als 150€. Du kriegst 800MhZ CPU, Soundkarte, Ethernet, LPT, COM, Tastatur, VGA usw. Alles ist auf Platine 12x12cm, kleiner als viele AVR oder ARM Projekten. Mikrocontroller braucht man NUR für portable sachen, die brauchen wenig Strom . Und dafür benutzt man auf keinem fall AVR oder ARM. Sie sind zu hungrig auf Strom. ARM kosten komisherweise viel für was sie anbieten. Ich empfehele dir MSP430 für Kleinigkeiten und nano-ITX VIA für grossere Dinge. MSP von TI hat gcc, glibc. Billigste MSP430 kostet weniger als zwei euro, hat DIP Gehäuse. Er ist ganz gut im Linux zu programmieren. Auf nano-ITX läuft normalerweise Linux. Um zu programmieren, einfach Display und Tastatur anzuschliessen. Aber vergiss über Akku-betrieb.
ich bin der meinung, dass man mit C schneller zum erfolg kommt und das ist gerade am anfang sehr wichtig. in einem 2. schritt kann man sich immer noch um assembler bemühen um codoptimierter zu programmieren oder um ein besseres verständnis des compilers zu bekommen. ps: die neuen 18er-PICs haben keine bänke mehr (kein umschalten mehr). mich wunders immer wieder, dass diese alte gerücht so standhaft propagiert wird
Hallo, > Grafische Programmierung wird immer als super einfach dargestellt, isses > aber nur solange, wie auch die Projekte einfach sind. Ich denke nicht, dass die DSP-Projekte für den Sigma-DSPO einfach sind. Abgesehen davon tut man sich sehr schwer, diesen nicht im Sigmastudio zu programmieren. Es ist leicht, einen Vergleich zwischen Visual DSP und Sigmastudio anzustellen. Compressor, Limiter, Filter müssten alles in Biquads erledigt werden. Der Programmieraufwand ist dabei sehr hoch. In Sigmastudi klickt man sich wirklich seine Lösung zusammen und so, wie es Libraries gibt, die die Funktionen in Assembler abbilden, so geht das auch in einer grafischen Umgebung. Nehmen wir eine Sensorschaltung für einen beliebigen µC, sagen wir, wir messen Spannung. Eine grafische Umsetzung gestaltet sich sehr einfach. Man nehme den ADC-Block, definiere den Eingangsbereich und den Anzeigeblock und definiere dortg die Art der Darstellung. UART gewünscht? kein Problem. Ein Klick und die UART ist drin. Was heute in Funktionen und Codeschnipsel verbreitet wird, lässt sich auch grafisch erstellen. Warum muss man für einen MP3-Dekoder immer und immer wieder dasselbe schreiben? Ein fertiger Block reicht völlig aus und ob die Daten nun als Funktionsparameter übergeben werden oder als Leitung dargestellt werden, ist irrelevant. > Du kannst praktisch nur solche Sachen machen, die der Entwickler der > grafischen Tools vorausgedacht hat. Du kannst alles machen, was sich Funktion nennt. Programmiert man öfters µCs, wird man immer wieder auf dieselben Funktionen treffen. Im Grunde klickt man dann erst mal das Grundgerüst zusammen und füllt dann aus. Da geht auch grafisch. Schon mal den Codevision AVR gesehen? Ohne auch nur einmal den Code anzufassen, kann man sich eine Ein-Ausgabe-Routine definieren und kümmert sich nur noch um die interne Verarbeitung der Daten. > Sobald die Applikation aber ein bischen umfangreicher wird, bist Du > schnell am Ende. Das sicher. Aber dann definiert man für diese Funktion den nächsten grafischen Block. Überlege mal, wieviel Zeit vergeht, um erst mal das Grundgerüst fertig zu bekommen, d.h. Initialisierung und Ein-Ausgabe. > Eine mittlere Applikation aus etwa 10.000 C-Zeilen kannst Du unmöglich > mehr grafisch überblicken. Das geht sogar sehr einfach, indem man die Funktionen gruppiert und dann beim Debuggen darin abtaucht, das ganze Design also hierarchisch aufbaut. Der Erfolg von NI mit LabVIEW beruht eben vor allem darauf, weil man eben nicht mehr Programmierer sein muss, um eine Steuerung zu realisieren. Auch Matlab geht diesen Weg. Man erstell in Simulink ganze Regelkreise, auf Knopfdruck wird der dazugehörige VHDL-bzw. C-Code erzeugt. Die Zukunft heißt zwangsläufig grafische Programmierung. Das sieht man auch an der Entwicklung: http://en.wikipedia.org/wiki/Visual_programming_language
>Die 16er gibt es immer noch und die meisten Topics drehen sich gerade um >diese Vermutlich, weil es dafür keinen (vernünftigen, bezahlbare) C-Compiler gibt. >Der Erfolg von NI mit LabVIEW beruht eben vor allem darauf, weil man >eben nicht mehr Programmierer sein muss, um eine Steuerung zu >realisieren. Auch Matlab geht diesen Weg. Man erstell in Simulink ganze >Regelkreise, auf Knopfdruck wird der dazugehörige VHDL-Code erzeugt. Fischertechnik und Lego arbeiten auf diesem Sektor ausch schon länger. Das muß aber noch lange nicht heissen, dass sie auch im Bereich der Controller sinnvoll/zweckmässig ist. Ein gutes Quasi-Beispiel ist Bascom (ja, ich bin kein Freund davon - wer es mag, darf damit glücklich werden): Hier gibt es wie bei der grafischen Programmierung eine Menge vorgefertigter Bausteine. Leider ist das nicht besonders resourcenfreundlich, da man z.B. einen Timer nur für einen Baustein benutzen kann - in einer "normalen" Programmiersprache wäre es auch möglich mehr, als nur diese eine Aufgabe damit zu erschlagen. >Die Zukunft heißt zwangsläufig grafische Programmierung. Das sieht man >auch an der Entwicklung: Auf diese Zukunft kann ich verzichten...
Steven Wetzel wrote: > Nehmen wir eine Sensorschaltung für einen beliebigen µC, sagen wir, wir > messen Spannung. Eine grafische Umsetzung gestaltet sich sehr einfach. > Man nehme den ADC-Block, definiere den Eingangsbereich und den > Anzeigeblock und definiere dortg die Art der Darstellung. UART > gewünscht? kein Problem. Ein Klick und die UART ist drin. Sach ich doch, Du kannst nur das hinklicken, was vorher eingebaut wurde. Das Problem ist doch nicht die UART, sondern daß ich darauf ein bestimmtes Protokoll implementieren muß. Und ein Protokoll besteht nunmal aus ner Menge Text, da wüßte ich nicht, wie man sowas grafisch machen soll. Und was mir am meisten an der Grafiksache fehlt ist die Zeitebene. Man hat überhaupt keine Übersicht über den Zeitablauf. Ich muß aber ne Menge Zeitabhängigkeiten prüfen und Zeitabläufe programmieren. Prozesse dürfen nur ne bestimmte Zeit dauern bzw. müssen eine bestimmte Zeit nach einem anderen ausgeführt werden, oder müssen nach einer bestimmten Zeit abgebrochen werden. Und so einfach nen ADC hinpappen, damit ists auch noch lange nicht getan. Wenn ich z.B. nen Regelkreis programmiere, kann man das nicht so einfach hinschreiben, wie es in der idealen Theorie aussieht. Ich muß auch da spezielle Bedingungen einbauen, um die Werte auf Gültigkeit zu prüfen, bei Änderungen ein schnelles Einschwingen zu erreichen, im Regelzustand ein Schwingen zu erkennen und abzubauen usw. Das Allgemeine kann ich mir genausogut auch in C aus Bibliotheken zusammenklicken. Aber sobald es speziell wird, ist Handarbeit angesagt und dabei wüßte ich nicht, wie ich es grafisch wuppen können soll. Peter
Bernhard, ich kann deine Suche nach der Eierlegenden Wollmilchsau verstehen aber das ist der falsche Weg. Für einfache Aufgaben reichen die 8 und 16 BIT MC's allemal. Also vielleicht nochmal zusammenfassend: MSP-430, Freier C Compiler: http://mspgcc.sourceforge.net/ 8x51, C Compiler: http://sdcc.sourceforge.net/ AVR, C Compiler: http://winavr.sourceforge.net/ Fang einfach mit irgendeiner dieser 3 Familien an. Kosten sind minimal und dann siehst du weiter. Für dein Einsteigerprojekt reichts allemal.
>MSP-430, Freier C Compiler: http://mspgcc.sourceforge.net/ >8x51, C Compiler: http://sdcc.sourceforge.net/ >AVR, C Compiler: http://winavr.sourceforge.net/ für AVR lieber ein normales GCC Compiler, der man als Standart Compiler unter Linux, FreeBSD, MinGW für Windows, MacOSX benutzt. Einfach 'man gcc' in deinem Terminal eintyppen, dann '/' drücken und 'avr' eintyppen, und press Return um ganzen list von optionen zu sehen. Was du brauchst, ist avr-libc: http://www.nongnu.org/avr-libc/ Ich empfehele dir Gentoo Linux, da kann man alle notwendige programme sehr einfach installieren: emerge cross-avr/gcc emerge cross-avr/binutils emerge avrdude emerge avr-libc
Graphische Programmierung ist gut unter 3 Gesichtspunkten. 1) Der Rechner ist massiv überdimensioniert 2) Der Benutzer hat keine Ahnung und keine Interesse 3) Der Benutzer hat satt Knete Z.
Nochmals vielen herzlichen Dank! Eure Meinungen haben mir sehr geholfen, eine Entscheidung zu treffen. Wenn ich das alles so lese, dann sieht es so aus, als würde ich mich für AVR entscheiden. Der ARM wäre interessant, ist aber für meine Bedürfnisse derzeit noch völlig überdimensioniert und doch recht komplex für den Anfang, der "Spontanbastelfaktor" ist nicht so attraktiv. Der TI MSP430 wäre hochinteressant und würde mir gut gefallen, da volle 16 Bit-Architektur, moderne und leicht verständliche Architektur und es gibt preisgünstige aber auch leistungsfähige Typen. Leider scheint auch hier die "Spontanbasteleignung" (3.3V) eingeschränkt, die Cummunity ist eher klein und die freien Tools aus meiner aktuellen Sicht nicht so vielfältig, wie beim AVR. Das Angebot an "größeren" Eval-Boards (inkl. Display, Ports etc.) und Prozessormodulen ist auch eher gering. Ich bitte um Korrektur, falls ich mich irre. Der AVR ist für meine aktuellen Projekte völlig ausreichend. Und wie einige bemerkten, muss ich erst wieder in Fahrt kommen, bis ich mich auf ein komplexeres Projekt einlassen kann. Dann kann ich ja noch immer auf eine leistungsfähigere Familie umsteigen, wenn ich wieder mehr Erfahrung habe. Der AVR bietet eine große Anwendergemeinde, viele freie Tools und Beispiele und auch in diesem Forum viel Unterstützung. Was haltet Ihr von dem Entwicklungs-Board BigAVR von http://www.mikroe.com/en/tools/bigavr/ ? Nicht gerade ein billiges Vergnügen, aber man kann bereits sehr viel ausprobieren und "spielen". Die endgültige Zielhardware im Fertiggerät kann ja dann ein kleinerer ATmega sein, oder sehe ich das falsch? Für die Programmierung und das On-Chip Debugging (C - Source-Code-Level) benötige ich doch nur noch ein AVR-JTAG-USB, dann kann ich doch schon richtig mit AVR-Studio/WinAVR loslegen, oder?
Ich finde den ARM7 eigentliche recht einfach. Das ganze ist sehr zukunfts"fähig" und auch recht preiswert zu realisieren. Ich hab sehr lange 8051 angewendet, aber irgendwann ist da auch mal der Zug abgefahren. Die neueren ARM7 Derivate sind preiswert und ne ganze Ecke leistungsfähiger als 8 Bit Prozessoren. Wenn ich mir dann noch sowas wie den LPC2101..3 vom Preis her anschaue, gibts kaum noch ne ALternative. Gruß Thomas
Gibt es denn für den ARM7 eine komplette, komfortable C-Entwicklungsumgebung mit IDE/Editor und Source-Level-Debugger-Oberfläche wie beim AVR mit AVR-Studio/WinAVR? Oder muss man auf die kommerziellen Compiler/Debugger ausweichen, wenn man beim ARM7 diesen Komfort möchte? Gehen wir einmal von einem (teuren) Tiny-Modul aus: Ist denn der Aufbau von Streckbrett-Experimenten mit dem ARM7 ebenso einfach möglich? Stört denn unter anderem die 3.3V Architektur nicht bei diesen Spontanexperimenten und schränkt die Anwendbarkeit von vielen Bausteinen ein?
> Gibt es denn für den ARM7 eine komplette, komfortable > C-Entwicklungsumgebung mit IDE/Editor und > Source-Level-Debugger-Oberfläche wie beim AVR mit AVR-Studio/WinAVR? > Oder muss man auf die kommerziellen Compiler/Debugger ausweichen, wenn > man beim ARM7 diesen Komfort möchte? Wie bei MSP430, AVR oder eben auch bei den ARMs Eclipse + CDT + entsprechende GCC-Variante. Z.B. hier für den MSPGCC erklärt http://inf.ntb.ch/infoportal/help/index.jsp?topic=/ch.ntb.infoportal/embeddedSystems_MSP430.html > Ist denn der Aufbau von Streckbrett-Experimenten mit dem ARM7 ebenso > einfach möglich? Mit entsprechenden Adaptern (zumindest sind mir keine ARMs im DIL-Gehäuse bekannt). http://shop.mikrocontroller.net/ > Stört denn unter anderem die 3.3V Architektur nicht bei > diesen Spontanexperimenten und schränkt die Anwendbarkeit von vielen > Bausteinen ein? Mittlerweile stört es eher, wenn man mit 5V arbeiten muss und dann modernere LCDs, OLEDs, RF-Transceiver, SDKarten, Flash-Speicher etc. anzubinden hat. Auch für die Standardschnittstellen ala RS-232/485, CAN gibt es passende Treiberbausteine.
> Sach ich doch, Du kannst nur das hinklicken, was vorher eingebaut wurde. Wie bei einer C-Library auch. > Das Problem ist doch nicht die UART, sondern daß ich darauf ein > bestimmtes Protokoll implementieren muß. > Und ein Protokoll besteht nunmal aus ner Menge Text, da wüßte ich nicht, > wie man sowas grafisch machen soll. Du wirst doch hoffentlich Standardprotokolle implementieren. Wie sieht denn heute eine typische UART-Transmission aus? UART initialisieren (Ports, BAUD-Rate), Daten ins Senderegister schreiben, abfragen, ob Daten gesendet wurden. Wie sieht es in Zukunft aus? Block nehmen, Leitung ziehen. > Und was mir am meisten an der Grafiksache fehlt ist die Zeitebene. > Man hat überhaupt keine Übersicht über den Zeitablauf. Den hat man bei C ohnehin kaum. Diese ist compilerabhängig aber viele gute Compiler bieten ja dafür eine Schnittstelle. > Ich muß aber ne Menge Zeitabhängigkeiten prüfen und Zeitabläufe > programmieren. Dann nimm Assembler oder einen C-Compiler, wo du genauestens die implementieren Funktionen aus der Lib kennst. Desweitern darfst du dann keine Optimierungsläufe machen. > Prozesse dürfen nur ne bestimmte Zeit dauern bzw. müssen eine bestimmte > Zeit nach einem anderen ausgeführt werden, oder müssen nach einer > bestimmten Zeit abgebrochen werden. Also Assembler. > Wenn ich z.B. nen Regelkreis programmiere, kann man das nicht so einfach > hinschreiben, wie es in der idealen Theorie aussieht. > Ich muß auch da spezielle Bedingungen einbauen, um die Werte auf > Gültigkeit zu prüfen, bei Änderungen ein schnelles Einschwingen zu > erreichen, im Regelzustand ein Schwingen zu erkennen und abzubauen usw. Ein Regelkreis, wie beschrieben, kann man heute in Simulink simulieren und sich den dazugehörigen Code ausspucken lasen. Das geht leider derzeit noch nicht bei kleinen µC, wobei man hier in unglaublicher Friemelarbeit den Code erzeugen muss und froh sein kann, wenn er das macht, was die Simulation zeigt. > Das Allgemeine kann ich mir genausogut auch in C aus Bibliotheken > zusammenklicken. > Aber sobald es speziell wird, ist Handarbeit angesagt und dabei wüßte > ich nicht, wie ich es grafisch wuppen können soll. Zu allen grafischen Programmiertools gibt es immer noch die normale Programmierschnittstelle. Man sollte nur von dem hohen Ross runter kommen, dass man eine entsprechende Persönlichkeit ist, wenn man einen µC programmieren kann. Heute ist es nicht wichtig, dass man programmieren kann und wie toll man das in Assembler schafft, sondern dass eine Lösung in kürzester Zeit aufweisen kann. Viele µC-Hersteller haben dies erkannt und bieten dementsprechend Tools an. Steven
> Ein Regelkreis, wie beschrieben, kann man heute in Simulink simulieren > und sich den dazugehörigen Code ausspucken lasen. Und hast du dir den Code mal angesehen? Er funktioniert zwar, ist aber dennoch unbrauchbar. In Basic wäre er effizienter zu programmieren.
>Man sollte nur von dem hohen Ross runter kommen, dass man eine >entsprechende Persönlichkeit ist, wenn man einen µC programmieren kann. Es ist schon was besonderes... >Heute ist es nicht wichtig, dass man programmieren kann und wie toll man >das in Assembler schafft, sondern dass eine Lösung in kürzester Zeit >aufweisen kann. Humbug. Wenn jemand einen Controller effizient per C oder Assembler programmieren kann, dann ist das auf jeden Fall besser, als wenn ein "Schimpanse"* irgendwelche Standard-Blöcke zusammenklicken kann, und das Programm zwar das gleiche wie das des "Experten" kann, dafür aber einen 32Bit-Controller braucht, wo das andere mit einem 8bitter auskommt. *)wie schon oben geschrieben: Lego und Fischertechnik bieten etwas derartiges an. >Viele µC-Hersteller haben dies erkannt und bieten >dementsprechend Tools an. Wer, und welche? >Geiz ist eben geil.Zeit ist auch Geld. Wenn ich für manche Aufgaben >mehrer Monate, statt Stunden brauche, rechnet sich das allemal. Wenn man aber aufgrund eines total überdimensionerten Controllers zwar niedriege Entwicklungskosten hat, dafür aber hohe Stückkosten, wird dann doch mal nachgeguckt, ob sich da nicht doch etwas optimieren lässt. >Wer seinen Lebenssinn in der Programmierung von µC sieht, anstatt in den >Lösungen, der darf auch weiterhin in Assembler programmieren. Den Kunden >interessiert aber das Produkt und nicht immer ist der Weg das Ziel. Hat hier irgendwer davon gesprochen/geschrieben, dass Assembler das Allheilmittel ist? Du lehnst dich ganz schön weit aus dem Fenster...
Steven Wetzel wrote: > Man sollte nur von dem hohen Ross runter kommen, dass man eine > entsprechende Persönlichkeit ist, wenn man einen µC programmieren kann. Man sollte von seinem hohen Roß runterkommen, daß Programmieren einfach ist und das einem grafische Tools die Programmierarbeit abnehmen können. > Heute ist es nicht wichtig, dass man programmieren kann Doch, genau das ist wichtig. Mich kotzt das immer wieder an, wie grauenhaft Heimelektronoik programmiert ist. Z.B. hatt ich mal nen Fernseher gekauft und mich gewundert, warum der Lieferant ihn beim Einstellen der Sender mit voller Lautstärke dröhnen ließ, das mir die Ohren schmerzten. Nun, im Sendermenü war eine Lautstärkeeinstellung nicht möglich. Z.B. hatte ich einen Philips Videorekorder, der hätte auf der FB ein Grafikdisplay mit einer animierten Sanduhr haben müssen, so schnarchlahm war das Ding (und natürlich keine Taste gepuffert). Dergleichen Beispiele lassen sich unendlich fortsetzen. Programmieren ist, sich Gedanken zu machen und nen Plan (und auch ein kleines bischen Können). Das kann einem kein Tool der Welt abnehmen. Man sieh ja ständig, was bei ner husch-husch Zusammenklickerei so rauskommt, nur der absolute Mist. Und der Kunde ärgert sich und kauft nie wieder ein Gerät bei dieser Firma. Peter
Grafische Programmierung: Ich bin Euch sehr dankbar, dass Ihr mir helft, aber die Diskussion über grafische Programmierung wäre doch besser in einem eigenen Thread aufgehoben. Das Thema ist bestimmt sehr interessant, aber es passt nicht so recht zu meinem aktuellen Problem und meinen Fragen. Bitte verschiebt das doch in einen eigenen Thread, sonst bläht sich dieser Thread unnötig auf. Lieben Dank!
Und wieder eine Fredentführung, für die ich nicht verantwortlich bin. @Bernhard: Falls es dir noch nicht aufgefallen sein sollte (bzw. im Trubel um grafische "Programmierung" untergegangen sein sollte): Hier im Forum benutzt die Mehrheit AVR-Controller der Firma Atmel. Die sind preiswert erhältlich, lassen sich mit dem AVR-GCC "komfortabel" in C programmieren und sind untereinander schön kompatibel (bis auf Controller ohne SRAM und durch unterschiedliche Namensgebung bei eigentlich gleichen Registern). Andere Controller-Familien werden hier etwas stiefmütterlich behandelt (teils berechtigt... dafür gibt es aber auch sprut.de), aber auch bei entsprechenden Fragen wird hier einem geholfen.
wieso bei 18er- und 30/33er-PICs berechtigt?
Rahul, der Trollige wrote: > @Bernhard: > Falls es dir noch nicht aufgefallen sein sollte (bzw. im Trubel um > grafische "Programmierung" untergegangen sein sollte): Hier im Forum > benutzt die Mehrheit AVR-Controller der Firma Atmel. > Die sind preiswert erhältlich, lassen sich mit dem AVR-GCC "komfortabel" > in C programmieren und sind untereinander schön kompatibel (bis auf > Controller ohne SRAM und durch unterschiedliche Namensgebung bei > eigentlich gleichen Registern). > Andere Controller-Familien werden hier etwas stiefmütterlich behandelt > (teils berechtigt... dafür gibt es aber auch sprut.de), aber auch bei > entsprechenden Fragen wird hier einem geholfen. Genau das ist es! Ich würde gerne auf einem neuen, modernen und richtig "saftigen" Prozessor wie dem ARM7 anfangen. Wenn ich aber bei kleinsten Problemen erst alles selbst herausknobeln muss und ich dann ewig nicht weiter komme, dann macht es keinen Spaß. Oft ist weniger mehr und es haben mir neben Dir ja einige empfohlen "klein" anzufangen. Ich habe mich für AVR entschieden und werde mir jetzt als nächstes die Entwicklungs-HW bestellen. Bitte noch eine wichtige Anfängerfrage, damit ich bestellen kann: Mit einem ATmega128 Entwicklungsboard mit AVR-USB-JTAG von Olimex (http://www.olimex.com/dev/avr-usb-jtag.html) kann ich doch so richtig mit AVRStudio/WinAVR in C in einer IDE inkl. Oberfläche für Source-Level-Debugging loslegen, sehe ich das richtig? Kann mir jemand eine günstige Bezugsquelle für das AVR-USB-JTAG empfehlen?
>Mit einem ATmega128 Entwicklungsboard mit AVR-USB-JTAG von Olimex >(http://www.olimex.com/dev/avr-usb-jtag.html) kann ich doch zunächst mit >AVRStudio/WinAVR in C in einer IDE inkl. Oberfläche für >Source-Level-Debugging loslegen, sehe ich das richtig? Kennst du den Spruch mit Kanonen und Spatzen? Das AVRStudio ist übrigens die "IDE inkl. Oberfläche für >Source-Level-Debugging", wenn man es auch noch mit dem AVR-GCCC "bekannt macht" kann man es auch als C-Editor benutzen (mir persönlich gefällt das Programmer's Notepad besser). Vielen reicht der im AVR-Tutorium beschriebene Programmer (für den Anfang). Praktisch sind auch das AVRISPmkII wegen seines USB-Anschlusses und das STK500, weil man das zum entwickeln/austesten und programmieren der Controller nutzen kann - auch lassen sich "totgefusete" Controller "wiederbeleben".
>Ich lobe hier nicht die grafische Programmierung in den Himmel. Doch, tust du wohl. >Was? Du kennst nur die Firma Atmel? Wie klein die Welt mancher Leute >ist... Nö, ich kenne auch ein paar andere. Nur fallen diverse "Controller-Anbieter" nicht mehr in den Bereich, der für mich noch unter "Controller" fällt. Freescale stellt auch nette "Controller" her... >Max Planck Höhö...und wieder ein Kieler... >Ich schließe das mit dem wunderschön passenden Zitat von Max Planck ab: Ich mit dem hier: "Du hast Recht, und ich meine Ruhe!"
Rahul, der Trollige wrote: >Praktisch sind auch das AVRISPmkII wegen seines USB-Anschlusses und das >STK500, weil man das zum entwickeln/austesten und programmieren der >Controller nutzen kann - auch lassen sich "totgefusete" Controller >"wiederbeleben". Danke für die Tipps. Ich habe mir das STK500 angesehen. Leider hat es keine JTAG-Schnittstelle und ist für das Gebotene relativ teuer. Es gibt günstigere Boards inkl. Display, LEDs, Taster etc. mit denen man zum Wiedereinstieg besser "spielen" kann. Wenn man viele unterschiedliche AVRs programmieren möchte, ist das STK500 natürlich ideal und dafür war es doch auch gedacht, nehme ich an. Ist der AVRISPmkII neben dem AVR-USB-JTAG von Olimex sinnvoll oder notwendig? Ich denke zwar nicht, dass ich mich gleich zu Anfang mit den Fuse-Bits auseinandersetzen werde. Aber habe ich das richtig verstanden, dass ich ein AVRISPmkII benötige, wenn ich z.B. einen ATmega128 "wiederbeleben" möchte?
>Aber habe ich das richtig verstanden, dass ich >ein AVRISPmkII benötige, wenn ich z.B. einen ATmega128 "wiederbeleben" >möchte? Falsch verstanden/ausgedrückt. Wiederbeleben kann man die Controller nur mit dem STK500 (oder einem anderen HV-Programmer). Ich wüsste zwar nicht unbedingt, wofür man ein JTAGICE braucht (Kanonen und Spatzen...), aber damit kann man auch glücklich werden.
@Bejoro: Zum "Wiederbeleben" benötigst Du nur das STK500-Mainboard, das die HV-Programmierung beherrscht. Das AVR JTAG mkII habe ich zwar, bin damit aber nicht so zufrieden. Das Olimex-Teil (Elektronikladen, EUR 49,90) gefällt mir viel besser.
Also, dann lege ich los! AVR-Board inkl. AVR-JTAG-USB wird bestellt. Sobald ich die ersten Gehversuche unternommen habe, werdet Ihr mit großer Wahrscheinlichkeit wieder von mir hören. ;-) Ihr habt mir alle sehr geholfen! Vielen lieben Dank! Ich freue mich schon auf meine ersten Programmiererfahrungen, ein erfreuliches und motivierendes Vorhaben, wenn man nach so langer Zeit wieder anfängt. Ich war mehrere Jahre SW-Entwickler bei Siemens, bis ich zum Manager mutierte. Ich bin aber immer im Herzen Ingenieur geblieben, weshalb mich dieser Wiedereinstieg motiviert und das Gehirn wieder auf trapp bringt. Bitte streitet Euch nicht weiter bzgl. der Berechtigung grafischer Programmierung. Ich war einige Jahre u.a. Produkt- und Marketingmanager bei Siemens für Industriesoftware im Bereich Automatisierungstechnik und mache mich jetzt gerade als Unternehmensberater selbständig. Der Trend geht eindeutig hin zur grafischen Projektierung mit anschließender automatischer Codegenerierung. Viele Anwender benötigen dies natürlich nicht oder lehnen es ab, das ist auch völlig o.k. Das ist so ähnlich wie der Übergang von reiner STEP5-Programmierung zur Programmierung mittels Kontakt- oder Funktionsplan. Das wurde zu Anfang auch abgelehnt. Als man aber feststellte, dass der Industrieelektroniker keine Tipps, Tricks, Spielereien und detaillierten Programmierkenntnisse mehr benötigt, um ein Programm zu erstellen oder zu verstehen, weil er es wie einen Schaltplan lesen konnte, kam langsam der Umstieg. Wer als Hersteller für Automatisierungssysteme diesen Zug der modularen, grafischen Projektierung und automatischen Codegenerierung verpasst, der wird langfristig am Markt nicht mehr erfolgreich sein können. Es ist somit nicht die Frage, ob die grafische Programmierung kommt, sondern wann. Wichtig ist jedoch dabei der Reifegrad. Auch hier wird es einen langen Prozess der Anpassung geben, bis auch die ausgefuchsten Programmierer zufrieden sind. Wie bei vielen Industriezweigen wird sich auch hierbei wieder eine Verschiebung der Kompetenzen ereignen, wenn sich diese Form der Programmierung oder besser gesagt Projektierung durchsetzt. Wir benötigen dann diese ausgefuchsten Entwickler nicht mehr, um die resultierenden Entwicklungsumgebungen zu bedienen/anzuwenden, sondern um diese zu entwickeln.
Das STK500 u. STK501 gibt's z.Zt. bei Reichelt recht günstig.
Ich finde den Mega128 total oversized für den Einstieg, den Mega8 oder Mega16 finde ich optimal. Aber ich will Dir nichts vorschreiben. Ne große CPU verleitet schnell dazu, Spaghettikode (copy&paste-Monster) zu fabrizieren, wo man dann hinterher nicht mehr durchblickt. Ne kleine CPU verleitet dazu, sinnvolle Unterfunktinen zu schreiben. Ich hab mir auch mal einen Debugger angesehen, zum Lernen ist das ja ganz lustig, wenn man sich mal die verschiedenen Register ansehen kann. Aber zum praktischen Programmieren taugt sowas überhaupt nichts, sobald man sich was ansieht, steht die CPU und die ganze Applikation ist zum Teufel. Z.B. die Gegenstelle sendet fleißig weiter an die UART, aber dort kommt nur Müll an, weil ja durch das Stillstehen haufenweise Daten verloren wurden. Und sämtliche Zeitabläufe krepieren auch. Ich mach dann immer Ausgaben an die Stellen rein, wo ich was wisen will aber auch nur dann, wenn sie von dem Erwarteten abweichen und die werden dann "on the fly" z.B. über die UART gesendet. D.h. die Applikation kann ungestört weiterlaufen. Peter
Peter Dannegger wrote: > Ich finde den Mega128 total oversized für den Einstieg, den Mega8 oder > Mega16 finde ich optimal. Aber ich will Dir nichts vorschreiben. > > Ne große CPU verleitet schnell dazu, Spaghettikode (copy&paste-Monster) > zu fabrizieren, wo man dann hinterher nicht mehr durchblickt. > > Ne kleine CPU verleitet dazu, sinnvolle Unterfunktinen zu schreiben. > > > Ich hab mir auch mal einen Debugger angesehen, zum Lernen ist das ja > ganz lustig, wenn man sich mal die verschiedenen Register ansehen kann. > > Aber zum praktischen Programmieren taugt sowas überhaupt nichts, sobald > man sich was ansieht, steht die CPU und die ganze Applikation ist zum > Teufel. > > Z.B. die Gegenstelle sendet fleißig weiter an die UART, aber dort kommt > nur Müll an, weil ja durch das Stillstehen haufenweise Daten verloren > wurden. > Und sämtliche Zeitabläufe krepieren auch. > > > Ich mach dann immer Ausgaben an die Stellen rein, wo ich was wisen will > aber auch nur dann, wenn sie von dem Erwarteten abweichen und die werden > dann "on the fly" z.B. über die UART gesendet. D.h. die Applikation kann > ungestört weiterlaufen. > > > Peter Peter, keine Sorge! Du darfst mir gerne viele Tipps geben. Ich fühle mich nicht bevormundet. Ich weiß Deine Hilfe sehr zu schätzen. Aufgrund meiner zwar zurückliegenden, aber mehrjährigen Erfahrung als SW-Entwickler, ist mir die Gefahr des "Quick-and-Dirty"-Programmierens bekannt. Ich werde versuchen diszipliniert zu programmieren. :-) Mein erstes Projekt bei Siemens war die Entwicklung eines BDE-Terminals auf Basis eines Siemens 80C535. Wir arbeiteten mit einem sehr komplexen und leistungsfähigem 80C535-ICE, Protokollanalyzer und natürlich Life-Ausgaben. Die Kombination aus ICE/Debugger und Life-Ausgabe z.B. über UART ist aus meiner Sicht optimal. Nicht jeder kann sich einen Protokollanalyzer leisten, so kann der PC helfen, die Ausgaben zu analysieren. Das ICE oder der JTAG-Debugger nimmt einem natürlich nicht die Denkarbeit ab, die Ergebnisse zu interpretieren. Eine schöne Funktion dieses (damals sauteuren) 80C535-ICE war die Trace-Funktion, die es auch erlaubte dynamische Prozesse aufzuzeichnen und zu analysieren. Das war aber dann auch eine sehr zeitaufwändige Arbeit. Ich werde mir natürlich auch einen Mega16 besorgen, ist ja kein Vermögen und einfach aufzubauen. Ein richtig schnuckeliges Prozessorchen mit viel Leistung.
Günter R. wrote: > Das STK500 u. STK501 gibt's z.Zt. bei Reichelt recht günstig. Ich bin noch unschlüssig, aber ich glaube ich werde mich für ein EasyAVR4 von mikroElectronica entscheiden. http://www.mikroe.com/en/tools/easyavr4/ Ich weiß, das ist ein Monsterboard, aber dort kann ich zum Start viel ausprobieren und "spielen" und alles einsetzen/programmieren, vom ATmega8 bis zum ATmega644.
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.