Moin Leute, ich bin aktuell auf der Suche nach einem neuen Mikrocontroller, ich habe schon ordentlich gesucht und mich durch Foren geklickt, habe auch sogar schon euren wunderbaren Artikel https://www.mikrocontroller.net/articles/Entscheidung_Mikrocontroller gelesen :) Allerdings finde ich die Auswahl, zwischen der man sich entscheiden muss immer noch so groß, dass ich nicht richtig weiter weiß. Von daher hier mal die Frage, ob ihr konkret schon µCs mit ähnlichem Funktionsumfang im Betrieb habt und eure Erfahrungen oder eure Meinung dazu mal abgeben könnt? Ich habe meine Projekte bis jetzt immer in Assembler und C auf einem 8051er Derivat gemacht und möchte nun für größere Projekte einen µC der einen größeren Funktionsumfang hat. Ich habe damals bewusst den 8051 als Einstieg in die µC-Technik genommen, gerade weil man sich hier um alles selbst kümmern muss und dadurch gezwungener Maßen viele neue Sachen lernt. Der 8051 hatte einige Nachteile die ich gerne mit dem neuen µC nicht mehr hätte allerdings auch einige Vorteile die ich ungerne aufgeben würde. Konkret sind mir folgende Dinge wichtig, die der 8051 nicht hatte: - programmierbar in Assembler, C und C++ - integrierte Implementierung von I2C-Bus und CAN-Bus - deutlich größerer interner Speicher als noch beim 8051 (was wsl. automatisch gegeben ist -> Der 8051 hatte 256Byte) - erweiterte Möglichkeiten zum Debuggen (JTAG oder ähnliches) (eigentlich nicht unbedingt wichtig für mich) - mehr Rechenleistung (vermutlich reicht eine 16 Bit-Architektur hier jedoch aus, weil ich wsl. keine riesigen Adressen adressieren will und auch keine extremen Berechnungen vorhabe). Und folgende Dinge würde ich gerne weiter nutzen können: - integrierte AD-Wandler - integrierte Implementierung eines Timers / Zählers - integrierte Implementierung der seriellen Schnittstelle - einfache programmierbarkeit (beispielsweise über einen ISP-Programmer) - Eine IDE mit Compiler die den µC simulieren kann und somit ein vorheriges Debugging im PC möglich macht (Hier habe ich früher KeilµVision genutzt und war immer sehr zufrieden. Allerdings bin ich nun auf Linux umgestiegen und suche nach einer IDE (bestenfalls OpenSource), mit ähnlichen Funktionen) - schön wäre es auch, wenn der Chip nicht nur in SMD zur verfügung steht, sondern entweder direkt oder über Adapter zum schnellen Testen auf eine einfache Lochraster-Platine lötbar ist. - Gute Dokumentation (ich würde ungern mit einem sehr seltenen µC arbeiten, den wenige Leute nutzen und zu dem es wenig Foren-Einträge und Doku gibt) - 5V Versorgungsspannung oder zumindest 5V-Kompatible IO-Pins Ich würde mich sehr freuen, wenn der ein oder andere seine Meinung dazu abgeben könnte :) Vielleicht sind meine Vorstellungen ja auch totaler Mist und überhaupt nicht umsetzbar. Dann könnt ihr das natürlich auch gerne schreiben. Insgesamt hoffe ich allerdings mal, dass ich hiermit keine Grundsatz-Debatte zwischen den verschiedenen Fronten lostrete.. Viele Grüße anon1234
Anon A. schrieb: > Konkret sind mir folgende Dinge wichtig, die der 8051 nicht hatte: > - programmierbar in Assembler, C und C++ C++ https://www.iar.com/iar-embedded-workbench/#!?architecture=8051¤tTab=Features > - integrierte Implementierung von I2C-Bus und CAN-Bus z.B. SiLabs C8051F58x > - deutlich größerer interner Speicher als noch beim 8051 > (was wsl. automatisch gegeben ist -> Der 8051 hatte 256Byte) z.B. SiLabs C8051F58x mit bis 128 kiB Flash, 8 kiB RAM, externer Speicher möglich > - erweiterte Möglichkeiten zum Debuggen (JTAG oder ähnliches) > (eigentlich nicht unbedingt wichtig für mich) vorhanden, es reichen bei den SiLabs-51ern die günstigen ToolStick-Werkzeuge > - mehr Rechenleistung (vermutlich reicht eine 16 Bit-Architektur hier > jedoch aus, weil ich wsl. keine > riesigen Adressen adressieren will und auch keine extremen > Berechnungen vorhabe). die oben genannten laufen mit bis zu 50 MHz, der Hersteller hätte auch welche mit bis zu 100 MHz im Angebot > Und folgende Dinge würde ich gerne weiter nutzen können: > - integrierte AD-Wandler hätten die genannten (12-Bit, 200 kSPS), Varianten mit 16-Bit oder 24-Bit-ADC gäbe es dort auch > - integrierte Implementierung eines Timers / Zählers hätten diegenannten auch. Zusätzlich zu den normalen, mehrere sog. PCAs (Programmable Counter Array) > - integrierte Implementierung der seriellen Schnittstelle auch vorhanden > - einfache programmierbarkeit (beispielsweise über einen ISP-Programmer) ebenso, siehe oben > - Eine IDE mit Compiler die den µC simulieren kann und somit ein > vorheriges Debugging im PC möglich macht dürfte es geben, wie sinnvoll das ist, ist eine andere Frage... > (Hier habe ich früher KeilµVision genutzt und war immer sehr > zufrieden. > Allerdings bin ich nun auf Linux umgestiegen und suche nach einer IDE > (bestenfalls OpenSource), > mit ähnlichen Funktionen) Keine Ahnung was da an Compilern außer dem SDCC für 8051er unter Linux verfügbar ist. IDE: Siehe andere Threads hier... > - schön wäre es auch, wenn der Chip nicht nur in SMD zur verfügung > steht, sondern entweder direkt > oder über Adapter zum schnellen Testen auf eine einfache > Lochraster-Platine lötbar ist. Adapter gibt es > - Gute Dokumentation (ich würde ungern mit einem sehr seltenen µC > arbeiten, den wenige Leute nutzen und > zu dem es wenig Foren-Einträge und Doku gibt) Dokumentation ist bei den SiLabs sehr gut > - 5V Versorgungsspannung oder zumindest 5V-Kompatible IO-Pins z.B. die C8051F58x... IO-Spannung bis 5V, integrierter Spannungsregler Bleibt noch die Frage: Warum auf was anderes als 8051er wechseln?
>Bleibt noch die Frage: Warum auf was anderes als 8051er wechseln?
Bleibt eher die Frage: Warum noch 50Jahre alten Schrott weiter
totreiten?
Gibt auch AVRs die CAN eingebaut haben (I2C, ADC usw sowieso). Hab da allerdings keine Erfahrung mit.
Anon A. schrieb: Schau Dir die PIC24/dsPIC/PIC32 an. Microchip hat aktuell über 1000 verschiedene PICs auf dem Markt, da sollte auch für Dich was dabei sein. Es gibt auch 5V-Modellreihen (wenn auch nur wenige), und bis 28 Pins gibts auch noch DIL-Gehäuse. Peripherie gibts alles, was das Herz begehrt, PPS ist sehr angenehm, d.h. Du kannst Peripheriefunktionen fast beliebig auf IO-Pins verteilen, Beschaffbarkeit ist kein Thema, und Rechenleistung sollte mit 70 MHz bei dsPIC33EP oder 200 MHz bei PIC32MZ auch erstmal ausreichen. Bei PIC32 wird C++ unterstützt. Compiler, IDE, Debugger etc gibts alles gleichermaßen für Windows, Mac und Linux. fchk
Frank K. schrieb: > Beschaffbarkeit ist kein Thema, und > Rechenleistung sollte mit 70 MHz bei dsPIC33EP oder 200 MHz bei PIC32MZ > auch erstmal ausreichen. Bei PIC32 wird C++ unterstützt. Compiler, IDE, > Debugger etc gibts alles gleichermaßen für Windows, Mac und Linux. Gibt es überhaupt einen nicht-kastrierten freien Compiler für PIC? Mit abgeschalterer Optimierung ist das mit der zu erwartenden Rechenleistung so eine Sache. Die dsPIC33EP laufen auch nicht mit 70 Mhz, die laufen mit 140 MHz und werden mit 70 MIPS beworben, real und vor allem ohne Optimierung dürfte das deutlich weniger sein. An der Stelle finde ich die Microchip Homepage und die Datenblätter echt schlecht, was soll der Müll mit den MIPS wenn man in der Realität eher genau wissen muss, wo welcher Takt verwendet wird?
Rudolph schrieb: > Gibt es überhaupt einen nicht-kastrierten freien Compiler für PIC? Leider nein. Ganz ehrlich? Nimm nen ARM ... irgend einen Cortex-M0+/3/4. Da gibt es wenigstens einen ordentlich ausgereiften Open-Source-Compiler (GCC) für.
Schau dir mal LPC800 von NXP an. Gibt's auch in DIL. Aber Simulatoren sind durch JTAG bei neueren uC rar gesät.
Rudolph schrieb: > Frank K. schrieb: >> Beschaffbarkeit ist kein Thema, und >> Rechenleistung sollte mit 70 MHz bei dsPIC33EP oder 200 MHz bei PIC32MZ >> auch erstmal ausreichen. Bei PIC32 wird C++ unterstützt. Compiler, IDE, >> Debugger etc gibts alles gleichermaßen für Windows, Mac und Linux. > > Gibt es überhaupt einen nicht-kastrierten freien Compiler für PIC? Ja. Der PIC32-Compiler ist der gcc. http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html (Abschnitt Source Archives) Warum Microchip den pic32/mips-gcc mit einer, im Quelltext leicht auffindbaren, Lizenzabfrage kastriert, ist eine andere Frage. Beim chipKit-Compiler wird diese einfach aus dem Quelltext entfernt: https://github.com/chipKIT32/chipKIT-cxx/blob/master/src48x/gcc/gcc/config/pic32/mchp.c
test schrieb: > Rudolph schrieb: >> Gibt es überhaupt einen nicht-kastrierten freien Compiler für PIC? > > Leider nein. > > Ganz ehrlich? > Nimm nen ARM ... irgend einen Cortex-M0+/3/4. Da gibt es wenigstens > einen ordentlich ausgereiften Open-Source-Compiler (GCC) für. Da stimme ich zu. Und ich würde jederzeit wieder zu ST gehen. Weil wenn man sich im STM32 Ecosystem mal eingerichtet hat, hat man eine riesige Auswahl an Controllern jeglicher Leistungsklasse und Peripherie, die alle irgendwie gleich funktionieren. Dazu mit StdPeriphLib und Cube für alle Controller mehr oder weniger einheitliche Libs.
:
Bearbeitet durch User
Cyblord -. schrieb: > Da stimme ich zu. > Und ich würde jederzeit wieder zu ST gehen. Weil wenn man sich im STM32 > Ecosystem mal eingerichtet hat, hat man eine riesige Auswahl an > Controllern jeglicher Leistungsklasse und Peripherie, die alle irgendwie > gleich funktionieren. Dazu mit StdPeriphLib und Cube für alle Controller > mehr oder weniger einheitliche Libs. Das ist bei den PIC32 nicht anders... Von der kleinsten MX im 28-Pin DIP mit 16 kiB Flash und 4 kiB RAM bis zu den MZ EF mit 2048 kiB Flash und 512 kiB RAM, Double Precision FPU und MMU. Als Framework gibt es Harmony und als Pendant zu CubeMX den Harmony Configurator. Was mich bei den STM32 stört, ist, dass es High Speed USB nur mit externem ULPI-Transceiver gibt. Zudem gibt's für die PIC32MZ ein 4.4BSD ;) https://github.com/sergev/LiteBSD/wiki
Arc N. schrieb: > Cyblord -. schrieb: >> Da stimme ich zu. >> Und ich würde jederzeit wieder zu ST gehen. Weil wenn man sich im STM32 >> Ecosystem mal eingerichtet hat, hat man eine riesige Auswahl an >> Controllern jeglicher Leistungsklasse und Peripherie, die alle irgendwie >> gleich funktionieren. Dazu mit StdPeriphLib und Cube für alle Controller >> mehr oder weniger einheitliche Libs. > > Das ist bei den PIC32 nicht anders... Mit dem Unterschied dass es ebenen keinen freien Compiler ohne Einschränkungen gibt. > Was mich bei den STM32 stört, ist, dass es High Speed USB nur mit > externem ULPI-Transceiver gibt. Ja irgendwas ist ja immer.
Cyblord -. schrieb: > Mit dem Unterschied dass es ebenen keinen freien Compiler ohne > Einschränkungen gibt. Copy and Paste von oben... Der PIC32-Compiler ist der gcc. http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html Quelltext downloaden, patchen, übersetzen. https://github.com/chipKIT32/chipKIT-cxx/blob/master/src48x/gcc/gcc/config/pic32/mchp.c Oder direkt den chipKIT-Compiler nehmen https://github.com/chipKIT32/chipKIT-cxx/tree/master/src48x Zitat "Added src48x XC32 v1.40 source code, based on gcc 4.8" XC32 v1.40 ist der aktuelle XC32 von Microchip, dessen Quelltext es unter dem Link von oben gibt... Oder den von LiteBSD benutzten: https://github.com/sergev/LiteBSD/wiki/Build https://sourcery.mentor.com/GNUToolchain/release2774
Es gibt auch die kleinen PICs, z.B den 18f26k80 (CAN, I2C) und seine pinstärkeren Verwandten (44k80, 66k80). Open-source Compiler gibt es neben der sdcc (den ich persönlich nicht gut finde für PIC18) noch den wenig bekannten CPIK, mit welchem ich sehr gute Erfahrung gemacht habe. Als Simulator (allerdings auf Assembler-Ebene) gpsim. Übert MPLab habe ich mich immer gelehrt. Klar ist ein STM32 leistungsfähiger, aber mit den modernen PIC18 lässt sich viel machen und sie sind je nach Bedarf extrem sparsam bzw schnell, besagter mit 64MHz mit internen Oszillator und PLL. Hab auch STM32 im Einsatz, sind aber aufwendiger zum selbst löten und CubeMX ist auch ein ziemliches Monstrum.
Hey Leute, vielen vielen Dank für eure zahlreichen und sehr hilfreichen Antworten :) Ich habe jetzt eure Vorschläge mal weiter recherchiert und mir ein Bild gemacht, was mir am besten gefällt. Arc N. schrieb: > z.B. SiLabs C8051F58x Der Mikrocontroller macht erst einmal einen guten Eindruck auf mich und kann prinzipiell ersteinmal auch alles, was mich interessiert. Allerdings möchte ich glaube ich, da ich ja nun schon Erfahrung mit dem 8051 gesammelt habe, mal über den Tellerrand schauen, damit ich bei der Sache auch mal ein paar andere Sachen kennenlerne :) Stefan schrieb: > Schau dir mal LPC800 von NXP an. Gibt's auch in DIL. Aber Simulatoren > sind durch JTAG bei neueren uC rar gesät. Frank K. schrieb: > Schau Dir die PIC24/dsPIC/PIC32 an. Cyblord -. schrieb: > Da stimme ich zu. > Und ich würde jederzeit wieder zu ST gehen. Weil wenn man sich im STM32 > Ecosystem mal eingerichtet hat, hat man eine riesige Auswahl an > Controllern jeglicher Leistungsklasse und Peripherie, die alle irgendwie > gleich funktionieren. Ansonsten standen ja noch - der PIC32 - der LPC800 - und der STM32 im Raum. Alle scheinen mir irgendwie geeignet und wahrscheinlich würde ich wohl auch mit keinem etwas falsch machen. Insgesamt gefällt mir glaube ich aber des STM32 am besten. Der Funktionsumfang scheint mir ziemlich komplex und die Rechenleistung ziemlich gut zu sein. Für kleinere Projekte ist der natürlich vollkommen überzogen. Aber da verwende ich dann ja ohnehin erstmal meinen 8051 weiter. Aber ich glaube mit dem STM32 werde ich wohl nicht so schnell an meine Grenzen kommen :) Bleibt natürlich noch die Frage welchen STM32 nimmt man am besten. Ich glaube ich will für den Anfang mal ein "DemoBoard" mit dem ich direkt Anfangen kann, ohne mich noch ewig um die Grundbeschaltung kümmern zu müssen. Ich habe mir hierzu den STM32F103C8T6 herausgesucht. Mit I2C, CAN, USB, UART, SPI, PWM, RTC, 16-Bit-Timern, jeder Menge 5V-taugliche GPIO-Ports, 64KBytes Flash, 20KBytes SRAM, AD-Wandler und 72MHz Takt, Watchdog-Timer und JTAG-Debugging habe ich wirklich alles was das Herz so begehrt. Und beispielsweise bei Ebay und Reichelt scheint die Verfügbarkeit und der Preis auch zu nich so schlecht zu sein. http://www.ebay.de/itm/STM32F103C8T6-Board-mit-ST-ARM-32-bit-Cortex-M3-/201475385315?hash=item2ee8de67e3:g:~CUAAOSw8-tWWthI Als Entwicklungsumgebung würde ich mich dann wohl für - Eclipse mit C/C++ Development Tooling und GNU ARM Plug-in entscheiden und entsprechend dann den guten GCC-Compiler bemühen :) Simulation des Chips wird hier dann wahrscheinlich wohl nicht möglich sein oder? Hat da jemand mal Erfahrung gemacht? Zur Not kann man da aber (da es sich ja um einen ARM-Chip handelt) wahrscheinlich ja auch mal auf KeilµVision zurückgreifen. Was das Programmieren und Debuggen angeht kann dies ja beides über die USB-Schnittstelle gehandhabt werden richtig? Oder benötige ich für das JTAG-Debuggen noch ein extra Tool? Ach so und was ich mich gefragt habe ist, ob es dann auch generell mit Eclipse und dem GCC-Compiler möglich ist, mal testweise in Assembler zu entwickeln? Oder muss ich dann hierfür einen anderen Compiler nutzen. Kennt sich hier jemand aus? An euch dann wirklich vielen Dank nochmal für die vielen Antworten :) Viele Grüße und einen schönen Abend noch. anon1234
Pascal X schrieb: > Es gibt auch die kleinen PICs, z.B den 18f26k80 (CAN, I2C) und seine > pinstärkeren Verwandten (44k80, 66k80). Open-source Compiler gibt es > neben der sdcc (den ich persönlich nicht gut finde für PIC18) […] Auch objektiv ist der SDCC für PIC nicht auf dem Niveau der anderen von SDCC unterstützten Architekturen. Philipp
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.