mikrocontroller.net

Forum: Compiler & IDEs IDE mit Fokus auf Assembler für Umsteiger AVR -> STM32


Autor: Christian K. (christian_knuell)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

bisher habe ich AVRs mit Atmel Studio in Assembler programmiert und 
möchte auf STM32 umsteigen. Momentan experimentiere ich mit einem 
STM32F411RE auf einem Nucleo Board.

- Angetestet habe ich System Workbench, TrueStudio und VisualGDB.
- System Workbench funktioniert so halbwegs für mich, fühlt sich aber 
völlig überladen und zu sehr auf C ausgerichtet an. Außerdem ist es 
ziemlich zickig wenn man viel in den IO Registern / Peripheriemodulen 
des Simulators herumsucht was bei Assembler zum täglich Brot gehört 
(klappt immer wieder den Baum zu, vergisst die Werte...).
- Keil MDK ist preislich völlig jenseits des Budgets und in der 
limitierten Version ist ausgerechnet der Assembler nicht verfügbar.

- Eigentlich benötige ich nur einen ARM Assembler, Simulator und 
Programmiertool in einem übersichtlichen Paket ähnlich wie es das Atmel 
Studio geboten hat.
- Preislich liegt die Schmerzgrenze bei 1000 Euro. Eingeschränkte 
Versionen kommen nur in Frage falls die kommerzielle Nutzung des damit 
erzeugten Codes erlaubt ist.
- Kennt da jemand etwas?

Bei Assembler möchte ich bleiben. Ist im wesentlichen nur eine 
Portierung von einem zum anderen System mit viel zeitkritischem Code 
(CNC Steuerung). Der weniger kritische Rest drum herum ist nicht so wild 
dass es das erlernen von C für mich rechtfertigt (Initialisierung des 
Boards ohne HAL und STM Standard Library rein über Assembler hab ich 
z.B. soweit schon hinbekommen - ist im Endeffekt kein Hexenwerk sobald 
man die Register kennt).

Christian

Autor: Tellerrand Hinausblick (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Christian K. schrieb:
> Bei Assembler möchte ich bleiben.

Wer wird dir die selbstgewählten Scheuklappen abnehmen können?

Wieviel wirst du an Geschwindigkeit gegenüber C Programmierung
gewinnen? Ich postuliere mal einen Daumenpeilwert von 20% max.

Autor: Tellerrand Hinausblick (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Christian K. schrieb:
> zum anderen System mit viel zeitkritischem Code

Bei diesen trägen, lethargischen STM32-Prozessoren muss
man schon höllisch aufpassen dass man nicht zu langsam wird.

Autor: Lama (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Tellerrand Hinausblick schrieb:
> Bei diesen trägen, lethargischen STM32-Prozessoren muss
> man schon höllisch aufpassen dass man nicht zu langsam wird.

Das stimmt allerdings. Deshalb spendieren wir bei uns z.B. jedem STM32 
noch einen Coprozessor (AVR tiny oder PIC, was halt da ist) damit es von 
der Performance her in halbwegs erträgliche Bereiche kommt.

Und gemessen an der Leistung und Ausstattung sind die STM32 auch noch zu 
teuer....  Jetzt aber echt... Bestes Beispiel: STM32F030F4P6

50 ct, eine Frechheit....

:-)

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lama schrieb:
> STM32F030F4P6

Für den gibt es sogar Keils MDK für lau.

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Hallo,

vergleicht mal was der Prozessor nur beim setzen eines Ausgangspins zu 
tun hat.

In Assembler geht die LED des Nucleo Boards z.B. so an:

ldr r0,=0x40020014U
mov r1,#32
str r1,[r0]

Danach schaut euch im Disassembler an was aus
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
wird - da kommen einem die Tränen...
Die Funktion schiebt in einer Schleife das Bit an die richtige Position 
- da gehen zig Takte drauf.

Jetzt kann man natürlich einwenden dass man die Sache auch in C mit 
direktem IO-Zugriff schreiben kann - nur ist man dann im Endeffekt 
wieder bei einem "Assembler auf Steroiden" und bekommt dennoch Overhead 
vom Compiler dazu.

Der F411RE hat 100MHz, der Atmega328 20MHz.
Beide Architekturen setzen einen Großteil der Befehle in einem Takt um.
ARM ist Load / Store Architektur ohne direkten Zugriff auf IO Register.
Der Atmega328 hat IO Zugriff und macht aus den 3 Zeilen Assembler oben 
eine einzige:

sbi PortA,5

Die Takterzeugungsschleife meiner CNC-Steuerung ist mit lauter so Zeug 
voll und hat die wichtigsten Variablen dauerhaft in nur dafür 
vorgesehenen Registern um Speicherzugriffe zu vermeiden was ein C 
Compiler soweit ich weiss niemals machen wird.
Alleine aus dem Grund würde der Atmega auf Assembler dem STM32 mit C / 
HAL schon davonrennen.

Es geht hier nicht um komplexe Sachen wo Hochsprachen ihre Vorteile 
ausspielen können. Der Controller hat nicht mal eine einzige Division 
oder gar Fließkommaberechnungen zu erledigen... Multiplikationen 
beschränken sich auf Shifts...
Ein bisschen Addieren, Subtrahieren, Vergleichen und Bits herumschieben 
- das war es im wesentlichen auch schon - allerdings 160000 mal je 
Sekunde für jede der 3 Achsen (beim Atmega328 auf 16MHz).
Dazu noch etwas serielle Kommunikation und fertig ist die Laube...

Christian

Autor: Tellerrand Hinausblick (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Christian K. schrieb:
> Danach schaut euch im Disassembler an was aus
> HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
> wird - da kommen einem die Tränen...

... und mir kommen die Tränden wenn du einen HAL Code mit
Assembler vergleichst .... keine weiteren Worte notwendig.

Mach nur weiter so und erfülle dir deine selbstgesetzten
Prophezeihungen.

Ich bin dann mal weg.

Autor: Safari (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch noch die SPL, die ist nicht so überladen.

Ein Programm besteht nicht nur aus LED an, LED aus. Sobalds von der 
Hadware-Abstraktion an die Programmlogik geht, ist C ein grosser Schritt 
nach vorn.

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Überzeuge mich...

schreibe in C einen Code der GPIOA Pins 1,2,3 einzeln hintereinander 
setzt, zum Spaß davor jeweils 2 Integer Variablen nach dem Schema A = 
A+B addiert (insgesamt 6 Variablen) und zum Schluss wieder alle Pins 
zurücksetzt.

Stelle den disassemblierten Code hier rein und dann vergleichen wir...
Wenn es weniger als die doppelte Taktzahl benötigt überlege ich es mir 
ernsthaft auf C umzusteigen.

Christian

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na gut, erster Versuch:
void
led (int b)
{
   static int  a, c, e;
   int         d = 2, f = 3;

   GPIOA->BSR = 1;
   a = a + b;
   GPIOA->BSR = 2;
   c = c + d;
   GPIOA->BSR = 4;
   e = e + f;
   GPIOA->BRR = 7;
   return;
}
mit -Os übersetzt:
200023c0:       2301            movs    r3, #1
200023c2:       4a09            ldr     r2, [pc, #36]   ; (200023e8 <led+0x28>)
200023c4:       8313            strh    r3, [r2, #24]
200023c6:       4b09            ldr     r3, [pc, #36]   ; (200023ec <led+0x2c>)
200023c8:       6819            ldr     r1, [r3, #0]
200023ca:       4408            add     r0, r1
200023cc:       2102            movs    r1, #2
200023ce:       6018            str     r0, [r3, #0]
200023d0:       8311            strh    r1, [r2, #24]
200023d2:       6859            ldr     r1, [r3, #4]
200023d4:       3102            adds    r1, #2
200023d6:       6059            str     r1, [r3, #4]
200023d8:       2104            movs    r1, #4
200023da:       8311            strh    r1, [r2, #24]
200023dc:       6899            ldr     r1, [r3, #8]
200023de:       3103            adds    r1, #3
200023e0:       6099            str     r1, [r3, #8]
200023e2:       2307            movs    r3, #7
200023e4:       8353            strh    r3, [r2, #26]
200023e6:       4770            bx      lr
200023e8:       40020000        .word   0x40020000
200023ec:       2001c00c        .word   0x2001c00c
mit -O2 übersetzt:
200024a0:       b4f0            push    {r4, r5, r6, r7}
200024a2:       2101            movs    r1, #1
200024a4:       2702            movs    r7, #2
200024a6:       2604            movs    r6, #4
200024a8:       2507            movs    r5, #7
200024aa:       4a08            ldr     r2, [pc, #32]   ; (200024cc <led+0x2c>)
200024ac:       4b08            ldr     r3, [pc, #32]   ; (200024d0 <led+0x30>)
200024ae:       8311            strh    r1, [r2, #24]
200024b0:       e9d3 4100       ldrd    r4, r1, [r3]
200024b4:       4420            add     r0, r4
200024b6:       19cc            adds    r4, r1, r7
200024b8:       6899            ldr     r1, [r3, #8]
200024ba:       6018            str     r0, [r3, #0]
200024bc:       3103            adds    r1, #3
200024be:       8317            strh    r7, [r2, #24]
200024c0:       8316            strh    r6, [r2, #24]
200024c2:       e9c3 4101       strd    r4, r1, [r3, #4]
200024c6:       8355            strh    r5, [r2, #26]
200024c8:       bcf0            pop     {r4, r5, r6, r7}
200024ca:       4770            bx      lr
200024cc:       40020000        .word   0x40020000
200024d0:       2001c00c        .word   0x2001c00c
200024d4:       ffffffff        .word   0xffffffff
200024d8:       ffffffff        .word   0xffffffff
200024dc:       ffffffff        .word   0xffffffff
aber wie willst du jetzt rausfinden, wie viele Zyklen das sind?

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ldr r0,=0x40020014U
mov r1,#1
str r1,[r0]
add r2,r3
mov r1,#2
str r1,[r0]
add r4,r5
mov r1,#4
str r1,[r0]
add r6,r7
mov r1,#0
str r1,[r0]

Takte zählen ist jetzt in der Tat nicht ganz easy - keine Ahnung ob das 
der Debugger kann. Gehen wir einfach von einem Takt je Befehl aus.

Ich gebe zu: das Ergebnis des Compilers ist definitiv gut (er hat z.B. 
die IO Adresse nicht ständig neu geladen).
Das mit Variablen in Registern halten ohne auf den Speicher zu gehen war 
auch definitiv eine Gemeinheit von mir die nur in begrenztem Umfang 
überhaupt möglich ist. Allerdings eine die ich bei der bisherigen 
Firmware mit 6 Variablen tatsächlich so handhabe, da das in meinem Fall 
viel gebracht hat.

Du hast mich überzeugt C ernsthaft in Erwägung zu ziehen. Könnte auf C 
mit Ausnahme der Hauptberechnungsschleife in Assembler rauslaufen.
Bleibt halt die Frage ob ich wirklich so viel schneller (gutes) C lerne 
als meine (zumindest eingebildet sehr guten) Assemblerkenntnisse von AVR 
auf ARM zu übertragen.

Hat jemand zumindest einen Vorschlag für eine IDE die nicht ganz so viel 
Ballast herumschleppt wie Eclipse?

Christian

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> Hat jemand zumindest einen Vorschlag für eine IDE die nicht ganz so viel
> Ballast herumschleppt wie Eclipse?

QtCreator. Vielleicht kommste dann auch noch zu C++ ...

Autor: Safari (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
emBitz, ultra klein und flott.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Christian K. schrieb:
> Überzeuge mich...
>
> schreibe in C einen Code der GPIOA Pins 1,2,3 einzeln hintereinander
> setzt, zum Spaß davor jeweils 2 Integer Variablen nach dem Schema A =
> A+B addiert (insgesamt 6 Variablen) und zum Schluss wieder alle Pins
> zurücksetzt.
>
> Stelle den disassemblierten Code hier rein und dann vergleichen wir...
> Wenn es weniger als die doppelte Taktzahl benötigt überlege ich es mir
> ernsthaft auf C umzusteigen.
>
> Christian

Du musst unbedingt Dein veraltetes Wissen auffrischen, denn so wie Du 
vorgehst, macht man das heutzutage nicht mehr, denn die Welt hat sich 
bei Mikrocontrollern in den letzten 10...15 Jahren massiv verändert.
Schnell Ports setzen um irgendwelche zeitkritischen Bitmuster 
auszugeben, das macht man definitiv nicht mehr mit I/O Zugriffen aus C 
(oder auch Assembler), sondern lässt dies vom DMA-Controller im 
Hintergrund erledigen, erst recht auf einem STM32, welcher dafür 
optimiert ist.

Die HAL mag etwas umständlich erscheinen, aber die Vorteile überwiegen 
dann doch, bedenkt man die schnellere Entwicklungszeit, die Portabilität 
innerhalb der STM32 Familien, die funktionstüchtigen Codeblöcke für z.B. 
USB, was Du definitiv nicht mehr mit Assembler machen willst...

Autor: Random .. (thorstendb) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich behaupte:
Mit gescheitem C Code und der Verwendung von Intrinsics erzeugt der 
armcc5 besseren Code. Vor allem wegen der hohen Komplexität der ARM 
basierten MCUs.

Bitte keine HAL verwenden, nur CMSIS Header und startup.

: Bearbeitet durch User
Autor: Ähm Bitz (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Random .. schrieb:
> Bitte keine HAL verwenden, nur CMSIS Header und startup.

Das hilft bei Betonköpfen leider nicht.

Zitat eines sarkastischen Arbeitskollegen: "Meine Meinung
steht fest, bitte verwirren sie mich nicht mit Tatsachen."

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Random .. schrieb:
> Bitte keine HAL verwenden, nur CMSIS Header und startup.

Was findest Du nicht gut an der HAL?

Ich finde die HAL zwar auch kein Meisterwerk, aber wie gesagt überwiegen 
für mich dennoch die Vorteile, insbesondere wenn man etwas komplexere 
Projekte hat inkl. FreeRTOS und viele Peripheriemodule verwendet oder 
eine Codebasis, welche für verschiedene Derivate passen soll.
z.B. für Standard I2C musste ich nur noch ca. 3 Zeilen Code mit 
Verwendung der HAL selber schreiben und den Rest hat CubeMX automatisch 
erzeugt; das ging keine 10 Minuten und funktionierte auf Anhieb 
einwandfrei.

Autor: Random .. (thorstendb) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich finde HALs sehr unübersichtlich und meisst zu tief verschachtelt. 
Wenn man sich komplett drauf einlässt, genug Ressourcen (Flash, RAM, 
CPU) hat, und wenig Zeit, kann man sicherlich gut die HALs verwenden. 
Auch für die Portierbarkeit könnte das von Vorteil sein.

Allerdings schreibe ich lieber ohne HAL direkt auf den Registern (ggf. 
mit eigenem Abstraktionslayer), denn schlussendlich muss man oft / 
meisstens doch wieder selbige direkt programmieren, und dann kann man es 
gleich von Anfang an richtig machen. Und man lernt so die MCU und ihre 
Möglichkeiten besser kennen, und kann an kritischen Ecken noch einiges 
rausholen.

Ich verwende trotzdem gerne Libraries für RTX RTOS, TCP/IP, FlashFS, 
Webserver, USB etc.

: Bearbeitet durch User
Autor: STM32_Nutzer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

HAL, CMSIS oder nicht sollte jeder für sein Projekt entscheiden.

Wir benutzen in der Firma maximal CMSIS aber kein HAL, da HAL uns sehr 
viel Codeplatz im Projekt gekostet hat und für uns nicht genug übrig 
war.
Aus Kostengründen konnten wir auch nicht einfach auf einen anderen uC 
umsteigen, da wir schon den größten Flash in diesem Gehöuse benutzt 
haben.

Ausserdem benötigen wir die HAL Features nicht in unseren Anwendungen.

Wir haben auch ausschliesslich sehr zeitkritische Anforderungen 
(Regelung Netzteil am Netz), da macht uns die extra Schicht nur Ärger.

Wer aber solche Anforderungne nicht hat, kann sicher schnell und 
komfortabel ein Projekt mit HAL aufsetzen.

Das ganze hängt einfach von den Anforderungen der Projektes ab ...

Wir benutzen übrigens das TrueStudio von STM -ist ja jetzt offen für 
Alle und Alles- und vor allem kostenlos.

Auch das Debugging mit einem simplen/billigen STLINK (J-Link Software 
von Segger) funktioniert super, ebenso das "Live" mitlesen von 
VAriablen, Registern usw.

Die Taktzyklen kannst Du mit TrueStudio ansehen, diese bietet viele 
Infos nebst Stackusage und sonstigem Speicherverbrauch.

Nochwas zu Assembler/C:
Wir haben viele Jahre die kritischen Dinge in Assembler gemacht (AVR, 
STM8), mit dem STM32, einer intelligenten Nutzung der Features (DMA, ISR 
usw.) machen wir nun keine Optimierung per Assembler mehr. Allerdings 
schauen wir schon mal nach, was beim Compilieren rauskommt (Beispiel: 
256 * A oder A << 8).

LG GM

Autor: Felix F. (wiesel8)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Christian K. schrieb:
> Danach schaut euch im Disassembler an was aus
> HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
> wird - da kommen einem die Tränen...
> Die Funktion schiebt in einer Schleife das Bit an die richtige Position
> - da gehen zig Takte drauf.
>
> Jetzt kann man natürlich einwenden dass man die Sache auch in C mit
> direktem IO-Zugriff schreiben kann - nur ist man dann im Endeffekt
> wieder bei einem "Assembler auf Steroiden" und bekommt dennoch Overhead
> vom Compiler dazu.
>
> Der F411RE hat 100MHz, der Atmega328 20MHz.
> Beide Architekturen setzen einen Großteil der Befehle in einem Takt um.
> ARM ist Load / Store Architektur ohne direkten Zugriff auf IO Register.
> Der Atmega328 hat IO Zugriff und macht aus den 3 Zeilen Assembler oben
> eine einzige:
>
> sbi PortA,5
>
> Die Takterzeugungsschleife meiner CNC-Steuerung ist mit lauter so Zeug
> voll und hat die wichtigsten Variablen dauerhaft in nur dafür
> vorgesehenen Registern um Speicherzugriffe zu vermeiden was ein C
> Compiler soweit ich weiss niemals machen wird.
> Alleine aus dem Grund würde der Atmega auf Assembler dem STM32 mit C /
> HAL schon davonrennen.

Dazu kann ich eine kleine Anekdote erzählen, die ich kürzlich erst 
selbst erlebt habe.
Ich habe ein IC per SPI mit einem F411RE (96 MHz CPU) angesteuert.
Code für das setzen von CS ist folgender:
void Spi_ChipSelect(SPI_TypeDef *SPIx, bool select)
{
    if(select)
    {
        if(SPIx == SPI1)
        {
            GPIO_ResetBits(SPI1_CS_GPIO_PORT, SPI1_CS_PIN);
        }
        else if(SPIx == SPI2)
        {
            GPIO_ResetBits(SPI2_CS_GPIO_PORT, SPI2_CS_PIN);
        }
        else if(SPIx == SPI3)
        {
            GPIO_ResetBits(SPI3_CS_GPIO_PORT, SPI3_CS_PIN);
        }
    }
    else
    {
        if(SPIx == SPI1)
        {
            GPIO_SetBits(SPI1_CS_GPIO_PORT, SPI1_CS_PIN);
        }
        else if(SPIx == SPI2)
        {
            GPIO_SetBits(SPI2_CS_GPIO_PORT, SPI2_CS_PIN);
        }
        else if(SPIx == SPI3)
        {
            GPIO_SetBits(SPI3_CS_GPIO_PORT, SPI3_CS_PIN);
        }
    }
}

Der Ablauf zwischen dem schreiben von 2 Bytes ist dabei folgender:
...
WriteByte()
ChipSelect(false)
VerlasseFunktion()
GeheWiederInFunktion()
ChipSelect(true)
WriteByte()
...

Da dieser Teil aber nicht mehr im Release-Build mit -O2 und LTO 
funktionierte, habe ich es mit dem LogicAnalyzer überprüft und 
festgestellt, dass zwischen den 2 ChipSelects (trotz mehreren 
Funktionssprüngen und Verwendung von SPL) NUR 2 Taktzyklen liegen! Der 
Chip am SPI benötigt aber 3 um zu reagieren.
Möchte mal sehen, ob du das genauso gut optimieren kannst wie der GCC ;)

mfg

Autor: Kai (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Entschuldigung wenn ich das so sage, aber wer heute noch alles in 
Assembler macht der sollte endlich mal in Rente gehen und seine 
Lochkarten mitnehmen.

Versuche mal einen Code von einem 8048 nach 8052 nach AVR nach STM32 zu 
Portieren. Habe ich schon mit einigen Programmen machen dürfen!
Auch macht das jedesmal neu schreien von der selben Routine für jeden 
Prozessor mir absolut keinen Spaß.

ZB. der GCC macht es einem so einfach und ob der nun vereinzelt doppelt 
so lange braucht ist im normal Fall uninteressant bei der 
Systemgeschwindigkeit.

Die HAL ist der letzt Mist die SPL war da wesentlich schöner.
Nur leider nutzen heute die recht viele und machen es damit einem 
schwer.
Wenn man was optimieren muss dann sollte man direkt auf die Register 
zugreifen.

Nimm C, deine Nerven und deine Sozialenkontakte werden es dir danken.

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai schrieb:
> Entschuldigung wenn ich das so sage, aber wer heute noch alles in
> Assembler macht der sollte endlich mal in Rente gehen und seine
> Lochkarten mitnehmen.

Aua... :-))
Ich bin 36 ;-)

> Auch macht das jedesmal neu schreien von der selben Routine für jeden
> Prozessor mir absolut keinen Spaß.

Assembler macht mir wirklich Spaß - vielleicht bin ich da einfach etwas 
"pervers" drauf aber so ist es. Ich verkaufe das Endergebnis zwar auch, 
angefangen hat es allerdings als reines Hobby und ich sehe es immer noch 
mehr als Hobby denn als Broterwerb.

Bei mir ist es einfach umgekehrt - C macht mir keinen Spaß. C ist 
Abstraktion - und ich mache gerne das Gegenteil: alles aufdröseln bis 
ins kleinste Detail. Es macht mir Spaß das letzte Bit auszureizen.
Klar - das ist ein Extrem - produktiv und wirtschaftlich ist es nicht 
unbedingt und dass ich damit in einer Firma nicht durchkommen würde ist 
mir auch klar - muss ich zum Glück nicht.

Wenn ich mir Sachen wie HAL ansehe bekomme ich das kalte Grausen. Kein 
Wunder dass heute alles unter 8-Kerner @4GHz als lahme Kiste angesehen 
wird wenn man heute selbst in Microcontrollern derart mit Ressourcen um 
sich wirft. So manche Taschenlampen App fürs Handy ist größer als mein 
komplettes CAM inclusive Steuerung - das ist das andere Extrem.

Die System Workbench / Eclipse ist auch ein wunderbares Beispiel für das 
Extrem: Programmpakete von hunderten MB / Rechner mit 4 Kernen und 8GB 
am ächzen - und wofür: um ein lausiges LED-Blink Testprogrämmchen in 
Maschinencode zu übersetzen...

Eigentlich wollte ich keinen Programmiersprachenkrieg auslösen - bin 
halt ein bisschen "Old-school".
Ich sehe Eure Punkte durchaus und werde wie oben schon geschrieben C 
ernsthaft in Erwägung ziehen - vielleicht finde ich ja mit der Zeit doch 
Gefallen daran.

Christian

Autor: Kai (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nun ich habe vor 37 Jahren angefangen und kann nur aus meiner Erfahrung 
sprechen.

Ich habe im Prinzip ja nichts gegen Assembler, solange es spezielle 
Funktionen sind.

Ich kenne nur zu gut das ich heute ein Programm schreibe und in X Jahren 
muss ich den Prozessor wechseln. Wenn ich das alles in ASM habe dann 
gute Nacht.
Auch benutze ich teilweise den selben Code auf unterschiedlichen 
Prozessoren.
Port Zugriffe mache ich Hardcore mit Macros (AVR-> PORTA |=1 ### 
STM->PIOA->BSR = 1 ).
So bleibt es immer der selbe Code nur die Hardware ändert sich.
Habe gerade ein Projekt das auf 3 unterschiedlichen Prozessoren laufen 
muss, pflege das mal in ASM.

Wie gesagt HAL ist gut gemeint, SPL ist besser!
Bräuchte die gerade für einen STM32F7, gibt es aber nicht.

Als Editor / IDE gibt es neben den klassikern von IAR & Keil auch 
EmBlitz.
Die Entwicklung kommt zwar gerade nicht vorran aber die aktuelle Version 
ist mehr als brauchbar.
Eclipse und ableger gehen auch, aber wie Du schon sagst überladen und 
langsam.

Fazit:
C ist einfach besser zu pflegen und leichter zu lesen.
Spart am Ende wirklich deine Zeit.

VG Kai

Autor: Random .. (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> Bei mir ist es einfach umgekehrt - C macht mir keinen Spaß. C ist
> Abstraktion - und ich mache gerne das Gegenteil: alles aufdröseln bis
> ins kleinste Detail. Es macht mir Spaß das letzte Bit auszureizen.

> Die System Workbench / Eclipse ist auch ein wunderbares Beispiel für das
> Extrem: Programmpakete von hunderten MB / Rechner mit 4 Kernen und 8GB
> am ächzen - und wofür: um ein lausiges LED-Blink Testprogrämmchen in
> Maschinencode zu übersetzen...

Darum verwende ich MDK-ARM (µVision, ULINK pro) und CMSIS-Headerfiles 
und C. Wenn man sich mit C auf µC auseinandersetzt, und sich dazu noch 
die Compiler-Intrinsics anschaut, kann man verdammt effizient coden.
Allerdings muss man sich dann mit seiner IDE (den Debugmöglichkeiten) 
und der MCU genauestens auseinandersetzen. Und ggf. einfach das Compilat 
anschauen und danach den C Code optimieren.

Ich habe z.B. Teile der TCP/IP Analyse (Antworten, Timeout, Durchsatz, 
Threading, sowie die Weiterverarbeitung und das Buffern von Daten) auf 
einem SAM3X mittels Software LogicAnalyzer (über DWT des Cortex-M3) 
analysiert :-)

.
Btw:
Lädst du dir das SVD file für dein Device, kannst du mittels SVDConv.exe 
(CMSIS Tool) ein kompaktes CMSIS-konformes Headerfile ohne den ganzen 
HAL Kram bauen.

: Bearbeitet durch User
Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai schrieb:
> Wie gesagt HAL ist gut gemeint, SPL ist besser!
> Bräuchte die gerade für einen STM32F7, gibt es aber nicht.

ST hat leider auf ihre C-beschränkte Kundschaft gehört und bietet 
mittlerweile für so gut wie alle Prozessoren und Peripherie alternative 
Treiber names "LL" (low-level) an.

Siehe etwa hier:
http://www.st.com/content/ccc/resource/technical/d...

Im wesentlichen sind das kleine Wrapper auf direkte Register-Zugriffe, 
die jeder vernünftige Compiler wegoptimieren sollte. Das ganze Drumherum 
mit Error-Handling und Status-Abfragen und sonstige HAL-Späße entfallen 
damit.


Was wir natürlich wirklich gebraucht hätten wäre ein vernünftiges C++ 
HAL, aber dafür müsste man halt
a) Tatsächlich platformunabhängige Treiber für seine Kundschaft 
bereitstellen wollen
b) Softwareentwickler einstellen die mehr als nur Register setzen 
können...

Autor: Peter H. (peterhofbauer)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo Christian!

ich wollte ebenfalls vom ATMEGA zum STM32 weil der ATMEGA mir zu langsam 
und auch langweilig wurde.
Habe ein STM32-Board (15 Euro) besorgt und getestet ob es mit Assembler 
noch machbar ist.
Also eine LED zum Blinken habe ich zwar in Assembler hinbekommen. Aber 
dann habe ich die ganze Software für den STM32 vom PC geschmissen und 
das Board verschenkt. Ich musste einsehen: ohne C ist es sinnlos!
Die Dokus für den STM32 ist nur für C ausgelegt und nach meiner Ansicht 
dahingeluscht.

Der PIC32 ist dagegen besser dokumentiert, jedenfalls für Assembler.
Mein Wahlspruch ist: "Eigenes Wissen geht vor fremdes Wissen!"
Und auch deshalb macht mir Assembler mehr Spaß als C. Vor hundert Jahren 
habe ich in Turbo-C programmiert.

Dann bin ich bei den 16-bitter PIC24/dsPIC gelandet und den setze ich 
jetzt immer ein.

Schau Dir mal die Dokus für die dsPIC-Reihe an!

Der Befehlssatz ist Assembler-freundlich und deutlich besser als beim 
ATMEGA. Und sehr gut dokumentiert.
Mit den internen Oszillator benötigen fast alle Befehle mur einen 
34ns-Takt.
Vor allem der Befehlssatz macht den Prozessor schnell.
Mal 2 Beispiele:
Für die Bedienung einer Sprungtabelle benötigt der ATMEGA 14 Befehle, 
beim dsPIC nur einen.
Für die Addition von BCD-Zahlen hatte der 8051 den Befehle daa. Beim 
ATMEGA war dazu ein Unterprogramn mit 100 Befehle nötig. Beim dsPIC ist 
der Befehl wieder vorhanden.
Zum Debuggen / Prorammieren verwende ich den PICkit3 und PICkit3.5. 
Kosten beim CH-Lieferant etwa 10 Euro. Funktionieren beide!
Als IDE verwende ich die alte MPLAB IDE 8.91 Version. Die neuere MPLABX 
habe ich gleich wieder entsorgt.
Den IDE-Editor verwende ich nur beim Debuggen, zum schreiben PSPad.
Der dsPIC ist vor allem für Assembler-Programmierer interessant, 
C-Programmierer merken nichts und werden beim STM32 bleiben.

Gruß Peter

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Was wir natürlich wirklich gebraucht hätten wäre ein vernünftiges C++
> HAL,

gibt es mit mbed, da wirkt nicht nur STM mit.

Zu den IDE:
https://www.rowley.co.uk/arm/index.htm wurden hier schon lange nicht 
mehr genannt, die gibt es aber auch immer noch. Da hatte ich mal mit den 
ARM7TDMI gespielt, das funktionierte da auch auf Anhieb.
Persönlich komme ich mittlwerweile mit den Eclipse basierten gut 
zurecht, man muss für den Start nur mit einem Tutorial anfangen sonst 
sucht man sich die Finger wund.

Autor: Vincent H. (vinci)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Vincent H. schrieb:
>> Was wir natürlich wirklich gebraucht hätten wäre ein vernünftiges C++
>> HAL,
>
> gibt es mit mbed, da wirkt nicht nur STM mit.

Nein mbed ist zu "high-level". Das bedient eher die IoT-Schiene. Ich 
kenn mich damit zwar nicht wirklich aus, aber ich wage zu bezweifeln 
dass ich damit etwa 3x ADCs initialisieren kann, die mir synchron zu 
einem Timer Werte via DMA liefern. Theoretisch spräche aber nichts 
dagegen eine vernünftige C++ Bibliothek anzubieten die genau das kann...

Platformunabhängigkeit definiere ich dabei als "innerhalb einer 
Prozessor-Familie", bzw. "innerhalb eines Herstellers". Dass ich etwa 
Prozessoren von ST und von NXP für mein ADC/Timer Beispiel unter einen 
Hut bekomm halte ich auch für illusorisch. Dazu bietet die jeweilige 
Peripherie zu viele Unterschiede. Aber grad innerhalb einer Firma 
gibts... wwi 2, 3 oder vielleicht 4 verschiedene Timer "Designs". Da wär 
schon ein feines Interface drin.

Autor: Kai (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
OH die STM32 low-level-lib ist mir noch nie untergekommen, gut ich suche 
auch nicht jede Woche danach.
Sieht auf den 1. Blick nach SPL aus, ein Diff wird dann zeigen was Sache 
ist.

Die PIC Teile sind auch nett.
Ein ARM CORTEX M würde ich aber für die meisten Sachen vorziehen.

Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Kai schrieb:
> Versuche mal einen Code von einem 8048 nach 8052 nach AVR nach STM32 zu
> Portieren.

Ich hab das einmal probiert, von P87C751 (abgekündigt) nach ATmega8, 
aber die Befehle sind viel zu unterschiedlich. Was man beim 8051 direkt 
im RAM machen konnte, braucht beim AVR erstmal LD/ST in ein Register. 
Und auch die vielen Bitbefehle hat der AVR nicht.
Auch hatte ich Probleme, mich wieder in die Datenstruktur einzuarbeiten, 
die ich mir damals ausgedacht hatte.
Ich hab dann aufgegeben und es einfach nach C umgeschrieben. Es war gar 
nicht schwer. Probleme bereitete nur der I2C-Multimasterbug. Da muste 
ich für das I2C nach langer Buganalyse noch Timeoutüberwachung mit Retry 
einbauen.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
In C besteht überhaupt eine Chance, ein Programm schmerzfrei auf eine 
andere Plattform zu portieren, in ASM wird das schwierig. Ich bin seit 
einigen Jahren dabei, meinen eigenen HAL zu entwickeln, aber 
letztendlich wird das eher eine unendliche Geschichte...
Das geht schon bei den Headerfiles los, die man auf einen gemeinsamen 
Standard hieven muss, um überhaupt die Übersicht zu behalten. Bei 
manchen Controllern (z.B. Renesas RL78) bleibt sogar nichts anderes 
übrig, als die Files aus den Datenblättern zu erstellen, da deren IDE 
ein "exotisches" Binärformat für die Registerdefinitionen nutzt. Und 
dann geht es weiter: Welchen gemeinsamen Nenner zwischen den 
Controllerfamilien gibt es, mit dem man praktisch noch etwas anfangen 
kann? Und es geht noch weiter: Welchen Compiler kann ich benutzen? Für 
viele Plattformen gibt es den GCC, bei manchen ist die letzte Version 
schon ein paar Jahre her (HCS12, MSP430), andere wiederum werden nur vom 
SDCC unterstützt. Kommerzielle Compiler habe ich dabei außer Acht 
gelassen, da es die meist nur für Windows gibt und damit für mich nicht 
relevant sind. Aber auch beim GCC musste ich irgendwann einen Stand 
"einfrieren" (4.92).


Die Portpin-Routinen z.B. habe ich meist in ASM geschrieben, für den 
STM32F0xxx sehen bei mir dann so aus:
//------------------------------------------------------------------------
// set Portpin level
// PAR1 (int)  PORT Nr
// PAR2 (int)  PIN Nr
// PAR3 (int)   level
//------------------------------------------------------------------------
set_portpin_level:  cmp  r2,#0
      bne  set_portpin_one

set_portpin_zero:  movs  r2,#1
      lsls  r2,r1
      str  r2,[r0,#0x28]    //BRR
      bx  lr


set_portpin_one:  movs  r2,#1
      lsls  r2,r1
      str  r2,[r0,#0x18]    //BSRR
      bx  lr

Wobei die PORT Nr eine Konstante aus dem Chip-spezifischen Headerfile 
ist. Um einen Portpin als Output zu setzen, wird es schon aufwändiger, 
da man den Port auch im RCC aktivieren muss. Aber in den meisten Fällen 
macht man das einmal am Programmanfang.

Von den Chipherstellern darf man letztendlich in der Richtung sowieso 
nichts erwarten, denen geht es mehr darum, die Kunden möglichst fest an 
sich zu binden. Das wäre ja noch schöner, wenn man seine Projekte 
einfach auf einen Controller der Konkurrenz portieren kann.

Und nach meinen Erfahrungen, das ist wirklich schön...

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.

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