www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Leistungsstarker Microcontroller


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark de Jong Electronics (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark de Jong Electronics (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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/...

Letztendlich wollte ich damit eh nur sagen, daß externer Codespeicher
nicht automatisch langsamer sein muß als interner Codespeicher.

Markus

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leistung?
MC68332!
http://www.elektronikladen.de/katce332.html
teuer, aber mit Hochsprache und einfach toll.

Quark

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, da hat mein Schreiben etwas länger gedauert, aber es soll ja auch
alles stimmen.

Peter

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gebe Dir 'mal einen Link:
http://www.renesas.com/media/products/mpumcu/micon...

Die Frage nach 486er dürfte sich Dir dann nicht mehr stellen.

Autor: Camel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur wenn du dir ein paar alte Mainboards besorgst und die Chipsätze
auslötest. :-)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann wer dich dass mit den 486er mal lassen! (-;

Michael

Autor: Tipper (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes M. Richter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kostet dafuer auch seine nahezu 30 Euronen ;)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
" 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 !

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Camel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso! Sind diese guten Compiler auch umsonst?
Ich werde wohl meine neuen Programme in C programmieren, da Assembler
manchmal schon kompliziert ist!

Michael

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael
Gnu-Compiler sind frei.

@Markus:
Für solche Sachen kann man ja einzelne Routinen in Assembler
schreiben.


Gruß, Michael

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, danke für die vielen Antworten!!!!!

Dann werde ich mal so einen Compiler runterladen und mal ein bischen
rumexperimentieren!

Danke nochmal!

Michael

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:

Es ist sicher besserer Programmierstil, wenn man dem Compiler explizit
mitteilt, dass eine Zählschleife nicht wegoptimiert werden darf.

Gruß, Michael

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

und beim Umstieg von Compiler A auf Compiler B denkt dann Compiler B
anders mit als Compiler A.

Matthias

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Gregor Knappik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gregor Knappik:

Taugt der sdcc etwas?


Gruß, Michael

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich hab schon einiges (bin hin zu FAT16) mit dem SDCC gemacht. Ist für
den 8051 durchaus brauchbar.

Matthias

Autor: Gregor Knappik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.