Übersicht Controller und Einstiegskosten (Debugger, Compiler)?

GCC und GDB gibt es nur für einige Plattformen. Bei den anderen bekommt 
man für $4,30 auch nur einen eingeschränkten Compiler. Daher die Frage, 
ich habe noch keine Hersteller abgeklappert.

Die Anwendung erfordert <100 kB Programm, <2kB RAM, ein paar UARTs, SPI, 
I2C. Ein integrierter Bootloader (USB) wäre nett, ebenso Mass-Storage 
Host für Updates im Feld, CAN, Ethernet. Kleinserie, <10 Euro der Chip. 
Mehrere Entwickler, daher fallen Compilerlizenzen ins Gewicht. C oder 
C++ wär gut, eine FPU muss nicht sein. Verschlüsselungshardware nice to 
have. RTOS oder embedded linux wäre eine Überlegung wert, damit habe ich 
allerdings noch keine Erfahrung. STM32 sehe ich mir mal an. Danke 
soweit.

Mark T. schrieb:
> Die Wahl eines Prozessors steht an, es muss nicht AVR sein.
> Hat sich schon mal jemand die Mühe gemacht..

Aber ja, ich hab mir für meine Belange schon immer die Mühe gemacht.

Du solltest es auch machen, ich meine, dir die Mühe machen.

Aber zuallererst solltest du dir Klarheit darüber verschaffen, was du 
eigentlich machen willst, was du dafür brauchst, auf welche 
Bezugs-Quellen du zurückgreifen kannst und so weiter.

W.S.

Hallo Peter,

gegen AVRs und GCC habe ich nichts, aber man kann sich ja auch mal 
umhören. Schließlich gibt es wahrscheinlich Controller, die den Anbau 
von viel Peripherie (RAM, Ethernet, CAN, zusätzliche IO und 
Schnittstellen) erübrigen und für gleiches Geld sogar noch mehr bieten.. 
Z.B einen integrierten Bootloader und eben USB.

Einen Debugger möchte ihn nicht mehr missen, aber du machst ja auch 
selten Fehler.. andererseits, bei externen / zeitkritischen Signalen 
nützt er auch nicht soviel.

Grüße

> Die Wahl eines Prozessors steht an, es muss nicht AVR sein.
> Hat sich schon mal jemand die Mühe gemacht, und eine Übersicht aktueller
> Controller und deren Einstiegskosten (Debugger, Compiler) erstellt?
> Es würde mich freuen.

Im Bereich Markt verkauft jemand gerade M16C/29. Wenn du 10Stueck nimmst 
dann bekommst du einen fuer 2Euro.

Das ist ein moderner 16Bit Controller mit folgenden Eigenschaften:

128k Flash, 4k-Dataflash, 12k Ram.
20Mhz Takt, laeuft mit 3.3V oder 5V!

9x Timer
2x UART/SPI
1x UART/SPI/I2C-Bus
1x I2C Multimaster
2x DMA
1x 10Bit AD-Wandler mit 27Eingaengen
1x CAN-Bus
1x CRC Generator

Der Controller kann Programme im Ram ausfuehren und kennt 
Interruptprioritaten. Ein klassischer AVR ist ein Witz dagegen.

Die Entwicklungsumgebung von Renesas (HEW) kannst du einfach so 
runterladen und sie ist dann auf maximal 64kByte Codegroesse 
beschraenkt. Reicht dir das nicht so kannst du dort den gcc 
nachinstallieren.
Solltest du aus irgendwelchen Gruenden die die professionelle 
Vollversion des Renesascompilers kaufen wollen so kostet die 2kEuro. 
(R8C/M16C/M32/R32)

Der PRozessor laesst sich einfach ueber RS232 programieren oder mit 
einem Debugger E8/E8a. Der Debugger, den man nicht unbedingt braucht, 
kostet so 80-160Euro. Abhaengig davon ob man den direkt kauft oder sich 
bei Ebay oder Glyn irgendein billiges Demoboard kauft wo er dabei ist.

Die Nutzung unter Linux ist kein Problem. Sowohl gcc wie auch flasher 
laufen. E8/E8a laeuft unter Linux nicht.

Renesas hat sehr viele und gute Dokumentation und Applikationen. Aber 
man muss die halt auch mal lesen. Leute die immer nur bei anderen 
abschreiben und nichts eigenes zustande bringen sind in Deutschland mit 
AVR besser dran. Renesas hat bis auf ganz wenige exotische Ausnahmen nur 
Controller in SMD. Das mag Anfaenger erstmal abschrecken! Ich wuerde 
aber nichts anderes verwenden wollen.

Olaf

p.s: Ich bin nicht der Verkaeufer, hab mir aber gerade bei ihm 10Stk 
gekauft. .-)

Danke für den Tipp. Renesas hatte ich noch nicht im Blickfeld.

Olaf schrieb:
> 20Mhz Takt, laeuft mit 3.3V oder 5V!

Aber nicht die angebotene V-Version :-)

Mark T. schrieb:
> Renesas hatte ich noch nicht im Blickfeld.

Dann wirf auch einen Blick auf die RX610 bzw. RX621/RX62N.
Es gibt sehr günstige Entwicklungsboards mit Segger J-Link Lite RX 
(Glyn) und ferner HEW (Renesas) und auch GCC (kpit).
Prozessorpreise erhält man bei digikey.de unter dem Suchbegriff RX600.

Hier geht es offenbar um einen "Neueinstieg", es ist also
-außer Wissen- keine nennenswerte HW oder SW da.
Ich würde so vorgehen:

a) Welcher Prozessor erfüllt die gestellten Forderungen am Besten?

b1) Welche Entwicklungstool gibt es dazu, was kosten die?
b2) Wie hoch ist die Chance daß dieser Prozessor, diese
    Prozessorfamilie weiterhin verwendet wird?
b3) Rentiert sich eine teure professionelle Entwicklungs-
    umgebung (Frage b2)?

c)  Kann ich die Kosten aufs Projekt bzw. den Kunden
    verlagern?

d) Welches Budget habe ich also zur Verfügung?

Richtig, a) und b) sind ja der Anlass meiner Frage.

> Aber nicht die angebotene V-Version :-)

STimmt, der laeuft nur von 4.2V bis 5.5V. Aber das ist ja die
Version fuer -40 bis +125Grad.

Ich denke mal wenn man die bei gemuetlicher Zimmertemperatur betreibt 
dann werden sie wohl auch mit 3.3V klar kommen. Wer dagegen ein 
Motorsteuergeraet fuer sein Auto bauen will der sollte aber wohl bei 5V 
bleiben.

BTW: Wer sowas unter Linux nutzen will und ein ld-file fuer den Linker 
braucht der kann sich bei mir melden. .-)

Oh..ein Nachteil will ich nicht verschweigen. Der gcc kommt nicht mit 
den 24Bit Pointern von Reneas klar. Deshalb verwendet er 16bit 
Pointer+Trampolin. Das ist zugegebenermassen etwas aergerlich.

> Dann wirf auch einen Blick auf die RX610 bzw. RX621/RX62N.

Ist das nicht eine etwas andere Liga? Also so fuer Einsteiger jetzt? So 
wegen Anspruechen an Boardlayout, Spannungsversorgung usw? Das sind ja 
gleich sehr dicke Kisten.

Olaf

Mark T. schrieb:
> Die Anwendung erfordert <100 kB Programm

Bei bis zu 100 kB Programm müsstest man bei den AVR schon die ATmega 
nehmen und zu dem Preis bekommt auch schon Cortex-M0 und M3 Controller.


Die Renesas M16C/M32C sind trotz 16 Bit und teilweise höheren Takt im 
Performance Bereich der AVR. Gestern erst einen Regel-Algorithmus 
getestet - Ausführungsdauer skaliert auf 20 MHz Takt:
M32C, gcc -oO, KPIT:               1305,9 µs
ATmega128, gcc -O2, AVRStudio5:    656,75 µs (Achtung: double = float)
Cortex-M3, gcc -O2, Codesourcery:  79,5   µs
Cortex-m3, armcc, -O2, Keil Arm:   49,8   µs

Hinweis: Algorithmus enthält auch float und double Berechnungen u.a. 
sqrtf().
Leider kein open source. AVR nur so schnell, weil dort double nur 32 Bit 
haben und dem float entsprechen.

Soll natürlich: M32C, gcc -02, KPIT heißen!

Olaf schrieb:
> Ist das nicht eine etwas andere Liga? Also so fuer Einsteiger jetzt? So
> wegen Anspruechen an Boardlayout, Spannungsversorgung usw? Das sind ja
> gleich sehr dicke Kisten.

Jein.
Es gibt kleinere Typen ab TQFP64, wenn man auf Vieles verzichten möchte.
Aber selbst im LQFP144 sind die 25er Preise <10€/Stk. und die Leistung 
enorm. Wenn hier Cortex-M3 genannt werden, dann dürfen die RX nicht 
fehlen.

Dann denke ich nicht, dass Mark ein absoluter Anfänger ist.

Daniel schrieb:
> Leider kein open source.

Schade, hätte ich gerne mit RX getestet. Oder, wenn Du eh schon Zugriff 
auf KPIT hast, heute soll es noch Starkregen geben; dann hättest Du 
genug Zeit für einen weiteren Test :-)

> Schade, hätte ich gerne mit RX getestet.

Und ich gerne mal auf nem SH2A. Was uns aber zu einer interessante Frage 
bringt, gibt es eigentlich irgendwo mal einen herstellerunabhaengigen 
Vergleichstest verschiedener Microcontroller? Das waere doch mal ganz 
interessant.

Olaf

Mit 64 Bit Double:
M32C, gcc -O2, KPIT:               1305,90  µs
RX610, gcc -O2, KPIT:               105,00  µs  (mit FPU on)
Cortex-M3, gcc -O2, Codesourcery:    79,50  µs
Cortex-M3, armcc, -O2, Keil Arm:     49,80  µs

Mit 32 Bit Double
ATmega128, gcc -O2, AVRStudio5:     656,75  µs
M32C, gcc -O2, KPIT:                296,90  µs
RX610, gcc -O2, KPIT:                24,90  µs  (mit FPU on)
Cortex-M3, armcc, -O2, Keil Arm:     20,45  µs

Alle mit C99 (armcc --c99, gcc -std=c99), und Gebrauch von inline 
Funktionen.
Skaliert auf 20 Mhz. M32C also doch doppelt so schnell wie AVR.

Die Werte sind nur als Hausnummern zu sehen, da dies kein Benchmark ist.
Bitte keine Diskussion über die Verwendung von double und float. Darüber 
rede ich nur mit Mathematikern. Basta ;-)

Daniel

A. K. schrieb:
> Sehen das meine tränenden Augen richtig? Ein Cortex-M3 mit
> Fliesskommarechnung in Laufzeitfunktionen ist schneller als ein
> Controller mit Hardware-FPU? Oder was soll das "FPU on" heissen?
Richtig, immer vergesse ich die Hälfte hier noch RX610 mit -nofpu Option 
hinzugefügt:

Mit 64 Bit Double:
M32C,      gcc -O2,   KPIT:         1305,90  µs
RX610,     gcc -O2,   KPIT:          222,75  µs  -m64Bit-doubles -nofpu
RX610,     gcc -O2,   KPIT:          105,00  µs  -m64Bit-doubles
Cortex-M3, gcc -O2,   Codesourcery:   79,50  µs
Cortex-M3, armcc -O2, Keil Arm:       49,80  µs

Mit 32 Bit Double
ATmega128, gcc -O2, AVRStudio5:      656,75  µs
M32C,      gcc -O2,   KPIT:          296,90  µs
RX610,     gcc -O2,   KPIT:          284,90  µs  -nofpu
RX610,     gcc -O2,   KPIT:           24,90  µs
Cortex-M3, armcc -O2, Keil Arm:       20,45  µs


64 Bit double schneller als 32 Bit double, wenn -nofpu Option!
Der Code ist C99 kompatibel, ohne Optimierung für die Cotec-M3 Familie. 
Der Code stammt eigentlich aus einer x386 Umgebung.

Am besten schreibt mal jemand einen Benchmark mit Int, float und double 
tests.

Daniel

Die Lib, hier newlib, wurde mit den gleichen Einstellungen 
neu-compiliert. Dies kann man in der HEW IDE einstellen. Bin aber auch 
kein RX600 Profi, heute das erste mal sozusagen. Am besten, wie gesagt, 
einen open source Benchmark schreiben, so dass auch andere Leute 
Ergebnisse beisteuern und evaluieren können.

Liegt wahrscheinlich an den 32 Bit Soft-Routinen der newlib. Die musste 
ich leider wegen C99 benutzen. Beim Keil Compiler sind die soft-floats 
natürlich hoch optimiert (asm).

Daniel

Statt newlib die optimierte Lib verwendet:
RX610, gcc -O2 -std=c99 -m32Bit-doubles, KPIT: 292 Cycles @20 MHz 14,6 
µs
@100 MHz 2,92 µs

Nachtrag: Der Regel-Algo benutzt ja nicht nur Fließkommaberechnungen, so 
dass die FPU hier nicht voll zum tragen kommt.

Daniel schrieb:
> Bin aber auch kein RX600 Profi, heute das erste mal sozusagen.

Ich finde es ganz toll, dass Du Dir die Mühe gemacht hast!
Von Renesas kann man sich auch deren Compiler herunterladen. (Ich will 
jetzt aber nicht frech werden :-)
Soweit ich das sehe, sind die Renesas-Compilate auch besser, weil sie 
speziell für den Zielprozessor den Code erzeugen. GCC kann das nicht 
(voll) leisten; aber bei dessen 'Preis' darf man auch nicht meckern.


Daniel schrieb:
> @100 MHz 2,92 µs

Hier zeigt sich, dass die Testroutine doch zu kurz ist. Andererseits 
sieht man, dass solche Berechnungen auch locker im Interrupt ablaufen 
könnten.

Noch etwas zu GCC: bei 68k und SH Prozessoren setze ich immer die Option 
-fomit-frame-pointer.

> bei 68k und SH Prozessoren setze ich immer die Option
> -fomit-frame-pointer.

Das ist doch der default bei: -O, -O2, -O3, -Os.

Benutzt du keine Optimierung?

Olaf

m.n. schrieb:
> Soweit ich das sehe, sind die Renesas-Compilate auch besser, weil sie
> speziell für den Zielprozessor den Code erzeugen. GCC kann das nicht
> (voll) leisten; aber bei dessen 'Preis' darf man auch nicht meckern.

Man darf allerdings nicht die Librarys vergessen, beim gcc häufig die 
newlib. Bei den Proprietären Produkten sind die Libs meistens speziell 
für den Zielprozessor in asm optimiert.

m.n. schrieb:
> Hier zeigt sich, dass die Testroutine doch zu kurz ist.
Das ist ja auch gar keine Testroutine, ich will ein Modul vom PC auf 
einen Mikrocontroller portieren (deswegen auch float und double) und 
wollte mir erst einmal einen Überblick verschaffen, wie es grob mit der 
Laufzeit aussieht. Der CM3 ist so schnell, dass ich mir die Umwandlung 
in Fixpoint Berechnung locker sparen kann.

Mann könnte ja mal fiese Astronomische Bahnberechnungen durchlaufen 
lassen. Mit sin, atan2, cos...  Werde die Tage mal nach entsprechenden 
Open Source Projekten suchen und dann einen neuen Thread aufmachen. Oder 
hat jemand einen Open Source Benchmark mit floats und doubles?

Olaf schrieb:
> Das ist doch der default bei: -O, -O2, -O3, -Os.

Allgemein kann ich das so nicht bestätigen. Beim H8SX (habe ich gerade 
zu laufen) und GNUH8-V11.01 und -O2 wird ohne zusätzliche Option 
erzeugt:

mov.l  er6,@-er7
mov.l  er7,er6
stm.l  er4-er5,@-er7
sub.l  #40,er7

-fomit-frame-pointer sorgt für:
stm.l  er4-er6,@-er7
sub.l  #36,er7

Das (unnütze) Anlegen eines frampointers frisst merkliche Zeit natürlich 
erst bei vielfachen Funktionsaufrufen. Ich werde die Sache im Auge 
behalten, wenn ich andere CPUs auf dem Tisch habe.

Daniel schrieb:
> Der CM3 ist so schnell, dass ich mir die Umwandlung
> in Fixpoint Berechnung locker sparen kann.

Vielleicht ist Fixpoint durch die Umwandlung sogar langsamer :-)