www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LPC1100, superguenstig, 8-bit? Wird immer unnoetiger


Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NXP hat heute den 32-bit Vogel erst mal abgeschossen. Die neue Baureihe 
LPC1100, die fuer Dezember angekuendigt ist soll (bei 10000 Stueck ;-) 
weniger als 50 Eurocent kosten. Das waere dann ein 33-pin 
Microcontroller, nein das ist kein Scherz, mit 8k Flash und 2k SRAM. Der 
soll dann bis 50 MHz schnell laufen und dabei weniger als 10 mAs 
benoetigen. Ich weiss, das ist immer noch kein 8-pin Chip aber es werden 
immer weniger, die Power immer niedriger, die Preise immer niedriger... 
Die Welt der ARM MCUs draengt immer mehr in den 8-bit Bereich waehrend 
sie gleichzeitig am enderen Ende Intel angreift, doch das soll hier 
nicht so sehr zur Debatte stehen.
Also hier gibts mehr Info, Link zum Data Sheet...
http://mcu-related.com/architectures/35-cortex-m3/92-lpc1100
Gruss, Robert

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum sollte sich ein 32Bitter billiger herstellen lassen als ein 4 Bit 
Mikrocontroller? Und letzterer reicht oft für alles aus.

Oder redest du vom Hobbybereich? ;)

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieviel MIPS macht der denn ? Mehr als 20 ?

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts einen Compiler ?

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Simon
Hobby und professional. 32-bit wird in neuester Technologie gemacht, ist 
somit wahrscheinlich kleiner als ein 15 Jahre alter 4-bit..
@Krishna
Soll 45 DMips koennen und Compiler von Keil, IAR und noch ein paar mehr 
gibt's auch.
Robert

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
45 Mips sind ja schonmal sehr ok :-) Schön.

Ist bei all den Compilern auch eine kostenfreie Variante dabei ?
Nicht, daß der Chip 50 Cent kostet, und der Compiler das hundertfache 
:-)

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och, kein EEPROM..schade naja, manchmal braucht man ja auch keins.

Ansonsten aber interessant !

Datasheet:
http://www.standardics.nxp.com/products/lpc1000/da...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nicht, daß der Chip 50 Cent kostet, und der Compiler das hundertfache


Das waeren 50 EUR - meine Vermutung: Das wird wohl lange nicht reichen.

Gast

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> mit 8k Flash und 2k SRAM
Damit läge er aber auch in der Kategorie eines ATMega8 nur schneller. 
Und in Einzelstückzahlen wird er sicher auch mehr als 50 Cent kosten.
Aber stimmt schon, mehr Rechenleistung fürs gleiche Geld.

> Gibts einen Compiler ?
Müsste nicht eventuell der gcc gehen? ARM wird doch von dem unterstützt, 
oder?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Malte __ schrieb:

> Müsste nicht eventuell der gcc gehen? ARM wird doch von dem unterstützt,
> oder?

Im Prinzip ja, denn der Befehlssatz entspricht ungefähr dem Thumb(1) aus 
ARM7TDMI, etwas erweitert. Insofern steckt das im Compiler grundsätzlich 
drin. Ob dieser Cortex-M0 Mix allerdings schon im GCC so auswählbar ist 
habe ich grad nicht parat.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Malte __ schrieb:
> Müsste nicht eventuell der gcc gehen? ARM wird doch von dem unterstützt,
> oder?

Zumindest Sourcery G++ Lite 2009q1-161 unterstützt alle aktuell 
erhältlichen Cortex-M Prozessoren. Vor wenigen Tagen ist mal wieder eine 
neue Version rausgekommen.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
5V tolerant und nur eine VCC klingt schonmal gut.
Die 8kB Flash kann man natürlich nicht mit nem 8-Bitter gleichsetzen, 
die entsprechen eher einem 2..4kB 8-Bitter.


Ich bin auch etwas irritiert, hat der Cortex nun Bitbefehle oder nicht?
D.h. wie lange dauert es, einen Portpin zu setzen, 1 Befehl oder 3 
Befehle?


Peter

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> Ich bin auch etwas irritiert, hat der Cortex nun Bitbefehle oder nicht?
> D.h. wie lange dauert es, einen Portpin zu setzen, 1 Befehl oder 3
> Befehle?

Letztlich 3 Befehle, egal ob ARM7, CM3 oder CM0. Einer um die Konstante 
zu laden, einer um die Adresse vom Portregister zu laden, und einer um 
sie dort reinzuschreiben.

Alle mir bekannten vollintegrierten Controller auf ARM Basis besitzen 
Portregister mit denen ohne erst lesen zu müssen Pins gesetzt und 
gelöscht werden können.

Details über den CM0 Core, also beispielsweise ob Bitbanding drin ist 
oder nicht, hat ARM m.W. noch nicht öffentlich verraten. Mal sehen wer 
schneller ist, NXP mit den Controllern oder ARM mit der Dokumentation 
dazu. ;-)

Autor: Gebhard Raich (geb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> 5V tolerant und nur eine VCC klingt schonmal gut.
> Die 8kB Flash kann man natürlich nicht mit nem 8-Bitter gleichsetzen,
> die entsprechen eher einem 2..4kB 8-Bitter.
>
>
> Ich bin auch etwas irritiert, hat der Cortex nun Bitbefehle oder nicht?
> D.h. wie lange dauert es, einen Portpin zu setzen, 1 Befehl oder 3
> Befehle?

Im Thumb mode schätze ich die Codelänge nicht sehr unterschiedlich zu 
den 8bit MC's ein. Beim RAM Verbrauch ist darauf zu achten, daß der 
Linker die Adressen von Arrays und Strukturen generell auf durch 4 
teilbare Adressen setzt.Dadurch konnen "Löcher" in der RAM-Belegung 
entstehen. Weiters ist bei den Strukturen darauf zu achten, dass 16bit 
und 32bit variable auf geraden bzw. durch 4 teilbaren Adressen 
liegen.Geht sich das nicht aus, so entstehen in der Struktur ebenfalls 
"Löcher".
Der ARM Kern scheint generell nicht für das setzen non einzelnen 
Port-Bits entwickelt zu sein. So um die 100ns muß man bei 50MHz Core 
rechnen.
Dennoch: Meiner Meinung nach bieten die Cortex MC's für jede auch nur 
wenig anspruchsvolle Applikation das beste Preis-Leistungsverhältnis.

Ach ja, kostenlosen GCC Compiler gibts natürlich auch.

Grüße

Autor: Krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert:

Kannst Du mir dann Samples (PLCC44) besorgen ?
Muss nicht umsonst sein ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gebhard Raich schrieb:

> Im Thumb mode schätze ich die Codelänge nicht sehr unterschiedlich zu
> den 8bit MC's ein.

Je grösser der Code wird, je mehr Software-Layer beteiligt sind, desto 
eher liegt Cortex vorne. Aber für Port-I/O und Steuerregister geht bei 
den Cortexen deutlich mehr Platz drauf als bei kleinen 8-Bittern. Um ein 
Steuerregister zu schreiben, egal ob Portpin oder SPI-Control, braucht 
man bei AVR oder 8051 2-4 Bytes, beim CM0 um die 10 Bytes (3 Befehle à 2 
Bytes, 2 Konstanten à 4 Bytes), und aufgrund der grösseren Komplexität 
der Module hat er auch deutlich mehr davon.

Ebenso sind globale Variablen deutlich teurer (Adressbreite). D.h. eine 
1:1 Umsetzung eines Programmierstils, der für PIC und 8051 optimal war, 
wird auf dem CM0 nicht unbedingt genauso gut abschneiden.

Autor: Krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, das widerspricht sich dann aber -
Programme mit viel IO brauchen also auch viel Platz - Aber grade die 
Mikros setzt man doch hauptsächlich für IO-Lastige Sachen ein.

So gesehen wird der verfügbare Flash aber sehr sehr schnell knapp - 
wodurch kein Platz mehr für "Intelligenteres" mehr bleibt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krishna schrieb:

> Hm, das widerspricht sich dann aber -

Bischen schon.

> Programme mit viel IO brauchen also auch viel Platz - Aber grade die
> Mikros setzt man doch hauptsächlich für IO-Lastige Sachen ein.

Aber das lässt schnell nach. Wenn man die I/O-Module geschrieben sind, 
dann war's das. Man hat einen Bodensatz von einigen KB, in denen der 
lowlevel-Kram abgewickelt wird. Der Rest sitzt dort drauf und greift 
nicht direkt auf die Hardware zu.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krishna schrieb:

> Kannst Du mir dann Samples (PLCC44) besorgen ?

Bin mal gespannt ob es dem genauso ergeht mit dem LPC2103 in PLCC44. Der 
wurde vor ein paar Jahren angekündigt und kam nie.

Autor: Krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In 4KB kann ein 8051 mehr machen als ein
>CM0. In 32KB kann ein CM0 bei passendem Programmierstil mehr
>unterbringen als ein 8051

Hm, der "neue" bietet ja eben nur 8 KB...

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8kB RAM, aber 32kB Flash! (LPC1114)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krishna schrieb:

> Hm, der "neue" bietet ja eben nur 8 KB...

8/16/24/32KB ROM, 2/4/8KB RAM.

Autor: Krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Huch, ok, hatte ich nicht "registriert" :-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Bastelbereich finde ich die LPC1100 nicht allzu interessant. Ob das 
Ding 2€ oder 4€ kostet spielt da nicht die grosse Rolle und ein 
QFN33-Gehäuse ist auch nicht mein Traum (PLCC44 ist schon 
interessanter). Beim LQFP48-Gehäuse wiederum gibt es die wesentlich 
reicher ausgestatteten und ebenso bezahlbaren STM32F103Cx.

Industriell sieht das natürlich anders aus.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krishna schrieb:

> Hm, der "neue" bietet ja eben nur 8 KB...

Solche Spar-Zwerge mit 8KB Flash auf CM3 Basis hat(te) Luminary Micro 
rausgebracht, in SO28. Aber in denen ist nicht nur wenig ROM und RAM 
drin, sondern auch sonst fast nichts. Wenn man mit sowas nicht dauernd 
32-Bit Zahlen multipliziert und dividiert, dann ist ein Mega8 allemal 
nützlicher.

Autor: Krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich warte immer noch die Firma, die für uns Bastler all die kleinen 
Dinger - bezahlbar! (und damit meine ich weniger als 5€ Aufpreis) - auf 
Headerboards liefert :-)

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gebhard Raich schrieb:
> Beim RAM Verbrauch ist darauf zu achten, daß der Linker die Adressen
> von Arrays und Strukturen generell auf durch 4 teilbare Adressen
> setzt.Dadurch konnen "Löcher" in der RAM-Belegung entstehen.

Aber nicht grundsätzlich. Das Alignment einer Struktur entsprcht dem
größten Aligment ihrer Elemente. Besteht die Struktur z.B. nur aus
char, dann hat die Struktur selbst auch nur Byte Alignment.

> Weiters ist bei den Strukturen darauf zu achten, dass 16bit und
> 32bit variable auf geraden bzw. durch 4 teilbaren Adressen
> liegen.

Je nach Compiler kann man auch ein packed-Attribut (oder __packed)
angeben. Damit wird das Alignment aufgehoben. Zu Lasten der
Speicherbandbreite, da Zugriffe möglicherweise[1] mehr als einen Zyklus
benötigen.

Gruß
Marcus
http://www.doulos.com/arm/


Footnotes:
[1]  Im Gegensatz zu früheren ARM cores (z.B ARM7, ARM9) hat das
     keine zusätzlichen Instruktionen zur Folge, die einen konstanten
     Overhead erzeugen.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Details über den CM0 Core, also beispielsweise ob Bitbanding drin ist
> oder nicht, hat ARM m.W. noch nicht öffentlich verraten.

Der Cortex-M0 implementiert die selbe Architektur wie der Cortex-M1
(v6-M). Man kann sich den M0 in etwa als ASIC Version des M1
vorstellen.

Cortex-M0 und -M1 haben kein bit-banding.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krishna schrieb:

> Ich warte immer noch die Firma, die für uns Bastler all die kleinen
> Dinger - bezahlbar! (und damit meine ich weniger als 5€ Aufpreis) - auf
> Headerboards liefert :-)

Ich habe mich mittlerweile damit anfreunden können:
Ebay-Artikel Nr. 330377221367

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:

> [1]  Im Gegensatz zu früheren ARM cores (z.B ARM7, ARM9) hat das
>      keine zusätzlichen Instruktionen zur Folge, die einen konstanten
>      Overhead erzeugen.

Doch. Im Gegensatz zu den CM3 unterstützt der CM0 kein unaligned access.

Autor: Krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A. K.
 Oh, das ist aber schonmal sehr okay.
Danke für den Tip.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Je grösser der Code wird, je mehr Software-Layer beteiligt sind, desto
> eher liegt Cortex vorne. Aber für Port-I/O und Steuerregister geht bei
> den Cortexen deutlich mehr Platz drauf als bei kleinen 8-Bittern. Um ein
> Steuerregister zu schreiben, egal ob Portpin oder SPI-Control, braucht
> man bei AVR oder 8051 2-4 Bytes, beim CM0 um die 10 Bytes (3 Befehle à 2
> Bytes, 2 Konstanten à 4 Bytes), und aufgrund der grösseren Komplexität
> der Module hat er auch deutlich mehr davon.
>
> Ebenso sind globale Variablen deutlich teurer (Adressbreite). D.h. eine
> 1:1 Umsetzung eines Programmierstils, der für PIC und 8051 optimal war,
> wird auf dem CM0 nicht unbedingt genauso gut abschneiden.

Interessanterweise habe ich hierzu vor etwa drei Jahren mal eine
Untersuchung angestellt und den C code aus dem c't-Bot (target: AVR)
für den Cortex-M3 übersetzt -- wohlgemerkt ohne ihn vorher auf die
speziellen Eigenschaften der ARM Architektur anzupassen. Das Ergebnis
war dennoch niederschmetternd für den AVR. Bei einzelnen Sachen wie
Peripheriezugriff mag der acht-bitter möglicherweise überlegen
sein. Sobald, wie Du vermutest, diese Ebene verlassen wird, geht die
Schere auf.

Bei der Datein motor.c (stark algorithmisch), z.B. lag die Größe des
erzeugten Thumb-2 Codes bei etwa 60-75% des entsprechenden AVR codes,
abhängig vom Compiler und Optionen. GCC hat durchweg schlechter
abgeschnitten als der RealView Compiler.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Untersuchung angestellt und den C code aus dem c't-Bot (target: AVR)
>für den Cortex-M3 übersetzt -- wohlgemerkt ohne ihn vorher auf die
>speziellen Eigenschaften der ARM Architektur anzupassen. Das Ergebnis
>war dennoch niederschmetternd für den AVR.

Was mir jetzt nicht ganz klar ist: Hast Du den Code für den AVR mit dem 
GCC für ARM kompiliert? Das ist meistens ziemlich gut möglich, da es ja 
der selbe Compiler ist.
Interessant wäre da die resultierende Codegröße.

>GCC hat durchweg schlechter
>abgeschnitten als der RealView Compiler.
Du hast also nicht GCC verwendet. Es wäre ja gut möglich, dass auch der 
IAR Compiler für den AVR wesentlich kleinere Codegrößen erzeugt.

Autor: Gastino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>LPC1100, die fuer Dezember angekuendigt ist soll (bei 10000 Stueck ;-)
>weniger als 50 Eurocent kosten. Das waere dann ein 33-pin
>Microcontroller, nein das ist kein Scherz, mit 8k Flash und 2k SRAM. Der
>soll dann bis 50 MHz schnell laufen und dabei weniger als 10 mAs

Hmm, finde ich jetzt nicht sooo überzeugend. Der winzige SRAM stört mich 
schon bei den ganzen 8-Bittern, warum soll ich mir einen 32-Bitter 
kaufen, der so ärmlich mit SRAM bestückt ist? Und die Bauform, naja. 
Eine Innovation wäre ja mal ein 32-Bit-uC als DIP.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino schrieb:

> Eine Innovation wäre ja mal ein 32-Bit-uC als DIP.

Ein Kompromiss ist LQFP48 auf obigem DIP48-Träger. Und wenn der LPC1100 
tatsächlich als PLCC44 kommt, dann nützt das zwar nicht für Breadboards, 
aber für Lötpunktraster taugt es.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>> Interessanterweise habe ich hierzu vor etwa drei Jahren mal eine
>>> Untersuchung angestellt

Wo kann man das Ergebnis dieser Untersuchung sehen? Gibt es einen Link?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino schrieb:

> Hmm, finde ich jetzt nicht sooo überzeugend. Der winzige SRAM stört mich
> schon bei den ganzen 8-Bittern, warum soll ich mir einen 32-Bitter
> kaufen, der so ärmlich mit SRAM bestückt ist? Und die Bauform, naja.
> Eine Innovation wäre ja mal ein 32-Bit-uC als DIP.

Schau dir mal die PIC24H bzw. dsPIC33F an, die gibts bis 128kByte Flash 
und 16kByte SRAM in DIP28. Sind aber nur 16bit, mit 40MIPs und Harvard 
Architektur dürften die ähnlich schnell sein wie der ARM.

Autor: Gebhard Raich (geb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt

Bei einem MC im Dip-Gehäuse und auf Steckbrett oder Lochraster muß und 
kann nix mehr rasend schnell gehen.Da hat man Platz und Zeit wie vor 20 
Jahren...

Grüße

Autor: Gastino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ein Kompromiss ist LQFP48 auf obigem DIP48-Träger. Und wenn der LPC1100
>tatsächlich als PLCC44 kommt, dann nützt das zwar nicht für Breadboards,
>aber für Lötpunktraster taugt es.

Prinzipiell ja. Das Problem ist nur, dass diese Träger ziemlich teuer 
sind und ein Vielfaches des Controllers kosten.

>Bei einem MC im Dip-Gehäuse und auf Steckbrett oder Lochraster muß und
>kann nix mehr rasend schnell gehen.Da hat man Platz und Zeit wie vor 20
>Jahren...

Diese "Logik" verstehe ich nicht.

>Schau dir mal die PIC24H bzw. dsPIC33F an, die gibts bis 128kByte Flash
>und 16kByte SRAM in DIP28. Sind aber nur 16bit, mit 40MIPs und Harvard
>Architektur dürften die ähnlich schnell sein wie der ARM.

Jep, die habe ich mir schon mal angesehen (nur ganz grob). Das scheint 
die einzige Alternative zu sein, wenn man etwas mehr SRAM benötigt. Zur 
Zeit komme ich zum Glück noch mit den RAMs der ATmega16/32/644 aus, aber 
wenn das nicht mehr reicht, wird es unschön. Dann bleiben nur die 
Alternativen Adapter (teuer) oder jedesmal eine Platine herstellen 
lassen (sehr teuer).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino schrieb:

> Prinzipiell ja. Das Problem ist nur, dass diese Träger ziemlich teuer
> sind und ein Vielfaches des Controllers kosten.

Muss der Controller aber sensationell günstig sein. Diese Träger kosten 
80¢ pro Stück inklusive Porto (bei 8 Stück).

Drauf ein STM32F103C8 mit USB/CAN und 64KB Flash 20KB RAM bei 72MHz 
(6,50€ plus MWSt bei TME). Akzeptables Preis/Leistungsverhältnis, ggf. 
pinkompatibel ausbaufähig auf 128KB Flash.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Wo kann man das Ergebnis dieser Untersuchung sehen? Gibt es einen Link?

Falls Du Zugriff auf die Vorträge der ARM Developers Conference 2006, 
möglicherweise auch 2007 hast, könntest Du das finden. Es ging aber 
hierbei ausdrücklich nicht um ARM vs. AVR, sondern lediglich darum, die 
Vorurteile gegenüber 32bit Prozessoren beim Einsatz in traditionellen 
8bit Domänen auszuräumen. Ein Teil dieses Vortrags behandelte die 
Codegröße.

Es handelte sich übrigens nicht um eine Untersuchung nach anerkannten 
wissenschaftlichen Standards. Schon die genaue Dokumentation der 
Vorgehensweise ist möglicherweise lückenhaft (hüstel). Vielleicht finde 
ich noch die Compile-Scripte.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Was mir jetzt nicht ganz klar ist: Hast Du den Code für den AVR mit dem
> GCC für ARM kompiliert? Das ist meistens ziemlich gut möglich, da es ja
> der selbe Compiler ist.

Aber für eine andere Architektur. GCC für AVR ist nun mal im Nachteil, 
da GCC stark auf 32bit optimiert ist. GCC ist aber der im c't-Bot 
Projekt verwendete Compiler und somit Referenz.

>>GCC hat durchweg schlechter
>>abgeschnitten als der RealView Compiler.
> Du hast also nicht GCC verwendet. Es wäre ja gut möglich, dass auch der
> IAR Compiler für den AVR wesentlich kleinere Codegrößen erzeugt.

Woraus liest Du das denn? Der (ungefähren) Fairness halber, habe ich 
natürlich auch GCC für ARM verwendet (Code Sourcery). Daneben habe ich 
den RealView Compiler eingesetzt. Auf IAR für AVR habe ich leider keinen 
Zugriff.
GCC für ARM hat sich auch nicht gerade mit Ruhm bekleckert.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>GCC für ARM hat sich auch nicht gerade mit Ruhm bekleckert.

Dafür das er nichts kostet ist er sehr ruhmreich. Die kastrierten 
Versionen der "guten" Compiler reichen auch für den Privatgebrauch 
längst nicht immer. Wenn man z.B. durch einen dummen Zufall mal einen 
TCP-Stack verwendet oder mehr als einen Zeichensatz braucht.

Und: Bei den Vergleichen die ich vor ca. zwei Jahren zwischen RealView 
und GCC gemacht habe war der RealView zwar durchweg besser, sein 
Vorsprung betrug aber nie mehr als 5% (Code und Speed). Und dafür >2000€ 
berappen? No Sir!

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> ... betrug aber nie mehr als 5% ...

Wo kann man das Ergebnis dieser Vergleiche sehen? Gibt es einen Link?

Autor: Gastino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Muss der Controller aber sensationell günstig sein. Diese Träger kosten
>80¢ pro Stück inklusive Porto (bei 8 Stück).

Das hier verlinkte Adapter-Board kostet 7,20$. Wo beziehst Du die für 
80Cent?

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino schrieb:
> Das hier verlinkte Adapter-Board kostet 7,20$. Wo beziehst Du die für
> 80Cent?
Also ich habe das Inserat so verstanden, dass 8 St. soviel kosten.

Autor: Gastino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also ich habe das Inserat so verstanden, dass 8 St. soviel kosten.

Das habe ich glatt überlesen... :)))

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wo kann man das Ergebnis dieser Vergleiche sehen? Gibt es einen Link?

Nirgendwo. Die Tests habe ich in meinem stillen Kämmerlein gemacht. Ich 
wurde auch nicht dafür bezahlt.
Die meisten Vergleiche bezogen sich auf Geschwindigkeit: Verschachtelte 
Funktionsaufrufe, Arrayzugriffe (Offsetberechnung), Strukturzugriffe und 
arithmetische Operationen (Integer). Bei letzterem hat es mich besonders 
interessiert ob und wie gut der Compiler Zwischenergebnisse aus 
vorherigen Berechnungen wiederverwenden kann.
a = 2*b + x + 9;
b = 2*b + x + 10; 
Da nehmen sich die beiden aber nichts.

Die libc habe ich nicht (wissentlich) verwendet. printf(), itoa() und co 
sind selbst programmiert.

PS: Controller dürfte ein LPC2103 gewesen sein, also ARM7. Auf jeden 
Fall im ARM Mode. Wofür war Thumb nochmal gut? ;)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehmet Kendi schrieb:

> Also ich habe das Inserat so verstanden, dass 8 St. soviel kosten.

Ist so. Hab's mit dem STM32F101C6 (32K/36MHz) vom gleichen Shop 
ausprobiert. Liess sich astrein mit der Flussmittel+Entlötlitzenmethode 
einlöten. Mega32/644 ade.

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie programmiert man den, d.h. wo gibt es Schaltplan + Software für den 
Programmer ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beispielsweise per fertig enhaltenem Bootloader über die serielle 
Schnittstelle. Programm dazu gibt's bei ST. Ein Pin steuert, ob der 
Bootloader oder das Flash startet.

Bequemer siehe Beitrag "STM32 Programmiertool", da steuert 
die serielle Schnitstelle an Stelle von Schaltern die BOOT0+Reset Pins 
und automatisiert den Vorgang.

Alternativ geht das natürlich auch via JTAG-Adapter für's Debugging, 
dafür siehe hiesigen Shop, die üblichen Verdächtigen wie Segger oder 
selber gebaut mit FT2232.

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, nachdem ich grade den Niche TCP/IP Stack dafür entdeckt habe, habe 
ich große Lust mein angedachtes Webradio mit dem STM zu realisieren :-)
Soweit ich gelesen habe, ist der doch kostenlos ("For customers") - 
Reicht es, wenn ich mich bei STM anmelde ?

Da muss ich mich nun wohl ein wenig auf STM einarbeiten - gibt es 
irgendwo Deutschsprachige Seiten für den Anfang ? Habe zwar mit Englisch 
kein Problem, aber auf Deutsch liest es sich doch immer noch flüssiger.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht deutsch, aber nützlich:

Über den Cortex-M3:
http://www.amazon.de/Definitive-Guide-Cortex-M3-Em...

Über die STM32 Implementierung:
http://www.st.com/mcdfiles/1221142709.pdf

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde mir für den Anfang mal das hier besorgen:

http://www.ehitex.de/p_info.php?products_id=430

Da kann man nicht meckern. 256 K Flash, 64KB Ram, Ethernet, Usb..

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Muss der Controller aber sensationell günstig sein. Diese Träger kosten
> 80¢ pro Stück inklusive Porto (bei 8 Stück).
>
> Drauf ein STM32F103C8 mit USB/CAN und 64KB Flash 20KB RAM bei 72MHz
> (6,50€ plus MWSt bei TME). Akzeptables Preis/Leistungsverhältnis, ggf.
> pinkompatibel ausbaufähig auf 128KB Flash.

Bei Farnell sind die Preise günstiger:
 1 - 9 st. 5,30
ab  10 st  4,15

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehmet Kendi schrieb:

> Bei Farnell sind die Preise günstiger:

Jo, aber in meinem Fall geht es um privaten Gebrauch. Und HBE als 
deutscher Vertrieb für solche Kunden will für den STM32F103C8 
indiskutable 13,40€. Kurioserweise will er für die grössere 128KB 
Version davon (CB) nur 12,90€.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hat doch aber die LPC17xx Serie von NXP noch ein besseres P/L 
Verhältnis, oder?
Immerhin kostet der LPC1752 mit 64k Flash, 16k RAM, 100MHz, USB/CAN 
gerade mal 5,20€ INKL MWSt (HBE). Und der große Brocken (LPC1768) mit 
512k Flash, LAN, USB ect. nur 9€.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gebe privat ab STM32F103CBT6 für 9,20 Euro inkl. Versandkosten
im Kompaktbrief.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg S. schrieb:

> Da hat doch aber die LPC17xx Serie von NXP noch ein besseres P/L
> Verhältnis, oder?

Bezogen auf die merkwürdige Preispolitik von HBE schon, aber auf Träger 
ist mit der 80-Pin NXP-Klops für viele Fälle zu gross. LQFP48 gefällt 
mir besser. Und TME hat ihn, jedenfalls in der 64KB Version.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:

> Ich gebe privat ab STM32F103CBT6 für 9,20 Euro inkl. Versandkosten
> im Kompaktbrief.

Danke, komme ich ggf. darauf zurück, aber vorzugsweise Kontakt per 
email.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Bezogen auf die merkwürdige Preispolitik von HBE schon, aber auf Träger
> ist mit der 80-Pin NXP-Klops für viele Fälle zu gross.

... und zu frisch. Das erste Jahr lasse ich gerne andere Leute die 
Fehler suchen. ;-)

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur noch mal zurueck zum Original-Thread. Es ging mir darum, dass es 
jetzt (bald) 32-bit controller gibt, die in fast allen Dingen den 
8-bittern ueberlegen sind.
Es ging mir jedenfalls nicht darum das obere Producktspektrum der 
Cortex-M3 Chips nochmals zu beleuchten, denn diese haben einen anderen 
Zielmarkt, naemlich das untere Ende von 32-bit Anwendungen bzw. den 
Schwerpunkt von 32-bit Flash MCU Anwendungen.

Robert

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es ging mir darum, dass es
>jetzt (bald) 32-bit controller gibt, die in fast allen Dingen den
>8-bittern ueberlegen sind.

Was für eine Feststellung!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Nur noch mal zurueck zum Original-Thread. Es ging mir darum, dass es
>jetzt (bald) 32-bit controller gibt, die in fast allen Dingen den
>8-bittern ueberlegen sind.

Na und. In vielen Anwendungen langweilen sich schon 8-Bitter oder sogar 
4-Bitter. Warum dann einen 32-Bitter bemühen?

MfG Spess

Autor: krishna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde auch, der Grat ist schmal.

Wenn z.b. ein avr mit 20MHZ nicht mehr reicht, warum dann nicht gleich 
zu etwas wesentlich stärkerem greifen.

Für Bastler - und dies ist ja ein "Bastel"-Forum - ist die Gehäuseform 
viel wichtiger, als ein paar Cent beim Prozessor zu sparen. Und da seh 
ich den neuen nicht wirklich im Vorteil gegenüber anderen - die dann 
aber auch direkt mit 256 KB Flash, 64K Ram usw. aufwarten können.
OK, PLCC44 und dann für unter 5 EUR (Endkundenbastlereinzelstückpreis) 
wäre ein echtes Argument - wenn es denn wirklich kommt.

Ansonsten kaufe ich mir eine stamp mit STM32 drauf für 18 € aus Thailand 
und habe dann gleich was in jeder Beziehung stärkeres - und muss mich 
nicht mit SMD herumplagen.

Das sagt einer, der grade von AVR in diese Liga wechselt.

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn ich mir das Datenblatt bezüglich ADC anschaue, bleibe ich doch 
lieber bei einem PIC. Der ADC des LPC ist zwar schneller, liefert aber 
nur "typisch" 8 Bit Genauigkeit. Beim PIC sind die Worst-Case angaben 
noch besser als die typischen des LPC.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

> Na und. In vielen Anwendungen langweilen sich schon 8-Bitter oder sogar
> 4-Bitter. Warum dann einen 32-Bitter bemühen?

Jenseits kleiner Anwendungen (einige KB) nervt mich bei vielen 8- und 
16-Bittern die Adressraumtrennung, die beispielsweise bei Strings zu 
Verrenkungen führt. Mit besserem Compiler-Support als GCC ist das zwar 
weniger krass, aber immer noch nervend.

Autor: Gebhard Raich (geb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Anja

Die STM32 Serie hat 12bit ADC's, ebenso die ADUC70xx und die sind bei 
entsprechendem Layout wirklich bis zum letzten Bit stabil.

Grüße

Autor: robertteufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@spess53
Warum 32-bit fuer kleine Anwendungen? Ich wuerde die Frage mal anders 
rum stellen.
Was bringt es mir meine getesteten Code Bausteine immer wieder benuetzen 
zu koennen?
Was bringt es mir immer dieselben Tools zu benutzen fuer meine 8k 
Anwendungen und fuer meine 512K Anwendungen?
Was bringt es wenn meine Ingenieure eine Architektur wirklich toll 
beherrschen anstelle von  Architekturen recht ordentlich?
Was bringt Standardisierung?

Es geht nicht darum ob ein 4-bit oder 8-bit Rechner das noch schaffen 
kann oder nicht. Die 4-bit Rechner wuerden auch heute noch vieles 
schaffen wofuer schon lange AVRs oder 8051 eingesetzt werden. Aber die 
8051 und AVRs sind einfach ein Standard geworden. Jetzt koennte sich ein 
neuer Standard auf 32-bit anbahnen, dann macht es wirklich nicht sehr 
viel Sinn bei vergleichbaren Kosten und Power noch einen 8-bit fuer neue 
Projekte einzusetzen.

Wer natuerlich annimmt er braucht nie einen 32-bit, fuer den ist dieser 
Thread nicht angebracht. So wie der Schoepfer des erster PCs / DOS es 
fuer unvorstellbar hielt, dass der verfuegbare Speicher von 64K bzw. die 
DOS Grenze von 640K jemals ueberschritten werden koennte :-)

Robert

Autor: DAC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>So wie der Schoepfer des erster PCs / DOS es
>fuer unvorstellbar hielt, dass der verfuegbare Speicher von 64K bzw. die
>DOS Grenze von 640K jemals ueberschritten werden koennte :-)

Das Zitat ist genauso fehlerhaft wie deine Pro-32-Bit Liste im selben 
Beitrag. Es lautete, dass kein normaler Mensch je mehr als 640K wirklich 
benötigen werde. Dass es locker möglich ist, mehr als das tausendfache 
zu verschwenden, war damals auch schon klar.

>Warum 32-bit fuer kleine Anwendungen? Ich wuerde die Frage mal anders
>rum stellen.
>Was bringt es mir meine getesteten Code Bausteine immer wieder benuetzen
>zu koennen?

Ne Menge Copy&Paste bringt es. Ein Programm als Gesamtkonzept ist eben 
mehr als die Summe der Einzelteile.

>Was bringt es mir immer dieselben Tools zu benutzen fuer meine 8k
>Anwendungen und fuer meine 512K Anwendungen?

Sicher bringt es auch Bequemlichkeit, was nicht immer der Qualität 
zuträglich ist.

>Was bringt es wenn meine Ingenieure eine Architektur wirklich toll
>beherrschen anstelle von  Architekturen recht ordentlich?

Sie werden immer versuchen, Probleme genau damit zu lösen.

>Was bringt Standardisierung?

Mehr Pflicht, weniger Spaß.

>Wer natuerlich annimmt er braucht nie einen 32-bit, fuer den ist dieser
>Thread nicht angebracht.

Ist bei mir keineswegs der Fall, habe schon alle Abstufungen von 8 bis 
32 Bit eingesetzt. Immer das, was halt am besten passt. Man muss halt 
schon mal ein paar Tage Recherche einplanen, da geht es sicher schneller 
sich einfach einen fetten 32Bitter von ner Liste zu schnappen. Ich 
verstehe unter einem ordentlich durchdachten Design aber was anderes.


Hier noch bissl was zum lesen:

QUESTION: I read in a newspaper that in 1981 you said, ``640K of memory 
should be enough for anybody.'' What did you mean when you said this?

ANSWER: I've said some stupid things and some wrong things, but not 
that. No one involved in computers would ever say that a certain amount 
of memory is enough for all time.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich pflichte Robert in allen Punkten bei.

Es dauert so seine Zeit, bis man sich in eine MCU-Familie und deren 
Toolchain eingearbeitet hat. Und ehrlich gesagt fehlt mir die nötige 
Zeit und (vermutlich die nötige) Brainpower, um für jedes Projekt die 
geeignete MCU-Familie auszusuchen.
Deshalb waere es ideal, wenn man in einer 32bit Familie zu hause waere, 
die preislich und leistungsmaessig eine grosse Flaeche abdeckt.

Und dieser LPC1100 ist ein Argument mehr, um nun endlich mal die 
AVR-Welt hinter sich zu lassen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  DAC (Gast)

>>Was bringt es mir meine getesteten Code Bausteine immer wieder benuetzen
>>zu koennen?

>Ne Menge Copy&Paste bringt es.

Käse. Schon mal was von modularem Aufbau gehört? Wozu ein Programmteil 
10mal neu erfinden?
Bibliotheken?

>>Was bringt es mir immer dieselben Tools zu benutzen fuer meine 8k
>>Anwendungen und fuer meine 512K Anwendungen?

>Sicher bringt es auch Bequemlichkeit,

Nicht nur. Es bingt aus eine meist sinnvolle Vereinheitlichung.

>>Was bringt Standardisierung?

>Mehr Pflicht, weniger Spaß.

Unsinn. Ingenieure sind keine freien Künstler, die vollkommen losgelöst 
von der Realität sich frei entfalten können und wollen!
Daß es zu jeder Sache immer Pro und Kontra gibt ist klar, da ist 
Standardisierung keine Ausnahme.
Sie bringt u.a. vor allem auch eine Vereinfachung und Entlastung beim 
Lösen bekannter Problemstellungen.

>Ist bei mir keineswegs der Fall, habe schon alle Abstufungen von 8 bis
>32 Bit eingesetzt. Immer das, was halt am besten passt. Man muss halt
>schon mal ein paar Tage Recherche einplanen, da geht es sicher schneller
>sich einfach einen fetten 32Bitter von ner Liste zu schnappen.

Richtig!

MFG
Falk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehmet Kendi schrieb:
> Und dieser LPC1100 ist ein Argument mehr, um nun endlich mal die
> AVR-Welt hinter sich zu lassen.

Warum sollte man denn sowas tun?

Wenn man sich mit den AVRs auskennt, gibt es keinen Grund, auch nicht 
weiterhin Projekte damit zu machen, für die er geeignet ist.
Man hat Erfahrungen, wo die Fallgruben liegen und wie stabil er arbeitet 
(never change a winning team).

Ich werde 32Bitter nur da einsetzen, wo sie auch Vorteile haben.
Es bringt ja nichts, einen ATtiny25 durch nen LPC zu ersetzen und dafür 
eine erheblich komplexere und damit deutlich länger dauernde 
Programmierung in Kauf zu nehmen. Programmierzeit ist auch Geld.


Wenn ich mir z.B. diesen Thread hier ansehe, kann ich mir nur an den 
Kopf fassen:

Beitrag "CMSIS und die Interrupt-Prioritäten"

Ich hab ja den ersten Beitrag echt für einen Joke gehalten (linksbündige 
Interrupts).
Ich verstehe nicht, wie man als Programmierer die Prioritäten mit der 
Gießkanne verteilt, damit die dann hinterher auf die tatsächlich 
verfügbaren runtergebrochen werden.
Wenn ich Prioritäten vergebe, dann denke ich mir auch was dabei und 
verlange auch, daß nicht plötzlich doch Interrupts wieder die gleiche 
Priorität haben können.


Peter

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Ich werde 32Bitter nur da einsetzen, wo sie auch Vorteile haben.
> Es bringt ja nichts, einen ATtiny25 durch nen LPC zu ersetzen und dafür
> eine erheblich komplexere und damit deutlich länger dauernde
> Programmierung in Kauf zu nehmen. Programmierzeit ist auch Geld.

Okay, ATtiny25 ist jetzt ein krasses Beispiel. Und da waere ein Einsatz 
eines LPC wohl sicherlich 'etwas' daneben.
Meine obige Konklusion kommt wohl daher, dass meine Porjekte so ab 
Atmega32 anfangen. Und ich in der Mehrzahl meiner Projekte stets nach 
mehr RAM und mehr MHz gelechzt habe.

Wenn Du die zeitlichen und geistigen Mittel dazu hast, zwischen den 
8-bit und 32-bit Welten je nach Bedarf hin und her zu wechseln: ich 
beneide Dich!
Würde ich auch gerne.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> Ich hab ja den ersten Beitrag echt für einen Joke gehalten ("linksbündige
> Interrupts).

Das steht da nirgends drin. Drin steht etwas von linksbündigen 
Prioritäten, nicht von linksbündigen Interrupts. Darf ich davon 
ausgehen, dass du die in vielen ADCs verfügbare "linksbündige Spannung" 
(d.h. die linksbündige Darstellung des Ergebnisses) ebenfalls für einen 
Witz hältst? Da steckt letztlich die gleiche Systematik dahinter.

> Wenn ich Prioritäten vergebe, dann denke ich mir auch was dabei und
> verlange auch, daß nicht plötzlich doch Interrupts wieder die gleiche
> Priorität haben können.

Ich konnte gut nachvollziehen, was der Designer des NVIC sich dabei 
gedacht hatte, immerhin geht die linksbündige Darstellung auf ihn 
zurück, nicht auf mich. Aber egal ob links- oder rechtsbündig: Meine 
Kritik richtete sich primär an die Verwirrung durch diesbezüglich 
unterschiedliche Konventionen von NVIC und CMSIS.

Dieser Designer hat damit ein Modul entwickelt, dessen Schema unabhängig 
von der Anzahl real implementierter Bits für alle Cortexe den gleichen 
Gesamtraum realisiert. Das halte ich weder für zufällig, noch für 
irgendwie hardwaremässig effizienter, sondern für Absicht.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Das steht da nirgends drin. Drin steht etwas von linksbündigen
> Prioritäten, nicht von linksbündigen Interrupts.

Sorry, Schreibfehler.

> Darf ich davon
> ausgehen, dass du die in vielen ADCs verfügbare linksbündige Darstellung
> des Ergebnisses ebenfalls für einen Witz hältst? Da steht letztlich die
> gleiche Systematik dahinter.

War jetzt nicht so bierernst gemeint. Ich wollte nur drauf aus, daß 
manche Sachen beim 32Bitter ungewohnt komplex sind und man sich erstmal 
wundert, was das überhaupt soll.

Ich hab mir das aber noch nicht angesehen, daher weiß ich nicht, was 
linksbündige Prioritäten bedeutet.
Beim 8051 habe ich für jeden Vector 2 Bits und stelle damit Priorität 
0..3 ein, fertig.
Ich lese z.B. einen 1-wire Sensor im Timerinterrupt aus und dabei kommt 
es auf µs an. Deshalb hat dieser als einziger die Priorität 3 und alle 
anderen Interrupts nur 0..2.


Peter

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> Ich hab mir das aber noch nicht angesehen, daher weiß ich nicht, was
> linksbündige Prioritäten bedeutet.

Der NVIC definiert Prioritäten als 8-Bit Werte. Von denen aber nur N 
Bits implementiert sind (Cortex-M3: wählbar, STM32=4; Cortex-M0: fix=3). 
Und diese N Bits stehen linksbündig im betreffenden Register, d.h. beim 
CM0 werden effektiv die Werte 0x00,20,40,60,80,A0,C0,E0 unterschieden.

CMSIS bildet diesen Wertebereich in Parameter/Ergebnis auf 0..7 ab. 
Folglich hat man je nach Blickwinkel 0x60 oder 3 dastehen, beim 
Debugging steht im NVIC 0x60, im Quellcode und irgendwelchen Variablen 
3.

Autor: DAC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk Brunner
>Käse. Schon mal was von modularem Aufbau gehört? Wozu ein Programmteil
>10mal neu erfinden?
>Bibliotheken?

Meine Aussage war etwas provokativ (aber nicht aggressiv gemeint), weil 
die Frage des TE sich aus Sicht eines jeden Programmierers selbst 
beantwortet. Genau aus den Gründen die du eben genannt hast.
Die wiederum aber nicht fest an eine einzige Architektur gebunden sind, 
daher wollte ich einen Kontrapunkt setzen.

>Unsinn. Ingenieure sind keine freien Künstler, die vollkommen losgelöst
>von der Realität sich frei entfalten können und wollen!

Ich bin Entwickler, ich entfalte mich in der Realität, wenn du so 
willst.

>Daß es zu jeder Sache immer Pro und Kontra gibt ist klar, da ist
>Standardisierung keine Ausnahme.

Eben, darüber würd ich auch nicht streiten wollen.

>Sie bringt u.a. vor allem auch eine Vereinfachung und Entlastung beim
>Lösen bekannter Problemstellungen.

Das ist die Intention dahinter, klappt mal mehr - mal weniger.

>Käse.
>Unsinn.

Ist das der Ausdruck des letzten Rests Kreativität, der dem Ingenieur 
von heute noch bleibt? ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel schrieb:

> @Krishna
> Soll 45 DMips koennen und Compiler von Keil, IAR und noch ein paar mehr
> gibt's auch.
> Robert

Und das kostet Schotter, ist proprietaer und laeuft nur unter Windows. 
Ausserdem eine neues und damit sicherlich noch reichlich fehlerhaftes 
Silizium gepaart mit einer Alpha-Toolchain. Da kommt Freude auf! Da sag 
ich: nein danke ;)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. schrieb:

> gepaart mit einer Alpha-Toolchain.

So schlimm kann es kaum sein, denn der Cortex M0 ist nicht viel anders 
als ARM7TDMI ohne ARM, nur Thumb-Modus. Existiert also im Compiler 
schon. Und für die Systemumgebung nimmt man den Kram vom Cortex M3, 
wirft die nicht existierenden Teile vom Systeminterface raus und fertig.

Es ist eher andersrum: Mancher Compiler hat den Schritt von Thumb1 zu 
Thumb2 (Cortex-M3) immer noch nicht so weit verdaut, dass er dessen 
Möglichkeiten effektiv nutzen würde (GCC beschränkt sich meiner 
Erkenntnis nach auch dann auf R0-R7 wenn R8-R12 wirklich opportun 
wären).

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A. K.,

danke für die Erklärung, so kompliziert ist das also garnicht.

Mir gefällt allerdings auch die Darstellung 0..7 besser.
Beim 8051 muß man die Priorität sogar in 2 Registern setzen (ein 
Register pro Bit), d.h. da ist die Umrechnung noch "komplizierter".

Ich bin aber auch nicht derjenige, der große Programme schreibt und sich 
dann mühsam mit dem Debugger durchkämpft.
Ich schreibe lieber kleine Module, die ich einzeln teste.
Dann habe ich beim Zusammenbau zum kompletten Programm wenig in den 
Eingeweiden rumzuwühlen. Es sind fast nur logische Fehler (z.B. ein ! an 
der falschen Stelle).


Peter

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> danke für die Erklärung, so kompliziert ist das also garnicht.

Nö. Allerdings war das nur die vereinfachte Kurzfassung. Man kann diese 
N Bits noch ein zwei Teile spalten, eine Ebene für's Nesting und eine 
Priorität innerhalb der Ebene ohne Nesting. Muss man aber nicht tun.

Lustiger ist was anderes: Dieser NVIC ist der vielleicht einzig 
existierende Interrupt/Exception-Controller, bei dem auch synchrone 
Core-Exceptions wie irregeleitete Speicherzugriffe oder Division durch 0 
frei wählbare Prioritäten haben. Das kann also heissen, dass solche 
Exceptions in einem ggf. höher priorisierten Interrupt-Handler nicht auf 
den passenden Handler verzweigen können - das gibt dann allerdings 
trotzdem eine Exception, aber ersatzweise als Hardfault.

Sinnlos ist das nicht, nur ungewöhnlich, denn so kann man in Umgebungen 
mit User/System-Trennung wie Linux gleich von vorneweg zwischen 
kritischen (im Systemkontext) und unkritischen Exceptions (normaler 
Prozess) unterscheiden, ohne das jeweils im Handler abfragen zu müssen.

Man spürt, dass in das NVIC Design eine Menge Erfahrungen aus der 
Vergangenheit eingeflossen sind. Auch in Hinblick auf effiziente 
Implementierung eines RTOS ohne dabei wie sonst oft jeden 
Interrupt-Handler aufblasen zu müssen (PendSV). Und es wird klar, dass 
Anwender ohne entsprechendem Background solche Aspekte nicht oder nicht 
ohne Erklärung verstehen werden.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Das kann also heissen, dass solche Exceptions in einem ggf. höher
> priorisierten Interrupt-Handler nicht auf den passenden Handler
> verzweigen können - das gibt dann allerdings trotzdem eine
> Exception, aber ersatzweise als Hardfault.

Das hat sogar noch einen weiteren Vorteil, der diesen Teil des Threads
möglicherweise wieder auf das eigentliche Thema zurückführt: In
softwaremäßig eher einfach gestrickten Systemen kann ich alle System
Exceptions, die ich nicht gesondert behandeln möchte, auf den
Hardfault Handler abbilden. Damit erspare ich mir, erstmal die ganzen
Handler aufzusetzen -- ohne jedoch die Information über sie ganz zu
verlieren.

Gruß
Marcus
http://www.doulos.com/arm/

PS: Cortex-M0 implementiert nur zwei Bits, und die Prioritätsregister
lassen sich sich nicht unterteilen. Man hat also effektiv immer vier
preemptive priorities.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gastino schrieb:
> Eine Innovation wäre ja mal ein 32-Bit-uC als DIP.

Gibt es doch. Sogar 8 einzelne 32bit Prozessoren auf einem Chip, und mit 
32kByte RAM. Das ganze im DIP40 Gehäuse.
Kostet auch nur 99 cent ($-cent) pro Prozessor (also knapp 8$ für den 
ganzen Chip) und das bei 1 Stück.
Optimiert für Bit-Banging, dafür sonst wenig Peripherie integriert.

Kurz: mein Lieblingsprozessor, der Parallax Propeller Chip.

Andi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andi schrieb:

> Kurz: mein Lieblingsprozessor, der Parallax Propeller Chip.

Er hat seinen Charme, das muss man sagen. Aber es gibt halt gerade mal 
einen Chip in der Familie und die Plaene zur Weiterentwicklung wurden 
ziemlich gestutzt, nachdem man gemerkt hat, dass gewisse Ziele 
unrealistisch waren ;) Ausserdem hat er halt einfach zu wenig RAM und 
ist auf ein externes EEPROM zur Programmablage angewiesen. Dann wird das 
meiste der Rechenleistung durch den (HW)-Interpreter der Spin-Sprache 
wieder verschenkt.

Am Rande: Ich hab nen weitgehend kompletten Parser fuer Spin geschrieben 
(JavaCC), wer einen Compiler fuer nativen Maschinencode entwickeln will 
kann sich bei mir melden :P

Michael

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@DAC,
ist es moeglich, dass Du in einer kleinen Firma arbeitest?
Einfach nur zu meinem Verstaendnis, wie ist dieser Satz zu verstehen:
"..... genauso fehlerhaft wie deine Pro-32-Bit Liste im selben Beitrag."
Wie koennen Fragen falsch sein?

Ich hab mit sehr grossen Kunden gearbeitet, die hatten Stueckzahlen, die 
es in Deutschland wohl nicht in einer einzigen Anwendung gibt (40 Mio 
MCUs / Jahr). Da lohnt es sich einen absolut massgeschneiderten Chip 
einzusetzen, keine Diskussion. Da wuerde ich auch einen 8-bit Rechner 
einsetzen wenn er kann was verlangt wird, wenn ich auch nur einen Cent 
einsparen kann, denn 1 cent enspricht dann 400000 (es waren $)

Andererseits haben sich auch schon viele kleine und mittlere Firmen mit 
der Vielfalt ihrer Architekturen totentwickelt. Warum denkst Du gibt es 
bei allem grossen Firmen starke Bestrebungen die Anzahl der 
Architekturen klein zu halten bzw. sie du reduzieren? Wenn ich aber nur 
wenige Architekturen einsetzen darf, dann ist doch ein logischer Fokus 
auf Architekturen mit grosser Bandbreite und grosser Preisspanne.

p.s. sorry, dass meine Quotation etwas zu frei uebertragen war.

@Falk,
ich denke mal Du arbeitest in einer groesseren Firma :-), da gibt es 
einfach Regeln fuer Wiederverwendung von Code.


@Peda,
auch ich hab viel mit dem 8051 programmiert und der Umstieg auf 32-bit 
erschien erst mal kompliziert. Ist nicht alles was anders ist erst mal 
kompliziert? Versuchs doch mal damit, das Wort kompliziert und das Wort 
komplez mit dem Wort "anders" zu ersetzen. Nur so ein Vorschlag die Welt 
etwas positiver zu sehen.

Gruss, Robert

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Robert Teufel (robertteufel)

>@Falk,
>ich denke mal Du arbeitest in einer groesseren Firma :-), da gibt es
>einfach Regeln fuer Wiederverwendung von Code.

Wenn 80 Leute für dich gross sind  . . .

Nööö, das ist ein Grundprinzip. Und unser Chef drängt auch immer auf 
Wiederverwendung von Hard- und Software, manchmal ein wenig zu viel.
Aber im Prinzip ist das schon richtig, denn auch bei uns gibt es viel 
Kleinkram, den man besser nicht ausufern lässt.

MFG
Falk

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Harnisch schrieb:

> PS: Cortex-M0 implementiert nur zwei Bits [...]. Man hat also effektiv
> immer vier preemptive priorities.

Ich hatte die 3 Bits aus dem Datasheet des LPC1100 abgeleitet, dort 
werden nämlich ausdrücklich 8 Prioritäten erwähnt. Die ARMv6-M Referenz 
spricht aber tatsächlich nur von 2 Bits.

Autor: DAC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert
>ist es moeglich, dass Du in einer kleinen Firma arbeitest?

Vieles ist möglich. Zu meinen Kunden gehören durchaus auch Größere. Hab 
den Eindruck, manch Einer hier hat Probleme über seinen Tellerrand zu 
schauen.

>Einfach nur zu meinem Verstaendnis, wie ist dieser Satz zu verstehen:
>"..... genauso fehlerhaft wie deine Pro-32-Bit Liste im selben Beitrag."

Sagte ich oben schon, dass mein Beitrag eine kleine Provokation enthielt 
um mal einen Kontrapunkt zu setzen.

>Wie koennen Fragen falsch sein?

Du hast hier keine reinen Fragen gestellt, sondern damit implizit etwas 
aussagen wollen. Genau wie in folgendem Zitat von dir:

>Andererseits haben sich auch schon viele kleine und mittlere Firmen mit
>der Vielfalt ihrer Architekturen totentwickelt. Warum denkst Du gibt es
>bei allem grossen Firmen starke Bestrebungen die Anzahl der
>Architekturen klein zu halten bzw. sie du reduzieren?

WO lässt du denn hier bitte noch Platz für eine Antwort?

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab lieber den alten Thread benuetzt als einen neuen aufzumachen.

Ab morgen gibt es die Moeglichkeit sich fuer einen Design Wettbewerb 
fuer den LPC1100 einzutragen, es gibt auch einige Gewinne.

Bedingung: Registrieren und eine kurze Beschreibung eines moeglichen 
Projektes. Dann stehen 2000 Platinen mit Tools LPCXpresso zu Verfuegung.
Info ueber den LPC1100 gibts unter anderem hier:
http://mcu-related.com/architectures/35-cortex-m3/92-lpc1100

Die homepage ueber den Design Wettbewerb gibt's hier:
http://www.lpc1100challenge.com/

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.