Da ich immer öfter von ARM und deren Leistung lese und der Preis bezogen
auf die AVR einfach gering ist komme ich nicht rum endlich in die ARM
einzusteigen.
Ich habe schon einiges dazu gelesen(auch solche Threads wie den hier…),
einige Beispielcodes überflogen und die Unterschiede sind deutlich.
Was mich vor allem beschäftigt ist der Stil/Aufbau des Programms.
War es beim AVR noch so dass man dort ein paar SFR setzt und dann mit
Endlosloop und ISR arbeitet – also alles recht hardwarenah und klar -
werde ich bei den ARM von massenhaft structs und Layer über Layer
überrumpelt.
Dieser Post hier drückt es gut aus
http://www.avrfreaks.net/comment/1220586#comment-1220586
Die Frage ist ob dieser „Stil“, der schon ein bisschen an Objekt
Orientierung und „Programmieren auf PC“ erinnert, auf dem ARM im
professionellen/industriellen Bereich mitsamt dieser Hilfsbibs ASF,
CMSIS etc. üblich ist und es mich als Programmierer auf dem höheren
Level einfach nicht mehr interessiert welche Bits da Hardwarenah gesetzt
werden, oder ob das nachlesen im Manual plus händisch setzen der SFRs à
la AVR auch noch üblich/rentabel ist.
F. schrieb:> Die Frage ist ob dieser „Stil“, der schon ein bisschen an Objekt> Orientierung und „Programmieren auf PC“ erinnert, auf dem ARM im> professionellen/industriellen Bereich mitsamt dieser Hilfsbibs ASF,> CMSIS etc. üblich ist und es mich als Programmierer auf dem höheren> Level einfach nicht mehr interessiert welche Bits da Hardwarenah gesetzt> werden, oder ob das nachlesen im Manual plus händisch setzen der SFRs à> la AVR auch noch üblich/rentabel ist.
Hängt allein von deinen Vorlieben ab, du kannst problemlos auf unterster
Ebene hardwarenah programmieren und alle Firmware-Libs ignorieren. Je
nachdem wie gut die Doku dieser Libs ist (oder eben nicht) kann das
sogar günstiger sein.
F. schrieb:> werde ich bei den ARM von massenhaft structs und Layer über Layer> überrumpelt
Das ist erst mal eine "Philosophie" der Hersteller Atmel und ST, bei NXP
und TI sind die Libraries deutlich mehr hardwarenah. Die Atmel M0 sind
mit ASF allerdings kaum nutzbar (zu wenig RAM).
Bei den als "8-bit Replacement" bezeichneten NXP LPC800 ist die direkte
Programmierung ohne Library üblich (schon wegen nicht viel Flash):
// LED on P0_4
DIR0_bit.P0_4 = 1;
PIN0_bit.P0_4 = 1;
Oder direkt ohne Register include:
#define DIR0 0xA0002000
#define PIN0 0xA0002100
// LED on P0_4
*((unsigned long *) DIR0) |= 1<<(4);
*((unsigned long *) PIN0) |= 1<<(4);
Von Objektorientierung kann man bei der CMSIS und den zugehörigen
Firmware-Libraries leider kaum sprechen, da die Kapselung sehr schlecht
umgesetzt ist und man keine ordentliche "Objekt-Identity" hat. (So
braucht man bei ST 3 Variablen mit 3 Typen um 1 Pin zu identifizieren -
warum nicht 1 Typ? - etc.). Die structs sind lediglich ein Mittel um
"named Parameters" umzusetzen, d.h. lange unverständliche
Parameterlisten zu vermeiden.
Es ist möglich, für das Hardware-API vernünftige Objektorientierung
effizient umzusetzen, aber das können die Leute bei ARM, ST & Friends
nicht. Wenigstens die Struktur des eigenen Programms kann man aber
ordentlich machen...
F. schrieb:> Die Frage ist ob dieser „Stil“, der schon ein bisschen an Objekt> Orientierung und „Programmieren auf PC“ erinnert, auf dem ARM im> professionellen/industriellen Bereich mitsamt dieser Hilfsbibs ASF,> CMSIS etc. üblich ist und es mich als Programmierer auf dem höheren> Level einfach nicht mehr interessiert welche Bits da Hardwarenah gesetzt> werden, oder ob das nachlesen im Manual plus händisch setzen der SFRs à> la AVR auch noch üblich/rentabel ist.
1. Nur weil man (der Hobbyprogrammer) es nicht versteht heißt das nicht,
dass es nicht gut ist.
2. 8bit vs. 32bit zu vergleichen ist wie Dreirad und Porsche
3. ARM ist wohl oder übel Marktführer. Angesichts der Milliarden
Stückzahlen die die verkaufen (aka lizenzieren) muss man das erst einmal
toppen. Da Kritik anzubringen ist schwer ... da muss man es schon selbst
besser machen (nicht nur können).
F. schrieb:> werde ich bei den ARM von massenhaft structs und Layer über Layer> überrumpelt.
Ich hoffe du meinst nicht sowas wie die Library von STM. Deren massiv
auf Datenstrukturen basierende Interfaces atmen den Geist von STs 8-Bit
Prozessoren, d.h. deren Umgang mit Registern und Speicher. Sie ist
dadurch wesentlich komplizierter als nötig. Ob sie das Leben erleichtert
oder verkompliziert ist umstritten. Mit Abstraktion und Verkapselung hat
sie jedenfalls wenig zu tun.
Es besteht ein Zusammenhang zwischen Abstraktion und Verkapselung und
der Grösse eines Programms. Nicht aber mit dem Typ des Controllers. Nur
sind manche AVR-Programmierer von Kleinen ins Grosse gewachsen, ohne
einen Sinn für saubere Strukturierung eines Programms zu entwickeln.
Programme mit wenigen KB Grösse sind noch unstrukturiert verkraftbar.
Bei 200KB ist das nicht mehr ratsam.
Das problem ist, dass die ganzen libs zu den ARM geschichten noch recht
jung sind... dementsprechend unausgereift. wie gut die werden, kann nur
die zukunft zeigen.
wenn in der industrie auf diese libs gesetzt wird, ist das eine reine
bauchentscheidung und man setzt darauf, dass diese libs mit dem eigenen
produkt reifen.
ich persoenlich habe auch gaaanz am anfang mit den atmegas gearbeitet
und bin nun bei den stm32f4 gelandet. bei den atemgas konnte ich fast
alles nutzen, was der uC zu bieten hatte und dennoch einen recht guten
überblick darüber behalten, was mein code so treibt. bei den stm32f4
hab ich noch nicht einmal richtig angefangen und verlier schon jetzt
langsam den überblick... auf lange sicht muss das also auf gute libs
hinauslaufen, die das ganze abstrahieren und kapseln.
weil die libs noch so unausgereift sind, hab ich mich also zunächst
dafuer entschieden alles from scratch zu machen... aber in erster linie
wollte ich so den uC besser kennenlernen und dann langsam zu den libs
rüberschwenken (auf die habe ich immer nebenbei ein auge). da der
grundtenor bei den libs aber immer noch recht schlecht ist, beginne ich
nun selber immer mehr layer zu bauen.
hoffe das konnte dir ein bissl vermitteln was auf dich zukommt ;)
123 schrieb:> Nur weil man (der Hobbyprogrammer) es nicht versteht heißt das nicht,> dass es nicht gut ist.
Dieses aufgeblasene unüberschaubare ARM Gestrüpp unzähliger Libs und
Layer, kombiniert mit der Abstraktheit und den unzähligen Kreationen
syntaxüberbordender, kryptischer objektorientierter Sprachen und
vielfältiger Compileroptionen soll gut bzw. die Zukunft sein? Ganz
abgesehen davon was in diesem furchtbaren Gestrüpp an Leistung
hängenbleibt. Dazu diese unendliche Konfiguritis der Chips. AVR und
simples Asm sind dazu der perfekte Gegenentwurf.
> 8bit vs. 32bit zu vergleichen ist wie Dreirad und Porsche
Richtig. Mit dem AVR Porsche ist man eben schneller fertig. Der ARM
Dreiradfahrer kommt hingegen aus der Lernphase nicht raus ;-)
Moby schrieb:> Dieses aufgeblasene unüberschaubare ARM Gestrüpp unzähliger Libs und> Layer,
Von welchen Libs redest du? Was STM liefert, hat erstmal nichts mit ARM
generell zu tun...
> kombiniert mit der Abstraktheit und den unzähligen Kreationen> syntaxüberbordender, kryptischer objektorientierter Sprachen und> vielfältiger Compileroptionen soll gut bzw. die Zukunft sein? Ganz> abgesehen davon was in diesem furchtbaren Gestrüpp an Leistung> hängenbleibt.
Wer OO nicht versteht, wird daran scheitern - richtig.
Abgesehen davon, daß fast alles, wo ARM drin ist, selbst nach etlichen %
Abzug durch verschwendete Leistung immer noch jeden AVR abledert.
> Dazu diese unendliche Konfiguritis der Chips. AVR und> simples Asm sind dazu der perfekte Gegenentwurf.
Kommt vielleicht auch etwas auf die Anwendung an - will ich nur mit ein
paar Pins wackeln, ist AVR sicher schneller am Ziel.
Wenn es mal komplexer wird (USB+Bluetooth+Ethernet...), dreht sich das
sehr schnell wieder um.
Und wenn ich jetzt ein typisches A20-Board mit Linux drauf anschaue als
extremes Gegenteil zum AVR, ist Pinwackeln auch schon wieder genauso
einfach.
Wenn man will, reicht dafür ein Shellscript oder eine kurze Zeile in der
Konsole - läuft ja ein ausgewachsenes Betriebssystem drauf.
Will ich WLAN oder Ethernet oder sonstwas dazu haben - alles fertig.
Klaus Wachtler schrieb:> Kommt vielleicht auch etwas auf die Anwendung an - will ich nur mit ein> paar Pins wackeln, ist AVR sicher schneller am Ziel.
Jetzt will ich das doch mal vergleichen:
AVR:
1
// Pin C3 auf output setzen
2
DDRC|=(1<<3);
3
// Pin C3 auf High setzen
4
PORTC|=(1<<3)
STM32F4:
1
// Pin C3 auf output setzen
2
GPIOC->MODER|=(1<<(3*2));
3
// Pin C3 auf High setzen
4
GPIOC->BSRR=(1<<3);
Also ich sehe keine riesiges Gestrüpp an Libraries, syntaxüberbordender
Objektorientierter Sprachen, Compileroptionen, die so viel Leistung
fressen und meine Brunnen vergiften.
Hi,
wenn du dir nur das Manual nimmst und die CMSIS Headerfiles, dann hast
du dein SFR = xxx - konzept wieder. Dazu packst du noch das startup und
system.c file, und kannst bei main() anfangen.
Die CMSIS macht erstmal nichts anderes als peripheral structs an die
peripheral adressen zu mappen. Das lässt sich etwas einfacher schreiben,
vor allem bei IDE-Features, die dir die struct member zeigen.
Im Grunde ist das aber nix anderes wie die alten #define-s.
Die CMSIS bietet zusätzlich in der core_cm3.h (core_cm4.h, ...) ein paar
Helferlein für den NVIC, dort passiert aber ausser SHIFT&MASK auch keine
grosse Magie. Nur die für einen Anfänger komplexe Programmierung des
NVIC wird dort vereinfacht - ohne weiteren Overhead.
Die Hersteller versuchen mit ihren eigenen APIs alles zu "vereinfachen",
je nach Projekt funktioniert das aber nur bedingt.
Meine persönliche Meinung:
Ich nutze Libraries für RTOS, TCP/IP, Filesystem und USB, sowie startup
und PLL Code, alles andere schreib ich lieber selbst.
VG,
/th.
Dr. Sommer schrieb:> Klaus Wachtler schrieb:>> Kommt vielleicht auch etwas auf die Anwendung an - will ich nur mit ein>> paar Pins wackeln, ist AVR sicher schneller am Ziel.> Jetzt will ich das doch mal vergleichen:
Naja, ehrlicherweise muß man schon zugeben, daß das restliche Programm
drum rum bei einem STM32 größer ist als bei AVR.
Das Setzen des Pins kann z.B. in der Konsole auf einem Cubieboard mit
cubian so aussehen
(https://github.com/cubieplayer/Cubian/wiki/GPIO-Introduction):
1
# vorbereiten:
2
echo 17 > /sys/class/gpio/export
3
echo out > /sys/class/gpio/gpio17_pg9/direction
4
# einschalten:
5
echo 1 > /sys/class/gpio/gpio17_pg9/value
6
# ausschalten:
7
echo 0 > /sys/class/gpio/gpio17_pg9/value
Das wäre auch noch kürzer als die AVR-Version, be ider ja noch ein
kleines Progrämmchen drum rum kommt.
PS: ich will jetzt nicht proagieren, daß man alles in Linux in der
Konsole machen soll.
Eher will ich damit sagen, daß man bei einem AVR typischerweise direkt
am unteren Ende wühlt, während man das bei ARM-Verwandten eher selten
tun wird.
Vielmehr sucht man sich dort eine passende Umgebung (C oder C++ mit
sinnvollen Libs, oder gleich ein echtes OS) und nutzt das dann
entsprechend.
Dann bekommt man wesentlich einfacher zu Funktionen, für die man sich
bei AVR ziemlich verkrampfen muß, oder gar keine Chancen hat.
Ohne zu sagen, was man vorhat, wird man also kaum sagen können, welcher
der beiden Wege besser ist.
Klaus Wachtler schrieb:> Wenn man will, reicht dafür ein Shellscript oder eine kurze Zeile in der> Konsole - läuft ja ein ausgewachsenes Betriebssystem drauf.> Will ich WLAN oder Ethernet oder sonstwas dazu haben - alles fertig.
Haha.
Und Leute die hier im Forum nur "A" vom Arduino sagen, werden
angespuckt. Aber klar, ARM ist jetzt fancy, da kann das ja durchgehen.
> Das Setzen des Pins kann z.B. in der Konsole auf einem Cubieboard mit> cubian so aussehen> ...> Das wäre auch noch kürzer als die AVR-Version, be ider ja noch ein> kleines Progrämmchen drum rum kommt.
Fehler.
Das sieht nur kürzer aus.
Danke für die Meinungen!
sina anargo schrieb:> ich persoenlich habe auch gaaanz am anfang mit den atmegas gearbeitet> und bin nun bei den stm32f4 gelandet. bei den atemgas konnte ich fast> alles nutzen, was der uC zu bieten hatte und dennoch einen recht guten> überblick darüber behalten, was mein code so treibt. bei den stm32f4> hab ich noch nicht einmal richtig angefangen und verlier schon jetzt> langsam den überblick... auf lange sicht muss das also auf gute libs> hinauslaufen, die das ganze abstrahieren und kapseln.
Genau. Die megas lassen sich für einfache Sachen leicht "aus dem Kopf"
programmieren – bevor es zu unübersichtlich wird ist eh der Speicher
alle...
Klaus Wachtler schrieb:> Wenn es mal komplexer wird (USB+Bluetooth+Ethernet...), dreht sich das> sehr schnell wieder um.
Komplexe Projekte rechtfertigen sicherlich eine systematische
Strukturierung, wodurch man die Leistung eines ARM auch gut Auslasten
kann.
Andererseits muss ich für den privaten Hobbybereich nicht unbedingt UML
auspacken, da würde ich den ARM nur als "8-bit Replacement" benutzten
wie es Lothar so schön formuliert hat.
Dass das Bitsetzen ohne struct und libs möglich ist, habe ich jetzt ja
gelernt. Für den Anfang taugt das auch und der Rest kommt per learning
by doing/reading.
F. schrieb:> Die Frage ist ob dieser „Stil“, der schon ein bisschen an Objekt> Orientierung und „Programmieren auf PC“ erinnert, auf dem ARM im> professionellen/industriellen Bereich mitsamt dieser Hilfsbibs ASF,> CMSIS etc. üblich ist.
Ich berichte mal aus meinem persönlichen Arbeitsumfeld:
STM32, IAR EWARM: weisse Ware.
Wir haben unsere Libs selber geschrieben und diese bilden auch das
Schichtenmodell der Firmware ab: ein BSP, das so einfache Sachen macht,
wie z.B. einen ADC Wert einlesen. Darüber eine Lib, die diese
Funktionalität nutzt und anhand von Sensortabellen hieraus z.B. ein
Temperatur in °C liefert. Hierdrauf eine Lib (Schicht), die die
Maschinenprozesse abbildet und sich z.B. die Temperatur holt, um Aktoren
ein/auszuschalten. Darüber main(), das alles zusammenhält. Parallel
hierzu selbstgeschriebene Lib für die Kommunikation zwischen Master und
Slaves und ein RTOS.
Was natürlich nicht heißen soll, dass man es nicht anders machen könnte.
Aber für uns passt das so, da wir so recht generisch sind und flexibel
auf andere HW (Sensorik) reagieren können.
>AVR:>...>STM32F4:>..
Wobei auch das ja nichts mit ARM oder AVR zu hat. Das sind lediglich
Unterschiede in den h-Files, die dem Compiler oder der IDE beiliegen.
Anstatt
GPIOC->BSRR = (1 << 3);
könnte man auch
GPIOC_SET = (1 << 3);
definieren.
Dann reduziert sich das darauf, dass ST (ein Hersteller, der ARM als
Kern benutz), eben extra ein Register für Setzen und eins für Rücksetzen
gebaut hat. Während man bei AVR direkt rein schreibt.
Microchip's C32 hat sogar beide Möglichkeiten, also die des AVR und ARM.
fettarm schrieb:> Das sind lediglich> Unterschiede in den h-Files, die dem Compiler oder der IDE beiliegen.
Auch falsch. Das sind Unterschiede der Library, die der Hersteller
bereitstellt, die eventuell manchen IDE's oder Compilern beiligen
könnten, die man aber auch manuell downloaden & verwenden kann.
fettarm schrieb:> eben extra ein Register für Setzen und eins für Rücksetzen> gebaut hat. Während man bei AVR direkt rein schreibt.
Das geht bei den STM32 aber auch, über das "ODR" register, dass sich
genau wie das "PORTx" Register vom AVR verhält.
Aber darum ging's eigentlich überhaupt nicht. Es ging nur darum zu
zeigen, dass man auch auf den STM32 direkte Register-Zugriffe machen
kann, und dass das nicht wirklich komplizierter als beim AVR ist.
fettarm schrieb:> GPIOC->BSRR = (1 << 3);> GPIOC_SET = (1 << 3);>> definieren.
Schon beim Versuch, in dieser Form GPIOC_RESET zu definieren, fliegst du
bei diesem Versuch der Abstrahierung auf die Nase, denn das sind die
Bits in der oberen Hälfte des o.A. Registers. Die ersten STM32 hatte
noch ein Reset-Register. Spätere nicht mehr.
A. K. schrieb:
> das sind die Bits in der oberen Hälfte des o.A. Registers.
was ja auch wieder nur eine Frage der Header-Files ist. Die Hardware
kann 32- und 16-Bit Zugriffe, also muss GPIOC_RESET 16 Bit breit sein
und schon geht es.
Stimmt. Ich hatte noch die Beschränkung der STM32F1xx im Kopf, deren
GPIO BSRR Register nur wortweise angesprochen werden dürfen. Obacht: Das
BSRR der neueren STM32 ist da eine Ausnahme, die anderen GPIO Register
sind auch da nur wortweise definiert.
Klaus Wachtler schrieb:> Wer OO nicht versteht,
Das leitest Du daraus ab daß ich es für zu komplex, zu
ressourcenfressend, schlicht überflüssig für viele Anwendungen halte ?
Klaus Wachtler schrieb:> nach etlichen %> Abzug durch verschwendete Leistung immer noch jeden AVR abledert
... der den Fall zumeist auch allein gelöst hätte ;-)
Klaus Wachtler schrieb:> will ich nur mit ein> paar Pins wackeln, ist AVR sicher schneller am Ziel
Und bei weitem nicht nur Pinwackeln ;-)
Klaus Wachtler schrieb:> Wenn es mal komplexer wird (USB+Bluetooth+Ethernet...),
Nicht unbedingt. Einige Xmegas haben USB auch schon drin.
Dieser ganze Anwendungs-irrelevante Lowlevel Kommunikationszirkus gehört
sowieso endlich aus dem Arbeitspensum des Programmierers gestrichen und
sollte interne Sache des Controllers sein. Sollen sich ARM & Co. mal in
diese Richtung bewegen statt wie gegenwärtig nur Leistung in OOP
verbraten zu können.
Klaus Wachtler schrieb:> ein typisches A20-Board mit Linux drauf> genauso einfach
Das soll wohl ein Witz sein. Aber stimmt, es soll ja Leute geben die
schwere Linux-Boards als beste Lösung für alle Steuerungsaufgaben sehen
;-)
