Hallo zusammen! Ich habe jetzt eine Zeit lang mit AVR und PIC programmiert und suche jetzt nach nach einer Leistungsfähigeren Microcontroller Familie! Am liebsten wäre mir ein 16/32 bit Microcontroller der isp usw. hat, für den es auch ein gratis Assembler gibt!! Jetzt würde ich gerne wissen, was ihr mir so für Microcontroller empfehlen würdet? Und noch ei Frage: Was ist eigentlich der Vorteil/Nachteil eines Micoprozessors zu einem Microcontroller? Wäre über jeden Tipp dankbar! Michael
16bit kann ich ja noch verstehen - aber 32bit? Was um Gottes Willen willst du tun? Ich hab schon mächtige Probleme, einen Mega@16MHz an die Leistungsgrenze zu bringen. Ok, 16bit-Typen setze ich auch schon mal ein, aber wirklich selten. 16bit: Hübsch ist der M16C, für noch mehr Dampf den M32C. Ansonsten sind auch die LPC-Controller von ST einen Blick wert. Assembler gibts eigentlich immer gratis vom Hersteller, muss nicht unbedingt das nonplusultra des Machbaren sein... Unterschied MC/MP: das solltest du eigentlich selbst wissen, wenn du dich in solche Regionen begeben willst.
So weit ich weis ist ein Microprozessor nur ein Prozessor/Recheneinheit oder eine CPU wie in einem modernen Rechner (P4, Athlon etc.). Ein Microcontroller ist ein 1-Chip Computer, eben mit allem drum und dran in einem mit dem ohne externer Hardware was läuft (CPU, Flash-ROM für Code, RAM zum werkeln/speichern/erfassen/rechnen und EEPROM als Festspeicher). Gruß Andi
Oh Gott, schon wieder diese konkreten Zahlen (leistungsstark = ?). Ein ARM ist z.B stärker als ein 8051 bezogen auf reines Nummernschubsen (*, /, +, -), wenns >8 Bit sein muß. Beim Bitschubsen (Zustandsmaschinen, IO-Zugriffe, logische Operationen, Interrupts, Software-SPI usw.) schlägt ein C8051F120 (8051) aber den LPC2106 (ARM) haushoch. Also Leistung wovon und wieviel oder am besten für welche Anwendung. Aber um Programmierfehler auszugleichen hilft keine noch so hohe Leistung, wenn sie irgendwo im Programmablauf nutzlos verpulvert wird. Peter
Die Msps von Ti haben zum beispiel 16bit. Gibts in packages von so24 bzw tssop24 bis tqfp64. Ein oder 2 Timer mit 3 bis 7 capture/compare Registern. Analog-comperator ADC 10 bit bzw 12 bit. ....uvm laufen allerdings "blos" mit 8mhz . gibts in ausführunb mit bis zu 60kb flash. www.ti.com mfg Flo
Danke schonmal! Ich werde mir den M16C oder M32C mal anschauen! Die Frage mit dem MC/MP war eigentlich eher auf den Speicher bezogen, da ein MP die Befehle doch meistens von außen bekommt, oder lieg ich da falsch? Das würde doch heißen, dass der MP durch die geschwindigkeit des Speichers gebremst würd, oder? Michael
Der Übergang zwischen MP und MC ist natürlich fließend. Grundsätzlich gilt, daß der Speicher immer zu langsam ist. ;) Verallgemeinernd gesagt: Externes SRAM ist schneller als interner Flashspeicher. Markus
Hallo Markus, Was hat flash mit RAM zu tun? Flash ist in der regel für denn program code und RAM für variabelen. Also verstehe ich deine bemerkung nicht! Grüße Mark,
Wieso denn nicht? Programmcode kann genausogut im RAM laufen, wenn die Architektur das hergibt. Das Programmspeicher ausschliesslich im internen ROM (wie auch immer der realisiert ist) liegt ist eine Besonderheit der Einchipsysteme, deswegen durchaus nicht die Regel.
SRAM ist idR schneller als Flashspeicher. Daher lädt man (wenn aus Performancegründen nötig) das Programm in ein RAM. Das kann durchaus dynamisch geschehen, z.B. in Form eines Caches der dem Flashspeicher vorgeschaltet ist. Dadurch sind Systeme mit externem Speicher gegenüber denen mit internem Speicher im Vorteil. Aber wie gesagt, das ist eine Verallgemeinerung. Man könnte natürlich auch Systemen mit internem Flash einen Cache zur Seite stellen, das wird aber meines Wissens nach eher selten gemacht. Markus
Hallo Crazy Horse, Es geht hier doch um mikrocontroller, oder? Bei die mikrocontroller die ich kenne (zb. ST10 / C167) ist der zugriff auf internes speicher immer schneller als auf externes. RAM ist in der regel nicht für program code, nicht bei mikrocontroller. und Flash wird in der regel nicht für variablen benutzt. Grüße Mark,
Der flash ist bei den AVR der Geschwindigkeitsflaschenhals, der Kern selbst könnte noch viel schneller (eh, das wäre doch mal tuning-Ausbaustufe, nach reset wird der flash automatisch in den Programm-RAM kopiert, dann gehts erst richtig los). Und meine ersten 8051-Systeme - da lief das Programm in der Testphase immer im RAM, das EPROM ausbauen/löschen/neuprogrammieren war doch zu lästig. Sicher ist es bei heutigen MCs nicht üblich, dass Programm im RAM laufen zu lassen, prinzipiell spricht aber nichts dagegen.
@Mark: Hier geht es eigentlich schon um MC, aber Michael wollte ja auch die Unterschiede zwischen MC und MP wissen (gerade in Bezug auf Speicher). Hier ist ein Beispiel für einen MC, bei dem das RAM für schnelle Codeteile benutzt werden kann/soll: http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=13753&cat_oid=-8138 Letztendlich wollte ich damit eh nur sagen, daß externer Codespeicher nicht automatisch langsamer sein muß als interner Codespeicher. Markus
Leistung? MC68332! http://www.elektronikladen.de/katce332.html teuer, aber mit Hochsprache und einfach toll. Quark
@ Quark, gibt es den 68332 denn inzwischen mit Flash on Board? Wir haben noch ein altes Projekt mit ihm laufen und ich muß sagen, wenn nicht allzuviel 16-Bit Rechnerei in der Applikation vorkommt, lassen sich die Sachen auch mit einem AVR realisieren. Ich habe von meinem damaligem Kollegen noch im Ohr, daß die Interrupt Ansprechzeit ziemlich bescheiden sein soll. Weiterhin wer will sich heute noch mit EPROM's herumärgern. Als letztes: der preis von ca. 24 ist ganz schön happig. Wenn schon ein Einstieg in den 16 oder 32'er Bereich, dann einen neuen Controller. Michael
@crazy horse, "Der flash ist bei den AVR der Geschwindigkeitsflaschenhals" Beim AVR ja, aber beim 8051 ist es genau umgekehrt. Da läuft der interne Flash voll mit 100MHz (C8051F120), aber für den externen Adreß-/Datenbus sind noch ne Menge zusätzlicher Zyklen erforderlich. Abgesehen davon ist eine externe 100MHz Verdrahtung nichts mehr für 2-Layer-Platinen. Ich nehme nur noch internen Flash, da geht der CE-Test viel leichter über die Bühne. Peter
Der C8051F120 ist zwar schon recht schnell aber nen 10 ns Flash hat er auch noch nicht, da muß immer noch nen SRAM Cache das Geschwindigkeitsmanko ausgleichen. Full Speed ist da auch nur wenn der Instruction Cache immer gut gefüllt ist.
Hier mein Brei bezüglich schneller µPs. Von Renesas die SH-Serie (z.B. 7145F50) oder aber auch Coldfire von Freescale (z.B. MFC52xx). Zu beiden gibt es m.E. GCC und beide haben internes RAM, was auch als Cache verwendet werden kann. Der GCC-Code für die SH-Serie ist sehr gut.
Hallo und danke erstmal für die ganzen Antworten! Ich brauch in erster Linie mehr Rechenleistung (+,-,*,/), aber auch die IO´s sollten nicht zu kurz kommen! Wäre da ein MP vielleicht die bessere Wahl, da diese intern doch um einiges schneller rechnen, oder? Michael
Wir wissen zwar immer noch nicht, welche Leistung Michael nun meint, aber hier mal ein Beispiel der IO-Leistung: Port Pin setzen: 8051F120: SETB P1.7 = 2 Zyklen = 20ns bei 100MHz, 2 Byte LPC2106 (ARM): MOV R1,#0x80 LDR R0,=0xE0028004 STR R1,[R0,#0x0] = 6 Zyklen = 100ns bei 60MHz, 4 Worte = 16 Byte Also der 8051 ist 500% schnell und spart 87,5% Code. Um ne LED blinken zu lassen, ist das ja egal, aber um in einem schnellen Interrupt das Interruptflag zu löschen, kann es schon sehr bedeutsam sein. Peter P.S.: Der Flash im 8051F120 ist 40ns schnell, deshalb legt er sich noch nen Branch Target Cache an, wo er sich die 63 häufigsten Sprungziele merkt. Der Flash im LPC2106 ist 50ns schnell und hat ein Memory Accelerator Module (MAM).
Ups, da hat mein Schreiben etwas länger gedauert, aber es soll ja auch alles stimmen. Peter
Na ja, das Flash im 7145 ist 20ns schnell. Die 'dickeren' Teile sind nichts für Bitschupser, aber für Leute, die schnell 0x12345678 + 0x74623529 addieren müssen, wobei sich die Zahlen permanent ändern. Soetwas gibt es tatsächlich!
Hallo, Ich hab grade durch zufall gesehen, dass ich noch 5x 486er CPU´s zuhause rumliegen hab! Die Frage klingt jetzt vielleicht etwas komisch, aber wäre es möglich solche CPU´s zu verwenden? Michael
Ich gebe Dir 'mal einen Link: http://www.renesas.com/media/products/mpumcu/miconproducts/03_sh.pdf Die Frage nach 486er dürfte sich Dir dann nicht mehr stellen.
Nur wenn du dir ein paar alte Mainboards besorgst und die Chipsätze auslötest. :-)
Da Michael die Priorität auf die vier Grundrechenarten legt, hier mein Vorschlag: XC161CJ Infineon, 16bit, 16 x 16 Multiplikation in 25nsec., ist teuer Entwicklungstool: µVision3 mit C166-Compiler von Keil, ist sehr teuer Programmierung und Debugging mit Keil ULINK, günstig. Tipper
Ich hab nochmal ins Datenblatt geschaut, rechenschwach ist der 8051F120 ja nicht gerade. Der hat eine "Multiply and accumulate engine", die macht 16Bit * 16Bit + 40Bit in 2 Zyklen (20ns). Problem könnte eventuell sein, eine C-Library zu finden, die die MAC auch benutzt. Peter
Hallo, Wenn ich dass jetzt richtig verstanden habe, habt ihr grad von C geredet, oder? Ich habe aber bis jetzt immer mit Assembler programmiert, was ja eigentlich keinen unterschied macht, oder?
" Ich hab nochmal ins Datenblatt geschaut, rechenschwach ist der
8051F120 ja nicht gerade. "
Dann würde mich ja mal interessieren, wie rechenstark dieser
Wunderprozessor Daten aus einem Array lesen kann:
xdata long feld[100][100];
long hole_wert(char x, char y)
{
return(feld[x][y];
}
Nur mal als Beispiel das Listing (Keil-Compiler) anbei.
Überzeugend ist das nun nicht gerade.
Einen GCC-SH habe ich gerade nicht aktiv; ich verspreche, das sieht da
ganz anders aus !
"was ja eigentlich keinen unterschied macht, oder?" Das macht schon einen großen Unterschied ! C nimmt Dir die ganzen Speicherverwaltung ab und organisiert die Parameterübergabe. Auch werden die Programme kürzer und leserlicher, ein "a=a+b" ist einfacher als "ld r0,a","ld r1,b","add r0,r1","st a,r0". 20 Variablen und 10 Funktionen kann man in Assembler gerade noch überblicken. Darüber nimmt die Fehleranfälligkeit drastisch zu. Für mich ist so die Grenze bei 2kB .. 4kB Binärcode, drunter geht noch Assembler, drüber ist C eindeutig im Vorteil. Wobei ich auch C-Programme unter 2kB mit float Zahlen habe, wegen der Bequemlichkeit. Peter
Da C doch eine Hochsprache ist, kann ich mir fast nicht vorstellen das die C Programme gleich schnell sind, wie die Assembler, oder? Da werden doch bei manchem Befehlen noch Schritte ausgeführt, die für den Zweck garnicht notwendig wären, oder ist das C geschwindigkeitsoptimiert? Michael
Ich denke dass aktuelle C-Compiler so gut sind, dass man schon ein sehr guter und routinierter Assemblerprogrammierer sein muss, um effizienteren Code zu schreiben.
@Michael C-Compiler können auch Code optimieren. (Je nach Compiler und eingestellter option mehr oder weniger gut.) Es ist aber oft so, dass die Vorteile einer erleichterten Programmentwicklung mittels Hochsprache bei weitem der Speicherplatzersparnis und Geschwindigkeitssteigerung durch handoptimierten Assemblercode übersteigen. (Natürlich kommt es immer auf die Anwendung an.) Was ich persönlich mache ist im allgemeinen nicht so geschwindigkeits- und platzkritisch. Ich würde nie freiwillig einen Assembler anfassen. Ich mache alles nur in C (C++ wenn möglich). Sollte doch einmal etwas dadurch zu langsam sein, dann würde ich die eine kritische Routine in Assembler schreiben aber den Rest unbedingt in C. Gruß, Michael
Am PC programmiere ich normalerweise auch mit Hochsprachen (Basic, C, Java, usw.) aber irgendwo hab ich in einem Tutorial über Assembler gelesen, dass es sogar bei einfachen AVR´s schon Anwedungen oder Routinen gibt, die man mit C nicht realisieren kann. Was meint ihr dazu? Michael
@Michael Was soll das sein, das man mit C nicht realisieren kann? Mir ist's jedenfalls noch nicht begegnet, aber ich mach' ja auch nicht die super schnellen Sachen. Wie gesagt: wenn man die Hardware-Resourcen bezüglich Geschwindigkeit wirklich voll ausnutzen muss, dann kann es natürlich schon sein. Gruß, Michael
Die Qualität der Compiler ist ziemlich unterschiedlich. Der Visual C++
macht aus
for (i = 0; i<5; i++)
{
x = i;
}
direkt
i = 5;
x = 4;
Viele "kleinere" Compiler gerade im embedded-Umfeld entfernen dagegen
noch nichtmal leere Schleifen.
Markus
@Markus: Das ist richtig. Der avr-gcc z.B. tut dies aber (siehe einige Fragen im Forum, warum die Warteschleife nicht wartet...). Für alle meine Belange hab ich den Code bislang mit -O2 noch schnell genug bekommen. Gruß, Michael
Achso! Sind diese guten Compiler auch umsonst? Ich werde wohl meine neuen Programme in C programmieren, da Assembler manchmal schon kompliziert ist! Michael
Man kann in C im Prinzip schon alles machen, braucht dazu aber auch Unterstützung vom Compiler bzw. der Lib, da es in ANSI C manche Dinge eben nicht gibt. Ein Beispiel wäre z.B. Sleep für Powerdown und dergleichen. Des weiteren kommt man in C natürlich nicht an die Flags ran. Wenn man z.B. 64Bit Ints braucht und der Compiler nur 32Bit bietet, dann kommt man in C bei der Addition nicht an das Carry-Flag ran und muß es simulieren (wenn a und b positiv sind und die Summe der beiden Zahlen kleiner als a oder b ist, dann hat ein Überlauf stattgefunden). Das ist in Assembler deutlich eleganter zu lösen. Markus
@Michael Gnu-Compiler sind frei. @Markus: Für solche Sachen kann man ja einzelne Routinen in Assembler schreiben. Gruß, Michael
@Michael: Die Qualität eines Compilers zu beurteilen ist nicht so einfach. Das o.g. Beispiel ist ja nur ein Kriterium von vielen. Der kommerzielle Imagecraft-Compiler kann leere Schleifen nicht wegoptimieren, während der freie GCC (WinAVR) das kann. Andererseits bietet z.B. CodeVisionAVR eine fertige Delay-Routine, wodurch man sich nicht erst lange was zusammenbauen muß usw. usf. DEN besten Compiler gibt es nicht, das kommt einfach immer auf Deine Anforderungen an. Markus
@Markus: Stimmt auch. Meine Anforderung: - darf nix kosten und - muß akzeptabel laufen zu ICCAVR von ImageCraft (den hab ich auch benutzt, bevor ich winavr gefunden habe): Den gibt es doch auch in einer teureren Version, die irgendwelche Optimierungen durchführt, oder? Weißt Du, wie viel die leisten? (nur so aus Interesse, benutzen würd ich's wohl eh nicht.) Gruß, Michael
Hallo Michael, ich habe mit den kommerziellen Compilern keine große Erfahrung, ich habe nur mal ein Hello World (d.h. LED-Blinken) in Bascom, FastAVR, Assembler , Imagecraft C, Codevision AVR und AVRco (Pascal) programmiert und verglichen. Da die meisten Umgebungen bereits ein delay, waitms oder dergleichen hatten, habe ich da nicht näher geschaut. Ich habe das auch nur mit den Demoversionen gemacht. Markus
Ok, danke für die vielen Antworten!!!!! Dann werde ich mal so einen Compiler runterladen und mal ein bischen rumexperimentieren! Danke nochmal! Michael
@Markus "Der kommerzielle Imagecraft-Compiler kann leere Schleifen nicht wegoptimieren, während der freie GCC (WinAVR) das kann." Das ist kein "Können" ! Viele MC-Compiler können mitdenken, d.h. gehen davon aus, daß sich der Programmierer bei leeren Schleifen ja was gedacht hat oder das globale Variablen in der Regel durch andere Funktionen geändert werden, d.h. wiederholte Leseoperationen nicht wegoptimiert werden dürfen. Das ist zwar nicht streng ANSI, aber sinnvoll. Der GCC kann das nicht und wirkt deshalb oft unnötiger Weise bevormundent. Besonders ärgerlich beim GCC ist, das kein Cast auf (volatile) möglich ist. D.h. volatile wirkt immer auch auf die Funktion, die die Variable erzeugt (z.B. Interrupthandler) Code verlängernd. Peter
@Peter:
Wenn ich Code in der Form habe
for (...)
{
#ifdef a
...
#endif
#ifdef b
...
#endif
}
dann soll der Compiler doch bitte die Schleife entfernen, wenn weder a
noch b definiert sind. Natürlich macht eine leere Schleife bei den MCs
oft Sinn, mir wäre aber eine waitms/waitus Funktion/Macro deutlich
lieber.
Markus
@Peter: Es ist sicher besserer Programmierstil, wenn man dem Compiler explizit mitteilt, dass eine Zählschleife nicht wegoptimiert werden darf. Gruß, Michael
@Markus,
ein simpler Schreibfehler in a oder b und Du suchst Dich tot, warum
garnichts mehr gemacht wird.
Wenn schon, dann:
for(){
#ifdef a
..
#else
#ifdef b
..
#else
#error blabla
}
Aber sowas mache ich nicht, wer soll da denn später noch einmal
durchsehen.
Ich hatte mal unter Borland-C das a2ps.c versucht zu übersetzen, das
strotzte nur so vor #ifdefs.
Nach mehreren erfolglosen Stunden habe ich schließlich alle #ifdefs
rausgeknallt und schon lief es.
Ich komme aus der Hardwareentwicklung und deshalb finde ich das
Mitdenken der kommerziellen MC-Compiler sinnvoller.
Peter
Hi und beim Umstieg von Compiler A auf Compiler B denkt dann Compiler B anders mit als Compiler A. Matthias
@Peter: Aber dann wird ja b nicht mehr ausgeführt, wenn a definiert ist. An der Stelle könnte man natürlich auch mit Variablen/Konstanten arbeiten, in der Hoffnung, daß der Compiler das merkt und entsprechend wegoptimiert. Ich frage mich auch, ob das hier wirklich mitdenken ist, oder ob das mangelnde Optimierung ist. Ich habe mir die C-Compiler im Microcontrollerbereich noch nicht so genau angeschaut, aber was die Basiccompiler veranstalten ist eher zweitklassig. Markus
Ich bevorzuge derzeit den Dallas 89C420 (oder für bessere EMV, mehr Flash) den 89C430 bis 50 (16K, 32K, 64K). Das System ist in Circuit über RS232 programmierbar und innerhalb von 30Min. auf einer Lochrasterplatine gelötet. Entweder man nimmt den Profi Keil Compiler, der 2KB Code gratis erzeugt, dann gibt es noch eine kommerzielle Variante die 8KB gratis erzeugt, oder man nimmt den SDCC der komplett gratis ist. Der uC kostet ca. 10Euro und lässt sich bis zu 33MHz takten (2Stk Samples gibt es auf www.maxim.de). Wegen der deutlich verbesserten Architektur gegenüber dem Ur-8051, bringt er auf bis zu 33MIPS(!), also 1Clock/machine cycle. Hier mal ein Auszug aus Datasheet: High-Speed 8051 Architecture One Clock-Per-Machine Cycle DC to 33MHz Operation Single Cycle Instruction in 30ns Optional Variable Length MOVX to Access Fast/Slow Peripherals Dual Data Pointers with Automatic Increment/Decrement and Toggle Select Supports Four Paged Memory-Access Modes On-Chip Memory 16kB/32kB/64kB Flash Memory In-Application Programmable In-System Programmable Through Serial Port 1kB SRAM for MOVX 80C52 Compatible 8051 Pin and Instruction Set Compatible Four Bidirectional, 8-Bit I/O Ports Three 16-Bit Timer Counters 256 Bytes Scratchpad RAM Power-Management Mode Programmable Clock Divider Automatic Hardware and Software Exit ROMSIZE Feature Selects Internal Program Memory Size from 0 to 64kB Allows Access to Entire External Memory Map Dynamically Adjustable by Software Peripheral Features Two Full-Duplex Serial Ports Programmable Watchdog Timer 13 Interrupt Sources (Six External) Five Levels of Interrupt Priority Power-Fail Reset Early Warning Power-Fail Interrupt Electromagnetic Interference (EMI) Reduction
Hi ich hab schon einiges (bin hin zu FAT16) mit dem SDCC gemacht. Ist für den 8051 durchaus brauchbar. Matthias
Hi Michael, bisher komme ich mit dem SDCC sehr gut aus, der größte Nachteil ist halt die fehlende Benutzeroberfläche. Hab mich noch nicht umgesehen aber vielleicht gibt es ja eine Freeware. Ansonsten ist der Code, den ich bisher erzeugt habe, mit dem des Keil identisch. Man kann also für beide Compiler schreiben. Gruß Gregor
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.