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
4 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
4 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
5 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
-3 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
3 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
4 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
0 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...

Beitrag #5465822 wurde von einem Moderator gelöscht.
Autor: dfggfbh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> 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...

hat sich eigentlich jemand von euch schon mal
https://modm.io/
angeschaut? Mir fehlts da leider an c++-Kentnissen ums wirklich bewerten 
zu können, aber auf den ersten Blick sieht es nach einem guten Ansatz 
aus.

Autor: Dr.Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> 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 ;-)

Mal ganz nüchtern betrachtet:
Ich bin 36 - sagt eigentlich Ggarnichts wenn jemand vom "Werner Syndrom" 
geplagt ist, ist er biologisch schon längst über die Sechzig :-(
Das betrifft dann auch das Cerebrum.
Das ist jetzt keine Unterstellung sondern vieleicht eine Erklärung.
(und der TO weiß noch gar nichts davon :-(

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr.Werner schrieb:
> Mal ganz nüchtern betrachtet:
> Ich bin 36 - sagt eigentlich Ggarnichts wenn jemand vom "Werner Syndrom"
> geplagt ist, ist er biologisch schon längst über die Sechzig :-(
> Das betrifft dann auch das Cerebrum.
> Das ist jetzt keine Unterstellung sondern vieleicht eine Erklärung.
> (und der TO weiß noch gar nichts davon :-(

Na komm... Ich hätte mir denken sollen dass das Thema alle Zutaten eines 
Religionskrieges C / ASM beinhaltet - auf der Ebene müsse wir jetzt 
allerdings nicht diskutieren.

Ich wollte einen Assembler für ARM ohne Schnickschnack...
Gibt es scheinbar nicht -> Schade aber kann man nichts machen...
Hinweis auf C als Alternative -> ist berechtigt...

Mein momentanes Fazit ist: C wäre zu viel Zeitverlust.
Nicht im Sinne von Prozessortakten - da habt ihr mich überzeugt, sondern 
im Sinne von: müsste ich erst von Grund auf lernen UND gut darin werden.

Bleibt also erst mal alles bei AVR / Assembler.
Leistung ist bisher ausreichend und wenn in Zukunft mehr benötigt wird 
gibt es immer noch die assemblerfreundlichen Xmegas mit 32Mhz, Events, 
DMA und vielen Timern.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> Ich wollte einen Assembler für ARM ohne Schnickschnack...
> Gibt es scheinbar nicht

Was spricht gegen den ARM-Assembler von ARM selbst? Oder den vom GCC? 
Verstehst du unter einem Linker Schnickschnack?

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der blanke Assembler selbst hat keinen zur Peripherie passenden 
Simulator.
Man kann zwar den Code an sich debuggen, befindet sich allerdings in 
Bezug darauf was z.B. UART oder Timer gerade machen völlig im Blindflug.

Das ist das schöne an AVR Studio Assembler:

- Schlanke und sehr schnelle IDE. Ein Built ist in sekundenbruchteilen 
abgeschlossen und der Simulator läuft.

- Alles wichtige vorkonfiguriert und nahtlos eingebunden. Neues Projekt 
-> verwendeten AVR auswählen -> Assembler auswählen -> alles fix und 
fertig konfiguriert (der Controller an sich aber noch blank ohne 
irgendwelche Abstrahierungsmonstren a la HAL).

- Ein guter und übersichtlicher Simulator incl. aller Peripheriemodule.

Alles vorhanden was (für meine Zwecke) benötigt wird und einem das Leben 
erleichtert - ohne viel darüber hinaus gehenden Schnickschnack. Passt 
einfach - hatte mich damals sofort überzeugt während ich in Bezug auf 
ARM jetzt seit Wochen X Programme von kostenlos bis 8000 Euro getestet 
habe von denen mir bisher keines auch nur halbwegs gefallen hat.
Die mögen vielleicht für abstraktere und komplexere Projekte ganz toll 
sein wenn man sich drauf einlässt oder lassen muss. Für meine Zwecke mit 
eigentlich gar nicht sonderlich komplizierter nur recht hardwarenaher 
Aufgabenstellung war allerdings einfach nichts dabei.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> Das ist das schöne an AVR Studio Assembler:
>
> - Schlanke und sehr schnelle IDE. Ein Built ist in sekundenbruchteilen
> abgeschlossen und der Simulator läuft.

Was hat die IDE mit dem Assembler zu tun? ARM Assembler sind genau so 
schnell.

Christian K. schrieb:
> - Alles wichtige vorkonfiguriert und nahtlos eingebunden. Neues Projekt
> -> verwendeten AVR auswählen -> Assembler auswählen -> alles fix und
> fertig konfiguriert.
Ja, bei den AVR's ist das einfach. Bei der gigantischen Menge an 
existierenden verschiedenen ARM Cortex-M ist das komplizierter 
umzusetzen. Aber bei IDE's wie dem Atollic Studio geht das auch.

Christian K. schrieb:
> - Ein guter und übersichtlicher Simulator incl. aller Peripheriemodule.
Bei der komplexen Peripherie der Cortex-M ist so etwas halt schwierig. 
Aber m.W. hat Keil µVision einen Simulator. Aber der Simulator hat 
natürlich auch nichts mit dem Assembler zu tun, genau so wenig wie ein 
Schraubenzieher mit einer Säge zu tun hat. Dank JTAG-Debuggings ist der 
Simulator auch deutlich weniger wichtig.

Christian K. schrieb:
> Für meine Zwecke mit
> eigentlich gar nicht sonderlich komplizierter nur recht hardwarenaher
> Aufgabenstellung war allerdings einfach nichts dabei.
Man kann nicht alles haben... Mit ein wenig Einarbeitung sollte man mit 
den vorhandenen IDE's klarkommen.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> (der Controller an sich aber noch blank ohne
> irgendwelche Abstrahierungsmonstren a la HAL).

Will halt kaum einer. Kann man aber auch problemlos haben. Wenn du schon 
deine Arbeitszeit durch Assembler verfünffachst macht das Deaktivieren 
der HAL doch auch keinen Unterschied mehr...

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Was hat die IDE mit dem Assembler zu tun? ARM Assembler sind genau so
> schnell.

Sehr viel wenn die IDE drum herum das gesamte System einbremst. Bringt 
nun mal nichts wenn der Assembler selbst in ner halben µs fertig ist, 
das Framework den Computer anschließend aber noch 15 Sekunden blockiert 
bevor man mit irgendwas weitermachen kann.
Klar... kann und muss man bei kostenlosen IDEs verschmerzen - dass es 
nervt und eigentlich ne schwache Leistung ist wirst du mir allerdings 
sicherlich zustimmen.

Google bringt bei "Eclipse slow" 33 Millionen! Treffer.
Scheint nicht nur an meiner "alternden" Geduld zu liegen ;-)

> Bei der komplexen Peripherie der Cortex-M ist so etwas halt schwierig.

Ja und nein...
Bezogen auf ARM im allgemeinen und herstellerübergreifend gebe ich dir 
völlig Recht.
In Bezug auf STM32 konkret sehe ich es anders.
Die Peripherie dieser Prozessoren ist so besonders nun auch wieder 
nicht. Die AVR Xmegas haben ähnlich komplexe Peripherie und werden vom 
AVR Studio Simulator vorbildlich unterstützt (Xmega wie gesagt - nicht 
nur die erheblich einfacheren Megas).
Ich habe einige Stunden Datenblätter gelesen und mich ständig an die 
Xmegas erinnert gefühlt. Andere Registernamen, andere Bits, oft ein paar 
Zusatzfeatures, doch im Endeffekt keine weltbewegenden Unterschiede.

Fazit: Atmel hat seit Jahren genau die Kombi Assembler / Simulator die 
ich schätzen gelernt habe - deswegen habe ich in meinem Eingangsposting 
auch ausdrücklich "Simulator" dazugeschrieben.

Für STM32 gibt es das scheinbar nicht - kein Vorwurf, nur eine 
Feststellung und für mich natürlich doof wenn ich gewohnt bin intensiv 
mit Simulator zu arbeiten.

> Aber m.W. hat Keil µVision einen Simulator. Aber der Simulator hat
> natürlich auch nichts mit dem Assembler zu tun, genau so wenig wie ein
> Schraubenzieher mit einer Säge zu tun hat.

Wenn du z.B. einen Webserver schreibst ist das in der Tat ziemlich egal 
- da ist die Hardware nur Beiwerk und wird zu Recht von Sachen wie HAL 
oder Standard Library erschlagen. Bei Entwicklungen die sich zentral um 
die Hardware drehen ist ein Simulator allerdings sehr hilfreich auch 
wenn er mit dem Assembler an sich wenig zu tun hat.

Jetzt C lernen und dann auch noch die Peripherie im Blindflug oder nur 
direkt am Board debuggen zu können ist mir echt zu viel. Nicht alles 
lässt sich am Board ohne weiteres real ohne größeren Aufwand auslösen 
was im Simulator ein paar Klicks sind.

Mein Fazit aus der Diskussion ist bisher dass STM32 und AVR für 
verschiedene Anwendungen vorgesehen sind. STM32 scheint mir für 
komplexere Sachen vorgesehen zu sein wo die Hardwareseite von 
Firmwarepaketen gehandhabtes Beiwerk ist so dass man sich auf anderes 
konzentrieren kann. Hardwareseitiges dann eher als Beifang weil man die 
Plattform halt kennt und das Preis / Leistungsverhältnis so extrem gut 
ist dass man einfach nen schnelleren Typ wählt und bei HAL bleibt.

AVR dagegen die sehr hardwarenahe "bare metal" Seite.
Merkt man auch in den Datenblättern und Appnotes -> Beispiele kommen 
zuerst in Assembler, dann in C. Manchmal auch nur in Assembler...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> Bringt nun mal nichts wenn der Assembler selbst in ner halben µs fertig
> ist, das Framework den Computer anschließend aber noch 15 Sekunden
> blockiert bevor man mit irgendwas weitermachen kann

Das ist mir noch nie untergekommen. Eclipse kompiliert bei mir in ca 
100ms mehrere C, C++ und Assembler Dateien.

Christian K. schrieb:
> Für STM32 gibt es das scheinbar nicht

Doch. Im Keil uVision.

Christian K. schrieb:
> Bei Entwicklungen die sich zentral um die Hardware drehen ist ein
> Simulator allerdings sehr hilfreich auch wenn er mit dem Assembler an
> sich wenig zu tun hat.

Ich hab schon jede Menge Low Level Treiber ohne Simulator, mithilfe des 
Debuggers, geschrieben. Hat meistens gut funktioniert. Problematisch 
sind nur die Dinge, die nicht dokumentiert sind. Die sind aber im 
Simulator bestimmt auch nicht korrekt umgesetzt.

Gerade arbeite ich z.B. mit einem Cortex-A8 Bare Metal,  der ist noch 
viel komplexer als die STM32. Da ist eine Menge Assembler sogar nötig 
zur Steuerung der MMU bzw. VMSA. Das geht supi in Eclipse unter Linux 
mit GCC und GNU Assembler.

Autor: Christian K. (christian_knuell)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Doch. Im Keil uVision.

Keil hatte ich ausprobiert und hat auch den besten Eindruck gemacht.
Nur wie schon geschrieben:

- Keil MDK ist preislich völlig jenseits des Budgets und in der
limitierten Version ist ausgerechnet der Assembler nicht verfügbar.

Wäre nur dann ein Kandidat falls ich doch irgendwann C lerne und die 
limitierte Version kommerziell genutzt werden darf. Wäre dennoch ein 
risky move sich von derart hochpreisiger Software abhängig zu machen. 
Wenn das kostenlose Angebot irgendwann eingestellt wird und z.B. nach 
einem PC-Wechsel keine Aktivierung mehr möglich ist hätte ich ein 
ernsthaftes und teures Problem.

Für mich ist das Thema erst mal weitgehend erledigt.
Meine Hoffnung war von der sehr einfachen und komfortablen AVR Assembler 
 Simulator Kombi zu einer ähnlichen Assembler  Simulator Kombi für 
STM32 wechseln zu können ohne dabei eine neue Programmiersprache lernen 
zu müssen oder mehrere tausend Euros los zu werden.

Hat sich als falsche Vorstellung herausgestellt, ist allerdings nicht 
weiter tragisch, da die Leistung der AVRs genügt und mit den Xmegas noch 
gut Luft nach oben ist.

Generell zum Thema ASM / C oder sonstige Programmiersprachen:

- Jeder hat sein Steckenpferd das er toll findet - meist die Sprache die 
man halt mehr oder weniger zufällig gelernt hat ;-)

- Ich teile Programmiersprachen weniger in "gut" oder "schlecht", 
sondern in "zweckmäßig" und "unzweckmäßig" ein.
Zu zweckmäßig gehört allerdings nicht nur die objektive Eignung einer 
Sprache für den konkreten Einsatzfall, sondern auch ob und wie gut man 
sie beherrscht.

- Wenn ich 2 Sprachen habe von denen ich eine sehr gut beherrsche und 
die andere gar nicht ist letztere zwangsläufig erst mal sehr 
unzweckmäßig, egal wie gut sie zur Aufgabenstellung an und für sich 
passen mag. Bringt nichts wenn man erst mal ein Jahr mit lernen und üben 
verbringt bevor man an die eigentliche Aufgabe ran kann.
Hat weniger mit Faulheit oder Weigerung über den Tellerrand zu blicken 
zu tun als einfach damit dass der Tag nur 24 Stunden hat und es auch 
noch andere Dinge als Programmieren gibt.

(Schadet natürlich dennoch nicht sich mit der Sprache später zu befassen 
wenn es Zeit und Lust erlauben)

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> Keil MDK ist preislich völlig jenseits des Budgets und in der
> limitierten Version ist ausgerechnet der Assembler nicht verfügbar.

Ich rede von uVision.  Da gibt's ne gratis Version von (bis 32kB wimre). 
Und die kann natürlich assemblieren und Debuggen.  habe ich schon 
genutzt. Wie eine IDE ohne Assembler funktionieren soll ist eh 
schleierhaft - wie soll da der vom Compiler generierte Code assembliert 
werden? Und der Startup Code?
Wenn du das kommerziell nutzen willst hast du doch Geld. Da deine 
Arbeitszeit auch nicht so wichtig ist scheint Wirtschaftlichkeit eh egal 
zu sein. Würde es wirklich um Geld gehen könntest du mit Eclipse&GCC 
eine auch kommerziell nutzbare komplett kostenlose Umgebung haben, in 
der du in C und C++ auch noch viel schneller an Ergebnisse kommst. So 
kannst du dir nach den nächsten 3 Aufträgen fix eine heiß geliebte 
Assembler IDE in Vollversion leisten...

Was für Kunden sind das, die Projekte in Auftrag geben die man mit AVR's 
erledigen kann und die bereit sind das Geld für eine Assembler 
Entwicklung auszugeben? Gibt's da keinen Preiskampf und Konkurrenz?

Autor: Felix F. (wiesel8)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Christian K. schrieb:
> - Ein guter und übersichtlicher Simulator incl. aller Peripheriemodule.

Frage: Wieso benötigst du einen Simulator? Ich kann mit dem Debugger 
sämtliche Register direkt an der Hardware auslesen (ohne der 
Wahrscheinlichkeit eines Fehlers durch einen Simulator Bug) und 
gleichzeitig überprüfen, ob die Hardware macht, was ich will. Da scheint 
mir ein Simulator eher kontraproduktiv.

mfg

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Christian K. schrieb:
> Google bringt bei "Eclipse slow" 33 Millionen! Treffer.
> Scheint nicht nur an meiner "alternden" Geduld zu liegen ;-)

Es scheint eher an Deinem mittelalterlichen PC zu liegen. Meiner ist nur 
5 Jahre alt und ich kann bei Eclipse keinen einzigen Vorgang bemerken 
(außer dem Start am Morgen [6 Sekunden]) der länger als ein 
Augenzwinkern benötigt.

Wenn bei Dir das Kompilieren 15s länger dauert als ohne IDE dann steckst 
Du entweder in einer üblen Zeitverzerrungs-Anomalie fest (bekommst Du 
schon graue Haare während alle anderen noch jung aussehen?) oder 
irgendwas anderes an Deinem Setup schreit nach dringender Erneuerung.

: Bearbeitet durch User
Autor: Til S. (Firma: SEGGER) (til_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian K. schrieb:
> Für mich ist das Thema erst mal weitgehend erledigt.
> Meine Hoffnung war von der sehr einfachen und komfortablen AVR Assembler
>  Simulator Kombi zu einer ähnlichen Assembler  Simulator Kombi für
> STM32 wechseln zu können ohne dabei eine neue Programmiersprache lernen
> zu müssen oder mehrere tausend Euros los zu werden.

Hast du dir schon Embedded Studio und Ozone angeschaut?

Embedded Studio sollte alles können, was du dir wünschst und liegt in 
deinem Preisrahmen:
https://www.segger.com/products/development-tools/...

Ozone ist ein reiner Debugger:
https://www.segger.com/products/development-tools/...

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Til S. schrieb:
> Embedded Studio sollte alles können, was du dir wünschst und liegt in
> deinem Preisrahmen

Aber auch nur, wenn er denn schon einen J-Link hat oder dessen Preis 
unter den Tisch fallen lässt.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Aber auch nur, wenn er denn schon einen J-Link hat oder dessen Preis
> unter den Tisch fallen lässt.

Früher oder später hat jeder einen J-Link. Man kann den Vorteilen nicht 
für immer widerstehen, irgendwann hat man einen schwachen Moment, der 
Widerstand bricht zusammen, dann hat man einen.

Autor: Dr.Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> (bekommst Du schon graue Haare während alle anderen noch jung aussehen?)
> oder irgendwas anderes an Deinem Setup schreit nach dringender
> Erneuerung.

Sagte ich doch: Den armen Mann plagt das "Werner" Syndrom. Eigendlich 
sollten wir den armen Kerl helfen seinen "Prozess" so angenehm wie 
möglich zu gestalten. ;-)

Autor: Michael F. (michaelfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Felix F. schrieb:
> Frage: Wieso benötigst du einen Simulator? Ich kann mit dem Debugger
> sämtliche Register direkt an der Hardware auslesen (ohne der
> Wahrscheinlichkeit eines Fehlers durch einen Simulator Bug) und
> gleichzeitig überprüfen, ob die Hardware macht, was ich will. Da scheint
> mir ein Simulator eher kontraproduktiv.

Du kannst aber mit einem Simulator Dinge in der Hardware sehen, an die 
kein Debugger kommt...

z.B. kann der Simulator der Embedded Workbench auch bei einem 
Cortex-M0(+) (oder AVR oder ...) ordentliches ETM Trace, was in Hardware 
an den fehlenden Trace-Pins und der nicht implementierten ETM Unit 
scheitert ;-)

Autor: Karl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andererseits, wer nutzt noch einiger Erfahrung den Simu noch? Am Anfang 
hab ich den auch verwendet, aber inzwischen seit Jahren nicht mehr.

Meist scheitert es daran, dass der Aufwand komplexe Signalverläufe für 
die Simu zu generieren größer ist als das Ding einfach in Echtzeit zu 
beobachten und an entscheidenden Stellen Debug Infos über Uart, Display, 
Oszi oder blinkende LED auszugeben.

Autor: Til S. (Firma: SEGGER) (til_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Aber auch nur, wenn er denn schon einen J-Link hat oder dessen Preis
> unter den Tisch fallen lässt.

Nicht unbedingt, es ging ja um ein Nucleo Board mit ST-Link OB, das kann 
man in einen J-Link umflashen. Aber ansonsten hast du natürlich Recht, 
das sollte man mit erwähnen.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Früher oder später hat jeder einen J-Link...

...in der Schublade herumsedimentieren.

Ja, ich auch (edu), dazu nen ULink (klasse Briefbeschwerer) und diverse 
auf Evalboards aufgelötete Teile. Auch die sedimentieren so vor sich 
hin.

W.S.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> ...in der Schublade herumsedimentieren.

Tut mir Leid für dich, dass du dein Hobby nicht ausüben kannst. Keine 
Zeit? Familie? Zu viel Stress im Beruf?

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.