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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 ;-)
@Moby Kannst du nicht woanders trollen? Dein Gesülze geht uns hier auf die E...!!!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.