Tutorial ARM Embedded

[Mathias]

Ich habe mal einen Anfang gewagt und ein Tutorial für den ARM Ebedded begonnen.

http://wiki.freepascal.org/ARM_Embedded_Tutorial/de

Dank mse Hilfe bin ich soweit gekommen, das man es der Öffentlichkeit vorstellen kann. Man sollt das Wissen weitergeben.

Das Tutorial ist natürlich noch in einem Anfangsstadium. Daher bin ich froh, wen jemand einen Fehler sieht und dies mitteilt.

[mse]

Ich würde in
http://wiki.freepascal.org/AVR_Embedded ... 2/de#Linux
einen testweisen Aufruf von "st-util" anfügen damit
https://github.com/texane/stlink/issues/700
bereits auskommt.
Bei
http://wiki.freepascal.org/AVR_Embedded ... und_MSEgui
fehlt das Setzen von 'Settings'-'Configure MSEide'-'${MSEDIR}' (Punkt 5. von MSEide+MSEgui README.TXT).

[Mathias]

Ich würde in
http://wiki.freepascal.org/AVR_Embedded ... 2/de#Linux
einen testweisen Aufruf von "st-util" anfügen damit
https://github.com/texane/stlink/issues/700
bereits auskommt.

Dann habe ich folgende Ausgabe:

Code: Alles auswählen

$ st-util -n
st-util 1.5.0
2018-04-13T16:37:20 INFO common.c: Loading device parameters....
2018-04-13T16:37:20 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-04-13T16:37:20 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-04-13T16:37:20 INFO gdb-server.c: Chip ID is 00000410, Core ID is  1ba01477.
2018-04-13T16:37:20 INFO gdb-server.c: Listening at *:4242...

Das Programm auf dem STM32 wird angehalten. Erst wen ich Ctrl-C drücke, komme ich wieder in die Konsole zurück und der STM32 läuft wieder weiter.
Jetzt weis ich wenigsten, das mein STM32 64KB Flash besitzt.

Bei
http://wiki.freepascal.org/AVR_Embedded ... und_MSEgui
fehlt das Setzen von 'Settings'-'Configure MSEide'-'${MSEDIR}' (Punkt 5. von MSEide+MSEgui README.TXT).

Bei mir ist das der Pfad schon eingetragen. ( /home/tux/STM32-FPC/msegui/ )
Nur weis ich nicht, ob ich das gemacht habe, oder ob dies automatisch geschehen ist.
Ich habe mal die Datei .mseide/mseideli mal gesichert und gelöscht, jetzt ist der Eintrag weg. Auch die Syntaxhiglight ist weg.

[mse]

Code: Alles auswählen

$ st-util -n
st-util 1.5.0
2018-04-13T16:37:20 INFO common.c: Loading device parameters....
2018-04-13T16:37:20 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-04-13T16:37:20 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-04-13T16:37:20 INFO gdb-server.c: Chip ID is 00000410, Core ID is  1ba01477.
2018-04-13T16:37:20 INFO gdb-server.c: Listening at *:4242...
 

Das ist korrekt. Im library Fehlerfall kommt:

Code: Alles auswählen

 
st-util: error while loading shared libraries: libstlink.so.1: cannot open shared object file: No such file or directory
 

Bei
http://wiki.freepascal.org/AVR_Embedded ... und_MSEgui
fehlt das Setzen von 'Settings'-'Configure MSEide'-'${MSEDIR}' (Punkt 5. von MSEide+MSEgui README.TXT).

Bei mir ist das der Pfad schon eingetragen. ( /home/tux/STM32-FPC/msegui/ )
Nur weis ich nicht, ob ich das gemacht habe, oder ob dies automatisch geschehen ist.

Das hast du gemacht (Punkt 5. in MSEide+MSEgui README.TXT). Davor hast du dich über fehlende Farben im MSEide Editor beklagt.

[Mathias]

Ich habe das Tutorial angepasst.

Auch das mit dem st-util.

Die libs, die man verschieben muss, ist dies ein Bug von der Installation des texane-stlink ?
Welcher man denen melden sollte ?

[mse]

Die libs, die man verschieben muss, ist dies ein Bug von der Installation des texane-stlink ?

Ja.

Welcher man denen melden sollte ?

Ist schon gemeldet:
https://github.com/texane/stlink/issues/700
https://github.com/texane/stlink/pull/701
https://github.com/texane/stlink/pull/707
Committed wurde noch nichts.

[Mathias]

Ist schon gemeldet:
https://github.com/texane/stlink/issues/700
https://github.com/texane/stlink/pull/701
https://github.com/texane/stlink/pull/707
Committed wurde noch nichts.

Wen dies mal behoben ist, werde ich das Tutorial anpassen

[Mathias]

Ich habe mich mal an die GPIOs gewagt, das wird einiges komplexer als beim AVR.
http://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Simple_GPIO_on_and_off_output/de

[Mathias]

Ich habe das Tutorial angepasst: http://wiki.freepascal.org/AMR_Embedded ... iler_bauen:

Unterdessen geht es auch mit Lazarus und man muss nicht zwingend MSEide verwenden.

[mschnell]

Bei Lazarus (aber nicht bei MSE) hast Du bei "embedded" das Problem, dass Du zusätzlich noch nach "headless" unterschieden musst.

Ein Lazarus-Projekt legt bei Projekt-Typ "NoGUI" (aka headless) keine Event Queue an. Deshalb geht "TTimer" und "TThread.Queue" / "TThread.Synchronize" und "procedure message" nicht. (MSE hat immer eine Event-Queue.)

Deshalb ist es fast immer empfehlenswert, ein "normales" Projekt zu verwenden. Der Overhead ist bei heute meist verwendeter ARM-Linux-Hardware (wie RasPi und BeagleBone) unproblematisch. (Und nicht-Linux embedded is ohnehin very outdated )

Ich habe zwar einen lauffähigen Prototypen für einen "activeNoGUI" Projekttyp, habe da aber nicht weitergemacht, weil kein Interesse bestand, das in das "offizielle" Lazarus svn aufzunehmen, damit jemand das ordentlich testen und bei der Weiterentwicklung helfen kann. Und wie gesagt ist es heute auch nicht mehr so wichtig.

-Michael

[mschnell]

Ein (für mich) wichtiger Aspekt bei "embedded" Projekten ist, wie man eine Überwachung / Wartung ermöglichen kann.
Ziemlich ideal ist es, mit einem Browser auf das Device zugreifen zu können.
Dazu muss man einen Webserver implementieren (gibt ts bei Lazarus als Paket) und eine Web-Oberfläche bauen. Für Web-Oberflächen gibt es eine ganze Menge Methodiken und Tools.

Besonders sexy finde ich MSE-IFI. Das geht bei Lazarus aber nicht. Hier wird kein Browser, sondern ein "Client" Pascal-Programm über eine beliebige Stream-Schnittstelle (z.B. also TICP/IP) verwendet, um auf die ganz normale MSE-designte GUI des embedded Programms zuzugreifen.

-Michael

[kupferstecher]

"embedded"

Es geht hier aber nicht um "embedded" in Anführungszeichen, sondern tatsächlich um Target Embedded (im FPC-Sinne), d.h. ohne Betriebssystem.

Und nicht-Linux embedded is ohnehin very outdated

Stimmt natürlich nicht. Das ist vielmehr eine ganz andere Baustelle.

[Mathias]

@mschnell

Ich verstehe nichts, was du meinst ?

Ich weis nicht, für was du Web, etc. für einen µController verwenden willst.
Und auch da mit den TTimer/TThread. Ein Timer wird sowieso per Interrupt geteuert,

[mschnell]

Wenn mit "embedded" tatsächlich "Ohne Betriebssystem" gemeint ist, passen meine Ausführungen natürlich wirklich nicht hier hin. (Das ist dann aber weniger ein "Lazarus" als ein reines Compiler-Thema und im "Lazarus"-Forum nicht ohne weiteres zu erwarten.)

Mikroprozessoren ohne Betriebssystem zu verwenden, macht aber heute - wenn man von Projekten absieht, die in Tausender-Stückzahlen produziert werden und deshalb Kosten sparen müssen, in den wenigsten Fällen wirklich Sinn. Mit dem RASPi- (für Netzwerk-Appliences) und dem Beagelbone (für "deeply embedded" Anwendungen) gibt es extrem preiswerte und leistungsfähige Boards (und diverse Unterstützungs- Hardware und Tools). Ich würde im klein-Stückzahl-Bereich nur noch unter sehr speziellen Bedingungen ein Projekt ohne Betriebssystem starten (z.B. wenn extrem Strom oder Platz gespart werden muss). Siehe z.B "Pocket BeagleBone" für ca. 25 Euro -> https://www.cnx-software.com/2017/09/22 ... 58-sm-sip/

Außerdem sagt der Thread-Titel "ARM". "embedded" Linux-Systeme arbeiten ja meist mit ARM-Architektur, während für Betriebssystem-lose Projekte die Wahl eher auf "AT" oder "PIC" Chips (inzwischen beide von Microchip) fällt (obwohl es natürlich diverse Chips diverser Hersteller für solche hoch-Stückzahl Zwecke mit ARM-Architektur gibt).

Eine viel diskutierte Frage ist, "wie kann ich meine xyz-Hardware an den PC mit einer komplexen Lazarus-Anwendung anschließen" ? Da ist der PocketBeagleBone ideal. Über USB an den PC stöpseln (Serienport-Emulation im PC, Stromversorgung über das USB-Kabel) und die low-Level Kommunikation mit der Hardware im Pocket-Bone realisieren, für kritische Realtime-Signale kann man den Realtime Coprozessor verwenden. Mit einem Prozessor ohne Betriebnssystem hat man zwar weniger Schwierigkeiten mit dem Realtime - Verhalten, die USB.-Unterstützung muss aber durch eine Library (statt einem im Linux ohnehin vorhandenen Treiber) organisiert werden.

P.S. Die MIPS-Unterstüzuung in FPC, die für PIC32 Chips verwendet werden könnte, ist anscheinend leider nicht wirklich einsetzbar.

-Michael

[kupferstecher]

Hallo Michael,

das ist jetzt zwar etwas Offtopic, aber ich denke das sollte geklärt sein~

Wenn mit "embedded" tatsächlich "Ohne Betriebssystem" gemeint ist,

So ist es.

Mikroprozessoren ohne Betriebssystem zu verwenden, macht aber heute - wenn man von Projekten absieht, die in Tausender-Stückzahlen produziert werden und deshalb Kosten sparen müssen, in den wenigsten Fällen wirklich Sinn.

Das hat mit der Stückzahl weniger zu tun, als viel mehr mit der Anwendung. Bei Arm-Linux-Boards ist man in Timingbereichen, die einem Mikrocontroller meilenweit hinterherhängen. Einen Inkrementaldekoder mit einem Raspi auszuwerten kann man vergessen. Natürlich kann man hinter den Raspi noch Spezialhardware/Treiberkarten dahinterhängen, dort werkeln dann oft Mikrocontroller, natürlich ohne BS.

während für Betriebssystem-lose Projekte die Wahl eher auf "AT" oder "PIC" Chips (inzwischen beide von Microchip) fällt (obwohl es natürlich diverse Chips diverser Hersteller für solche hoch-Stückzahl Zwecke mit ARM-Architektur gibt).

Mikrocontroller auf ARM-Basis sind heutzutage sehr weit verbreitet, sie bieten im vergleich zu AVR (ATMega/ATTiny) oder PICs zum gleichen Preis eine deutlich höhere Leistung und mehr Peripherie. Sind aber deutlich komplizierter in der Programmierung, daher im Hobbybereich und damit in Internetforen/Tutorials eher unterrepräsentiert.

und die low-Level Kommunikation mit der Hardware im Pocket-Bone realisieren, für kritische Realtime-Signale kann man den Realtime Coprozessor verwenden

Schon mal gemacht? Das läuft vermutlich auf klassische Mikrocontrollerprogrammierung heraus.