ARM &Co: EmBitz 2.0 IDE, was wird denn nun draus?

[Christian J. (Gast)]

Moin!

Ich eier immer noch mit der Version 1.1 herum, habe inzwischen das gute 
EBLINK manuell eingebunden statt STLINK, was nicht so ganz einfach war 
und kann nun alle Bluepills brennen mit vollen 128 KB. Der GCC ist von 
2016, wir schreiben das Jahr 2021.

Es basiert immer noch auf den StdPeripheral Libs, die werden automatisch 
erzeugt, seit ca 4-5 Jahren wird aber HAL benutzt, was man manuell 
einbinden muss. Neuere Chips wie den STM32F410xx (Blackpill) einbinden 
ist teilweise ein Drama, never touch the Config Files.

Spielt man sich den aktuellen GCC für ARM ein merkt man schnell, dass 
einiges nicht mehr funktioniert. Das bekannte while(1); nimmt er nicht 
mehr, es muss jetzt heissen while (1){}; Auch die LTO (Link Time 
Optimization) klappt nicht mehr, der erzeugte Code ist zu kurz und 
funktioniert nicht mehr. Die Systick Int Routine hat LTO gleich ganz 
verschluckt, beim Debugg crasht er gleich da mit einer Hardfault 
Exception. Schaltet man LTO ab wird der Code deutlich größer als bei der 
2016er Version vom GCC.

Der Entwickler aus Holland, der das Ding geschrieben hat fleuchte doch 
mal hier herum? Was wird denn nun aus 2.0 was seit gut 3 Jahren 
abgekündigt war? EmBitz ist die wohl beste IDE, die man im Bastelbetrieb 
umsonst kriegen kann.

Christian

[Stefan F. (Gast)]

Christian J. schrieb:
> seit ca 4-5 Jahren wird aber HAL benutzt

Von wem? Ich habe eher den Eindruck dass die HAL ein Werbegag ist.

[Christian J. (Gast)]

Stefan ⛄ F. schrieb:
> Von wem? Ich habe eher den Eindruck dass die HAL ein Werbegag ist.

Darum geht es nicht. In tausenden Code Samples findest du die HAL und 
die ist nunmal Standard. Ich nutze sie auch nicht, weil mit SPL gut 
vertraut aber so ist es nunmal. SPL nutzt keiner mehr.

[Dieter Gräf (Gast)]

Die Middleware für das STM32CubeU5 Firmware Package V1.0.0 sieht 
übrigens so aus:
20.10.2021  21:14    <DIR>          cmsis_rtos_threadx
20.10.2021  21:14    <DIR>          filex
20.10.2021  21:14    <DIR>          levelx
20.10.2021  21:14    <DIR>          netxduo
20.10.2021  21:14    <DIR>          OpenBootloader
20.10.2021  21:14    <DIR>          STM32_Network_Library
20.10.2021  21:14    <DIR>          STM32_TouchSensing_Library
20.10.2021  21:14    <DIR>          STM32_USBPD_Library
20.10.2021  21:14    <DIR>          threadx
20.10.2021  21:14    <DIR>          usbx
Da mach mal was ohne HAL.
Ich bin auf die Mischung CodeBlocks und Cmake umgestiegen weil mit cmake
 -GCodeBlocks direkt ein Projekt auf ninja Basis erzeugt wird. Auch 
debuggen funktioniert. Es fehlt aber die Portregister Anzeige. Dafür 
läuft es aber gut und schnell auf einem Raspberry Pi 400 unter Ubuntu.

[Johannes S. (Gast)]

Auf dem RaspPi kann man auch ccache installieren, dann sollte es richtig 
fix werden. Auf dem PC fegt der g++ damit durch 100 Quellcodedateien / 
Sekunde.
https://snapcraft.io/install/ccache/raspbian
https://ccache.dev/

SPL scheint bei den Chinesen noch beliebt zu sein, zumindest für deren 
eigene STM32 Derivate. Was aber auch nichts daran ändert das es einfach 
veraltet ist.

Zu emBitz würde ich ja mal versuchen den Autor direkt anzumailen. Aber 
so ist das bei One Man Shows, emBitz selber hat er doch afaik nicht 
public gemacht, nur den EBLink Teil. Damit kann auch die Community nicht 
weitermachen. Und auch auf so Erweiterungen wie ccache möchte man nicht 
mehr verzichten wenn man es kennengelernt hat.

[temp (Gast)]

Christian J. schrieb:
> Darum geht es nicht. In tausenden Code Samples findest du die HAL und
> die ist nunmal Standard. Ich nutze sie auch nicht, weil mit SPL gut
> vertraut aber so ist es nunmal. SPL nutzt keiner mehr.

Die Profis die mit Softwareentwicklung Geld verdienen haben besseres zu 
tun als ein paar simpel Libs bei github zu veröffentlichen. Der andere 
Rest denkt HAL/SPL sind überall Standard. Und wenn dann noch Arduino ins 
Spiel kommt, bestehen 90% des Codes auf einem STM aus HAL/SPL und 
Arduino. Klar für die Deppen ist das gut, aber im normalen Leben und bei 
größeren Stückzahlen werden nicht mal die 3 Cent verschenkt die für den 
Flash nötig ist um die HAL/STL Grüze zu speichern.

[Dieter Gräf (Gast)]

Johannes S. schrieb:
> Auf dem RaspPi kann man auch ccache installieren

Danke für den Hinweis. Es funktioniert.

[Dieter Gräf (Gast)]

Es lässt sich übrigens von https://www.embitz.org/ eine
neue Version herunter laden. Leider nicht für Raspberry pi unter aarch64 
Linux.

m. f. G.
Dieter

[Christian J. (Gast)]

Sie ist DAAAAAAAA!ZwoNulllll!

https://www.embitz.org/

[kalender kelander (Gast)]

Christian J. schrieb:
> Sie ist DAAAAAAAA!ZwoNulllll!

Booooaaaaahhhhh eyyyy bist du ein Schnellmerker!
Kaum drei Wochen später hat es schon gecheckt!

https://www.embitz.org/forum/thread-51.html

[Christian J. (Gast)]

Sccchhhhhhtttt! Bei mir stand jemand auf der Leitung.

Erstmal diese ganzen Flash Debug Geschichten hinfrickeln, damit der 
Stick auch wieder spielt...

[Christian J. (Gast)]

Moin!

Inzwischen habe ich das Ding zum Spielen gebracht, auch endlich gibt es 
eine Flash Option.

Problem für den ARM M3 von ST ist allerdings, dass die LTO LInk-Time 
Optimization nicht mehr benutzbar ist. Die scheint etliche Interrupt 
Routinen einfach zu eliminieren. Der Systick Einsprung führt direkt in 
einen Hardfault Error. Oder irgend ein anderer, mein Logger benutzt 
alles was die CPU so hat an Interfaces. Kaum rein gesteppt schmiert er 
schon ab. LTO aus, alles gut.

Da die LTO aber auf 80kb locker mal noch 5KB rausholte ist schade drum.

printf ("-------------------------");

zb taucht oft im Code auf, das wurde zu einem Ausdruck zusammen gefasst. 
Jetzt aber nicht mehr. Und ne Funktion draus machen.... naja, das macht 
das ganze nicht grad lesbarer, sind ein paar tausend Zeilen Code.

Gibt es da einen Work Around?

[Programmierer (Gast)]

temp schrieb:
> aber im normalen Leben und bei größeren Stückzahlen werden nicht mal die
> 3 Cent verschenkt die für den Flash nötig ist um die HAL/STL Grüze zu
> speichern.

Bei uns in der Firma nutzen wir die HAL, und den größten STM32H7 
Controller um uns möglichst einfach zu machen, obwohl wir den vielleicht 
zu 1% nutzen. Bei einer angepeilten Stückzahl von 10 verkauften Anlagen 
im Jahr (jede davon Millionen teuer), spielen die paar Euros keine 
Rolle.

[MS (Gast)]

Christian J. schrieb:
> Spielt man sich den aktuellen GCC für ARM ein merkt man schnell, dass
> einiges nicht mehr funktioniert. Das bekannte while(1); nimmt er nicht
> mehr, es muss jetzt heissen while (1){}; Auch die LTO (Link Time
> Optimization) klappt nicht mehr, der erzeugte Code ist zu kurz und
> funktioniert nicht mehr. Die Systick Int Routine hat LTO gleich ganz
> verschluckt, beim Debugg crasht er gleich da mit einer Hardfault
> Exception. Schaltet man LTO ab wird der Code deutlich größer als bei der
> 2016er Version vom GCC.

Mit Assembler wär das nicht passiert 😉

[Johannes S. (Gast)]

LTO war eigentlich immer in den älteren gcc Versionen schlechter.

[Christian J. (Gast)]

MS schrieb:
> Mit Assembler wär das nicht passiert 😉

Willkommen im Jahre 2021...

[Christian J. (Gast)]

Johannes S. schrieb:
> LTO war eigentlich immer in den älteren gcc Versionen schlechter.

Vorher ging es, jetzt aber nicht mehr. Und ein while(1) geht auch nicht 
mehr, das muss jetzt while(1){}; heissen.

[MS (Gast)]

Christian J. schrieb:
> Willkommen im Jahre 2021...

Das ändert nix daran 😉

[Johannes S. (Gast)]

Christian J. schrieb:
> das muss jetzt while(1){}; heissen.

der Compiler ist mit jeder Version besser geworden was potentielle 
Fehler angeht, und das ist auch gut so. Man sollte sich sowieso 
angewöhnen jeden Block mit {} zu umklammern, auch nach if ... then wenn 
nur eine Zeile folgt. Wenn man da ein Makro hinschreibt kann der 
Programmfluß je nach Makroinhalt geändert werden, ein Fehler an dem man 
auch lange suchen kann.

Und LTO ist wie gesagt besser geworden, aber vielleicht sind jetzt 
Module/Libs beim Linker in anderer Reihenfolge angegeben als vorher, das 
hat auch einen Einfluss.

[Christian J. (Gast)]

MS schrieb:
> Das ändert nix daran 😉

Na dann fang mal an in Assembler... hoffe ich werde noch alt genug das 
dann zu erleben :-)

////////////////////////////////////////////////////////////////////////////////////
/*
    Funktion:   CalcSonnenAufgang()
    Modul   :   rtc_user.c
    --------------------------------------------------------------------------------
    Beschreibung           : Berechnet den Sonnenaufgang und Untergang (auf 5 Minuten genau)

    Zeitgleichung:          WOZ - MOZ = -0.171*sin(0.0337 * T + 0.465) - 0.1299*sin(0.01787 * T - 0.168)
                            Deklination = 0.4095*sin(0.016906*(T-80.086))
                            Zeitdifferenz = 12*arccos((sin(h) - sin(B)*sin(Deklination)) / (cos(B)*cos(Deklination)))/pi;
                            Sonnenaufgang h=-50 Bogenminuten = -0.0145

                            Aufgang Ortszeit = 12 - Zeitdifferenz - Zeitgleichung
                            Untergang Ortszeit = 12 + Zeitdifferenz - Zeitgleichung

                            Aufgang = Aufgang Ortszeit - geographische Länge /15 + Zeitzone
                            Untergang = Untergang Ortszeit - geographische Länge /15 + Zeitzone

*/
////////////////////////////////////////////////////////////////////////////////////

void CalcSonnenAufgang()
{
    #define hoehe   -0.0145     // Sonnenhöhe in RAD
    #define PI      3.14159265359

    double  B,
            Deklination,        // Deklination der Sonne
            Zeitdiff,           // Zeitdifferenz
            DIFF_WOZ_MOZ,
            Aufgang_MOZ,        // Aufgang mittlere Ortzeit
            Untergang_MOZ,      // Aufgang mittlere Ortszeit
            Aufgang_WOZ,        // Aufgang wahre Ortszeit
            Untergang_WOZ;      // Untergang wahre Ortszeit

    B = PI * roGPS->latitude / 180; // Umrechnung in rad;
    int T = RTC_Now.tm_yday;

    Deklination = 0.4095 * sin(0.016906 * (T-80.086));
    Zeitdiff = 12 * acos((sin(hoehe) - sin(B) * sin(Deklination)) / (cos(B) * cos(Deklination))) / PI;
    DIFF_WOZ_MOZ = -0.171 * sin(0.0337 * T + 0.465) - 0.1299 * sin(0.01787 * T - 0.168);    // WOZ-MOZ

    double diff = Zeitdiff - DIFF_WOZ_MOZ;
    Aufgang_MOZ   = 12 - diff;
    Untergang_MOZ = 12 + diff;

    // Sommerzeit berücksichtigen
    int korr = IsSummertime(&RTC_Now) ? (MEZ + SOZ) : MEZ;

    Aufgang_WOZ   = Aufgang_MOZ - roGPS->longtitude/15 + korr;
    Untergang_WOZ = Untergang_MOZ - roGPS->longtitude/15 + korr;

    // Umrechnung in Stunden/Minuten
    DailyData.Sunrise.tm_hour = floor(Aufgang_WOZ);
    DailyData.Sunrise.tm_min  = (Aufgang_WOZ - floor(Aufgang_WOZ)) * 60;
    DailyData.Sunset.tm_hour  = floor(Untergang_WOZ);
    DailyData.Sunset.tm_min   = (Untergang_WOZ - floor(Untergang_WOZ)) * 60;
}

[Bauform B. (bauformb)]

Christian J. schrieb:
> Problem für den ARM M3 von ST ist allerdings, dass die LTO LInk-Time
> Optimization nicht mehr benutzbar ist. Die scheint etliche Interrupt
> Routinen einfach zu eliminieren.

void __attribute__ ((used,aligned (16)))
systick_isr (void)

 hilft auch nicht?

[Christian J. (Gast)]

Bauform B. schrieb:
>> Problem für den ARM M3 von ST ist allerdings, dass die LTO LInk-Time
>> Optimization nicht mehr benutzbar ist. Die scheint etliche Interrupt
>> Routinen einfach zu eliminieren.

Naja, mal testen... wobei ich so rund 10 Ints habe, alle Timer benutzt, 
alle Interfaces, DMA.... und die werden halt von der Vector Table aus 
angesprungen,  die im Startup initialisiert wird nicht aus dem Code 
heraus.

Mal schauen, ausprobieren bringt manche Lösung...

-15kb bringt die auf 80kb ohne LTO jedenfalls.

edit: keine Wirkung! Auch von der Codesize nicht. Das System startet 
nicht mal auf. Ab hier verabschiedet er sich beim Debuggen mit LTO, beim 
ersten Delay, was auf dem Systick basiert.

[Christian J. (Gast)]

Gibt es aber was drüber:

https://stackoverflow.com/questions/53997196/gcc-8-for-arm-in-lto-mode-is-removing-interrupt-handlers-and-weak-functions-ho


Darum geht es
 .weak    \handler_name

Nur wie man das behebt erschließt sich mir noch nicht. Das Thema wurde 
hier auch mal diskutiert, entfernte sich dann aber leider recht schnell 
weg in Fachsimpelei von sich anzickenden Insidern, ohne dass eine Lösung 
entstand. Nur dass es ein Bug ist, das der Linker weak Funktionen, die 
im ASM oder Linker Script stehen ignoriert und weil sie keinen Caller 
haben löscht.

Ab GCC 7 trat das auf, Embitz 1.0 hatte GCC 6
Beitrag "arm gcc 7.2.1 -flto broken?"

Da die F103er aber 128kb nutzbaren Flash haben lasse ich jetzt LTO aus, 
pfeif drauf, ist ja Platz genug da.

[MS (Gast)]

Christian J. schrieb:
> Na dann fang mal an in Assembler

Um den Sonnenaufgang zu berechnen ?
Lächerlich. Sowas löst man in Hardware mit einem simplen Lichtsensor. 
Genauer und aktueller.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

MS schrieb:
> Mit Assembler wär das nicht passiert 😉


MS schrieb:
> Christian J. schrieb:
>> Na dann fang mal an in Assembler
>
> Um den Sonnenaufgang zu berechnen ?
> Lächerlich. Sowas löst man in Hardware mit einem simplen Lichtsensor.
> Genauer und aktueller.

Maulheld.

[Lord Estrich (Gast)]

Hannes J. schrieb:
> Maulheld

Aber es stimmt.