Hallo!! Meine Microcontroller-Erfahrungen liegen fast schon Jahrzehnte zurück. Nun möchte ich mich gerne im Rahmen einer Hobby Anwendung mit einem etwas moderneren Controller beschäftigen. Ich bin in der Auswahl also völlig frei. Und das macht die Sache kompliziert! Zunächst wäre es schön, wenn PDIP Gehäuse verfügbar wären. Damit fällt Freescale schon mal raus, wenn ich das richtig sehe. PICs wären wohl was die Gehäuse angeht am vielfältigsten, allerdings erscheint mir die Leistungsfähigkeit dieser Prozessoren eher etwas eingeschränkt gegenüber der Konkurrenz. Atmel und Ti sind offensichtlich gerade im Hobbybereich sehr populär. Das wird wohl seinen Grund haben, aber gäbe es evtl. trotzdem weniger bekannte Controller, die man sich mal angucken sollte? Ein ganz wichtiger Punkt ist eine Entwicklungsumgebung unter Linux. Das schließt auch die Datenübertragung zum Controller mit ein. Weiterhin wäre es sehr von Vorteil dieses per USB bewältigen zu können. Sehe ich das richtig, dass eigentlich nur der Bootloader des MSP430 in Frage kommt um die Daten über eine serielle (USB) Schnittstelle unter Linux in einen Prozessor zu bekommen? Die ganzen proprietären Technologien wie debugWIRE und spy-bi-wire lesen sich recht angenehm, da gerade in einem 14 oder gar 8-pin Gehäuse die Peripherieleitungen nicht gerade großzügig verwendet werden können. Aber dafür wird es wohl gar keine freien Tools geben. Können das denn wenigstens die kostenlosen Einsteigertools der Hersteller (AVRStudio bzw. dieses Kickstartdings von ti)? Oder muss man dafür zahlen? Wenn mir nun jemand raten würde, die Idee die Programmierung über eine USB Schnittstelle gleich zu vergessen, würde das auch den Windowseinsatz nicht generell ausschließen. Allerdings stünde dann nur win98 zur Verfügung und ich bezweifle, daß die Tools darin lauffähig sind. Ich will aber nun die Auswahl des Prozessors nicht übermäßig am Aufwand für das Setup der Entwicklungsumgebung orientieren, wenn andere Gründe für oder gegen einen Prozessor sprechen würden. Es heißt der Bootloader des MSP sei recht buggy, auch die A/D-Wandler seien quasi nicht zu gebrauchen. JTAG am MSP430 braucht offenbar 4 Leitungen, SPI am AVR aber auch schon 3. Das macht keinen großen Unterschied mehr. Und das debugging des MSP mit JTAG scheint mittels gnu toolchain recht praktikabel zu sein. Wenn ich debugWIRE mangels passendem Betriebssystem für AVRStudio sowieso nicht benutzen kann spricht diesbezüglich nicht mehr viel für AVR. Ich hätte z.B. eine Kfz (äh, pardon, automotive nennt man das wohl heutzutage :-) Anwendung. Gibt es für den MSP brauchbare Spannungsregler, deren Eigenverbrauch nicht den sparsamen Verbrauch des Prozessors wieder kaputt macht? (Natürlich gibt es die, aber es wäre halt auch wieder schön im DIP oder TO-xx Gehäuse und sie sollten auch in kleinen Stückzahlen bei so "consumer-distributoren" wie Reichelt o.a. erhältlich sein). Der MAX666 schwebte mir da vor, aber der macht ohne externe Beschaltung nur 5V. Auch anderer Peripherie würden 5V oft besser "schmecken", was mich wieder eher an den AVR denken lässt. Aber auch das sind alles Probleme, die sich beim MSP lösen lassen. Die Frage ist, ob sich der Aufwand lohnt? Ok, MSP hat 16bit. Das hat gerade bei Assembler-Programmierung natürlich schon seinen Charme. Ich habe bislang noch nie einen Mikrocontroller in C programmiert, aber ich stelle mir vor, daß eine 8bit Variante in C ähnlich komfortabel zu handhaben sein müsste. Abgesehen davon, dass der Code weniger effizient sein dürfte. Ich stehe der C-Programmierung eines Mikrokontrollers sowieso noch etwas skeptisch gegenüber. Sicher bietet sich das in leistungsfähigeren und umfangreicheren Applikationen an, aber manchmal drängt sich mir der Verdacht auf, dass man sich nur vor der Assemblersprache scheut? - Ok, ich weiß schon, portabilität, reusability usw usw... Aber hat das nicht auch seinen Preis? Der MSP hat kein EEPROM. Ist das in der Praxis eine Einschränkung? Ist die TI-Philosophie dergestalt, daß man aufgrund des geringen Stromverbrauchs eh immer irgendwo ne LI-Batt anstöpseln und so auf "Datensicherung" verzichten kann? Letztenendes hängt die Entscheidung bei mir wohl in erster Linie schon maßgeblich davon ab, wie "smooth" sich die Entwicklungsumgebung handhaben lässt. Aber das ist wohl auch viel eine Frage des persönlichen Geschmacks und wird man so pauschal nicht beantworten können. Generell bin ich jedenfalls eher ein Freund von Comandline-Tools unter Linux als von bunten Windows-Programmen. Und eine zuverlässige Funktion wiegt sicher schwerer als dass man mit ein paar Mausclicks eine LED zum Blinken bringen kann. Kommt man eigentlich früher oder später zur "Rettung" um so nen HV-Programmer eh nicht drum rum? Ein AVR ist damit IMMER zu retten, oder? Bei Ti gibt es etwas vergleichbares nicht, soweit ich sehe. D.h. ein TI-Controller ist per Programmierung unrettbar zu zerstören? Bei Prozessoren dieser Kategorie scheinen Bugs wohl mehr oder weniger normal zu sein. Bei einigen PICs ist die Liste allerdings schon beeindruckend lang. TI hat die Bugs veröffentlicht, bei Atmel habe ich derartiges noch nicht gefunden. Gibt es denn tatsächlich schwerwiegende Fehler, die die Verwendbarkeit eines Controllers beeinträchtigen? Dieses USB-Stick evaluation board von ti sieht recht lustig aus. Ich vermute das ist aber auch nur mit der mitgelieferten Software zu gebrauchen und stellt zum Host-System hin nicht etwa eine normale serielle USB Schnittstelle dar, über die sich z.B. der Bootloader im MSP bedienen lassen würde? Ich bin mir schon bewusst, das mein Artikel jetzt recht umfangreich geworden ist und die Chancen darauf eine umfangreiche Antwort zu bekommen eher gering sind. Trotzdem oder gerade deswegen würde ich mich aber SEHR freuen, wenn sich jemand die Mühe machen würde, das eine oder andere ein wenig zu kommentieren. Vielen Dank und viele Grüße! Klaus
Ich hab mich in den letzten Jahren mit 8051ern, AVRs und PICs gespielt, für alle gabs unter Linux Compiler, Assembler, Linker und Tools zum flashen. 8051er mit SDCC, hatte allerdings den AN2131SC, der schon einige Erweiterungen/Änderungen gegenüber den Standard-'51ern hat. Vorallem einen eingebauten USB-Bootloader. Ansteuerung über fxload. Den Chip gibts leider AFAIK nicht mehr, evtl mal bei den Nachfolgemodellen umsehen. PIC geht ebenfalls mit SDCC, gibt auch ein paar schöne graphische Oberflächen für, piklab, ktechlab, pikdev. USB-Programmer dafür gibts bei www.sprut.de. Dummerweise weicht die SDCC Syntax deutlich von der des Microchip-Compilers ab, Beispielprogramme aus dem Web lassen sich also meist erst nach einigen Anpassungen verwenden. AVRs lassen sich perfekt unter Linux programmieren, immerhin sind fast alle AVR-Tools unter Windows einfach Ports der Unix-Versionen, avr-gcc, avrdude, uisp, ... Programmieren über USB geht z.B. mit dem USBasp (http://www.fischl.de/usbasp/). HV-Programmer zur Rettung verflashter AVRs hab ich noch nie gebraucht, man muss halt ein bischen vorsichtig mit den Fuses sein. Ansonsten: Verflashte AVRs alle in ner Kiste sammeln, wenn die zusammen mehr Wert sind als ein HV-Programmer kostet lohnt sich die Anschaffung :). Zur Programmiersprache: Freunde dich mit C an, da ist dann der Umstieg auf eine andere Architektur relativ schmerzlos. Ansonsten: > fortune "The C Programming Language -- A language which combines the flexibility of assembly language with the power of assembly language." /Ernst
> JTAG am MSP430 braucht offenbar 4 Leitungen, + Reset + GND (+ evt. TEST). > Der MSP hat kein EEPROM. Ist das in der Praxis eine Einschränkung? Ist > die TI-Philosophie dergestalt, daß man aufgrund des geringen > Stromverbrauchs eh immer irgendwo ne LI-Batt anstöpseln und so > auf "Datensicherung" verzichten kann? ?? Der MSP hat Flash als NVM. Da geht nichts verlohren, oder wie meinst du das? > D.h. ein TI-Controller ist per Programmierung unrettbar zu > zerstören? Wenn man die Fuse nicht kaputt macht (was man unabsichtlich kaum schafft) geht da überhaupt nichts kaputt. > Dieses USB-Stick evaluation board von ti sieht recht lustig aus. > Ich vermute das ist aber auch nur mit der mitgelieferten Software > zu gebrauchen und stellt zum Host-System hin nicht etwa eine > normale serielle USB Schnittstelle dar, über die sich z.B. > der Bootloader im MSP bedienen lassen würde? Ich kenn die Platine jetzt ehrlich gesagt im Detail nicht, aber der Bootloader wird beim MSP (meiner Erfahrung nach) extrem selten bei solchen Boards verwendet. I.d.R. wird immer per JTAG angesteuert um Debugging Funktionen nutzen zu können.
Die Kernfrage ist nicht "welchen MC verwende ich (du)" sondern was willst du damit machen ? Du fängst also bei Null an, daher ist es egal womit du startest. Über C solltest du aber noch einmal nachdenken. ASM ist nicht portierbar, C schon (zumindestens > 80%).
Hallo!!! Vielen Dank gleich mal für die Antworten! @Ernst Bachmann: >avrdude, uisp, ... Programmieren über USB geht z.B. mit dem USBasp >(http://www.fischl.de/usbasp/). Das sieht ja schon mal recht vielversprechend aus. Nach dem Studium der avrdude manualpage bin ich auch auf "AVRISP mkII" gestoßen. Das Teil scheint dem usbasp vergleichbar zu sein. Nur wesentlich teurer :-). >Zur Programmiersprache: Freunde dich mit C an, da ist dann der Umstieg >auf eine andere Architektur relativ schmerzlos. Oh, ich hab' kein Problem mit C. Ich frage mich nur immer ob die Abstraktion im Falle der Microcontrollerprogrammierung wirklich so ausgeprägt ist, daß der Umstieg auf eine andere Achitektur WIRKLICH schmerzlos sein kann. Aber darüber brauchen wir nicht weiter diskutieren, das muss ich halt einfach mal ausprobieren. @Jörg: > > Der MSP hat kein EEPROM. Ist das in der Praxis eine Einschränkung? Ist > > die TI-Philosophie dergestalt, daß man aufgrund des geringen > > Stromverbrauchs eh immer irgendwo ne LI-Batt anstöpseln und so > > auf "Datensicherung" verzichten kann? > ?? Der MSP hat Flash als NVM. Da geht nichts verlohren, oder wie meinst > du das? Naja, der Code im Flash geht natürlich nicht verloren. Aber wenn ich im Betrieb mal ein paar Byte über einen Stromausfall hinweg retten will... Das Flash scheint für solche Aktionen doch eher ungeeignet, oder? > Ich kenn die Platine jetzt ehrlich gesagt im Detail nicht, aber der > Bootloader wird beim MSP (meiner Erfahrung nach) extrem selten bei > solchen Boards verwendet. I.d.R. wird immer per JTAG angesteuert um > Debugging Funktionen nutzen zu können. Klar, alles andere ist wohl auch eher ein Notlösung. Aber bei einem 14pol Gehäuse muss man mit den Pins eben schon etwas geizen. @Joe: > Die Kernfrage ist nicht "welchen MC verwende ich (du)" sondern was > willst du damit machen ? Jein. Primär will ich erstmal mit dem Prozessor spielen. Die aktuelle Anwendung ist pipifax und mit jedem Prozessor zu realisieren. Deswegen würde ich mir eben gerne einen "schönen" aussuchen. So dass sich das angeeignete Wissen evtl. auch später in Projekten bewähren könnte (die es jetzt noch gar nicht gibt). In dem Zusammenhang wären die 16bit des MSP schon auch reizvoll. Aber wenn ich in C programmiere, werde ich davon (außer in Form von effizienterem Assemblercode) wohl nicht viel merken, oder? Das ist ja schließlich der Sinn der Portabilität. Viele Grüße! Klaus
Bezüglich des MSP430 ist anzumerken, daß der GCC (mspgcc) für diese µC-Familie noch auf gcc-3.x basiert und die Weiterentwicklung offenbar nur schleppend voranschreitet. In den offiziellen GCC-Releases der FSF ist bisher keine MSP430-Unterstützung vorhanden. (Die aktuellen Binutils enthalten Unterstützung für den MSP430.)
> Es heißt (...) die A/D-Wandler > seien quasi nicht zu gebrauchen. Es gibt in unterschiedlichen MSP-Varianten unterschiedliche A/D-Wandler (ADC10, ADC12 und ADC16), welcher soll denn nicht funktionieren? Der ADC12 funktioniert in meinem Projekt zufriedenstellend. > Naja, der Code im Flash geht natürlich nicht verloren. Aber wenn > ich im Betrieb mal ein paar Byte über einen Stromausfall hinweg > retten will... Das Flash scheint für > solche Aktionen doch eher ungeeignet, oder? Dafür ist das sogenannte "Information memory" gedacht, das ist zwar auch "nur" Flash, kann aber im Betrieb beschrieben werden. Es ist in Segmenten à 128 Bytes Größe aufgebaut. Die Zweidraht-Debugschnittstelle der kleinen MSP430 ('F20xx) heißt SpyBiWire, verhält sich aber im Endeffekt wie ein echtes JTAG-Interface. Der für just diese kleinen MSPs verkaufte "USB-Stick" ist ein vollwertiges SpyBiWire-Interface, darüber ist mit der mitgelieferten Software sowohl ein Programmieren als auch ein Debuggen möglich. Die codegrößenbeschränkte Version des IAR-Compilers ist hier vollkommen ausreichend, da die kleinen MSPs weniger Flash-ROM haben als der Compiler kostenlosen Code generieren kann ... Allerdings ist das Windows-Software; inwiefern der "USB-Stick" mit irgendeinem *nix-Derivat zu verwenden ist, entzieht sich meiner Kenntnis. Von Olimex gibt es ein USB-JTAG-Interface für MSP430, mit dem sich auch die größeren Brüder bearbeiten lassen, es soll auch ein SpyBiWire-Interface enthalten (habe ich selbst nicht getestet). Aber auch hier kann ich zur Praxis unter *nix nichts sagen. Zur Entwicklung jedenfalls ist JTAG einem einfachen Bootloader gegenüber vorzuziehen, und beim '20xx belegt das SpyBiWire-Interface eh nur nicht anderweitig nutzbare Pins. Literaturempfehlung: "Das große MSP430-Praxisbuch, Bierl, Franzis-Verlag". Zwar spröde geschrieben und geht auch nicht auf neuere Familienmitglieder wie die '20xx ein, aber von einem (übrigens deutschen) Entwickler des MSP430 höchstselbst verfasst.
>> I.d.R. wird immer per JTAG angesteuert um Debugging Funktionen nutzen >> zu können. > Klar, alles andere ist wohl auch eher ein Notlösung. Aber bei > einem 14pol Gehäuse muss man mit den Pins eben schon etwas geizen. Bei den kleineren AVRs gibt's dafür DebugWire. Da kann man die Programmierung und das Debugging komplett über einen einzigen (den RESET-) Pin erledigen. Das geht dann sogar schon bei Achtbeinern wie dem ATtiny13. DebugWire und JTAG werden z.B. vom AVR-Dragon unterstützt, aber leider nur bei Controllern bis 32k Flash. Das kann man dann per avarice auch unter Linux mit GDB verwenden.
Rolf Magnus wrote: > Bei den kleineren AVRs gibt's dafür DebugWire. Da kann man die > Programmierung und das Debugging komplett über einen einzigen (den > RESET-) Pin erledigen. Das geht dann sogar schon bei Achtbeinern wie dem > ATtiny13. DebugWire und JTAG werden z.B. vom AVR-Dragon unterstützt, > aber leider nur bei Controllern bis 32k Flash. Das kann man dann per > avarice auch unter Linux mit GDB verwenden. AHA! Das ist ja toll dass debugWIRE mit dem gdb nutzbar ist! Mit dem USBasp Adapter wird das aber wohl nicht gehen? Inzwischen habe ich festgestellt dass es offensichtlich sehr günstige Bundles aus AVR-Dragon und STK500 (39 Euro?) gegeben hat. Ich hab' zwar nichts gegen Selbstbasteln, aber in dem Fall würde man wohl nichts falsch machen. Ob es da wohl wieder irgendwelche Sammelbestellungen gibt? Viele Grüße! Klaus
Klaus, Du hast derart einengende Anforderunegen, dass du die Mikrocontroller besser sein laesst. Du kannst auch ohne diese schnell genug pensioniert werden. Eine SMD Leiterplatte gehoert heute dazu. Mit PDIP gewinnt man nichts. Faedeln und Wrappen sind vorbei. Die EMV Anforderungen sind heute derart hoch, das das nicht mehr geht. Jeder will sein Mobiltelephon auch noch auf die Leiterplatte legen koennen ohne dass da nichts mehr laeuft. Und das ist mit geaetzen Leiterplatte und SMD Technologie machbar. Vergiss Linux fuer die Microcontrollerentwicklung. Da ist nichts. Die heute verwendeten Tools sind fuer Windows geschrieben worden. Die modernen Click-click IDEs bieten auch was fuer's Clicken. Einen globalen Replace mit GREP, naja, muss nicht sein. Simulatoren gehoeren zu einer IDE und sind besser als ein Singlestep auf dem Target. Vergiss, dass du mit einem Bootloader einen Programmer aushebeln kannst. Den Programmer, unter Windows, benoetigt man weiterhin, zumindest um den Bootloader ins Device zu kriegen. Der JTAG Anschluss ist nicht immer die optimale Alternative zum SPI ptrogrammer. Aus Platzgruenden kommt es vor, dass das JTAG Port auf dem ADCs oder sonstwo liegt. Dh man tauscht JTAG gegen eine funktionalitaet, wogegen das SPI port nemeb dem Programmieren auch als SPI laufen kann. Vergiss die vielzitierte C-Kompatibilitaet fuer Portierbarkeit. Das ist dummes Geschwaetz. Wenn man etwas fuer einen AVR entwickelt hat wird man's nicht nach PIC, oder MSP430 portieren, das Problem ist ja geloest. Genauswenig wird man PC programme auf den Prozessor portieren. Die Programmierstile sind zu verschieden. Vergiss Objekte in verketteten Listen, vergiss Floating point, das macht man alles nicht so. Ausser C gibt es genuegend Alternativsprachen, nicht immer gratis, aber guenstig. In dem Sinne...
Man sollte zwischen professionellem (viel-Geld-verdienendem) und
Hobby-Bastler (Geld-reinsteckendem) unterscheiden.
Wer die Programmiertätigkeit pro Stunde bezahlt bekommt, kauft seine
Geräte/Software nach dem Kosten:Zeitersparnis Faktor - der Hobbybastler
geht vor allem nach dem Preis.
...und so kommt es, daß der Hobbybastler gerne in den "sauren Apfel"
beißt, und mittels gcc und eclipse unter Linux entwickelt - kostenlos
und fast genauso produktiv.
Somit gilt die Aussage
>Vergiss Linux fuer die Microcontrollerentwicklung. Da ist nichts.
Vielleicht gilt es in einer Firma, aber nicht in diesem Forum :-)
> Vergiss Linux fuer die Microcontrollerentwicklung. > Da ist nichts. Die heute verwendeten Tools sind fuer Windows geschrieben > worden. Crossworks AVR, MSP430 und ARM gibt es für Linux. Man kommt aber auch mit den Open-Source-Tools schon sehr weit. JTAG-Debugging funktioniert z.B. bei MSP430 & ARM unter Linux einwandfrei (AVR habe ich nicht ausprobiert). Und wer gern klickt kann das ganze in Eclipse oder eine andere universelle IDE einbinden. > Den Programmer, unter Windows, benoetigt man weiterhin, zumindest um den > Bootloader ins Device zu kriegen. Das geht unter Linux genauso. > Vergiss die vielzitierte C-Kompatibilitaet fuer Portierbarkeit. Das ist > dummes Geschwaetz. Das ist alles andere als "dummes Geschwätz". Es ist sehr angenehm die gleichen Bibliotheken für FAT32, LCD, 1wire, RC5, Entprellung, Drehgeber usw. auf verschiedenen Controllern verwenden zu können, ohne wieder bei Null anfangen zu müssen.
Zum rein virtuellem Experimentieren ist KTechLab http://ktechlab.org/ ganz nett. Da kannst Du (leider nur PIC-) Mikrocontroller in "analoge" Schaltungen einbetten und das in Echtzeit durchsimulieren. Ansonsten habe ich meinen "Wiedereinstieg" mit AVR's geschafft indem ich mir einen einfachen SP-12-Programmieradapter gebaut http://www.xs4all.nl/~sbolt/e-spider_prog.html Dazu brauchst Du eigentlich nur eine Lochrasterplatte wo Du eine DB-25-Buchse (? oder Stecker?) seitlich raufschiebst und dann die paar Widerstände und Kondensatoren verlötest. Ich habe eine längere Platine genommen und auf dieser dann die Programmierleitungen als eine Art "Bus" oben durchgezogen. Darunter habe ich dann Sockel gelötet für die gängigen ATtiny's. Einen für den Tiny15 (ohne Quarz aber mit LED + Lötstifte für ein Eingangssignal), dann einen für einen ATtiny12/13 mit Quarz und jeweils einen für den ATtiny2323 und den ATtiny26. Oder Du baust Dir halt einen Adapter mit einem ATmega nach dieser Art und baust dann darunter noch einen MAX232 mit seriellem Port. Hier sind noch ein paar nette Artikel: http://www.linuxjournal.com/article/7289
>>Vergiss Linux fuer die Microcontrollerentwicklung. Da ist nichts. > > Vielleicht gilt es in einer Firma, aber nicht in diesem Forum :-) Bei mir gilt es auch in der Firma nicht. Auf allen meinen Rechnern, sowohl in der Firma, als auch zuhause, mache ich die Mikrocontroller-Entwicklung ausschließlich unter Linux. >> Vergiss die vielzitierte C-Kompatibilitaet fuer Portierbarkeit. Das >> ist dummes Geschwaetz. > > Das ist alles andere als "dummes Geschwätz". Ich würde eher das, was "Fastpensioniert" so schreibt, als dummes Gewschätz bezeichnen. Da ist ziemlich viel Unsinn dabei.
Hallo, für den Hobbybereich sind beide Controller je nach Einsatzzweck geeignet MSP 430: + preiswerte DEBUG/Download-Tools erhältlich (MSPFET oder Olimex-clone für 19 €) + gut strukturierter Assemblerbefehlssatz (man versaut sich nicht den Stil) + recht ausgereift: ADC12 geht ohne Props, wenn der 2,5V-Pufferzweig gut geblockt wird, siehe Datasheet. Interne Referenz auch OK. - je nach Derivat und Gehäuse nicht mehr vom Hobbyelektroniker beherrschbar (Leiterplattenselbstherstellung MSP430 z. B. F149) - miese EMV-Festigkeit (Ground-bounce wegen Low-Powerarchitektur-> KFZ???) - kann über die PIN's mit Betriebsspannung versorgt werden (KFZ?) AVR: + schöne DIL-Gehäuse + ausgereift + viel Flash/RAM verfügbar + kostenlose Downloadtools (Ponyprog) + recht EMV-fest (Mega): läuft als WIS auf Hochseeschiffen, hat auch eine DNV-Prüfung überstanden -> KFZ dürfte kein Problem sein - Debugger teuer (bei Tiny-Typen oder dem alten S1200 kaum sinnvoll möglich) - die alten Tiny-Typen hatten Latch up bei ESD-Pistolen-Beschuß im EMV-Labor - exotische Assemblersyntax (Addressierungsarten) Im übrigen würde ich C für den Controller nicht verschmähen. Bringt viel Lesbarkeit, einfache Wartung und Robustheit ins Programm. Ab 2k Flash mache ich nichts mehr in Assembler (zeitkritische Routinen, ISR mal ausgenommen) Ein schöner C-Compiler für beide kommt von Imagecraft (www.imagecraft.com) und NoIce als Debugger. Der Vorteil: Sehr ausgereift, gleiche Oberfläche für beide und als Demo und Hobbyvariante kostenlos verfügbar. Nachteil: Nicht für Linux, keine Stimuli, keine SFR-Überwachung, keine Trace-Überwachung. Beide Tools liefen bei mir unter Win '98, Imagecraft für den ARM geht aber nur noch unter XP! Ich würde für µC-Entwicklung eigentlich auch eher zu Windows raten. PS: Schau mal bei MCT vorbei: www.elektronikladen.de
STS wrote: [diverse infos] Vielen Dank für die Informationen! Die Entscheidung ist zwar inzwischen gefallen, aber ist trotzdem schön nochmal Bestätigung zu bekommen. viele Grüße! Klaus
Hallo, falls Du nochmal einen Blick in diesen Beitrag wirfst, hätte ich noch einen Tip : Interessant ist auch der R8C µC, hier gibt es für Linux das kpit-gnu tool (kostenlos) chain und der download in den µC geht mittels RS232 Pegelwandler. Einfach nur zur Info ...
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.