Hallo, ich habe mich viel mit Arduino beschaeftigt und Projekte damit gemacht, jedoch habe ich das Gefuehl bekommen, dass es in der Industrie nicht wirklich einsetzbar ist. Ich moechte mich mit Avr naeher beschaeftigen, weiß jedoch nicht, ob ich unbedingt den teuren Bootloader kaufen muss. Ich bin auf den usbasp gestoßen und wollte fragen, ob man damit dasselbe machen kann wie mit dem AVRISPmkII... Danke
Der AVRISPmkII ist genauso ein Bastler Programmer. Profis verwenden einen Programmer mit dem man auch den Controller mittels In-Circuit Emulation debuggen kann. Dafür gibts von Atmel z.B. den JTAGICE3. Kostet allerdings ein paar Euro mehr.
AVRISPmkII schrieb: > Der AVRISPmkII ist genauso ein Bastler Programmer. Profis verwenden > einen Programmer mit dem man auch den Controller mittels In-Circuit > Emulation debuggen kann. Nur völlig unfähige Programierer benötigen gewöhnlich "unbedingt" einen IC-Debugger... Und gerade die sind dann in aller Regel nicht dazu in der Lage, diesen in den extrem wenigen Fällen, wo er tatsächlich nutzbringend anwendbar wäre, auch wirklich nutzbringend anzuwenden...
Also warum ist der usbasp nicht in der Industrie einsetzbar? Was ist der Unterschied zu AVRISPmkII?
Muco schrieb: > Ich moechte mich mit Avr naeher beschaeftigen, weiß jedoch nicht, ob ich > unbedingt den teuren Bootloader kaufen muss. Du meinst sicher nicht "Bootloader", sondern "Programmieradapter". > Ich bin auf den usbasp gestoßen und wollte fragen, ob man damit > dasselbe machen kann wie mit dem AVRISPmkII... Im Prinzip ja, aber. Der AVRISP ist ein Tool vom selben Hersteller wie die µC und die (ok, eine der) IDE. Deswegen legt dieser Hersteller viel Wert darauf, daß alle diese Teile so gut wie nur möglich miteinander funktionieren. Soll heißen, der AVRISP unterstützt alle ISP-Protokolle (auch die für µC die du vielleicht gar nicht verwendest). Und er funktioniert ganz ohne daß du etwas konfigurieren müßtest aus dem AVR-Studio heraus. Allerdings läßt sich Atmel das auch ganz gut bezahlen. Der usbasp hingegen ist Open Source und Open Hardware. Jeder kann den bauen (China Klone des usbasp sind legal, Klone von AVRISP nicht). Im Gegenzug kann er nur ISP (die meisten AVR) und TPI (die ganz kleinen ATtiny) aber nicht PDI (xMega). Und du brauchst noch die Software avrdude (damit kannst du den usbasp dann auch aus dem AVR-Studio heraus verwenden). Ein Problem vieler usbasp von ebay ist, daß die Chinesen da eine hornalte Firmware drauf brennen. Die kann dann kein TPI und auch die Geschwindigkeit des ISP-Interface kann man dann nicht per Software einstellen. Man kann die Firmware des usbasp zwar updaten, braucht dazu aber einen zweiten Programmer (das darf aber dann auch ein alter usbasp sein).
Noch eine Frage: Microchip ist da glaube ich kostenguenstiger oder? Da gibt es beispielsweise den Pickit3 habe ich gesehen. Kann man da auch ganz normal in C programmieren? Gibt es große Unterschiede? Danke
Muco schrieb: > Noch eine Frage: Microchip ist da glaube ich kostenguenstiger oder? Da > gibt es beispielsweise den Pickit3 habe ich gesehen. Das Original PICKIT ist kaum preiswerter als das AVRISP. Allerdings kann es im Gegensatz zu letzterem auch debuggen. Wirklich billig ist das PICKIT3 nur wenn man einen Klone kauft. > Kann man da auch ganz normal in C programmieren? Gibt es große > Unterschiede? Die kleinen PICs bis einschließlich PIC18 sollte man im Interesse seiner geistigen Gesundheit ausschließlich in C programmieren. PIC24 (und dsPIC) sind intern ganz anders aufgebaut. Und PIC32 ist in Wirklichkeit MIPS. Aus Sicht eines C-Programmierers sind Unterschiede vorhanden, aber nicht gravierend. OK, hängt davon ab on man überhaupt schon mal was anderes als einen AVR gesehen hat. Sonst könnte der Kulturschock schon etwas größer sein als angenommen. Leider sind die Toolchains bei PIC alle etwas angestaubt. Für die kleinen (bis PIC18, wie gesagt) gibt es kostenlos nur einen nicht- optimierenden Compiler. Der Compiler für PIC24 ist ein alter gcc, anscheinend nicht mehr(?) gepflegt. Und auch hier gibts den kompletten Satz Features nur gegen Bares. PIC32 sollte dann wieder ok sein. Andererseits würde ich mich im Zweifel eher Richtung ARM orientieren, wenn es etwas größer sein darf. Toolchain ist exzellent und die meisten Typen kommen mit Bootloader, so daß ein USB-Serial Wandler oder gleich direkt USB zum Flashen ausreicht.
Axel S. schrieb: > Die kleinen PICs bis einschließlich PIC18 sollte man im Interesse seiner > geistigen Gesundheit ausschließlich in C programmieren. PIC24 (und > dsPIC) sind intern ganz anders aufgebaut. Und PIC32 ist in Wirklichkeit > MIPS. So ein quatsch ASM aufm PIC ist doch super simpel ehr alles >PIC18 sollte man nicht mehr in ASM Programieren. > > Leider sind die Toolchains bei PIC alle etwas angestaubt. Für die > kleinen (bis PIC18, wie gesagt) gibt es kostenlos nur einen nicht- > optimierenden Compiler. Der Compiler für PIC24 ist ein alter gcc, > anscheinend nicht mehr(?) gepflegt. Und auch hier gibts den kompletten > Satz Features nur gegen Bares. PIC32 sollte dann wieder ok sein. > Auch Quatsch siehe SDDC, angestaubt sind die auch nicht die meisten werden weiterentwickelt, naja die Optimierungen braucht man meist auch nicht wirklich vor alledem nicht als Anfänger, das kommt dann aber auch auf den Compiler drauf an manchmal gibt es dann stat der Optimirungsbegrenzung auch eine Größenbegrenzung aber die ist meist auch recht human, bei MicroC sind es 2k Programm Wörter. > Andererseits würde ich mich im Zweifel eher Richtung ARM orientieren, > wenn es etwas größer sein darf. Toolchain ist exzellent und die meisten > Typen kommen mit Bootloader, so daß ein USB-Serial Wandler oder gleich > direkt USB zum Flashen ausreicht. Da hast du mal recht für den Neuanfang würde ich auch ehr zu "Cortex M3" oder ähnlichen Tendieren als ich angefangen habe gabs das noch nicht ist halt auch ne frage was man machen möchte, ich Programmiere meine PIC16/18 immer noch in ASM und komme gut damit klar.
K. J. schrieb: > Axel S. schrieb: >> Die kleinen PICs bis einschließlich PIC18 sollte man im Interesse seiner >> geistigen Gesundheit ausschließlich in C programmieren. PIC24 (und >> dsPIC) sind intern ganz anders aufgebaut. Und PIC32 ist in Wirklichkeit >> MIPS. > > So ein quatsch ASM aufm PIC ist doch super simpel ehr alles >PIC18 > sollte man nicht mehr in ASM Programieren. Oh. Ein PIC-Fanboy! <seufz> Mein Beileid! >> Leider sind die Toolchains bei PIC alle etwas angestaubt. ... > Auch Quatsch siehe SDDC SDCC für PIC sehe ich eher als Machbarkeitsstudie denn als ernsthaften Compiler. Aber zugegeben, ich verwende keine PICs, insofern bin ich da sicher nicht auf dem letzten Stand. > die Optimierungen braucht man meist auch > nicht wirklich vor alledem nicht als Anfänger Err, Nein. Falsch. Ganz falsch. Gerade als Anfänger will man einen guten Compiler, der alle Optimierungen macht. Weil man sonst nie zu Potte kommt. Diese kostenlosen "Compiler" von Microchip sind nichts anderes als der "erste Schuß kostenlos" vom Dealer. Damit wollen sie Kunden anfixen und sonst nichts.
Axel S. schrieb: > Der AVRISP ist ein Tool vom selben Hersteller wie die µC > Allerdings läßt sich Atmel das auch ganz gut bezahlen. Der ICE-BASIC ist inzwischen billiger als der AVRISPmkII http://de.farnell.com/atmel/atatmel-ice-pcba/debugger-atmel-arm-avr-pcba-kit/dp/2407171 Dieses Tool ist auch als günstigerer und zuverlässiger Programmer für AVR verwendbar (aber auch für ARM / CPLD / FPGA): http://www.exp-tech.de/bus-pirate-sparkfun-version Aber der Hinweis soll hier nicht fehlen: AVR ist einfach teuer. Einen 8051 oder ARM kann man einfach mit einem USB-seriell Kabel für 5 EUR flashen und Debugger gibt es ab 15 EUR
Axel S. schrieb: > Man kann die Firmware des usbasp zwar updaten, braucht dazu > aber einen zweiten Programmer (das darf aber dann auch ein alter usbasp > sein). ... oder ein passend programmierte Arduino (Arduino IDE - Beispiel 11.ArduinoISP).
> Aber der Hinweis soll hier nicht fehlen: AVR ist einfach teuer. Einen > 8051 oder ARM kann man einfach mit einem USB-seriell Kabel für 5 EUR > flashen und Debugger gibt es ab 15 EUR Das kann nicht von Bedeutung sein. Schliesslich konnte man bei Renesas schon vor >15Jahren ueber RS232 flashen und seit mindestens 10Jahren auch auch kostenlos auf Sourcelevel debuggen. Hat noch nie einen in Deutschland interessiert. Der deutsche Bauer kennt nur seine eigene Zuckerruebe. .-) Ich nutze im uebrigen zum basteln gerne einen steinalten (sind von 2000) SH7045. Perfekte gcc Unterstuetzung, natuerlich flashen ueber RS232 (auch unter Linux), Cache, hatten damals schon Peripherie bis zum abwinken eingebaut und war angeblich mal der schnellste Microntroller der Welt. Wollte ich nur mal so erwaehen damit ihr seht was ihr verpasst habt. :-) Die Erwaehnung von Industrie und Arduino/AVR in einem Satz ist schon erheiternd. Es mag einen gefallen oder nicht, aber Industrie heisst derzeit ausschliesslich ARM. Ich hab schon FAEs gesehen die sich dafuer entschuldigt haben das ihre Firma noch kein ARM hat. Oder schaut euch mal die MSP432 von TI an. Vor einem halben Jahr konnte man bei google noch eine Diplomarbeit oder Diss finden/einsehen wo jemand an dem MSP432 als Nachfolger der MSP430 entwickelt hat. Das scheinen sie komplett eingestampft zu haben und dafuer einen ARM in MSP432 umbenannt zu haben. Wenn ich heute in meiner Firma noch was anderes wie ARM verwenden will dann ist das zwar moeglich, aber das muss ich gut begruenden. Andererseits denke ich das man sich als Anfaenger da nicht verrueckt machen sollte. Wenn man einen Microcontroller kann, dann kann man alle. Ich steig in ein paar Tagen auf jeden beliebigen Controller um. Wichtig ist viel eher das man diese Copy&Paste Mentalitaet ablegt, Datenblaetter liesst und selber mal seinen Arsch hoch bekommt. Ich persoenlich finde die Dominanz von ARM im uebrigen erstaunlich. Ich frag mich immer ob dies ein Zeichen von sich verbreitender Doofheit ist. Man kann zwischen verschiedenen Cores praktisch so schnell wechseln wie man einen Compiler installieren kann. Kleine Unterschiede mag es geben sind aber irrelevant/beherschbar. Zwischen verschiedenen ARMs zu wechseln ist dagegen wegen der unterschiedlichen Peripherie mit ERHEBLICHEM Aufwand verbunden. Olaf
Danke vielmals für die ganzen Antworten. Was gibt es zu Infineon zu sagen? Es ist ja schlussendlich ein deutsches Produkt :) Also ich glaube bis jetzt klingt AVR für mich am besten. Ich möchte halt mit etwas beginnen, das auch in der Industrie gut einsetzbar ist.
> Was gibt es zu Infineon zu sagen? Es ist ja schlussendlich ein deutsches > Produkt :) Nach meiner Einschaetzung ist das eine dicke Firma die in irgendwelchen Nischen aktiv ist. > Also ich glaube bis jetzt klingt AVR für mich am besten. Ich möchte halt > mit etwas beginnen, das auch in der Industrie gut einsetzbar ist. Wie ich schon sagte, es ist egal womit du anfaengst und deshalb kann es natuerlich auch AVR sein. Aber Industrie bedeutet derzeit ARM! Es ist vermutlich klueger wenn du dir als Anfaenger ein STM32 Entwicklungskit besorgst. Damit wirft ST doch nur so um sich. Du hast dann fuer 10-20Euro eine Hardware mit der du sofort loslegen kannst, du bekommst bereits einen Debugger mitgeliefert und weil du doch so Industrieglaeubig bist, dein Gehirn bekommt sogar schon eine IAR Vorpraegung. :-) Such zum beispiel mal nach STM32F0-Discovery. Die haben in Japan Y800 gekostet. Also 6-7Euro und da ist sogar bereits eine Lochrasterplatine und Steckerleisten dabei. Olaf
Also ich Nutze immer noch meinen Selbstbau usbasp, und das seit über 5 Jahren. Habe mir auch mal den AVR ISK MK2 besorgt, den habe ich gleich wieder zur seite gelegt. Der USBASP ist der einzige der unter MacOS X ohne anstand läuft, braucht aber die libusb bzw. Crosspack. Alles andere habe ich nicht zum laufen bekommen. Das schlimme ist, das ich mit einen Arduino Mega 2560 zugelegt habe, der hat ein CDC device drauf, sollte eigentlich unter MacOS X ohne Treiber gehen, geht aber nicht. Und die Arduino Oberfläche ist auch nicht zu gebrauchen. Ich nutze weiterhin den avr gcc und usbasp als RS232 Schnittstelle nehme ich nur die FTDI Interface Schnittstelle und den richtigen Treiber dazu. Somit habe ich alles abgedeckt was ich dazu brauche.
Olaf schrieb: > Ich persoenlich finde die Dominanz von ARM im uebrigen erstaunlich. Ich > frag mich immer ob dies ein Zeichen von sich verbreitender Doofheit ist. > Man kann zwischen verschiedenen Cores praktisch so schnell wechseln wie > man einen Compiler installieren kann. Kleine Unterschiede mag es geben > sind aber irrelevant/beherschbar. Zwischen verschiedenen ARMs zu > wechseln ist dagegen wegen der unterschiedlichen Peripherie mit > ERHEBLICHEM Aufwand verbunden. Du sprichst in Rätseln. Welche "Cores" meinst du? Da du von verschiedenen Compilern sprichst, denke ich, du meinst nicht die Cores einer Serie, sondern wirklich ganz verschiedene, also z.B. TriCore, RX, SH, Mips. Und du denkst, du kannst zwischen denen schneller wechseln als zwischen den Cortexen verschiedener Hersteller? Träumst du?
Olaf schrieb: > Die Erwaehnung von Industrie und Arduino/AVR in einem Satz ist schon > erheiternd. Es mag einen gefallen oder nicht, aber Industrie heisst > derzeit ausschliesslich ARM. Ack Ich findes es auch erheiternd, dass für alles gleich ein ARM herhalten muss.
Muco schrieb: > Ich moechte mich mit Avr naeher beschaeftigen, weiß jedoch nicht, ob ich > unbedingt den teuren Bootloader kaufen muss. Ich bin auf den usbasp > gestoßen und wollte fragen, ob man damit dasselbe machen kann wie mit > dem AVRISPmkII... Verwenden den USBASP und gut ist. Für dich als Lernenden ist es doch völlig unerheblich, wie in der Industrie Boards geflashed werden. Der AVR eignet sich gut zum lernen, da er bei weitem nicht so komplex wie die ARM-Cortexe ist und man im Internet viele Tipps bekommt. Wenn du dann mal fit bist in Bezug auf bare-metal Programmierung (Interrups, Timern, Ports, DMA, EEProms, Display ansteuern, embedded C allgemein -> Gebrauch von volatile) und dich dann den "höheren Layern" gewidmet hast (z.B. Zugriff auf SD-Karten) dann bist du i.A. mit der Terminologie der embedded Programmierung vertraut und dich schrecken auch andere Architekturen nicht mehr. Auch ist es gut, schon mal einen 8-bitter mit seinen beschränkten Resourcen programmiert zu haben. Andererseits können sich hier aber auch manche Fehler einschleichen, wenn man später auf 32-Bitter umsteigt. Mancher Code, der für 8-bitter gut ist, ist für 32-Bitter schlecht.
Der AVRISP MKII ist auf jeden Fall eine gute Wahl, wenn man einen soliden, einfachen Programmieradapter benötigt. Preis-Leistungs-Verhältnis und Zuverlässigkeit sind top!
ARM-Entwickler schrieb im Beitrag #4429025: > Und du denkst, du kannst zwischen denen schneller wechseln als > zwischen den Cortexen verschiedener Hersteller? Träumst du? Diese Aussage heißt übrigens nicht, dass das Wechseln von Cortexen verschiedener Hersteller sehr einfach ist. Wer z.B. die StdPeriphieLib vom STM verwendet, tut sich schon schwer, dann auf LPC zu gehen. Nur ist es m.E. auch nicht schwerer, als auf MIPS von Microchip zu gehen. Bei den Cortexen kann ich z.B. meine Entwicklungsumgeben gleich lassen, ich verwende arm-none-eabi-gcc mit Makefiles. Damit kann ich sehr schön Code für LPC und STM32 generieren.
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.