Hallo miteinander, ich hatte da schonmal vor geraumer Zeit einen Post dazu, allerdings hat sich mittlerweile das Anforderungsprofil doch sehr gewandelt - daher möchte ich mal ein paar Fragen stellen, die ihr mir mit eurer Erfahrung sicher schnell beantworten könnt. Ich habe jetzt länger recherchiert. Freescale wurde ja jetzt von NXP aufgekauft, und daher sind diese erstmal außen vor. Wer weiß schon, wie das Portfolio geändert werden wird?! 1) Ich suche eine Controllerfamilie, die ich komfortabel programmieren lässt - und bin da jetzt bei der Glaubensfrage PIC oder Atmel angelangt. Beide liefen Chips mit AECQ. Beide liefern µC mit LIN/CAN und wären damit auch "zukunftssicher". Die IDE von Atmel ist äußerst komfortabel. Ich kenne keine bessere, mit PIC hatte ich aber bisher auch kaum Berührpunkte. Ist die IDE vergleichsweise gut, oder sind dort deutliche Abstriche? 2) Wie sieht es mit dem Debugging aus? Lassen sich die kleinen 8-Beiner PICs gut debuggen? Bei den ATTiny soll das ja eine mittelprächtige Katastrophe sein. Allerdings hoffe ich doch schwerstens, dass das anno 2015 inzwischen gut funktioniert - oder nicht? 3) Soweit wie ich bisher mit Atmel zu tun hatte, haben die 8bit AVRs allesamt keine I/O Multiplexer - und damit ist man auf eine Pinfunktionalität angewiesen. Das kann beim Layouten ziemlich ekelhaft werden. Ist das bei den PIC auch so? Vielen Dank für Eure hilfe, schönes WE, M.S.
:
Gesperrt durch Moderator
Schon mal STM8 Serie angesehen? Debuggen und Programmieren geht mit dem discovery Board für 10€. IDE und Compiler (Cosmic) gibt es umsonst.
PIC Debugger ist extrem einfach. Gibt sowieso nur mehr MplabX und Pickit3. Alles andere ist de fakto ausgestorben. MplabX ist ein angepasstes NetBeans. Brauchbar, aber in Java geschrieben. Passt alles zusammen. Das bedeutet aber umgekehrt, du hast keine Alternativen. Entweder verkrüppelter Optimizer oder teure Compilerlizenz. Spezialfunktionen auf Pins - unterschiedlich. Bei manchen neuen lässt sich die Belegung routen. (Analog und ein paar andere sind trotzdem fest zugeordnet).
Martin Schwaikert schrieb: > haben die 8bit AVRs allesamt keine I/O Multiplexer Aktuelle 8051 haben I/O Multiplexer und SWD (2-Wire Debug): http://www.silabs.com/products/mcu/8-bit/Pages/efm8.aspx http://www.ftdichip.com/Products/ICs/FT51.html
Martin Schwaikert schrieb: > Bei den ATTiny soll das ja eine mittelprächtige Katastrophe sein. Soll es? Aber kleine Controller sind natürlich immer knapp beim Debuggen.
STM32F0 (10 €, oder umsonst auf der Embedded World) http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1574?sc=stm32f0 + kostenlosen Keil Compiler (sonst 5000,- €) http://www2.keil.com/stmicroelectronics-stm32/mdk
STM32F0 (10 €, oder umsonst auf der Embedded World), das STM32Fo Discovery Kit meinte ich natürlich, und debuggen kann man eh alle Cortex(e)
Jörg Wunsch schrieb: > Aber kleine Controller sind natürlich immer knapp beim Debuggen. Dazu gibt es ja immer noch das gute alte Led Debugging.
F. Fo schrieb: > Jörg Wunsch schrieb: >> Aber kleine Controller sind natürlich immer knapp beim Debuggen. > > Dazu gibt es ja immer noch das gute alte Led Debugging. Oder das gute alte "Pin HIGH, Pin LOW" und aufs Oszi gucken.
Martin Schwaikert schrieb: > Das kann beim Layouten ziemlich ekelhaft > werden. Wenn man keine BGA-Typen nimmt, sehe ich da ab 2-lagig keine Probleme. Einen ATmega48 im TQFP-32 plaziere ich um 45° gedreht, dann kann man besser wegrouten.
Mark Brandis schrieb: > F. Fo schrieb: > Jörg Wunsch schrieb: > Aber kleine Controller sind natürlich immer knapp beim Debuggen. > > Dazu gibt es ja immer noch das gute alte Led Debugging. > > Oder das gute alte "Pin HIGH, Pin LOW" und aufs Oszi gucken. Ihr seid ja zwei Vollprofis. :-( Aber dem TO wird es reichen, denn er empfindet das Atmelstudio als komfortabel. :-( Ich empfehle natürlich den MSP430 und das Launchpad als günstigen Einstieg mit Programmer, Debugger, ... alles mit an Bord. Mit den avr fühlt man sich dagegen in der Entwicklersteinzeit. Sonst passen auch die PIC auf die Anforderung, wenn man Angst vorm Cortex hat. ;-)
Bastler schrieb: > Schon mal STM8 Serie angesehen? > Debuggen und Programmieren geht mit dem discovery Board für 10€. > IDE und Compiler (Cosmic) gibt es umsonst. Jupp, hab ich. Allerdings sind die Controller schon "zu groß". Ich bin aktuell in der Liga SO-8 unterwegs. Vllt. schwenkt man später nochmals um. Ein großes Minus ist halt leider, dass es - im Gegensatz zu PIC und AVR - vergleichsweise wenig Sources im Netz gibt. Ich bin kein Fan vom Rad-neuerfinden (wenn es nicht sein muss). msp430 schrieb: > Mark Brandis schrieb: >> F. Fo schrieb: >> Jörg Wunsch schrieb: >> Aber kleine Controller sind natürlich immer knapp beim Debuggen. >> >> Dazu gibt es ja immer noch das gute alte Led Debugging. >> >> Oder das gute alte "Pin HIGH, Pin LOW" und aufs Oszi gucken. > > Ihr seid ja zwei Vollprofis. :-( > > Aber dem TO wird es reichen, denn er empfindet das Atmelstudio als > komfortabel. :-( Findest Du nicht? Beim Code Composer Studio hab ich regelrecht das kalte Grauen bekommen. Zwar ist der Register- und und RAM-Auszug wirklich brauchbar, aber der Rest konnte mich nicht begeistern. Und im Vergleich zu Cosmiq ist das Atmel Studio regelrecht hochentwickelt. > Ich empfehle natürlich den MSP430 und das Launchpad als günstigen > Einstieg mit Programmer, Debugger, ... alles mit an Bord. Mit den avr > fühlt man sich dagegen in der Entwicklersteinzeit. Kann ich irgendwie schon nachvollziehen. Aber was erwartet man von Achtbeinern? Die können halt eben nunmal nicht viel. Dafür erreiche ich die angepeilten 500µA Stromaufnahme. > Sonst passen auch die PIC auf die Anforderung, wenn man Angst vorm > Cortex hat. ;-) Cortex ist halt ein kleines bisschen Overkill.
Martin Schwaikert schrieb: > 1) Ich suche eine Controllerfamilie, die ich komfortabel programmieren > lässt - und bin da jetzt bei der Glaubensfrage PIC oder Atmel angelangt. Naja, solange hier kein allseitiges Flamen einsetzt, ist das doch wurscht. Aber sag mal, was zum Kuckuck soll denn der ganze Ansatz? So ein µC ist ja kein Selbstzweck und das "komfortable" Programmieren erst recht nicht. Ich würde da an deiner Stelle ganz andere Prioritäten ansetzen, allen voran, daß der Chip für die Aufgabe geeignet ist, wieviel er in Serie kostet, welche Eskapaden sich der Hersteller bislang bei der Lieferzuverlässigkeit geleistet hat und wie lange das Teil voraussichtlich am Markt sein dürfte. Das ist alles viel wichtiger als "komfortabel programmieren". Martin Schwaikert schrieb: > 2) Wie sieht es mit dem Debugging aus? Lassen sich die kleinen 8-Beiner > PICs gut debuggen? Schreib einfach fehlerfreie Programme. Bei den allerkleinsten mit 512 Programmschritten (sprich Anzahl der im Flash unterbringbaren Maschinenbefehle) sollte sowas ja keine echte Hürde sein. Notfalls benutze einen Simulator. W.S.
> Schreib einfach fehlerfreie Programme.
Wer kann das heutzutage noch? Mal ernsthaft - als es noch keine Debugger
gab, hatten wir hochkonzentriert fehlerfreie Programm geschrieben.
Heutzutage tippen wir beim Youtube hören nebenbei irgendwas ein und
schaun im Debugger was da eigentlich passiert.
Martin Schwaikert schrieb: > > Jupp, hab ich. Allerdings sind die Controller schon "zu groß". Ich bin > aktuell in der Liga SO-8 unterwegs. Vllt. schwenkt man später nochmals > um. Ein TQFP32-Package ist etwa genauso klein wie ein SO8, warum also nicht einfach einen aus der Xmega oder Atmega-Serie nehmen? > > Findest Du nicht? Beim Code Composer Studio hab ich regelrecht das kalte > Grauen bekommen. Zwar ist der Register- und und RAM-Auszug wirklich > brauchbar, aber der Rest konnte mich nicht begeistern. Und im Vergleich > zu Cosmiq ist das Atmel Studio regelrecht hochentwickelt. Das Atmel-Studio hat auch eine gute Simulation. Die reicht bei so Mini-projekten wie mit Attinys völlig aus um 90% der Probleme zu finden. Ich hab bei meinem letzten Projekt mit einem attiny85 den Debug-wire gar nicht gebraucht.
Martin Schwaikert schrieb: > Findest Du nicht? Nein, ich habe zum Glück etwas professionelles unter den Fingern. Fürs Hobby reicht sogar Kickstart IAR. Martin Schwaikert schrieb: > Achtbeinern? Die können halt eben nunmal nicht viel. Das hat nichts mit der Anzahl der Beine zu tun, sondern mit der veralterten Technik inside. ;-) Martin Schwaikert schrieb: > Dafür erreiche ich > die angepeilten 500µA Stromaufnahme. Und der MSP430 nimmt 500mA? :-((( Noch einer schrieb: >> Schreib einfach fehlerfreie Programme. > > Wer kann das heutzutage noch? Mal ernsthaft - als es noch keine Debugger > gab, hatten wir hochkonzentriert fehlerfreie Programm geschrieben. Jetzt wird es aber albern. Hat dein Auto Sicherheitsgurte, Airbag, Servolenkung und Bremskraftverstärker? Das braucht man alles nicht, das ging früher auch ohne.
Martin Schwaikert schrieb: > 1) Ich suche eine Controllerfamilie, die ich komfortabel programmieren > lässt - und bin da jetzt bei der Glaubensfrage PIC oder Atmel angelangt. > Beide liefen Chips mit AECQ. Beide liefern µC mit LIN/CAN und wären > damit auch "zukunftssicher". Die IDE von Atmel ist äußerst komfortabel. > Ich kenne keine bessere, mit PIC hatte ich aber bisher auch kaum > Berührpunkte. Ist die IDE vergleichsweise gut, oder sind dort deutliche > Abstriche? MPLabX ist quasi ein angepasstes NetBeans. Also nichts ganz unbekanntes. Funktioniert gleichermaßen auf Windows, OSX und Linux. Alle Compiler (für 8-, 16- und 32-Bit Architekturen) sind für alle drei Betriebssysteme verfügbar, und sind extra Downloads. > 2) Wie sieht es mit dem Debugging aus? Lassen sich die kleinen 8-Beiner > PICs gut debuggen? Bei den ATTiny soll das ja eine mittelprächtige > Katastrophe sein. Allerdings hoffe ich doch schwerstens, dass das anno > 2015 inzwischen gut funktioniert - oder nicht? Alle aktuellen PICs haben ICSP, von den 6-Pinnern bis hin zu den 300MHz PIC32MZ MIPS-Controllern. Du kannst alle PICs mit einem PICKIT3 oder ICD3 programmieren UND debuggen, brauchst aber für einige kleine PIC10/12/16 einen sogenannten Debug Header, wo quasi ein debugfähiger Spezial-PIC drauf ist. Bei den 6- und 8-Pinnern musst Du beim Debuggen natürlich PGC und PGD frei lassen, sonst kommt der Debugger nicht an den Chip ran. > 3) Soweit wie ich bisher mit Atmel zu tun hatte, haben die 8bit AVRs > allesamt keine I/O Multiplexer - und damit ist man auf eine > Pinfunktionalität angewiesen. Das kann beim Layouten ziemlich ekelhaft > werden. Ist das bei den PIC auch so? Ab PIC24 hast Du Programmierbare Pinfunktionen (PPS), d.h. Du kannst beispielsweise einen UART auf einen von n Pins legen. Die 8 Bitter haben das nicht, diese Funktionalität ist den 16- und 32 Bittern vorbehalten. fchk
msp430 schrieb: > Ich empfehle natürlich den MSP430 und das Launchpad als günstigen > Einstieg mit Programmer, Debugger, ... alles mit an Bord. Habe mir gerade den MSP432 bestellt. Bin mal gespannt.
Martin Schwaikert schrieb: > Aber was erwartet man von > Achtbeinern? Was heißt hier "Achtbeiner"? Ich nehme gern den ATTiny10. Um mal ein Relais zu schalten oder den Tester für meinen 190ziger. Da wird der Blinkcode eingelesen und wiederholt; wenn man mal nicht schnell genug mitgezählt hat. Dafür reichen die sechs Beine alle Male. Womit ich dann wieder beim richtigen Thema bin.
:
Bearbeitet durch User
Zum Tiny10. Der Programmcode lässt sich fast Eins zu Eins vom ATmega328 übernehmen. Und für mich ist das sehr angenehm, wenn ich das auf einen Arduino Nano testen kann und dann brenne ich das Programm (die Pins nur noch angepasst) über meinen selbst gebauten Adapter in den Tiny10, auflöten und fertig.
msp430 schrieb: > Ich empfehle natürlich den MSP430 Hat mich nicht sonderlich überzeugt, als ich ihn letztens mal in den Fingern hatte. Die Errata-Liste kann man ja schon fast mehrbändig herausgeben, und dass sie es nichtmal schaffen, dem Zählerregister einen Synchronizer zu verpassen, damit man es im laufenden Betrieb auslesen kann (auch wenn er asynchron zur CPU getaktet wird), ist mehr als schwach. Debuggen mit dem FET aus einer virtuellen Maschine ging auch nicht, der TI-Support hat sich zwar über meine analysierten USB-Logs gefreut, aber das war's dann auch. ($KUNDE hatte IAR als Compiler vorgegeben, daher konnte ich nicht native auf dem Host arbeiten, sondern nur aus 'ner VM. Atmel Studio finde ich nicht toll und würde es nicht freiwillig benutzen, aber zumindest funktioniert sowas damit.) Längerfristig dürften aber beide Architekturen Auslaufmodelle sein. Das wird dem TE für sein aktuelles Problem jedoch eher egal sein können.
F. Fo schrieb: > Ich nehme gern den ATTiny10. Das ist aber nun wieder das andere Extrem nach unten hin. ;-)
F. Fo schrieb: > Programmcode lässt sich fast Eins zu Eins > ... > auf einen > Arduino Nano testen > ... > dann brenne ich das Programm (die Pins nur > noch angepasst) über meinen selbst gebauten Adapter ... ich nehme den Spy-Bi-Wire (vom Launchpad) und programmiere und debugge direkt in der Zielhardware. :-)))
Noch einer schrieb: >> Schreib einfach fehlerfreie Programme. > > Wer kann das heutzutage noch? Mal ernsthaft - ... Ähem.. eigentlich meine ich das ernst. Aber so, wie der TO an die Sache herangeht, wird er wohl was Anderes brauchen als nen Debugger, nämlich jemanden, der sein Handwerk versteht und der ihm die eigentliche Arbeit macht. Arduino-Generation sozusagen. W.S.
msp430 schrieb: > programmiere und debugge direkt in der Zielhardware Mit einem Controller im Format SOT-23-6?
Jörg Wunsch schrieb: > msp430 schrieb: >> programmiere und debugge direkt in der Zielhardware > > Mit einem Controller im Format SOT-23-6? He he he! W.S. schrieb: > Noch einer schrieb: >>> Schreib einfach fehlerfreie Programme. >> >> Wer kann das heutzutage noch? Mal ernsthaft - ... > > Ähem.. eigentlich meine ich das ernst. Bei den drei Zeilen die man für so einen Tiny10 verwendet, sollte es auch noch fehlerfrei sein oder zumindest keinen großartigen Debugger brauchen.
Hallo Foldi, F. Fo schrieb: > Habe mir gerade den MSP432 bestellt. > Bin mal gespannt. Das führt jetzt etwas vom Thema ab: Ich habe heute auch den MSP432 entdeckt und bin sehr interessiert. Ein Launch Pad für 13.- € ist schon "ein Angebot, dass man nicht ablehnen kann". Prozessoren einzeln scheint es noch nicht zu geben, und das Launch Pad habe ich nur in den USA gefunden. Ich habe früher sehr viel mit 8051 gemacht, wollte was Moderneres, habe mir in den letzten Zeit AVR, PIC und MSP430 angesehen und bin beim MSP hängen geblieben. Allerdings aus Gründen, die hier wieder eine von diesen frustrierenden Grundsatzdiskussionen auslösen würden. Frage A: Hast du deas Launch Pad aus DE? B: Wo gibt's eine Befehlsbeschreibung (nicht nur Übersicht)? Wahrscheinlich bei ARM, aber auch bei TI? C: Hast du schon einzelne Prozessoren gesichtet? Da die Antworten hier nicht so interessant sind, Antwort gerne als PN. Oder als neuen Beitrag. (Thema: Sammelbestellung MSP432 Launch Pad? - Ok, natürlich nicht für dich.) Grüße, Uwe
Du musst eigentlich nur unterm Chip schauen. Dort findest du jede Menge Dokumente. http://www.ti.com/product/MSP432P401R/technicaldocuments Aber das spezielle findest du hier: http://www.ti.com/lit/ug/slau356/slau356.pdf Ich habe den bei TI selbst bestellt und habe ich dafür 26,99$ bezahlen müssen.
STM32User schrieb: > STM32F0 (10 €, oder umsonst auf der Embedded World) mann sag blos du hast einen bekommenals ich bei denen war waren die alle schon vergriffen -,- die gingen anscheinend weg wie warme semmeln XD zurück zum thema ich bin ja eher der atmel fan finde die sind einfacher handzuhaben als pic (vorallem pic brennen erforderd nen teureren programmer wie galep oder den eigenbau usburn) für avr reicht n isp programmer (ich nutze hierfür arduino as isp) btw: gabs nich irgentwo mal n avr simulator?
:
Bearbeitet durch User
--- GeneralUltra758 --- schrieb: > zurück zum thema ich bin ja eher der atmel fan finde die sind einfacher > handzuhaben als pic (vorallem pic brennen erforderd nen teureren > programmer wie galep oder den eigenbau usburn) für avr reicht n isp > programmer (ich nutze hierfür arduino as isp) Ein PIC erfordert einen 20€ China PICKit3-Clone, und damit kannst Du auch debuggen. Was ist daran teuer? Und wie die meisten Leute kennst Du nur die 8-Bit PICs. Probiere mal einen 16- oder 32 Bit PIC aus (die gehen auch mit dem PICKit3). Du wirst sehr angenehm überrascht sein. Es sind ganz andere Architekturen. fchk
--- GeneralUltra758 --- schrieb: > als ich bei denen war waren die alle > schon vergriffen Die konnte man doch vorbestellen und sonst lass dir doch ein Board vom FAE schicken.
--- GeneralUltra758 --- schrieb: > ich bin ja eher der atmel fan finde die sind einfacher > handzuhaben als pic ... und welchen Atmel, 8051, avr, ARM???
Martin Schwaikert schrieb: > Ich bin aktuell in der Liga SO-8 unterwegs Falls SO-16 noch in Frage kommt, wie gesagt aktuelle 8051 haben I/O Multiplexer und SWD (2-Wire Debug), Eval-Board mit Debugger 25 EUR: http://de.farnell.com/silicon-labs/slstk2020a/entw-board-efm8bb10f8g-busy-bee/dp/2469338 Und hier der SO-16 (interner 25 MHz Oszillator, im Vergleich zu AVR mit 40 Cent extrem günstig): http://de.farnell.com/silicon-labs/efm8bb10f8g-a-soic16/mcu-8bit-aec-q100-8051-25mhz-soic16/dp/2468081
>Ab PIC24 hast Du Programmierbare Pinfunktionen (PPS), >Die 8 Bitter haben das nicht Diese Aussage ist nicht mehr aktuell. So 1/10 der Pic16 und Pic18 haben PPS. Auf der Microchip Produktsuche lässt sich nach PPS filtern. ..... Kleiner Nachtrag zu MplabX und Pickit3. So einmal am Tag vertütelt sich der Debugger. Programm beenden - USB-Kabel raus/rein - Programm starten. Gewöhnt man sich dran. Darf bei so einem Programm aber eigentlich nicht vorkommen.
Lothar schrieb: > Falls SO-16 noch in Frage kommt, Nein, leider nicht. Frank K. schrieb: > Die 8 Bitter haben > das nicht, diese Funktionalität ist den 16- und 32 Bittern vorbehalten. Ach danke. Das hat mich der Entscheidung ein gehöriges Stück weiter gebracht. W.S. schrieb: > Ich würde da an deiner Stelle ganz andere Prioritäten ansetzen, > allen voran, daß der Chip für die Aufgabe geeignet ist, Sind nahezu 100% der am Markt verfügbaren Kleinst-Prozessoren. > wieviel er in > Serie kostet, Alles bis 70ct. ist bei 500 Stück pro Jahr vertretbar. > welche Eskapaden sich der Hersteller bislang bei der > Lieferzuverlässigkeit geleistet hat Da ist Atmel, wie auch Microchip sehr weit verbreitet. Mouser hat von kleinen immer > 10.000 Stück auf Lager. Über die Broker sind die dann auch noch etwa 50% billiger, als beim blauen M. > und wie lange das Teil > voraussichtlich am Markt sein dürfte. Atmel sichert für die AECQ-qualifizierten ca. 7 Jahre zu, bei den anderen Herstellern sind es 15. In Anbetracht des vergleichsweise geringen Portierungsaufwandes sehe ich auch 7 Jahre als vertretbar an. > Das ist alles viel wichtiger als "komfortabel programmieren". Nein, ist es nicht, weil sich so gut wie alle Hersteller die Klinke in die Hand geben. Für mich ist daher wichtig, wie gut der Support außerhalb derjenige des Herstellers im Netz ist. Und da kann halt nunmal Atmel ziemlich punkten. Klar gibt es Exoten-Prozessoren - z.B. von Via. Aber wer setzt die Teile schon großartig ein? Ich hatte mit den Stellaris schon das Geschiss, dass man selbst für die popeligsten Aufgaben Seitenweise Datenblätter studieren musste, weil es eben kaum Informationen im Netz gab. Bei AVR/PIC ist das eben nicht so, weil es ein Wald-und-wiesen-µC ist. Und ich habe ehrlichgesagt überhaupt keine Lust, das Rad neu zu erfinden. Dafür ist mir meine Zeit zu schade. Und daher frage ich hier auch nach: Weil es hier viele Anwender gibt, die meist schon mehr als nur einen einzigen Typ gesehen haben, und daher auch ganz anders Rede und Antwort stehen können.
Na ja, hier wirst du nur Antworten von Hobbyisten bekommen. :'( Ob du darauf dein Produkt stützen möchtest? Datenblätter lesen muss man immer. Wenn du Codefragmnete aus dem Forum zusammen Kopierer, wirst du kein stabiles Produkt erhalten. :'(
define schrieb: > Na ja, hier wirst du nur Antworten von Hobbyisten bekommen. :'( Täusch dich da mal nicht. Hier sind auch viele Profis unterwegs. Die Flamen aber nicht dämlich herum (daran erkennt man sie). > Ob du darauf dein Produkt stützen möchtest? Nein, ich stütze mein Produkt - wenn überhaupt - auf meiner eigenen Entscheidung. > Datenblätter lesen muss man immer. Richtig. Das sehe ich auch so. > Wenn du Codefragmnete aus dem Forum > zusammen Kopierer, wirst du kein stabiles Produkt erhalten. :'( Und das ist wiederum eine haltlose Pauschalisierung. Solange ich weiß, was der Kopierpasten-Code macht, ist es auch legitim, ihn zu verwenden. Gerade als Programmierer unter Windows lernt man, dass man das Rad NICHT jedes mal neu erfinden muss. Zugriffe auf die WMI beispielsweise - wer das jedesmal selbst programmiert, dem ist nicht mehr zu helfen.
@Martin Gut erkannt, Profis beteiligen sich inhaltlich nicht an Threads wie diesem. Natürlich verwendet man Code wieder und erfindet das Rad nicht neu. Aber man sollte Funktion und Stabilität absichern. Bei den Datenblättern widerspricht du dir irgendwie.
Martin Schwaikert schrieb: > Lothar schrieb: >> Falls SO-16 noch in Frage kommt, > > Nein, leider nicht. Dann wird DIP-8 wohl auch nicht gehen. Hier gäbe es genau einen ARM mit I/O Multiplexer und SWD (2-Wire Debug). Der ist auch sehr verbreitet, Mouser hat 12.000 Stück auf Lager. Die Programmierung ist (aus meiner Sicht ähnlich 8051) einfach, liegt aber auch daran dass der LPC800 (ARM) der offizielle Nachfolger des LPC900 (8051) ist, und die Peripherie ähnlich funktioniert. http://www.mouser.de/ProductDetail/NXP/LPC810M021FN8FP/?qs=%2fha2pyFaduiGKlE7K%252bl%2foWBWRr%2fRA2onCtWBuDOEGkw%3d
Uwe Bonnes schrieb: > Oder von ST STM32030F/042F ... Ich gucke häufig in Steuerungen und von ST habe ich noch keine Cortexe gesehen. Atmel manchmal, PIC und viel Infineon. Mag ja sein, dass die im Kommen sind ... In Weißware findet man auch viel Cypress.
:
Bearbeitet durch User
define schrieb: > Gut erkannt, Profis beteiligen sich inhaltlich nicht an Threads wie > diesem. Was erwartet ihr von einem Profi für eine Antwort? Etwa so etwas: http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DV244005 Für einige Controller mit 8/14/16 Pins von Microchip gibt es spezielle Debug-Versionen. Z.B.: PIC12F675 (8pin) -> PIC12F675-ICD (14pin) -> Zur Programmentwicklung wird die ICD-Version verwendet. Zum Debuggen stehen damit alle I/Os für die Schaltung zur Verfügung.
Der schon mehrfach erwähnte Keil-Compiler http://www2.keil.com/stmicroelectronics-stm32/mdk zusammen mit diesem Board(10EUR) http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF260944 sind meines Erachtens derzeit der Hammer - wozu sich PIC, AVR, 8051 mit popeligem Speicher antun, wenn man für praktisch gleiches Geld einen 32 bit ARM mit 32kB SRAM und 256kB Flash haben kann.
F. Fo schrieb: > Ich gucke häufig in Steuerungen und von ST habe ich noch keine Cortexe > gesehen. Atmel manchmal, PIC und viel Infineon. > > Mag ja sein, dass die im Kommen sind ... Puuuhhhh, wo bekommt ihr solche Infos her? :-* ST hat bei Cortex den größten Marktanteil und das mit Abstand. Infineon hat den ARM Hype fast verpennt und Atmel war auch erst spät dran.
Ein wichtiger Punkt bei der µC Wahl ist auch noch die Versorgungsspannung: AVR, PIC und viele 8051 laufen mit etwa 2.5-5 V. Die ARMs eher mit 2,5-3,3 V. Wenn man Wert auf das Debuging (auf dem selben chip) legt sind 8 Pins aber schon recht knapp, das wären dann mit 2 Pins fürs Debugging nur noch 4 nutzbare IO Pins. Bei nur noch 4 Pins dürfte das Routen nicht so schwer sein - ein Problem ist aber ggf. das einige Funktionen ggf. mit den Debug-Pins kollidieren.
Martin Schwaikert schrieb: > Ich hatte mit den Stellaris schon das Geschiss, > dass man selbst für die popeligsten Aufgaben Seitenweise Datenblätter > studieren musste, weil es eben kaum Informationen im Netz gab. Da hat er sich geoutet, der typische Copy&Paste-DAU. Mußtest du tatsächlich einmal in deinem völlig nutzlosen Programmiererleben etwas wirklich selber programmieren und dafür dann sogar die nötigen Informationen auch noch ganz alleine aus dem Datenblatt extrahieren? Armer Junge, schnell mal die Mutti zum Trösten rufen. Mein Mitleid jedenfalls hält sich da doch in sehr engen Grenzen. Kein Bussy. Wenn ich dein Chef wäre, würde ich dir aber extrem in den Arsch treten. Und vor allem auch mal die Lizenzlage des vielen geklauten Codes prüfen, bevor es vielleicht mal Ärger gibt. Denn so ein Ärger kann wirklich ruinös für eine Firma sein...
F. Fo schrieb: > viel Infineon. Infineon? Das wäre die aller aller letzte Adresse, bei der ich an die Tür klingeln würde. Ich kenne absolut keinen Halbleiterhersteller mit einem derart miesen Kundenservice. Alles < 100.000 Stück pro Jahr interessiert die gar nicht (Aussage von einer Dame in der Infineon Zentrale). Es kann schon sein, dass im Automotive Bereich genug Umsatz für Infineon ist, aber alles andere sind für die ohnehin keine Kunden. Schau Dir mal die BTT Typen an - und versuch mal ein Muster davon bekommen :) Lothar schrieb: > DIP-8 Schreibfehler?! Ist viel viel viel zu groß.
Viele kleine PICs lassen sich richtig debuggen. D.h. mit Breakpoints, durchsteppen Stopwatch und was man so braucht. Man muss aufpassen, dass man solche mit Debug-Support kauft. Z.b. den 12F1840 - ein 8-Haxer. Der ist recht brauchbar für Miniprojekte und Reichelt hat ihn auf Lager. Die Debug-Haxen kann man auch andersweitig verwenden, nur logischerweise nich umittelbar beim Debuggen und etwas eingeschränkt - bei einem 8-Haxer wie dem 12F1840 tut das schon weh. Ich kenne die ATMEL-IDE nicht, aber MPLABx ist relativ brauchbar. Zumindest ich persönlich komme gut damit zurecht. Es ist aber etwas träge, was man bei kleinen Controllern aber gar nicht merkt. Großer Vorteil: keinerlei Registierung nötig, man kann es einfach herunterladen. Das PICkit3 ist recht brauchbar, zumindest für die kleinen Controller, die du ja verwenden möchtest. Da merkt man nicht, dass es etwas träge ist.
Schau dir mal http://ww1.microchip.com/downloads/en/DeviceDoc/51292U.pdf an. ICE = realtime trace, ICD = breakpoint / halt.
Frank K. schrieb: > Ab PIC24 hast Du Programmierbare Pinfunktionen (PPS), d.h. Du kannst > beispielsweise einen UART auf einen von n Pins legen. Die 8 Bitter haben > das nicht, diese Funktionalität ist den 16- und 32 Bittern vorbehalten. Nö, das haben teilweise auch die 8 Bitter z.B. der 18F26J50
Chris S. schrieb: > Schau dir mal http://ww1.microchip.com/downloads/en/DeviceDoc/51292U.pdf > an. > ICE = realtime trace, ICD = breakpoint / halt. etwas OT: was macht eigentlich den ICD3 von Microchip so teuer? was kann er was chipkit3 nicht kann? weiß das einer?
ups - ich meine natürlich PICkit3. habe auf Microchip-seite dieses Bild gefunden, aber sehe nix was den preis rechtfertigt,
c-hater schrieb: > Da hat er sich geoutet, der typische Copy&Paste-DAU. Ach, du haust mal wieder mit der Herkules-Keule um dich. Im Grunde hast du es ja auf den Punkt gebracht, aber ich hätte versucht, es dezenter auszudrücken. W.S.
Fragender schrieb: > was macht eigentlich den ICD3 von Microchip so teuer? > was kann er was chipkit3 nicht kann? > weiß das einer? Genau dieses Ding habe ich auch gekauft weil ich die dsPic's ganz interessant finde. Wen man aber von den Cortexen kommt und mit einem JLINK arbeitet, schmeißt man das ICD3 weiter als man sehen kann.
temp schrieb: > Genau dieses Ding habe ich auch gekauft weil ich die dsPic's ganz > interessant finde. Wen man aber von den Cortexen kommt und mit einem > JLINK arbeitet, schmeißt man das ICD3 weiter als man sehen kann. danke für die Antwort, aber leider nicht wirklich auf meine frage.
Icd2 war 130$ , pickit2 49$. Ich denke die wollten die einfach eine Neuauflage um die pickit2 Klone eindämmen und etwas Geld abstauben. Icd3 ist etwas aufwendiger als icd2. Ich verwende immer noch pickit2 zwar Mit 5v/3.3v stabilisierter Spannung und step up für vpp und manueller vpp Einstellung. Update der Programmieralghorithmen gibt es ja vom Programmierer kostenlos, nicht aber von microchip. Sourcen verfügbar.
Fragender schrieb: > ups - ich meine natürlich PICkit3. > habe auf Microchip-seite dieses Bild gefunden, > aber sehe nix was den preis rechtfertigt, Der Unterschied liegt in der deutlich höheren Geschwindigkeit (High Speed vs Full Speed bei USB) und einigen besseren Debugfähigkeiten. Das ICD3 hat heftig viel Elektronik drin, ein FPGA, 256k RAM etc pp. Als Bastler brauchst Du es in der Regel nicht. fchk
Icd3 ist ein Produktion certified programmer. Auch pickit2 ist mit entsprechenden batch files als solches zu gebrauchen, pickit3 nicht. Icd3 ist ca 4.3x schneller als pickit2.
Mark Brandis schrieb: > > Oder das gute alte "Pin HIGH, Pin LOW" und aufs Oszi gucken. Gibt's noch was anderes? Gruss Chregu
temp schrieb: > Fragender schrieb: >> was macht eigentlich den ICD3 von Microchip so teuer? >> was kann er was chipkit3 nicht kann? >> weiß das einer? > > Genau dieses Ding habe ich auch gekauft weil ich die dsPic's ganz > interessant finde. Wen man aber von den Cortexen kommt und mit einem > JLINK arbeitet, schmeißt man das ICD3 weiter als man sehen kann. PIC32 kann man auch mit dem Segger JLINK debuggen. Auch in MPLABX - es gibt ein Plugin von Microchip dazu. Das ist wirklich sehr schnell und stabil und hat mich sehr positiv überrascht. Wenn man den mit dem PICkit3 vergleicht ist das so wie Bollerwagen <> Formel1-Auto. Auch die PGD/PGC Schnittstelle wird untertützt, allerdings nur bei den neueren Devices. Aber wer nimmt schon alte Gurken her. Für kleine Projekte mit z.B. <32k Flash ist das PICkit3 aber gut zu gebrauchen - da gehts noch flott. Und man kann richtig Debuggen damit. Außerdem hat des das absolute Breadboard-Killerfeature: Eine kurzschlussfeste, per Software einstellbare Versorgung. Aber ab 128k wirds eben recht träge.
Christian Müller schrieb: > Mark Brandis schrieb: >> >> Oder das gute alte "Pin HIGH, Pin LOW" und aufs Oszi gucken. > > Gibt's noch was anderes? Man kann einen Großteil der Funktionen auch so entwickeln, dass man sie erstmal auf dem PC laufen lässt. Alles, was Temperaturwerte umrechnet oder einen Protokollstack bearbeitet oder Strings zusammenpfriemelt etc. ist ja nicht µC-spezifisch. Wenn die Funktionen auf dem PC dann modulgetestet sind (z.B. mit Hilfe von CUnit), verwendet man sie auf dem eigentlichen Target.
:
Bearbeitet durch User
chris schrieb: > Es geht hier um 8 pinner mit 1 bis 2 k flash und 256 eeprom. Was an der Sinnhaftigkeit von Modultests meiner Meinung nach nichts ändert.
Mark Brandis schrieb: > chris schrieb: > Es geht hier um 8 pinner mit 1 bis 2 k flash und 256 eeprom. > > Was an der Sinnhaftigkeit von Modultests meiner Meinung nach nichts > ändert. Sorry, mein Beitrag galt @WehOhWeh Bezüglich >128k flash.
STM32User schrieb: > STM32F0 (10 €, oder umsonst auf der Embedded World) > > http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1574?sc=stm32f0 > > + kostenlosen Keil Compiler (sonst 5000,- €) > > http://www2.keil.com/stmicroelectronics-stm32/mdk Würde Dir auch gleich zu einem 32bitter mit Cortex-m0 raten plus dem erwähnten Compiler oder dem Atollic TrueSTUDIO, das es jetzt von ST für umme gibt - die STM32F0 gehen bei Mouser bei 1,69 los - für 3,90 kriegst Du schon den STM32F091RC mit 32kByte SRAM und 256kB Flash, also Speicher satt - da würd' ich mir keinen Controller mehr antun, bei dem man beim Speicher knausern muss. Für den STM32F091RC gibt's von ST auch ein NUCLEO Board für 'n Appel und Ei mit Debug- und Virtuellem COM-Port-Interface zum PC.
:
Bearbeitet durch User
U.G. L. schrieb: > Würde Dir auch gleich zu einem 32bitter mit Cortex-m0 raten plus dem > erwähnten Compiler oder dem Atollic TrueSTUDIO, das es jetzt von ST für > umme gibt - die STM32F0 gehen bei Mouser bei 1,69 los - für 3,90 > kriegst Du schon den STM32F091RC mit 32kByte SRAM und 256kB Flash, also > Speicher satt - da würd' ich mir keinen Controller mehr antun, bei dem > man beim Speicher knausern muss. > Für den STM32F091RC gibt's von ST auch ein NUCLEO Board für 'n Appel und > Ei mit Debug- und Virtuellem COM-Port-Interface zum PC. Cool. Nachdem der arme Mensch nach 4 Jahren Untätigkeit jetzt deine Empfehlung bekommen hat (NATÜRLICH für einen STM32 ;-)), kann er jetzt ja loslegen. Super.
Uff - frag' mich allerdings, wieso das im Forum an vorderster Stelle aufgeführt wurde - hatte sicherlich nicht auf die nächsten Seiten geblättert!
U.G. L. schrieb: > wieso das im Forum an vorderster Stelle > aufgeführt wurde Wenn man nach Datum sortiert sucht dann höchstwarscheinlich nicht.
Beitrag #5839944 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.