Forum: Compiler & IDEs STM32 und Linux - Einsteigerfragen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

wg. eines LinuxCNC-Projekts will ich mal ausprobieren, ob ich vorhandene 
STM32-Sourcen auf einem Nucleo-Board zum laufen bekommen. (ohne jede 
STM32-Erfahrung)

Der Entwickler hat das unter WIN und mit Eclipse erstellt - und ich 
hasse beides wie die Pest.

Offensichtlich benoetigt der STM32 aber einen gewaltigen Overhead an 
Libs, git-Sourcen usw...

Bevor ich mir da jetzt ergebnislos einen Wolf suche:

Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die 
Commandline zu programmieren oder wird man  dann an irgendwas scheitern?

Wenn ich es richtig sehe, dann benoetigt man den hier auf jeden Fall:

 https://github.com/ARMmbed/mbed-os


Ist das hier beschriebene Vorgehen noch aktuell?

https://os.mbed.com/docs/mbed-os/v5.12/tools/working-with-mbed-cli.html


(oftmals findet man ja wunderbare step-by-step-Anleitungen, die dann 
allerdings von der aktuellen Entwicklung überrollt wurden, völlig 
veraltet sind und nicht mehr funktionieren)

Vorhin las ich noch irgendwo:

der GCC waere voellig veraltet und embedded-entwickler wuerde ihn 
hassen.

sehe ich nicht so - aber vielleicht bin ich ja auch voellig veraltet ;-)


wie seht ihr das?

wicki

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die
> Commandline zu programmieren

Ja.

Wicki W. schrieb:
> Wenn ich es richtig sehe, dann benoetigt man den hier auf jeden Fall:

Keineswegs, das ist nur eine Möglichkeit von vielen.

Wicki W. schrieb:
> der GCC waere voellig veraltet und embedded-entwickler wuerde ihn
> hassen.

GCC und Clang sind die einzigen Compiler welcher aktuelle 
Sprachstandards (C++17) unterstützen. GCC wird auch von vielen 
kommerziellen IDEs genutzt. Der ist also sehr gut geeignet.

Du kannst dir problemlos eigene Makefiles schreiben, welche den GCC und 
Linker aufrufen und dann via GDB flashen & debuggen. Natürlich geht das 
mit einer IDE wie Eclipse viel komfortabler; insbesondere das Anzeigen 
von Peripherie-Registern ist hilfreich.
Mit Atollic Studio for STM32 und STM32CubeIDE geht das ganze auch unter 
Linux sehr komfortabel, aber die sind eben Eclipse-basiert.

Wicki W. schrieb:
> Offensichtlich benoetigt der STM32 aber einen gewaltigen Overhead an
> Libs, git-Sourcen usw...

Nö, du kannst auch ganz ohne Library programmieren. Mindestens die 
Register-Definitionen sollte man sich aber beim Hersteller holen, weil 
die selbst zu erstellen ein riesiger sinnloser Aufwand ist. Die 
Bibliotheken für den Hardware-Zugriff (HAL, SPL) kann man verwenden, 
aber die haben auch ihre Nachteile.

Wicki W. schrieb:
> (ohne jede
> STM32-Erfahrung)

Vielleicht wäre es sinnvoll, mit einer etablierten IDE anzufangen 
anstatt direkt alles selbst zu machen und an 25 Baustellen gleichzeitig 
zu arbeiten...

: Bearbeitet durch User
von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos!

"Vielleicht wäre es sinnvoll, mit einer etablierten IDE anzufangen 
anstatt direkt alles selbst zu machen und an 25 Baustellen gleichzeitig 
zu arbeiten..."

Im Prinzip ist da was dran.
Aber: wenn ich diesen Klickibunti-Mist mit der Mausschubserei sehe, dann 
kriege ich die Krise...

Ich will ordentlich Commandlines, die man sich auch einfach speichern 
und weitergeben kann.
Ohne jedes mal einen Screenshot und Mails mit File-Attach erstellen zu 
muessen.

Gut, ich gebe zu: Makefiles zu bauen ist auch kein Spass. Aber das 
Ergebnis ist dann eine wenige k grosse Datei. und keine Sammlung von 
Screenshots mit "kier klicken", "da klicken".


mal schauen, wie es weiter geht.... ;-)

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Ich will ordentlich Commandlines, die man sich auch einfach speichern
> und weitergeben kann.

Eclipse kann auch selbstgeschriebene Makefiles aufrufen. Erfahrungsgemäß 
haben viele Leute weniger Probleme damit, per IDE-Installer alle 
Komponenten auf Einmal zu installieren, das Projekt in der IDE zu 
importieren und dann auf "Build" zu klicken...

Wenn man den grundlegenden Workflow erstmal verstanden hat, kann man die 
IDE immer noch weglassen. Es gibt da ja noch diverse Details zu beachten 
(Startup-Code, Linkerscript, Syscalls für malloc, korrekte 
Präprozessor-Makros für Controller, Register-Definitionen, HAL, 
GDB-Server für JTAG/SWD-Hardware) die man nicht alle auf Einmal angehen 
will...

von Lars F. (flemmy)


Bewertung
0 lesenswert
nicht lesenswert

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
das ist schon mal ein guter tip.
aber irgendwie mag er nicht mit mir sprechen....

erkannt wird er. die "hd" wird auch gemounted.
aber dann wars das auch:

 kernel: [503966.935386] usb 1-7: new full-speed USB device number 34 
using xhci_hcd
 kernel: [503967.084789] usb 1-7: New USB device found, idVendor=0483, 
idProduct=374b
 kernel: [503967.084795] usb 1-7: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
 kernel: [503967.084800] usb 1-7: Product: STM32 STLink
 kernel: [503967.084803] usb 1-7: Manufacturer: STMicroelectronics
 kernel: [503967.084807] usb 1-7: SerialNumber: 0670FF353638425043013805
 kernel: [503967.140123] usb-storage 1-7:1.1: USB Mass Storage device 
detected
 kernel: [503967.140945] scsi host5: usb-storage 1-7:1.1
 kernel: [503967.141827] cdc_acm 1-7:1.2: ttyACM0: USB ACM device
  mtp-probe: checking bus 1, device 34: 
"/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7"
  mtp-probe: bus: 1, device: 34 was not an MTP device
  kernel: [503967.189440] usbcore: registered new interface driver uas
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.3
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.2
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.1
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7
  kernel: [503968.144163] scsi 5:0:0:0: Direct-Access     MBED 
microcontroller  1.0  PQ: 0 ANSI: 2
  kernel: [503968.145033] sd 5:0:0:0: Attached scsi generic sg3 type 0
  kernel: [503968.145367] sd 5:0:0:0: [sdd] 4168 512-byte logical 
blocks: (2.13 MB/2.04 MiB)
  kernel: [503968.145591] sd 5:0:0:0: [sdd] Write Protect is off
  kernel: [503968.145595] sd 5:0:0:0: [sdd] Mode Sense: 03 00 00 00
  kernel: [503968.145755] sd 5:0:0:0: [sdd] No Caching mode page found
  kernel: [503968.145764] sd 5:0:0:0: [sdd] Assuming drive cache: write 
through
  kernel: [503968.165691] sd 5:0:0:0: [sdd] Attached SCSI removable disk


#$ st-info --probe
2019-06-06T12:27:53 WARN usb.c: failed to get libusb device descriptor
Found 0 stlink programmers


woran liegts ?

von zufaulzumanmelden (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei mir lag's daran, dass ich nicht root war.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
AUA!

danke ;-)

wenn er jetzt was von "permission den.." gesagt haette,
waer ich auch sofort drauf gekommen.

aber dennoch ist das problem nicht geloest.
es hat sich (mal wieder) nur verlagert:

st-info --probe
Found 1 stlink programmers
 serial: 303637304646333533363338343235
openocd: "\x30\x36\x37\x30\x46\x46\x33\x35\x33\x36\x33\x38\x34\x32\x35"
  flash: 0 (pagesize: 0)
   sram: 0
 chipid: 0x0000
  descr: unknown device


bzw:
# st-flash write main.bin 0x8000000

st-flash 1.5.1-28-gd040db5
2019-06-06T13:16:33 INFO common.c: Loading device parameters....
2019-06-06T13:16:33 WARN common.c: Invalid flash type, please check 
device declaration
Unknown memory region

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt bin ich zwar ein bisschen weiter - aber fuer
den H743 scheint es keinen compiler fuer linux zu
geben :-(

scons kennt nur die unten gelisteten.

oder hat den hier schon mal jemand unter linux gaengig bekommen?

STM32 by ST NUCLEO-H743ZI Nucleo Development Board

https://www.amazon.de/gp/product/B077NDX82H/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1


-------------------------------------------

  <MCU>: f1hd/f1cle/f1mdvl/f042/f051/f030/f4.
    f030   = STM32F030 series.
    f042   = STM32F042 series.
    f051   = STM32F051 series.
    f1hd   = STM32F103HD series.
    f1cle  = STM32F107 series.
    f1md   = STM32100 medium density series.
    f1mdvl = STM32100 medium density value line series.
    f4     = STM32F407/f417 series (maintained for backwards 
compatibility)
    f405   = STM32F405
    f407   = STM32F407
    f415   = STM32F417
    f417   = STM32F417
    f427   = STM32F427
    f437   = STM32F437
    f429   = STM32F429
    f439   = STM32F439

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Jetzt bin ich zwar ein bisschen weiter - aber fuer
> den H743 scheint es keinen compiler fuer linux zu
> geben :-(

Der H743 ist ein cortex-m7, das unterstützt der GCC schon länger 
(zumindest seit 4.9).

Falls die st-utils mit dem H743 (noch) nicht umgehen können würd ich mal 
pyOCD probieren, das kommt von ARM und sollte mit dem st-link auf dem 
nucleo problemlos zusammenarbeiten können.

Gibts mehr Infos zum LinuxCNC-Projekt? Klingt interessant. Wo kommt da 
mbed ins Spiel? mbed ist ja recht praktisch weil man recht schnell zu 
Ergebnissen kommt (fast sowas wie ein Arduino "für Große") und alles 
mögliche vorgekaut integriert ist (RTOS, IPv4, TLS, ...), ich hab aber 
den Eindruck, dass die ARMen oft selber nicht wissen wo sich das alles 
hinentwickeln soll...

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> GCC und Clang sind die einzigen Compiler welcher aktuelle
> Sprachstandards (C++17) unterstützen.

Die IAR Embedded Workbench für Arm v8.40.1 unterstützt C++17 und C18.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael F. schrieb:
> Die IAR Embedded Workbench für Arm v8.40.1 unterstützt C++17 und C18.

Ah, gut zu wissen. GCC ist jedenfalls keineswegs veraltet, der wird 
ständig weiter entwickelt, u.a. von ARM selbst. Es gibt nur viele 
veraltete Pakete/Distributionen im Netz, wie z.B. Yagarto und teilweise 
die Pakete von Linux-Distributionen.

Man kann den ST-Link auch als J-Link umflashen, dessen Software 
funktioniert super unter Linux, aber proprietär.

von Stute (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> AUA!
>
> danke ;-)

Ich sehe schon, voll der CmdLine Hengst der noch nicht mal strace 
bedienen kann.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> der wird
> ständig weiter entwickelt, u.a. von ARM selbst.

Die letzten paar offiziellen Releases von ARM enthalten leider ein paar 
kapitale showstopper bugs:

* unter bestimmten Umständen bleiben nach dem Linken Weak-Symbole stehen 
obwohl passende Strong-Symbole existieren
* Die Windows-Version kann keine .hex Dateien erzeugen (Absturz)
* Die Windows-Version kann keine Debug-Informationen generieren wenn LTO 
aktiv ist (Absturz)

Ich bin echt mal gespannt wann (oder ob?) wieder mal eine Version von 
denen rauskommt die zufällig mal wieder funktioniert.

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hi zusammen,


erst mal besten dank fuer die infos.
ich schau nachher mal, ob ich nun weiter komme.

"Gibts mehr Infos zum LinuxCNC-Projekt?"

stelle ich nachher mal zusammen.
im wesentlichen gehts darum: ich bin gefragt worden, ob wir
dieses paket

 Rapsberry/Arduino Treiberpaket fuer LinuxCNC via Raw-Ethernet

http://erste.de/ethraw/readme.de.html

auf stm32 portieren wollen.

aber wie gesagt: hatte noch nie mit dem ding zu tun.
fest steht jedenfalls, dass man mit arduino und raspberry
auf grenzen stoesst, wenn man 5kHz stepperfrequenz
ueberschreitet.
beim ardu aus anderen gruenden als bei rasp.

es gibt zwar die mesa-cards - aber das ist kein open-source.

und genau das ist das ziel.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Wicki W. schrieb:
> Falls die st-utils mit dem H743 (noch) nicht umgehen können würd ich mal
> pyOCD probieren, das kommt von ARM und sollte mit dem st-link auf dem
> nucleo problemlos zusammenarbeiten können.


soifz

 pyocd list
## => Board Name | Unique ID
-- -- ----------------------
 0 => NUCLEO-H743ZI [stm32h743zi] | 0670FF353638425043013805

aber:

  stm32f051               STMicroelectronics      STM32F051 
builtin
  stm32f103rc             STMicroelectronics      STM32F103RC 
builtin
......
  stm32l475xe             STMicroelectronics      STM32L475xE 
builtin
  stm32l475xg             STMicroelectronics      STM32L475xG 
builtin


das war wohl nix....


und das auch nich:
Warning

This platform is not yet available on mbed on-line compiler. Please use 
mbed-cli commands in the meantime.

The following mbed APIs are also not supported yet: CAN, ETHERNET, 
USBDEVICE

: Bearbeitet durch User
von diePoetteringdie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie Eingangs schon jemaand schrieb, mit einer fertigen IDE
hat man deutlich weniger Baustellen.

06/01/2019  10:40 PM     1,424,623,034 EWARM-CD-8401-21539.exe

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
diePoetteringdie schrieb:
> EWARM-CD-8401-21539.exe

Und wie benutzt man das unter Linux? Mit wine? Geht da auch der 
Debugger? Da ist eclipse vermutlich doch das kleinere Übel (ich finde 
Eclipse sowieso gar nicht so schlimm).

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
also doch....

zumindest comiliert es jetzt

# cd mbed-os-example-blinky

# mbed  compile -t GCC_ARM

[mbed] Working path "...../mbed-os-example-blinky" (program)
[mbed] Detected "NUCLEO_H743ZI" connected to "....../NODE_H743ZI" and 
using com port "/dev/ttyACM0"
[Warning] @,: Compiler version mismatch: Have 8.2.1; expected version >= 
6.0.0 and < 7.0.0
Building project mbed-os-example-blinky (NUCLEO_H743ZI, GCC_ARM)
Scan: mbed-os-example-blinky
Compile [  0.8%]: at24mac.cpp
Compile [  0.9%]: NanostackRfPhyMcr20a.cpp
Compile [  1.0%]: main.cpp
Compile [  1.2%]: NanostackRfPhyAtmel.cpp
Compile [  1.3%]: NanostackRfPhys2lp.cpp
[.....]
Compile [ 99.8%]: USBSerial.cpp
Compile [ 99.9%]: PolledQueue.cpp
Compile [100.0%]: TaskBase.cpp
Link: mbed-os-example-blinky
Elf2Bin: mbed-os-example-blinky
| Module             |         .text |       .data |        .bss |
|--------------------|---------------|-------------|-------------|
| [fill]             |     148(+148) |     12(+12) |     45(+45) |
| [lib]/c.a          | 26000(+26000) | 2472(+2472) |     89(+89) |
| [lib]/gcc.a        |     772(+772) |       0(+0) |       0(+0) |
| [lib]/misc         |     208(+208) |     12(+12) |     28(+28) |
| main.o             |   1066(+1066) |       4(+4) |     36(+36) |
| mbed-os/cmsis      |   1021(+1021) |       0(+0) |       0(+0) |
| mbed-os/components |     104(+104) |       0(+0) |       0(+0) |
| mbed-os/drivers    |     810(+810) |       0(+0) |       0(+0) |
| mbed-os/hal        |   3357(+3357) |       8(+8) |   247(+247) |
| mbed-os/platform   |   5086(+5086) |   260(+260) |   257(+257) |
| mbed-os/rtos       |   9343(+9343) |   168(+168) | 6289(+6289) |
| mbed-os/targets    | 18470(+18470) |       8(+8) | 1457(+1457) |
| Subtotals          | 66385(+66385) | 2944(+2944) | 8448(+8448) |
Total Static RAM memory (data + bss): 11392(+11392) bytes
Total Flash memory (text + data): 69329(+69329) bytes

Image: ./BUILD/NUCLEO_H743ZI/GCC_ARM/mbed-os-example-blinky.bin

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:

> zumindest comiliert es jetzt
> Image: ./BUILD/NUCLEO_H743ZI/GCC_ARM/mbed-os-example-blinky.bin


und es funktioniert sogar.....

dass man einfach nur das .bin nach /media/xxx/NODE_H743ZI kopieren muss, 
das haette ich jetzt nicht erwartet.

ich glaube, das teil faengt an mir zu gefallen ;-)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Den integrierten ST-Link auf den Nucleo-Boards kannman auch auf J-Link 
umflashen, dann kann man J-Link-Software für Linux installieren und hat 
dann alle Annehmlichkeiten von J-Link (keine Gesichtslähmung mehr beim 
Debuggen, unbegrenzte Breakpoints, etc).

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> soifz
>
>  pyocd list
> ## => Board Name | Unique ID
> -- -- ----------------------
>  0 => NUCLEO-H743ZI [stm32h743zi] | 0670FF353638425043013805
>
> aber:
>
>   stm32f051               STMicroelectronics      STM32F051
> builtin
>   stm32f103rc             STMicroelectronics      STM32F103RC
> builtin
> ......
>   stm32l475xe             STMicroelectronics      STM32L475xE
> builtin
>   stm32l475xg             STMicroelectronics      STM32L475xG
> builtin
>
> das war wohl nix....

Das verstehe ich nicht. Was war wohl nix? Ich hab gerade kein 
Nucleo-H743ZI herumliegen drum kann ich das nicht testetn, aber was 
funktioniert denn mit pyocd nicht?

$ pyocd list -b | grep 743
  0743   DISCO-F413ZH                     stm32f413zh             None
  0813   NUCLEO-H743ZI                    stm32h743zi             None

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> http://erste.de/ethraw/readme.de.html
>
> auf stm32 portieren wollen.

Muss ich mir genauer anschaun, auf den ersten Blick hab ich nur einen 
Haufen riesen-LEDs gesehen. Die Idee einen RaspberryPi als Ethernet 
IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.

Das wird mit dem Nucleo deutlich besser und deterministischer 
funktionieren, Step-Raten im zig-MHz Bereich sind da dann auch kein 
Problem.

Update-Raten mit richtiger Hardware und mit "privatem" Netzwerk (evt. 
ohne switch) von 4kHz sollten mit RT PREEMPT Kern ohne speziellere 
Ethernet-Tricksereien möglich sein.

> aber wie gesagt: hatte noch nie mit dem ding zu tun.
> fest steht jedenfalls, dass man mit arduino und raspberry
> auf grenzen stoesst, wenn man 5kHz stepperfrequenz
> ueberschreitet.
> beim ardu aus anderen gruenden als bei rasp.
>
> es gibt zwar die mesa-cards - aber das ist kein open-source.
>

Die Mesa-Hardware ist nicht open source, die Software schon. Karten wie 
die 7i90 sind auch nicht besonders teuer IMHO. Die Ethernet-Karten haben 
durch die Bank alle FPGAs mit BGA-Kontaktierung, ob man sowas selber 
löten will...

Ansonsten als Anregung kann ich das STMBL-Projekt (auf github zu finden) 
empfehlen, die interfacen auch mit LinuxCNC.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Die Idee einen RaspberryPi als Ethernet
> IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.
>
> Das wird mit dem Nucleo deutlich besser und deterministischer
> funktionieren, Step-Raten im zig-MHz Bereich sind da dann auch kein
> Problem.

Vielleicht wäre ein TI Sitara Prozessor (z.B. in Form eines BeagleBone 
Black) interessant - hart echtzeitfähig, viel Rechenleistung, Ethernet 
mit Industrieprotokollen möglich (z.B. EtherCAT)

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Muss ich mir genauer anschaun, auf den ersten Blick hab ich nur einen
> Haufen riesen-LEDs gesehen.

das war nur ein daran anschliessendes nebenprodukt - weil die 
schnittstelle grad da war.... hat aber ansonsten nix damit zu tun.


> Die Idee einen RaspberryPi als Ethernet
> IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.

diese diskussion hatten wir schon x mal....
ich wollte es bauen und meine fraese laeuft jedenfalls damit.

und nun gits da einen bulgaren und einen russen(?) die aehnliches
mit einem stm32 gebaut haben - teils aber auf eigener hardware.
(was ebenfalls laeuft, aber den stepgen auf dem stm32 hat)
damit ich mir das ansehen kann, muss ich es erst mal zum laufen 
bekommen.

http://pekka.eu/cnc/
https://github.com/pekkaroi/ethernetcnc

vielleicht bekommen wir es ja hin, aus mehreren halbfertigen loesungen 
eine gesamtloesung zu bauen.

darum sehe ich mir jetzt den 743 an.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die
> Commandline zu programmieren oder wird man  dann an irgendwas scheitern?

Das hängt davon ab, ob es bei Linux eine benutzbare Kommandozeile gibt.

Mal im Ernst:
Selbstverständlich kann man sowohl bei Windows als auch bei Linux die 
komplette Toolchain per Kommandozeile benutzen - präziser gesagt: per 
Batch-Datei (Windows) oder Shell-Script (Linux). Ist ja bis auf 
unterschiedliche Schreibweisen dasselbe.

Wenn du gucken willst, wie man per Kommandozeile den Keil oder den GCC 
(damals yagarto) aufruft, dann guck hier in die Lernbetty, da ist das 
damals vorexerziert worden.


Wicki W. schrieb:
> WIN und mit Eclipse erstellt - und ich
> hasse beides wie die Pest.

Hass ist für den Ingenieur etwas sehr Unbrauchbares und 
Kontraproduktives. Wenn du dich von sowas leiten läßt, wirst du 
lediglich deinen Blutdruck steigern und deine Kreativität kaputtmachen 
und obendrein auch noch deine Möglichkeiten einschränken. Irgend etwas 
aus guten, sachlichen Gründen nicht zu mögen, ist hingegen etwas 
anderes.

Wicki W. schrieb:
> Offensichtlich benoetigt der STM32 aber einen gewaltigen Overhead an
> Libs, git-Sourcen usw...

DER  stm32?

Erstmal: es gibt viele davon, genauso wie es auch viele LPC's gibt oder 
Chips von Nuvoton, Freescale und anderen Herstellern.

Und zweitens: Für die diversen STM32-Chips benötigt man keinesfalls 
einen gewaltigen Overhead. Sowas ist hausgemacht, indem man fröhlich 
diverse Hersteller-Beigaben benutzt, einen Sack voll Indirektionen 
benutzt, obendrein auch noch die gleiche Menge an Datei-Senf von 
irgendeiner IDE dazurührt, Projektfiles und vorkompilierte Header liebt 
und so weiter.

Nein, wenn man es einfach hält und nicht mutwillig so ein Projekt 
ausufern läßt, dann schnurrt das Ganze sehr schnell auf eine 
übersichtliche Anzahl von Dateien zusammen.

Aber gestern war noch nicht Freitag. Also!

W.S.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> Die Idee einen RaspberryPi als Ethernet
>> IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.
>
> diese diskussion hatten wir schon x mal....
> ich wollte es bauen und meine fraese laeuft jedenfalls damit.

Kein Bange, ich will da nix diskutieren.

> und nun gits da einen bulgaren und einen russen(?) die aehnliches
> mit einem stm32 gebaut haben - teils aber auf eigener hardware.
> (was ebenfalls laeuft, aber den stepgen auf dem stm32 hat)
> damit ich mir das ansehen kann, muss ich es erst mal zum laufen
> bekommen.

Die Mesa Ethernet-Karten verwenden ein einfaches UDP Protokoll, analog 
dazu eine  LinuxCNC-Komponente die UDP redet zu schreiben und das 
Gegenstück mit dem LinuxCNC-eigenen Software-Stepgen auf einem STM32 ist 
keine Hexerei.

Mit mbed sollte das auch relativ shcnell zu machen sein.

Der Software-Stepgen aus LinuxCNC bzw. Hostmot2 ist mehr oder weniger 
ein rückgekoppeltes Schieberegister, das mit (mehreren) 100kHz laufen zu 
lassen sollte auch für mehrere Achsen kein Problem für den M7 
darstellen. Wenns nicht reicht kann man immer noch auf die Timer 
zurückgreifen, da muss man dann halt etwas mehr Hirn reinstecken.

> vielleicht bekommen wir es ja hin, aus mehreren halbfertigen loesungen
> eine gesamtloesung zu bauen.

viel Erfolg

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
> > WIN und mit Eclipse erstellt - und ich
> > hasse beides wie die Pest.

> Hass ist für den Ingenieur etwas sehr Unbrauchbares und
> Kontraproduktives.

das mag sein. Aber meine Gesundheit und meine Nerven
sind mir wichtiger...

Wenn man jahrzehntelang beobachtet, wie fehlerhafte, proprietäre OSs und 
IDEs den Anwender und Entwickler mehr und mehr entmündigen und 
inzwischen in Online-Compilern und -Libs münden, deren Daten dann 
möglichst noch in der Cloud gespeichert werden - dann ist man es 
irgendwann leid.

Aber ich schweife ab ;-)

Dass es "den" STM32 nicht gibt, ist mir schon klar. Und genau das ist 
das/mein Problem: Die Inflationäre Zahl der Typen und IDEs macht es 
nicht leicht, den Einstieg zu finden.
Selbst der Entwickler brauchte ein paar Tage Recherche, um mir sagen zu 
können, dass das 743-Board das richtige für seine Sourcen ist.
Das ist aber ein WIN/Eclipse Mensch - und ich will das nun unter Linux 
compilieren.

Hinzu kommt, dass es zahlreiche unterschiedliche Herangehensweisen gibt 
um zum gleichen Ergebnis zu kommen und so passiert es, dass man völlig 
aneinander vorbei redet, Anleitungen verwendet, die gar nicht mehr 
aktuell sind, weil sie nicht mehr zum Compiler in der neusten Version 
passen usw...

Wenig Hilfreich sind dann dumme Kommentare wie weiter oben "nicht mal 
strace bedienen koennen"....

Jedenfalls scheint das 743-Board schon ein ziemlicher Exot zu sein. Ich 
versuche, jetzt erst mal eine minimalistische Umgebung aufzubauen, um 
simple "hello words" &Co. gaengig zu bekommen.

Und dann das ganze mal als step-by-step-howto zusammenzufasssen.

mir war z.b. nicht klar, dass es neben
pyocd list --targets

auch noch
pyocd list --boards
gibt

Insofern ist dieses Forum hier doch eine große Hilfe ;-)

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
ok, den ueblichen mbed-spielkram bekomme ich jetzt
gaengig.
ist durchaus irgendwie spannend, das teil ;-)

aber wie bekomme ich solchen exclipse-kram uebersetzt?
geht das mit mbed irgendwie automatisiert?
muss man die project-files von hand auseinanderdroeseln?

https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

hat da jemand eine idee zu?

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Wenn man jahrzehntelang beobachtet, wie fehlerhafte, proprietäre OSs und
> IDEs den Anwender und Entwickler mehr und mehr entmündigen und
> inzwischen in Online-Compilern und -Libs münden, deren Daten dann
> möglichst noch in der Cloud gespeichert werden - dann ist man es
> irgendwann leid.

Der mbed online-Compiler hat schon Vorteile auch, das Ding funktioniert 
einfach und ist sofort von jedem Rechner/Tablet mit Webbrowser zu 
bedienen. Die Supergeheime Raketensteuerung würde ich dort nicht 
entwickeln, aber für die Quellen einer typischen LED-Blink-Anwendung mit 
eingebautem Webserver interessiert sich wirklich niemand. Da ist auch 
kein Know-How drin was ausgespäht werden könnte.

> Selbst der Entwickler brauchte ein paar Tage Recherche, um mir sagen zu
> können, dass das 743-Board das richtige für seine Sourcen ist.
> Das ist aber ein WIN/Eclipse Mensch - und ich will das nun unter Linux
> compilieren.

Kannst du das erläutern. Welcher Entwickler. Und warum braucht der 
mehrere Tage Recherche, um feszustellen, für welche Hardware er sein 
Programm schreibt. Klingt ziemlich absurd.

> mir war z.b. nicht klar, dass es neben
> pyocd list --targets
>
> auch noch
> pyocd list --boards
> gibt

Die Doku von pyocd ist ja jetzt nicht sooo lang, das ist in 2 Minuten 
überflogen, und mit Argumenten wie "-h" oder "--help" oder auch "-?" 
kann man üblicherweise alle Programme zu beschreibenden Ausgaben 
bewegen.

Board-Support etc.. kann man übrigens auch nachrüsten (pyocd pack).

Der H743 ist vermutlich wirklich ein Exot, von der Performance und vom 
Preis her eher kein typischer Mikrocontroller. Für ein Ethernet-BOB aber 
keine schlechte Wahl.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> aber wie bekomme ich solchen exclipse-kram uebersetzt?
> geht das mit mbed irgendwie automatisiert?
> muss man die project-files von hand auseinanderdroeseln?
>
> https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP
>
> hat da jemand eine idee zu?

* herausfinden für welche eclipse ide das gedacht ist

* selbige installieren

* github projekt klonen

* in eclipse als workspace öffnen

* loslegen

Soweit ich sehe tut das verlinkte Projekt aber (noch) nichts, das ist 
nur eine leere Hülle.

von Niklas Gürtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> aber wie bekomme ich solchen exclipse-kram uebersetzt?
> geht das mit mbed irgendwie automatisiert?

Das Projekt benutzt doch überhaupt kein mbed, oder? Habe da auf die 
Schnelle nur HAL-Code gesehen. Dann bringt dir mbed hier eher wenig.

Du musst dir ein Makefile basteln, welches alle Source Files kompiliert 
und linkt. Nötige Parameter für die GCC-Aufrufe finden sich z.B. unter 
ARM GCC.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> * herausfinden für welche eclipse ide das gedacht ist

dürfte SW4STM32 sein 
http://www.ac6-tools.com/content.php/content_SW4L.xphp

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
mbed ist schon etwas mehr als nur ein Kommandozeilenwerkzeug.
Es ist ein OS mit Realtime Kernel (rtx5 von ARM), einheitlicher 
Treiberstruktur für HW wie gpio, serial, spi, ethernet und einiges mehr. 
Dazu Multikulti was das HostOS angeht (Windows, Linux, MacOS) sowie die 
die unterstützten Compiler (gcc, ARM, IAR). Mit mbed-cli hast du eine 
Kommandozeilenunterstützung, das ist das bevorzugte Werkzeug der 
Entwickler weil zB die ganzen Tests auch automatisiert ablaufen müssen.
Das CLI ist in den letzten Jahren massiv weiterentwickelt worden und 
sehr mächtig. Man muss sich nicht mit makefiles rumquälen, einfach 
Verzeichnisse anlegen und Quellcode reinwerfen, dann werden die 
mitkompliert. Es gibt ein paar Namenskonventionen die unterschiedlichen 
Code für die verschiedenen Targets vereinfachen.
Dann kann das CLI Projektfiles für verschiedenen IDE erzeugen, findet 
man unter export Funktion. Eclipse war mal mein Favorit, aber das 
Persistenzformat für Eclipse ist eklig kompliziert, VSCode und Co. sind 
da mit ihren JSON Files viel pflegeleichter. Obwohl viele Eclipse IDE 
sehr ähnlich sind können die nicht einfach Projektconfigs anderer lesen, 
nur wenn die das Format kennen und konvertieren (zB Atollic liest und 
konvertiert SW4STM32).
Mittlerweile hat ARM eine eigene IDE veröffentlicht, basierend auf dem 
Atom Editor, ähnlich VSCode. Relativ schlank und gut erweiterbar (wennn 
man in JavaScript einigermassen fit ist). Nebenbei bekommt man da sogar 
den sonst sehr teuren ARM Compiler mitinstalliert. Für meine 
Hobbyprojekte reichte mir der gcc allemal, aber die Unterstützung für 
Cortex-M0 ist immer noch sehr mässig und der ARM Compiler erzeugt 
besonders für die M0 oft 20-30% kürzeren Code.
OS für µC werden hier immer kontrovers diskutiert, aber ich mag mbed-OS. 
Es ist wesentlich besser strukturiert als der Arduino Wildwuchs. Die 
Targets sind in einem Topf mit dem OS und Änderungen werden exzessiv 
getestet. Bei Arduino gibts verschiedene Cores von Drittanbietern und 
das Zusammenspiel ist Glückssache. Auch werden in den Cores pauschal 
Resourcen beschlagnahmt die dann auf Applikationslevel blockiert sind. 
Bei mbed lassen sich spezielle Hardwareunits schöner einbinden und auch 
Targetabhängig in Libs einbauen.
Mit einem OS hast du natürlich mehr Annehmlichkeiten zu Kosten von 
Resourcen. Aber auch das ist gut gelöst durch C++ Interfaces die dann 
Targetabhängig die Implementierung aufrufen.
Ethernet wurde überarbeitet, USB gab es anfangs nur für die LPC, kam 
dann auf ein unsupported Abstellgleis und ist jetzt in eine erweiterte 
Komponentenstruktur übernommen und weiterentwickelt worden. Der H743 ist 
aber auch recht neu und die Unterstützung gibt es noch nicht solange. 
Aber es ist ja alles auf github verfügbar, man muss sich nur etwas durch 
die Quellen hangeln...

: Bearbeitet durch User
von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:

> Der mbed online-Compiler hat schon Vorteile auch,
...
>  Da ist auch
> kein Know-How drin was ausgespäht werden könnte.

es geht nicht um "ausgespähtes Know-How" - es geht darum, dass es einen 
Software-Hersteller und/oder Server-Betreiber einen feuchten Kehricht 
angeht, wann, wo, unter welchem OS, mit welchem Browser ich was 
programmiere.
Abgesehen davon, steht man ziemlich dumm da, wenn der Server ausfällt, 
der Betreiber die Oberfläche oder die Nutzungsrechte ändert oder Pleite 
geht oder man einfach keinen Netzzugang hat.


> Kannst du das erläutern. Welcher Entwickler. Und warum braucht der
> mehrere Tage Recherche, um feszustellen, für welche Hardware er sein
> Programm schreibt. Klingt ziemlich absurd.

Das musst Du ihn schon selbst fragen. Es gibt halt auch Leute die 
arbeiten gehen, nicht unbegrenzt Zeit haben - und auch ich könnte dir 
detaillierte Fakten aus Projekten, die Monate zurück liegen, nicht 
nennen, ohne in den Unterlagen oder Sourcen nachzusehen.
Ich bin froh, wenn jemand mit einem interessanten Projektvorschlag kommt 
und einiges dazu beisteuern kann. Ihm vorzuwerfen, dass es absurd ist, 
wenn er eine Frage nach einer optimalen Hardware nicht sofort 
beantworten kann - das ist absurd......


> Die Doku von pyocd ist ja jetzt nicht sooo lang, das ist in 2 Minuten
> überflogen,

ja, das ist in 2 Minuten überflogen.
und da steht genau nichts vom "pyocd list --boards" drin.
wahrscheinlich findet man es irgendwo, wenn man in den tiefen der docs 
nachsieht.


> Der H743 ist vermutlich wirklich ein Exot, von der Performance und vom
> Preis her eher kein typischer Mikrocontroller. Für ein Ethernet-BOB aber
> keine schlechte Wahl.

... und das war wohl auch der Grund, warum man mir genau dieses Board 
genannt hat.

Aber es wäre schön, wenn wir nun diese Philosophischen Betrachtungen 
abhaken könnten...

Wenn mir jemand sagen kann, wie ich bestehende Eclipse-Projekt-Files auf 
mbed (oder irgendetwas anderes commandline-orienteirtes) portieren kann 
- darüber würde ich mich freuen....

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> es geht nicht um "ausgespähtes Know-How" - es geht darum, dass es einen
> Software-Hersteller und/oder Server-Betreiber einen feuchten Kehricht
> angeht, wann, wo, unter welchem OS, mit welchem Browser ich was
> programmiere.
> Abgesehen davon, steht man ziemlich dumm da, wenn der Server ausfällt,
> der Betreiber die Oberfläche oder die Nutzungsrechte ändert oder Pleite
> geht oder man einfach keinen Netzzugang hat.

Der Online Compiler hält sich schon hartnäckig seit über 10 Jahren. War 
auch nicht für professionelle Entwickler gedacht sondern soll die 
Ausbildung einfacher machen: Keine Installation von Software nötig, 
keine teueren Lizenzen, keine Spezialhardware für die Programmierung, 
mur ein USB Kabel. War seiner Zeit voraus weil die meisten da noch mit 
ihren AVR glücklich waren  und das erst mbed Board mit LPC1768 relativ 
teuer war.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
> Das CLI ist in den letzten Jahren massiv weiterentwickelt worden und
> sehr mächtig. Man muss sich nicht mit makefiles rumquälen, einfach
> Verzeichnisse anlegen und Quellcode reinwerfen, dann werden die
> mitkompliert.


wow - das sind ja alles schon wieder hilfreiche Infos. Besten Dank.

Das auf dem Teil ein eigenes OS laufen kann / laeuft habe ich ja jetzt 
auch erst durchs rumprobieren und rumfragen mitbekommen. Gefaellt mir 
recht gut, was ich bislang gesehen habe.

Und ich meine natuerlich das mbd-cli, mit dem ich gern arbeiten moechte.
genau aus den oben genannten Gruenden.

Aber es ist mir halt noch nicht gelungen, dieses hier (das ist nur ein 
beispiel) mittels mbed (und ich meine auch damit mbed-cli) compiliert zu 
bekommen:

https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Der Online Compiler hält sich schon hartnäckig seit über 10 Jahren.

ich sag ja nicht, dass er schlecht ist. er hat auch sicher seine 
berechtigung.
ich sag nur, dass ich das nicht moechte.

ich finde auch einen tesla nicht unbedingt schlecht.
haben moechte ich dennoch keinen....

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Aber es ist mir halt noch nicht gelungen, dieses hier (das ist nur ein
> beispiel) mittels mbed (und ich meine auch damit mbed-cli) compiliert zu
> bekommen:

das ist auch nicht im Sinne der mbed Erfinder, mbed-cli ist das Werkzeug 
um Anwendungen mit dem mbed-OS einfach erstellen zu können. Das OS und 
mbed wegzulassen kann gehen, aber da musst du vermutlich auch den 
Startupcode anpassen, der ruft auch früh die RTOS initialisierung auf. 
Und die Speicherverwaltunf muss man sich auch ansehen.
Also ich würde eher versuchen die Ethernetunterstützung von mbed zu 
nutzen...
Das H743 ist wie es aussieht auch nicht offiziel unterstützt aka 'mbed 
enabled', ich finde es nicht in der board Liste:
https://os.mbed.com/platforms/?q=nucleo
Im Quellcode gibt es mehr Targets, aber die sind dann eben noch nicht 
oder nicht mehr voll unterstützt.
Für Ethernet einfach mal testen ob dieses Beispielzeilen kompilieren:
https://os.mbed.com/docs/mbed-os/v5.12/apis/ethernet.html

von Niklas Gürtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Wenn mir jemand sagen kann, wie ich bestehende Eclipse-Projekt-Files auf
> mbed (oder irgendetwas anderes commandline-orienteirtes) portieren kann
> - darüber würde ich mich freuen....

Wie gesagt - mit entsprechenden Makefiles kannst du das per GCC 
kompilieren. Woran hapert es? Kannst du keine Makefiles schreiben? Dann 
wäre Eclipse keine so schlechte Idee. Wieso mbed? Statt das Projekt 
komplett auf mbed umzubauen, kannst du auch einfach ein neues mbed 
Projekt anfangen. Das ist vermutlich einfacher. mbed ist nicht einfach 
nur ein Konsolen Programm zum Kompilieren, sondern ein ganzes RTOS mit 
diversen Frameworks. Die müsste man dann auch in den Code einpflechten.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> Der mbed online-Compiler hat schon Vorteile auch,
> ...
>>  Da ist auch
>> kein Know-How drin was ausgespäht werden könnte.
>
> es geht nicht um "ausgespähtes Know-How" - es geht darum, dass es einen
> Software-Hersteller und/oder Server-Betreiber einen feuchten Kehricht
> angeht, wann, wo, unter welchem OS, mit welchem Browser ich was
> programmiere.
> Abgesehen davon, steht man ziemlich dumm da, wenn der Server ausfällt,
> der Betreiber die Oberfläche oder die Nutzungsrechte ändert oder Pleite
> geht oder man einfach keinen Netzzugang hat.

Ich hab nur ein paar Vorteile aufgezählt. Dass es nicht nur Vorteile 
gibts ist auch klar, kommt halt drauf an, was man will, aber sowas 
gleich pauschal für alle ablehnen ist übertrieben.

Wicki W. schrieb:
> Selbst der Entwickler brauchte ein paar Tage Recherche, um mir sagen zu
> können, dass das 743-Board das richtige für seine Sourcen ist.
> Das ist aber ein WIN/Eclipse Mensch - und ich will das nun unter Linux
> compilieren.

Wicki W. schrieb:
>> Kannst du das erläutern. Welcher Entwickler. Und warum braucht der
>> mehrere Tage Recherche, um feszustellen, für welche Hardware er sein
>> Programm schreibt. Klingt ziemlich absurd.
>
> Das musst Du ihn schon selbst fragen. Es gibt halt auch Leute die
> arbeiten gehen, nicht unbegrenzt Zeit haben - und auch ich könnte dir
> detaillierte Fakten aus Projekten, die Monate zurück liegen, nicht
> nennen, ohne in den Unterlagen oder Sourcen nachzusehen.
> Ich bin froh, wenn jemand mit einem interessanten Projektvorschlag kommt
> und einiges dazu beisteuern kann. Ihm vorzuwerfen, dass es absurd ist,
> wenn er eine Frage nach einer optimalen Hardware nicht sofort
> beantworten kann - das ist absurd......

Ich fühle mich da sinnentstellend zitiert. Bis jetzt war ja nicht die 
Rede davon dass das Projekt von jemand anderem entwickelt wird.

Auf dem verlinkten github-projekt steht ausserdem gleich auf der 
Einstiegsseite bzw. im README "How to test it? Power up the 
Nucleo-H743ZI".

Es war nirgendwo die Rede von "der optimalen Hardware für" wasauchimmer. 
Der Vorwurf der Absurdität ist ja kein Vorwurf an "den Entwickler" 
sondern an die Salami-Taktik und total unklare Diskussion deinerseits.

Wicki W. schrieb:
> Aber es ist mir halt noch nicht gelungen, dieses hier (das ist nur ein
> beispiel) mittels mbed (und ich meine auch damit mbed-cli) compiliert zu
> bekommen:
>
> https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

Die Frage ist (fast) analog zu "wie bekomme ich diese Android-Sourcen im 
XCode für IPhone kompilieren". Das ergibt keinen Sinn.

In dem github-Projekt ist nichts drinnen was das mbed von Haus aus nicht 
auch tut/kann. Ja, das Ethernet-Interface muss man konfigurieren damit 
der Nucleo auf ICMP Pings antwortet, aber das sind 2 Zeilen:
EthernetInterface eth;
nsapi_error_t status = eth.connect();

https://os.mbed.com/docs/mbed-os/v5.12/apis/ethernet.html

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> In dem github-Projekt ist nichts drinnen was das mbed von Haus aus nicht
> auch tut/kann. Ja, das Ethernet-Interface muss man konfigurieren damit
> der Nucleo auf ICMP Pings antwortet, aber das sind 2 Zeilen:
> EthernetInterface eth;
> nsapi_error_t status = eth.connect();

Leider fehlt beim H473 die Ethernet Unterstützung noch...

Mit einem dieser Boards würde es gehen:
https://os.mbed.com/platforms/?q=nucleo&Communication=Ethernet&sort_by=relevance

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
wie ich schon sagte:

Aber es wäre schön, wenn wir nun diese Philosophischen Betrachtungen
abhaken könnten...

> Auf dem verlinkten github-projekt steht ausserdem gleich auf der
> Einstiegsseite bzw. im README "How to test it? Power up the
> Nucleo-H743ZI".

ja - und da steht auch:

> How to build?
>     You can build this projest using Eclipse (SW4STM32) IDE

und ich will es ohne eclipse.


> der Nucleo auf ICMP Pings antwortet, aber das sind 2 Zeilen:
> EthernetInterface eth;
> nsapi_error_t status = eth.connect();


warum ich das nicht so mache?

The following mbed APIs are also not supported yet: CAN, ETHERNET, 
USBDEVICE


soifz

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Das H743 ist wie es aussieht auch nicht offiziel unterstützt aka 'mbed
> enabled', ich finde es nicht in der board Liste:
> https://os.mbed.com/platforms/?q=nucleo

In der Beschreibung vom Nucleo auf der ST Website steht schon "arm mbed 
enabled". Da das Reference Manual ein Datum "April 2019" trägt ist das 
vermutlich nur eine Frage der Zeit bis das auch auf den mbed-Seiten 
offiziell wird.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> How to build?
>>     You can build this projest using Eclipse (SW4STM32) IDE
>
> und ich will es ohne eclipse.

Also selber Makefile bauen. Ich kenn SW4STM32 nicht, aber die GNU ARM 
MCU Eclipse plugins legen selber Makefiles an, die kann man dann 
natürlich auch ohne Eclipse weiterverwenden, man muss nur aufpassen, 
dass man sie sich nicht wieder überschreibt. Falls das die SW4STM32 
genauso handhabt kann man die generierten Makefiles ja als Ausgangspunkt 
für eigene verwenden...

von W.S. (Gast)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Aber es wäre schön, wenn wir nun diese Philosophischen Betrachtungen
> abhaken könnten...
>...

> und ich will es ohne eclipse.

Herrjemineh, kannst du eigentlich lesen oder nur schreiben???

Daß das alles ohne aufgeblähten Aufwand geht, habe ich dir ja schon 
geschrieben. Also lade dir die Arm-Toolchain deiner Wahl herunter, 
installiere sie und rufe von der Kommandozeile erstmal den Compiler mit 
einem popligen Winzprogramm auf, etwa sowas:
int main (void)
{ return 0;
}

und guck dir an, ob du das übersetzt kriegst. Mir ist das jetzt zu doof, 
dir die Grundlagen eines Shell-Skripts beizubringen, zumal ich kein 
Linuxer bin. Aber sowas simples wie dieses:
echo Compile Main
ARM-NONE-EABI-GCC @compile_gcc.xcl -o main.thumb.o main.c
if Errorlevel==1 goto ende

echo Linke
ARM-NONE-EABI-LD @link_gcc.xcl
if Errorlevel==1 goto ende

echo Mache Hex
ARM-NONE-EABI-OBJCOPY -O ihex linkedgcc.elf BettyBASEgcc.hex
if Errorlevel==1 goto ende

echo Mache Bin
ARM-NONE-EABI-OBJCOPY -O binary  linkedgcc.elf BettyBASEgcc.bin
if Errorlevel==1 goto ende

echo So, das war's.
goto schluss

:ende
echo ...
echo Hei, da ist was schiefgelaufen!
pause

:schluss

solltest du mit links in ein Shellskript umschreiben können. Wer Linux 
benutzt, der hat sowas gefälligst auch zu können. Du wirst vermutlich 
nicht mehr die yagarto-Distri benutzen, also solltest du das obige 
Beispiel an deine Distri anpassen.
Obendrein sind natürlich auch die beiden .xcl (extended command lines) 
an dein Projekt anzupassen.

Und jetz jammere nicht mehr so herum, sondern mache.

W.S.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:

> Herrjemineh, kannst du eigentlich lesen oder nur schreiben???


liest du eigentliche auch oder kannst du nur pöbeln?

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wer mich kennt, weiß daß ich noch ganz anders kann. Du hingegen jammerst 
herum, daß du dies und das hasst und somit nicht weiter kommst.

Und wenn du schon keine Ratschläge haben willst, sondern nur deinem 
angestauten Unmut Ausdruck geben willst, dann sage das. Sowas kann 
auch akzeptiert werden. Manchmal muß man sich halt mal aussprechen...

W.S.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hilfe alarm. Was ist ein .xcl?

So wie sich das bis jetzt entwickelt hat sehe ich 2 Möglichkeiten wie 
das (kurzfristig) weitergehen kann:

* den ursprünglichen Entwickler dazu bringen, dass er ein Build-System 
integriert (z.B. Makefiles)

alternativ

* SW4STM installieren, einmal auf "build" drücken und die dabei 
erzeugten Makefiles zukünftig ohne eclipse weiterbenutzen.

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
rµ schrieb:
> Hilfe alarm. Was ist ein .xcl?

Auch du kannst offensichtlich nicht lesen, sonst hättest du die Antwort 
nur 3 Posts über dem deinigen lesen können. Extended Command Line. Eine 
Datei, die all das enthält, was man ansonsten in die Commandline hätte 
geschrieben haben müssen. Sowas spart Schreibarbeit.

W.S.

von (Gast)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Auch du kannst offensichtlich nicht lesen, sonst hättest du die Antwort
> nur 3 Posts über dem deinigen lesen können. Extended Command Line. Eine
> Datei, die all das enthält, was man ansonsten in die Commandline hätte
> geschrieben haben müssen. Sowas spart Schreibarbeit.
>
> W.S.

natürlich kann ich lesen. Ich kann auch google bedienen, und das liefert 
weder zu .xcl noch zu "Extended Command Line" irgendwas brauchbares, ob 
mit oder ohne Windows- Linux- oder sogar MacOS Kontext.

Normalerweise würde man da ein Makefile bauen. So ein Shellskript 
verursacht ja auf 10 Quelldateien erweitert schon Augenkrebs und Schaum 
vorm Mund.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> How to build?
>>     You can build this projest using Eclipse (SW4STM32) IDE
>
> und ich will es ohne eclipse.

Eclipse läuft auch unter Linux - gut hilft nichts, wenn man Eclipse 
selbst nicht mag.

SW4STM32 zB mag ich nicht, ich verwende Eclipse CDT + Gnu-Arm Plugin + 
OpenOCD.

Das Debuggen ist schon echt oft sehr hilfreich.

Ansonsten kannst du OpenOCD auch direkt von der Konsole aus starten und 
per GDB debuggen.

Du kannst alles ohne Eclipse per Makefiles kompilieren.

Du kannst mit OpenOCD auch die STM32 flashen.

Man kommt also schon ohne IDE aus.

von Niklas G. (erlkoenig) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ist das prekär hier... Im Anhang ein Makefile, mit welchem das erwähnte 
Projekt kompiliert werden kann. War jetzt gar nicht so schwierig.

Erst den Compiler installieren:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

In der syscalls.c muss man am Anfang noch folgendes einfügen:
int _getpid(void) __attribute__((used));
int _kill(int pid, int sig) __attribute__((used));
void _exit (int status) __attribute__((used));
int _read (int file, char *ptr, int len) __attribute__((used));
int _write(int file, char *ptr, int len) __attribute__((used));
caddr_t _sbrk(int incr) __attribute__((used));
int _close(int file) __attribute__((used));
int _fstat(int file, struct stat *st) __attribute__((used));
int _isatty(int file) __attribute__((used));
int _lseek(int file, int ptr, int dir) __attribute__((used));
int _open(char *path, int flags, ...) __attribute__((used));
int _wait(int *status) __attribute__((used));
int _unlink(char *name) __attribute__((used));
int _times(struct tms *buf) __attribute__((used));
int _stat(char *file, struct stat *st) __attribute__((used));
int _link(char *old, char *new) __attribute__((used));
int _fork(void) __attribute__((used));
int _execve(char *name, char **argv, char **env) __attribute__((used));

In der "Src/lwip.c" muss man die "#if defined ( __CC_ARM )" 
auskommentieren. kA warum die da sind.

Dann kann man per "make" alles automatisch kompilieren.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt mal für den Kollegen aus Bulgarien eine
Linux-Konstellation beschrieben, mit der man zumindest die
einfachen Demo-Sourcen übersetzt bekommt.
s.u.

Da es aber neben den 100ten von STM32-Typen/Board auch noch
unzählige Wege gibt, um Programme dafür zu entwickeln, ist es
nicht eben leicht, die passende Zusammenstellung zu finden.

mbed war bislang der Weg des geringsten Widerstandes. (für mich)
Blöd ist natürlich, dass Eth. nicht unterstützt wird.
Das müsste man dann wohl zu Fuss machen - aber wenn ich das
richtig sehe, ist das ja hier der Fall:


https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

da steigt er aber aus mit:

Compile [ 10.9%]: NanostackRfPhyMcr20a.cpp
[Fatal Error] device.h@41,10: stm32f7xx_hal_rng.h: No such file or 
directory
[ERROR] In file included from ./mbed-os/platform/platform.h:30,
                 from ./mbed-os/drivers/DigitalIn.h:20,
                 from 
./mbed-os/components/802.15.4_RF/mcr20a-rf-driver/mcr20a-rf-driver/Nanos 
tackRfPhyMcr20a.h:23,
                 from 
./mbed-os/components/802.15.4_RF/mcr20a-rf-driver/source/NanostackRfPhyM 
cr20a.cpp:19:
./mbed-os/targets/TARGET_STM/TARGET_STM32H7/device.h:41:10: fatal error: 
stm32f7xx_hal_rng.h: No such file or directory
 #include "stm32f7xx_hal_rng.h"
          ^~~~~~~~~~~~~~~~~~~~~

obwohl "stm32f7xx_hal_rng.h" da ist - und zwar an der gleichen stelle,
wie das eine Zeile früher includete "stm32h7xx_ll_usart.h"

Und zu "issue 4408" habe ich noch nichts gefunden, was mich weiter 
brachte...


#include "objects.h"
/*  WORKAROUND waiting for mbed-os issue 4408 to be addressed */
#include "stm32h7xx_ll_usart.h"
#include "stm32f7xx_hal_rng.h"



----------------------------------
###################################


I use linuxmint (19.1 - xfce) - but any debian/ubunto should work.

And I use mbed-cli. Here are the installation-steps:

https://os.mbed.com/docs/mbed-os/v5.12/tools/linux.html

after installation of the gcc-arm-none-eabi:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

(for testing, I placed it in)
/mnt/gcc-arm-none-eabi-8-2018-q4-major

you should configure the mbed-path:

mbed config GCC_ARM_PATH /mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^path to 
your compiler


copy the blinkey-sources

or some other test-sources like:
wget 
https://os.mbed.com/teams/ST/code/HelloWorld_IKS01A3/archive/44bf486fd3cf.zip


cd 44bf486fd3cf

/usr/local/bin/mbed deploy .

mbed-cli compile -j0 -t GCC_ARM  -m NUCLEO_H743ZI


copy the resulting .bin  from
BUILD/NUCLEO_H743ZI/GCC_ARM/44bf486fd3cf.bin to 
/media/user/NUCLEO_H743ZI

and watch the output:

miniterm /dev/ttyACM0 9600

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Mir ist das jetzt zu doof,
> dir die Grundlagen eines Shell-Skripts beizubringen

Bei einem Projekt mit so vielen Dateien wird ein Shell-Skript schon 
ziemlich langsam. Bei jeder kleinsten Änderung alles neu zu kompilieren 
wird schon nervig. Make kompiliert automatisch nur die benötigten 
Dateien neu. Außerdem kann man mit "make -j 8" o.ä. mehrere Vorgänge 
gleichzeitig laufen lassen. Shell-Scripte sind hier doch ziemlich 
überholt.

Wicki W. schrieb:
> Das müsste man dann wohl zu Fuss machen - aber wenn ich das
> richtig sehe, ist das ja hier der Fall:

Das Projekt nutzt HAL und lwIP - was versprichst du dir davon, da noch 
mbed rein zu pfriemeln? Welche mbed-Features möchtest du nutzen?

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Besten Dank fuer das Makefile - aber das
steigt sofort aus mit:

Makefile:31: Release/syscalls.d: Datei oder Verzeichnis nicht gefunden
....
make: *** Keine Regel, um 
„Release/Middlewares/Third_Party/LwIP/src/netif/ppp/utils.d“ zu 
erstellen.  Schluss.


lege ich ihm die .d-files von hand an, dann kommt:

Release/syscalls.d:1: *** Fehlender Trenner.  Schluss.


und nein, ich schreibe normalerweise keine Makfiles von Hand.
Hab also keine Erfahrung damit


> Das Projekt nutzt HAL und lwIP - was versprichst du dir davon, da noch
> mbed rein zu pfriemeln? Welche mbed-Features möchtest du nutzen?

Das weiss ich nicht. Ich weiss nicht viel ueber die STM32. Deshalb steht 
da
oben ja auch "Einsteigerfragen".
Aber grundsätzlich hielt es es für eine gute Idee, das mal 
auszuprobieren.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
https://os.mbed.com/questions/84077/Ethernet-support-for-STM32H7/

hier ist der mbed fork mit Ethernet für H743:
https://github.com/CurryGuy/mbed-os/tree/test-stm32h7-emac

Ich kenne die Unterschiede im Emac zwischen F7 und H7 nicht, aber durch 
die HAL scheint die Portierung nach H7 nicht so aufwändig zu sein. 
Natürlich können kleine Unterschiede grosse Wirkung haben und manchmal 
benennt ST einfach was um, aber das ist doch schonmal ein Ansatz.
Die Treiber und den Zusatz für den H7 findest du hier:
https://github.com/CurryGuy/mbed-os/tree/test-stm32h7-emac/features/netsocket/emac-drivers/TARGET_STM_EMAC

mbed wird da nicht reingepfriemelt, es ist das OS mit einem 
einheitlichen API. Für die Implementierung wird für die STM32 HAL/LL 
benutzt, daher kann man fehlende Devices gut mit Code von CubeMX 
ergänzen. Bei anderen Targets wie z.B. NXP, Atmel oder Nordic werden 
deren Frameworks benutzt oder bei älteren NXP auch nur 
Registerprogrammierung. Deswegen sind die oft bei den kleineren µC mit 
mbed2 besser geeignet.
Der Vorteil eines OS ist da einfach auf ein anderes Board wechseln zu 
können, sogar Herstellerübergreifend.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Besten Dank fuer das Makefile - aber das
> steigt sofort aus mit:

Oh, es muss "-include" sein. Im Anhang ein aktualisiertes Makefile mit 
noch ein paar mehr Verbesserungen. Man kann "make DEBUG=y" übergeben für 
einen Debug-Build.

Wicki W. schrieb:
> und nein, ich schreibe normalerweise keine Makfiles von Hand.
> Hab also keine Erfahrung damit

Wie soll das dann gehen? Kein Makefile, keine IDE, sondern...?

Johannes S. schrieb:
> mbed wird da nicht reingepfriemelt, es ist das OS mit einem
> einheitlichen API.

In ein bestehendes HAL-Projekt mbed einzubauen klingt 
verkehrt/fehleranfällig, gerade weil eben noch keinerlei OS-APIs benutzt 
werden. Vor allem weil das ein leeres Projekt ist, wäre es sinnvoller, 
direkt ein mbed-Projekt anzulegen, wenn man denn überhaupt die mbed-APIs 
nutzen will.

: Bearbeitet durch User
von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
> Oh, es muss "-include" sein. Im Anhang ein aktualisiertes Makefile mit
> noch ein paar mehr Verbesserungen.


ja, danke!
jetzt passt es. und compiliert.
funktionieren tuts aber leider noch nicht.

aber das ist eine basis von der aus ich weiter machen kann.


> Wie soll das dann gehen? Kein Makefile, keine IDE, sondern...?

meine sachen laufen alle per script. makefiles brauche ich
bislang nur selten.




> hier ist der mbed fork mit Ethernet für H743:

ja, ebenfalls danke.
damit komme ich jetzt auch schon ein bisschen weiter.


mal sehen, wohin das noch führt.....

von Niklas G. (erlkoenig) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> meine sachen laufen alle per script. makefiles brauche ich
> bislang nur selten.

Wie erwähnt sind Makefiles für größere Projekte sinnvoller, da 
schneller...

Wicki W. schrieb:
> funktionieren tuts aber leider noch nicht.

Das Projekt ist ja auch praktisch leer und tut nichts.

Im Anhang nochmal eine etwas verbesserte/aufgeräumte Version des 
Makefiles.

von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Bei jeder kleinsten Änderung alles neu zu kompilieren
> wird schon nervig.... Shell-Scripte sind hier doch ziemlich
> überholt.

Das war und ist nicht das Thema, sondern wie man OHNE eine IDE und 
dediziert OHNE Windows ne Quelle übersetzt. Alles unter dem Begriff 
Einsteigerfragen.

Ne simple Batch-Datei oder ein ebenso simples Script mögen zwar 
langsamer sein als Make, weil eben alles übersetzt wird.

Aber sie haben einen gewaltigen Vorteil: Sowas kann JEDER (oder sollte 
es zumindest), ohne sich zuvor in die Syntax und das Grundverständnis 
eines jeden MAKE's eingearbeitet zu haben. Batch oder Skript sind wohl 
die simpelsten Methoden und eben deshalb leicht lesbar, überschaubar und 
damit auch zuverlässig. Es gibt keine Fallstricke wie vorübersetzte 
Header, Mismatch von Datumsstempeln und dergleichen.

Und ja, Make's gibt es viele und jedes hat seine eigene Syntax, die 
natürlich komplett inkompatibel ist zu jedem anderen Make.

Aber mal abgesehen davon: Warum meinst du, daß das Übersetzen damit 
langsamer ist als bei Make - das Weglassen wegen Datumsstempel bei Make 
mal außen vorgelassen.

Ich sehe das eher so, daß das Übersetzen immer dann langsam wird, wenn 
in einzubindenden .h Dateien ellenlange Romane geschrieben wurden und 
eben zuviel Indirektion betrieben wird.

Siehe z.B. die blutige Auseinandersetzung hier im Forum, wo es Leute 
gibt, die lieber 30x eine > 1 MB große Headerdatei sich reinziehen 
wollen, um dort das
#define SYSAHBCONTROLSETPLIMPLUMIENOTMASK ~(1<<3)
und das
#define SYSAHBCONTROLSETPLIMPLUMIESETMASK (1<<3)
und das
#define SYSAHBCONTROLSETPLIMPLUMIEBIT 3
zu finden - anstelle nen leserlichen Code zu schreiben, der auf unnötige 
Indirektionen solcher Art verzichtet.

W.S.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Aber sie haben einen gewaltigen Vorteil: Sowas kann JEDER (oder sollte
> es zumindest), ohne sich zuvor in die Syntax und das Grundverständnis
> eines jeden MAKE's eingearbeitet zu haben.

Makefiles schreiben ist aber eine ziemliche Grundlage. Weil das so 
hilfreich und so verbreitet ist, sollte das jeder lernen.

W.S. schrieb:
> Und ja, Make's gibt es viele und jedes hat seine eigene Syntax, die
> natürlich komplett inkompatibel ist zu jedem anderen Make.

GNU Make ist in diesem Bereich sehr verbreitet. Bei der Syntax gibt es 
einen kleinsten gemeinsamen Nenner, der sehr wohl kompatibel ist.

W.S. schrieb:
> Aber mal abgesehen davon: Warum meinst du, daß das Übersetzen damit
> langsamer ist als bei Make

Weil ein simples Shell-Script immer alles neu kompiliert, und ohne 
weiteres nicht mehrere Compiler-Aufrufe parallel startet. Bei make ist 
das gratis mit dabei; damit kann man Mehrkern-Prozessoren effektiv 
nutzen. Bei größeren Projekten wie diesem kann das die Zeit auf einen 
Bruchteil reduzieren.

W.S. schrieb:
> Siehe z.B. die blutige Auseinandersetzung hier im Forum, wo es Leute
> gibt, die lieber 30x eine > 1 MB große Headerdatei sich reinziehen
> wollen, um dort das

Include-Guards verhinden die 29 Aufrufe. Außerdem sind die paar 
Millisekunden für die Konstanten ein gern bezahlter Preis für die 
Vermeidung von Magic Numbers. Bei "1 << 3" weiß keiner was das Bit jetzt 
bedeutet.

Das Schreiben eines Makefiles welches paralleles Kompilieren ermöglicht 
ist immer noch viel besser und effektiver als das Vermeiden von ein paar 
Makros.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
> Das war und ist nicht das Thema, sondern wie man OHNE eine IDE und
> dediziert OHNE Windows ne Quelle übersetzt. Alles unter dem Begriff
> Einsteigerfragen.

Danke!
Sehr schön zusammengefasst.

Wie soll man als Neuling auf diesem Board und mit diesen Werkzeugen auf 
so was kommen:

------------------------
In der syscalls.c muss man am Anfang noch folgendes einfügen:
int _getpid(void) __attribute__((used));
[....]
int _execve(char *name, char **argv, char **env) __attribute__((used));
In der "Src/lwip.c" muss man die "#if defined ( __CC_ARM )"
auskommentieren. kA warum die da sind.
-------------------------

Jetzt hab ich 2 kommandozeilenfaehige Varianten (mit make und mbed)
Besten Dank dafür.

und jetzt muss mich jetzt mal für eine davon entscheiden...

Aber erst werde ich noch ein bisschen rumprobieren.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Wie soll man als Neuling auf diesem Board und mit diesen Werkzeugen auf
> so was kommen:

Indem man diese Datei von der jeweiligen IDE anlegen lässt oder aus 
einem Beispiel/Template übernimmt. Wenn man alles von Hand macht muss 
man das eben selbst wissen. Konkret ist das "used" nötig, weil es sonst 
bei aktiviertem LTO Linker-Fehler gibt, weil diese Funktionen nicht aus 
dem eigenen Sourcecode sondern aus der C-Library referenziert werden.

von (Gast)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
>> Bei jeder kleinsten Änderung alles neu zu kompilieren
>> wird schon nervig.... Shell-Scripte sind hier doch ziemlich
>> überholt.
>
> Das war und ist nicht das Thema, sondern wie man OHNE eine IDE und
> dediziert OHNE Windows ne Quelle übersetzt. Alles unter dem Begriff
> Einsteigerfragen.
>
> Ne simple Batch-Datei oder ein ebenso simples Script mögen zwar
> langsamer sein als Make, weil eben alles übersetzt wird.

Einen solchen Einsteiger dann mit ".xcl" in die Wüste zu schicken ist 
aber auch nicht nett.

Makefiles sind schon ein Standard, wenn man sich beschränkt dann 
funktioniert das selbe Makefile mit Microsoft NMAKE, BSD make, GNU make, 
standard SYSV make und vermutlich auch Turbo- oder Borland-make.

Was im Fall des TO den Einstieg natürlich auch erschwert, ist die 
ausgewählte Hardware: der H743 ist aus der STM32 Microcontroller-Reihe 
ja die Maximalvariante. Refman hat >4000 Seiten. Kein Wunder dass da der 
eine oder andere Fallstrick lauert.

So ein Projekt mit Filesystem, RTOS, lwip, diversen Treibern und 
eventuell auch noch einigen C++ Quellen (mbed) hat schon mal einige zig 
bis hundert Quelldateien, wenn man die immer komplett neu übersetzt weil 
das dumme Shellskript nicht weiss was wovon abhängig ist wird das bald 
keinen Spass mehr machen.

Ein richtig erstelltes Makefile übersetzt nur Dateien neu die sich 
gegenüber dem letzten Lauf geändert haben bzw. deren Abhängigkeiten. Da 
man normalerweise ja nicht an allen Stellen gleichzeitig arbeitet spart 
man sich da bald einiges an Wartezeit.

Probleme mit Zeitstempeln gibts normalerweise nur mit Netzlaufwerken und 
nicht synchronisierten Uhren und mit FAT-Dateisystemen, die den 
Zeitstempel nur auf 2s genau aufgelöst abspeichern, aber in den (fast 
schon) 20ern des 21. Jahrhunderts sollten diese Dinge längst überwunden 
sein.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> und
> dediziert OHNE Windows

Und dann postest du xcl-Scripte?......

kopfschüttel

Als eingefleischter Linuxer mußte ich erst mal googeln, was das 
überhaupt ist.

Daß man sowas bereits seit Jahrzehnten mit makefiles macht wurde ja 
bereits ausreichend oft gesagt.

von Holm T. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
[..]
>
> solltest du mit links in ein Shellskript umschreiben können. Wer Linux
> benutzt, der hat sowas gefälligst auch zu können.
[..]
>
> W.S.

..warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
die dafür gedacht sind?

Kopfschüttel,

Holm

von Bernd K. (prof7bit)


Bewertung
4 lesenswert
nicht lesenswert
Holm T. schrieb:

> warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
> die dafür gedacht sind?
>
> Kopfschüttel,
>
> Holm

Weil ws ein Sturkopf ist der alles ablehnt was andere jemals für 
nützlich befunden haben denn dann hat er es nicht selbst erfunden und es 
kann deshalb nur scheisse sein.

Er hat NIH-Syndrom im letzten Stadium. Wenn er könnte würde er sich 
seinen eigenen Compiler schreiben, in DOS batch, das schafft er aber 
nicht und das nagt an ihm. Deshalb ist er so wie er ist.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
ist wirklich schön hier bei Euch.
Ihr tut viel gutes für die Menschen.....

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Naja, bei einer handvoll Quellen die in Nullkommanix kompilieren kann 
man ja mit Batchfiles leben wenn man make nicht verwenden will. Aber die 
heutigen Monster-CPUs wie hier ein STM32H743 mit 2 MB Flash / 1 MB RAM 
haben doch mehr Power und eingebaute Peripherie als ein alter 386er PC 
und entsprechend kann man da grössere Projekte mit starten. Alleine mit 
der Taktkonfiguration kann man Tage/Wochen verbringen. Aber sowas 
braucht ein Hobbyist ja alles nicht, der soll sich gefälligst an ein 
paar blinkenden LED erfreuen.

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
Mal eine ernst gemeinte Frage an die User, die ihre Projekte per 
Kommandozeile bauen und flashen:

Wie sieht bei Euch das Debugging einer Anwendung aus?

Wie Johannes S. treffend schreibt, kann man bei einem H7 Tage/Wochen mit 
der Konfiguration der Peripherie verbringen und ohne sinnvolle 
Debug-Möglichkeiten (die ich mir in der Kommandozeile sehr übersichtlich 
vorstelle) würde ich den Spaß der ganzen Aktion als sehr gering 
einstufen...

von Niklas Gürtler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Michael F. schrieb:
> die ich mir in der Kommandozeile sehr übersichtlich vorstelle

Über den GDB geht das schon. Die IDE/GUI greift da letztlich auch nur 
drauf zu. In der GUI ist es nur etwas komfortabler, die Möglichkeiten 
sind gleich. Manchmal benutze ich auch den GDB auf der Konsole weil 
Eclipse irgendwas durcheinander bringt...

von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
rµ schrieb:
> Einen solchen Einsteiger dann mit ".xcl" in die Wüste zu schicken ist
> aber auch nicht nett.

Hä? Also ich habe davon zwei Stück gepostet, dazu nen auszug aus einer 
Batchdatei. Das ist alles sehr einfach gestrickt und damit les- und 
verstehbar, ohne daß man erstmal irgendwo nachschlagen müßte.

Und .xcl findet sich auch in der Dokumentation des GCC - die allerdings 
muß man wirklich suchen.

Das Problem ist also gar keines.

Und nochwas: lies mal den Eröffnungspost. Wer über Windows und IDE's 
klagt und erst mal sowas anfragt:

Wicki W. schrieb:
> Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die
> Commandline zu programmieren oder wird man  dann an irgendwas scheitern?

..dem ist sehr wohl damit geholfen, wenn er zuvörderst sein 
allerersten HelloWorld mit einer popligen Batchdatei/Shellscript 
übersetzt kriegt.

Von riesengroßen Projekten mit hunderten von Dateien war und ist hier 
nicht die Rede, sondern von der Frage, ob Wicki es ÜBERHAUPT von der 
Kommandozeile hinbekommt.



Holm T. schrieb:
> ..warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
> die dafür gedacht sind?
>
> Kopfschüttel,

Ebenso Kopfschüttel meinerseits, weil du nix kapiert hast.

Grund: Wenn einer hier anfragt, weil er noch nie seinen Compiler auf der 
Kommandozeile aufgerufen hat sondern nur IDE's kennt, dann hat er auch 
noch nie Make benutzt und er kennt deshalb auch noch nicht dessen 
Syntax.

DARUM!

Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

W.S.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Von riesengroßen Projekten mit hunderten von Dateien war und ist hier
> nicht die Rede

Doch:

Wicki W. schrieb:
> https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

W.S. schrieb:
> Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

Schon passiert:

Niklas G. schrieb:
> Im Anhang nochmal eine etwas verbesserte/aufgeräumte Version des
> Makefiles.

Ist ja auch nicht so schwierig. Warum man da erst lange rumeiert...

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
> W.S. schrieb:
> > Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

> Schon passiert:
> Ist ja auch nicht so schwierig. Warum man da erst lange rumeiert...

ja - und nochmals besten dank dafuer!

natuerlich habe ich auch schon makefile geschrieben.
das ist aber

a) schon lange her
und
b) immer erst dann passiert, wenn ueberhaupt
   klar ist, wohin der weg fuehren soll


natuerlich findet man auch fuer stm32 1000de beispielsourcen.
deutlich weniger findet man fuer den h743zi und eth.
und das sind alles eclipse&co-beispiele. (jedenfalls die,
die ich gefunden habe)

und ich fuehle mich von dem zeugs entmuendigt.
kann man benutzen, wenn man feststellt, dass man es
irgendwann braucht.

anfangen moechte ich damit aber nicht.

im moment bin ich eh eher geneigt, die ganze stm32-kiste
beiseite zu legen.
interessant, mal rein zu sehen - einige sachen sind toll.
aber zu infaltionaer und unuebersichtlich sind die IDEs,
compiler, libs und board-typen.
zumindest fuer meinen geschmack.


munter bleiben

wicki

von (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Niklas G. schrieb:
> W.S. schrieb:
>> Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

Normalerweise ist es ja nicht nachhaltig zielführend wenn man eine 
vorgekaute Lösung präsentiert, beim nächsten ähnlichen Problem steht der 
Fragesteller dann ja wieder gleich da.

Gscheiter ist es IMHO Möglichkeiten aufzuzeigen wie man dann zu so einem 
Makefile kommt. Von RTFM abgesehen gäbs eben auch die Möglichkeit, sich 
von einer IDE eins erzeugen zu lassen. Die IDE muss man danach ja nicht 
verwenden. Spätestens beim Debuggen wirds ohne GUI aber schnell recht 
unübersichtlich, das ist nur hardcore Textmode-Freaks zu empfehlen, die 
haben aber solche Probleme wie "wie komme ich zu einem Makefile" nicht.

Egal.

Mich interessiert eigentlich die ursprüngliche LinuxCNC-Anwendung, ich 
hoffe es gibt noch Updates wie die Geschichte weitergeht.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> und unuebersichtlich sind die IDEs,
> compiler, libs und board-typen.

Dann fang doch mal mit einem kleineren STM32 an, z.B. dem allseits 
beliebten STM32F103. Den kann man ganz gut ohne Bibliothek (außer 
Register-Definition) programmieren. Dafür gibt's auch die handlichen und 
billigen Bluepill-Boards.

Wenn du den größten Controller der Familie aussuchst, Ethernet und 
TCP/IP haben willst, wird es ohne komplexe Bibliotheken schwierig! Oder 
erwartest du, dass der Prozessor TCP in Hardware spricht?

rµ schrieb:
> Normalerweise ist es ja nicht nachhaltig zielführend wenn man eine
> vorgekaute Lösung präsentiert

Tja, es ist irgendwie irritierend wenn hier so lange um den heißen Brei 
diskutiert wird. Da möchte man manchmal Tatsachen schaffen.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> und ich fuehle mich von dem zeugs entmuendigt.
> kann man benutzen, wenn man feststellt, dass man es
> irgendwann braucht.

Manchmal ist der umgekehrte Ansatz zielführender. Im Codegenerator alles 
reinpappen was man brauchen wird, und so schnell wie möglich auf dem 
Nucleo zumindest prinzipiell zum Laufen zu bringen.

Dann den generierten Code anschauen und eventuell ausdünnen.

> im moment bin ich eh eher geneigt, die ganze stm32-kiste
> beiseite zu legen.
> interessant, mal rein zu sehen - einige sachen sind toll.
> aber zu infaltionaer und unuebersichtlich sind die IDEs,
> compiler, libs und board-typen.
> zumindest fuer meinen geschmack.

Die mbed-seite führt einen haufen unterstützte Boards auf mit Ethernet:
https://os.mbed.com/platforms/?q=&Communication=Ethernet

Eventuell ist es einfacher, vom H743 auf einen gängigeren µC mit 
offiziellem mbed-support zu wechseln wie Nucleo-F429ZI, Nucleo-F746ZI 
o.ä, die 25€ sind schnell an gesparten Nerven/nicht ausgerupften Haaren 
wieder eingespart.

Nur als Hinweis: die selbe Geschichte mit NXP LPC 1769 (LPC xpresso) als 
Basis ist auch nicht weniger komplex (mEn). Ein TCP/IP-Stack ist halt 
mal ein großer Brocken SW der auch einiges an "Verhalten" hat, da 
passiert viel im Hintergrund.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Mich interessiert eigentlich die ursprüngliche LinuxCNC-Anwendung, ich
> hoffe es gibt noch Updates wie die Geschichte weitergeht.

da bin ich selbst gespannt. die sourcen des bulgarischen entwicklers
habe ich noch nicht compiliert bekommen.
irgendwas stimmt mit den headern nicht.
denn er included  stm32f4xx_hal_conf.h aber laufen soll es
doch auf einer stm32f743-hardware...

und auf seiner seite ist es ein zeitliches problem - und ein problem,
dass er kein linux-mensch ist....

vorschlag:
ich frage den entwickler aus bulgarien, ob er bereit ist, seine
sourcen offen zu legen. (die liegen z.zt. in einer pw-geschuetzten
google-cloud und ich kann sie nicht ohne rueckfrage einfach weitergeben)

es wuerde die sache erheblich einfacher gestalten, wenn die sourcen
offen liegen

so ist die kommunikation doch etwas schwierig.....

von Niklas Gürtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> vorschlag:
> ich frage den entwickler aus bulgarien, ob er bereit ist, seine
> sourcen offen zu legen. (die liegen z.zt. in einer pw-geschuetzten
> google-cloud und ich kann sie nicht ohne rueckfrage einfach weitergeben)

Am besten auf GitHub mit entsprechender Open Source Lizenz (GPL, MIT, 
BSD, ...) dann kann jeder damit arbeiten und Änderungs Vorschläge 
einreichen.

von Holm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> Michael F. schrieb:
>> die ich mir in der Kommandozeile sehr übersichtlich vorstelle
>
> Über den GDB geht das schon. Die IDE/GUI greift da letztlich auch nur
> drauf zu. In der GUI ist es nur etwas komfortabler, die Möglichkeiten
> sind gleich. Manchmal benutze ich auch den GDB auf der Konsole weil
> Eclipse irgendwas durcheinander bringt...

Es sollte auch nicht verschwiegen werden das es Frontents für den GDB 
gibt ..so wie DDD (Data Display Debugger) die da ein Stück weit Komfort 
ermöglichen.

Von Eclipse habe ich mich verabschiedet nach dem Versuch die für MSP430, 
Atmels und die Host CPU (AMD64) gleichzeitig benutzbar zu machen, 
natürlich nur ein Projekt gleichzeitig. Nach einer Woche habe ich 
eingesehen das das ein Projekt für zukünftige Generationen ist.. und 
nehme die Kommandozeile..über einen Terminalmultiplexer namens x11.

Gruß,

Holm

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Von Eclipse habe ich mich verabschiedet nach dem Versuch die für MSP430,
> Atmels und die Host CPU (AMD64) gleichzeitig benutzbar zu machen,

Host (AMD64) mit C++, Java, Ruby und Target mit Cortex-M (STM32, LPC) 
mit C++ war bei mir kein Problem mit Eclipse (auch wenn alles 
gleichzeitig offen).

von Holm T. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
[..]
>
> Holm T. schrieb:
>> ..warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
>> die dafür gedacht sind?
>>
>> Kopfschüttel,
>
> Ebenso Kopfschüttel meinerseits, weil du nix kapiert hast.
>
> Grund: Wenn einer hier anfragt, weil er noch nie seinen Compiler auf der
> Kommandozeile aufgerufen hat sondern nur IDE's kennt, dann hat er auch
> noch nie Make benutzt und er kennt deshalb auch noch nicht dessen
> Syntax.
>
> DARUM!

...sollte er sich von Begin an auf das falsche Werkzeug einlassen?

Kennst Du exec(), execve(), fork() und system()? Warum schlägst Du dem 
TO nicht vor den Build Prozess durch ein C-Programm zu steuern?
>
> Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?
>
> W.S.

Gegenfrage: Du schreibst Shellscripte (Batch Dateien) für den TO für 
lau?
Mach mir mal eins für DCL bitte...

(evtl. hilfreich: 
https://www.dcl.hpi.uni-potsdam.de/teaching/serveros/OpenVMS/uebung/OpenVMS-DCL.pdf 
)

Für Dich gilt offensichtlich der Ansatz: "wenn ein Hammer das einzige 
Werkzeug ist das man besitzt, dann fängt Alles um einen herum an wie ein 
Nagel auszusehen" ..in verschärfter Form.

Die Shell Scripte sind schon alleine deshalb Kokolores, weil sie 
zwischen verschiedenen OS nicht portabel sind, make aber bis auf geringe 
Unterschiede schon.

Gruß,

Holm

von Holm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Holm T. schrieb:
>> Von Eclipse habe ich mich verabschiedet nach dem Versuch die für MSP430,
>> Atmels und die Host CPU (AMD64) gleichzeitig benutzbar zu machen,
>
> Host (AMD64) mit C++, Java, Ruby und Target mit Cortex-M (STM32, LPC)
> mit C++ war bei mir kein Problem mit Eclipse (auch wenn alles
> gleichzeitig offen).

Ok, es ist ein paar Jahre her das ich das auf dem Tisch hatte. 
Möglicherweise hat sich da was verbessert, aber außer seitenlangen Java 
Fehlermeldungen habe ich nicht viel Vernünftiges damit produzieren 
können, mal abgesehen davon das ich mir jedes Mal einen Wolf gesucht 
habe um irgendwelche Pfade oder Compileroptionen irgendwo ändern zu 
können. Da war IMHO noch mit Eclipse Helios.


Gruß,

Holm

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
hi zusammen,

hier die antwort aus bulgarien

web page
http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=18671&start=200

Files
http://www.cnc-club.ru/forum/download/file.php?id=148983
http://www.cnc-club.ru/forum/download/file.php?id=148984
http://www.cnc-club.ru/forum/download/file.php?id=148987
http://www.cnc-club.ru/forum/download/file.php?id=148988


Im wesentlichen gehts um die Sourcen, die in
http://www.cnc-club.ru/forum/download/file.php?id=148984
drin steckt:

EthernetCNC_ver3

den rest kenne ich auch erst seit gerade eben...

mein russisch ist jetzt auch nicht sonderlich gut... ;-)

aber mir ist nicht klar, wo denn nun der bezug zum h743
herkommen soll...

ich vermute mal fast:
den gibts gar nicht...

von Wicki W. (wicki)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab jetzt mal in

system/include/cmsis/stm32f4xx.h

testweise

    #define STM32F437xx

aktiviert

das Makefile auf meine config angepasst und versucht zu compilieren.
Hier steigt er aus.
Auch wenn ich

system/lwip/src/include/lwip/netifapi.h

in der err_t definiert ist, explizit include:


system/lwip/src/netif/ethernetif_template.c: At top level:
system/lwip/src/netif/ethernetif_template.c:72:8: error: unknown type 
name 'err_t'
 static err_t low_level_output(struct netif *netif, struct pbuf *p)


vermutlich sehe ich grad wieder den Wald vor lauter Baeumen nicht...

von Niklas G. (erlkoenig) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> #define STM32F437xx

Das ist verkehrt; das Makro kommt ins Makefile. Da da schon das Makro 
für den H7 stand, kollidiert das.

Wicki W. schrieb:
> system/lwip/src/netif/ethernetif_template.c: At top level:

Die Datei soll wohl gar nicht mitkompiliert werden ("template").

Mit dem Makefile im Anhang gehts. Ich habe dort mal die Source-Dateien 
explizit angegeben statt sie automatisch zu suchen; ist sauberer und 
vermeidet das Kompilieren dieser "template" Datei und der 
"utils/sendconfig.c".

In der src/main.cpp muss noch die Definition der main-Funktion 
korrigiert werden:
int
main(int, char* [])

Und in der system/src/cmsis/vectors_stm32f4xx.c müssen Zeilen 195-196 
auskommentiert/gelöscht werden.

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Es sollte auch nicht verschwiegen werden das es Frontents für den GDB
> gibt ..so wie DDD (Data Display Debugger) die da ein Stück weit Komfort
> ermöglichen.

Danke für die Info :-)

Ich hab mir jetzt einiges zum GDB und dem DDD angeschaut muss 
feststellen, dass das dann doch nicht meine Welt ist...

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
"Mit dem Makefile im Anhang gehts."


Ja super!
Besten Dank.

und ehrlich gesagt, darauf dass ethernetif_template.c gar nicht
compiliert werden soll, waere ich so schnell nicht gekommen.
hab den namen gar nicht wirklich zur kenntnis genommen...

Mal sehen, wie wir jetzt weiter kommen.

ich meld mich.....

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
ok, nun hab ich den Kram compiliert.

Hab jetzt auch ganz tolle Ergebnisse:

drwxrwxr-x  4,0K Jun 15 13:49 system
drwxrwxr-x  4,0K Jun 15 15:42 src
-rwxrwxr-x  221K Jun 15 15:42 Prog.elf
-rw-rw-r--  107K Jun 15 15:42 Prog.hex
-rwxrwxr-x   99K Jun 15 15:42 Prog.bin
-rw-rw-r--  600K Jun 15 15:42 Prog.disas


bin nun aber nicht wirklich schlauer:

ist das Zeugs nun auf dem h743 lauffähig oder
nicht?

und wenn es lauffähig ist:
wie bekomme ich es auf das Board drauf?

einfach das .bin nach
 /media/user/NODE_H743ZI/
zu kopieren reicht hier wohl nicht.

mein bulgarischer freund hüllt sich derzeit
auch noch in schweigen.
kann mir hier jemand weiterhelfen?

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> ist das Zeugs nun auf dem h743 lauffähig oder
> nicht?

Ich dachte das ist für den STM32F437xx?!

Wicki W. schrieb:
> wie bekomme ich es auf das Board drauf?

Welches Board denn jetzt? Hängt vom verwendeten Tool ab! Die .elf Datei 
kannst du in GDB laden, welcher sich z.B. mit dem J-Link GDB-Server, 
oder mit den OpenOCD, oder dem texane st-link Tool verbindet. Die .bin 
oder .hex Datei kannst du mit dem JLink Commander, dem ST-Link-Utility 
(Windows Only) oder dem texane stlink tool direkt laden.

Bei den neueren ST-Links müsste sich die .bin Datei auf das simulierte 
Mass Storage kopieren lassen. Allerdings ist das wenig hilfreich, weil 
es in einem derart komplexen Programm bestimmt viel zu debuggen gibt.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
moin, moin,


Niklas G. schrieb:
>> ist das Zeugs nun auf dem h743 lauffähig oder
>> nicht?
> Ich dachte das ist für den STM32F437xx?!

es ging immer um den hier
---------------
STM32 by ST NUCLEO-H743ZI Nucleo Development Board
https://www.amazon.de/gp/product/B077NDX82H/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
---------------

das board wurde mir genannt - darauf soll das zeugs laufen. sagte der 
(weiter-)entwickler
aus bulgarien.


>> wie bekomme ich es auf das Board drauf?
>
> Welches Board denn jetzt? Hängt vom verwendeten Tool ab! Die .elf Datei
> kannst du in GDB laden, welcher sich z.B. mit dem J-Link GDB-Server,
> oder mit den OpenOCD, oder dem texane st-link Tool verbindet. Die .bin
> oder .hex Datei kannst du mit dem JLink Commander, dem ST-Link-Utility
> (Windows Only) oder dem texane stlink tool direkt laden.
>
> Bei den neueren ST-Links müsste sich die .bin Datei auf das simulierte
> Mass Storage kopieren lassen. Allerdings ist das wenig hilfreich, weil
> es in einem derart komplexen Programm bestimmt viel zu debuggen gibt.

d.h.: wenn ich das .bin rueber kopiere, sollte es laufen?
(mit den blinkey-testprogrammen oder den sensor-readern klappt das auch)

d.h.:
wenn ich in "main" hier eine ausgabe, led-blink oder sonstwas
einbaue, dann muesste es gehen?

        while (1)
        {
          LWIP_Process();
        }

mich macht halt nur stutzig:
wenn ich eine "blink-demo" rueber kopiere, dann dauert das 1-2 sekunden
bis es drueben ist und laeuft.
wenn ich das .bin aus dem o.g. paket rueber kopiere, ist es sofort 
drueben
und es passiert weiter nichts....


nun ist aber eh erst mal pause.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> das board wurde mir genannt - darauf soll das zeugs laufen. sagte der
> (weiter-)entwickler
> aus bulgarien.

Schwer zu glauben, da der ganze Code sich auf den STM32F4 bezieht. Da 
müsste man erst aufwendig einiges portieren.

Wicki W. schrieb:
> d.h.: wenn ich das .bin rueber kopiere, sollte es laufen?

Wenn der Code zum Controller passt, was ich nicht glaube.

Wicki W. schrieb:
> und es passiert weiter nichts....

Der Code wird nicht vernünftig starten, weil er für einen F4 ist.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Schwer zu glauben, da der ganze Code sich auf den STM32F4 bezieht. Da
> müsste man erst aufwendig einiges portieren
.....
> Der Code wird nicht vernünftig starten, weil er für einen F4 ist.

das war auch meine vermutung.
aber gerade kam die rueckmeldung aus bulgarien:

---------
When I was test my discovery board I used ST-LINK to
upload HEX file under windows ... :( .... not BIN file ..
---------

aber dessen nucleo-board ist auch ein f4....

grundsaetzlich sind aber hex/bin nur unterschiedliche
formate fuer unterschiedliche upload-modi, nehme ich an?


also muss ich mal versuchen, die anpassungen fuer den 7h
vorzunehmen. allerdings sehe ich da ziemlich schwarz.
mit dem austausch von ein paar headern wird es wohl nicht
erledigt sein.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> ---------
> When I was test my discovery board I used ST-LINK to
> upload HEX file under windows ... :( .... not BIN file ..
> ---------

Das macht praktisch keinen Unterschied.

Wicki W. schrieb:
> grundsaetzlich sind aber hex/bin nur unterschiedliche
> formate fuer unterschiedliche upload-modi, nehme ich an?

Hex und Bin enthalten fast die gleichen Informationen. Die Hex-Datei 
enthält zusätzlich die Ziel-Adressen; bei der Bin-Datei muss man die 
beim Flashen mit angeben.

Wicki W. schrieb:
> also muss ich mal versuchen, die anpassungen fuer den 7h
> vorzunehmen. allerdings sehe ich da ziemlich schwarz.

Ja, das könnte ein beträchtlicher Aufwand sein, je nachdem wie das 
programmiert ist. Kauf einfach das passende STM32F4-Board...

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:

> Ja, das könnte ein beträchtlicher Aufwand sein, je nachdem wie das
> programmiert ist. Kauf einfach das passende STM32F4-Board...


das haette ich ja getan - aber das "passende" STM32F4-Board gibt
es nicht.

"pekka" hat eine eigene hardware gebaut, "emil" hat diese auf
sein nucleo-f4-board portiert.
das hat aber wohl keine eth-schnittestelle.
von ihm war dann der vorschlag, es mit dem h743-board (weil: das
hat alles) zu probieren.

da wusste ich aber noch gar nichts von STM32 - ausser, dass
es welche gibt.

zumindest weiss ich jetzt, was das problem ist....

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> das haette ich ja getan - aber das "passende" STM32F4-Board gibt
> es nicht.

Oh nein... Dann musst du es eben portieren. Das hat dann aber nichts 
mehr mit STM32-Mit-Linux oder mbed zu tun.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Das hat dann aber nichts
> mehr mit STM32-Mit-Linux oder mbed zu tun.

aber es ist schon hilfreich, dass man sourcen compilieren
kann, wenn man aenderungen im source vornimmt - da sind
wir uns einig, hoffe ich.

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

nach urlaubs- und kranheitsbedingten Pausen nun mal ein weiterer
Anlauf.

Ich hänge hier unten mal Auszuege unseres Mailwechsels (Pekka aus 
Finnland,
Emil aus Bulgarien und mir aus .de) dran.

Wir sind alle 3 keine STM32-Profis (ich am wenigsten).
Uns/mir ist es jedenfalls bis jetzt noch immer nicht gelungen,
auf dem dem H7-Board wenigstens mal einen pingbaren IP-Stack
zum laufen zu bekommen.

Und ich habe inzwischen schon viele IDEs ausprobiert.
Irgendwo hakt es immer.

Am besten gefallen hatte mir bislang mbed. Aber irgendwie komme
ich da nun auch nicht mehr weiter. Bin etwas entnervt....

Wenn jemand meint, hier helfen zu koennen, dann würde ich mich
ueber eine Meldung freuen.

munter bleiben

wicki

----------------------------------


I hate most of the development environments as well.. :) I have been 
using makefiles and libopencm3 in the most recent projects I've done, 
but haven't bothered transforming the existing ones.. Thanks for working 
on the makefile for my project, I will try that for sure. Unfortunately 
my ~ten words of Deutsch I know is not enough to follow the conversation 
there. :)

Regarding the port to STM32H7 series.. Unfortunately I have no 
experience.I have used the CubeMX tools which are provided by ST to 
generate most of the initializations for the HAL drivers. ( I hate those 
tools as well..) So as the code is partially generated by the ST tools 
and if they have done good job with the drivers, they should be quite 
compatible with other series of their microcontrollers.. But I have 
never tried porting the code to other familes.. But I think you have 
pretty much the same ideas as I, changing the headers and HAL libraries 
to suitable ones and then trying to see if it compiles. I don't know if 
H743 has exactly the same peripherals (Timers etc..) as F407 I have 
used, so there may be other modifications required as well.

If the porting seems very difficult, another way would be to first try 
to make a new project for H743 from scratch, add ethernet functionality 
with LwIP and when that works, the actual "meat" of my firmware should 
be quite easily copied on top of that, it is basically just one LwIP 
"application" to handle the UDP communication and then few files which 
define the different types of IO (stepgen, pwm, encoder etc..). I have 
done pretty much that once, when I changed from some other ethernet 
stack to LwIP.

Sorry for not being able to help too much.. But if you still have some 
questions you think I could have answers, I can try to help.

---------------------------------
[....]
changing the header-files would be a lot of work:

 find -name "stm32*"|egrep "\.h|\.c"|wc
    129

129 files. it will take some time.....
maybe, emil is able to generate automated a new source-package by 
eclipse.
(I'm unable to handle this IDE... shudder)
emil: are you?
If it compiles, we can debug it...

---------------------------------
Yes - there are probably quite many files to modify but I do not believe 
it is that many, if you did that find from the root level of the 
project, you found all the sources of the HAL libraries which you should 
be able to just replace as a whole.

But my advice is maybe going towards the idea of getting the ethernet 
communication to work between you PC and the board. When you are able to 
ping, you are almost there. Then adding from my project should be quite 
easy when doing it piece by piece. You'll also learn about the code as 
you go, and soon you will be able to make it better. :) I must warn you 
that the stepgen part of the code is least used, I use only PWM outputs 
on my CNC mill. But I think Emil was able to make the step generators 
run somewhat sensibly.

You can publish my comments for sure. Like said, I have no German 
skills, but luckily you guys are good in English as well. :)

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> Uns/mir ist es jedenfalls bis jetzt noch immer nicht gelungen,
> auf dem dem H7-Board wenigstens mal einen pingbaren IP-Stack
> zum laufen zu bekommen.

Auch nicht mit den fertigen Beispielen von ST?

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"Auch nicht mit den fertigen Beispielen von ST?"

nein, sonst wäre ich nicht so genervt :-(


inzwischen habe ich hier x IDEs, libs, examples
usw. installiert, dass es nicht mehr zu durchschauen
ist und nur noch ein "komplett reset" einen neustart
sinnvoll erscheinen laest.

also werde ich mal ein virt-image mit debian o.ae.
aufsetzen und dann von dem aus ausgehen.
was den vorteil hat: alle arbeiten dann in der gleichen
umgebung.

das scheint mir momentan der sinnvollste weg zu sein.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> inzwischen habe ich hier x IDEs, libs

An den IDEs liegt's wohl kaum. Wenn die Beispiele von ST selbst 
unmodifiziert nicht gehen, würde ich mal ST kontaktieren.

von Sebastian (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Unter Linux könnte das Ganze mit der Arduino Umgebung laufen.

Das NUCLEO_H743ZI ist hier zumindest aufgeführt.

Beitrag "Re: STM32 Core Arduino Framework"

Im "Official" Core ist's wohl auch drinn:

https://github.com/stm32duino/Arduino_Core_STM32/tree/master/variants

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mbed mit ethernet sollte auf diesen Boards "out of the box" laufen:

https://os.mbed.com/platforms/?q=&Communication=Ethernet&Interface+Firmware=ST-Link&Board+vendor=STMicroelectronics

Falls der fürs H7 Board von CubeMX-generierte Code nicht funktioniert 
würd ich mir die Nerven sparen und die 30€ für ein Nucleo mit einem M4 
oder M7 ausgeben.

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"Unter Linux könnte das Ganze mit der Arduino Umgebung laufen."

vielleicht versuche ich das auch noch mal.

Mit STM32CubeMX kann ich entweder ein Makfile erzeugen, das nicht
maket oder ein object-file, das nichts tut :-(

So ganz langsam verliere ich die Lust.

Man findet youtuut-Videos, deren Tonfall zu einem 
magic-Nicer-Dicer-Verkaeufer auf QVC passen - und Videos, deren Inhalte 
nicht mit den
aktuellen Softwareversionen uebereinstimmen.

Wo sind sie hin, die simplen ASCII-Readme und plain-text-howtos?
Die früher in jedem Softwarepäckchen drin waren.
Aber da musste man ja auch nicht 1GB IDE und libs runterladen
um eine LED blinken zu lassen....

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"würd ich mir die Nerven sparen und die 30€ für ein Nucleo mit einem M4
oder M7 ausgeben."


... um dann nach einem 1/2 Jahr festzustellen, dass diese Board
dann nicht mehr hergestellt wird...

Das neue M24 kann dann vieeel mehr, ist vieeel schneller - nur
leider nicht 100% kompatibel.

Es geht doch nicht um 30 EUR. Es geht darum, dass ich solchen
Kram (wenn er denn mal läuft) auch nach ein paar Jahren wieder
rausholen und weiter bearbeiten kann.
Und diese "Zukunftssicherheit", die sehe ich grade hier nicht,
wenn ich sehe, mit welchem Tempo immer wieder neue Controller,
Boards, Libs, IDEs rausgeworfen werden.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> Es geht doch nicht um 30 EUR. Es geht darum, dass ich solchen
> Kram (wenn er denn mal läuft) auch nach ein paar Jahren wieder
> rausholen und weiter bearbeiten kann.
> Und diese "Zukunftssicherheit", die sehe ich grade hier nicht,
> wenn ich sehe, mit welchem Tempo immer wieder neue Controller,
> Boards, Libs, IDEs rausgeworfen werden.

Dann bist am falschen Dampfer. Solche Totschlagargumente kann man gegen 
jede Art von Hardware ins Feld führen. Die ARM Prozessoren kann man auch 
ohne irgendwelche Libs, IDEs und anderem Kram programmieren, wenn man 
aber UDP über Ethernet reden will ohne eine fertige Lib zu verwenden 
muss man halt 1-2 Jahre rechnen um sich das nötige Know-How anzueignen, 
einen IP-Stack zu implementieren, und dann nochmal so lang um den auch 
ausgiebig zu testen und an die Realität "anzupassen".

Die Nucleos gibts schon eine ganze Weile, auf der ST Seite wird man auch 
finden wie lang diese garantiert hergestellt werden.

Der STM32H7 ist halt recht neu, da wirds nicht ausbleiben dass man sich 
den Feuerwehrschlauch "reference manual" in den Mund steckt und den Hahn 
aufdreht.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> Uns/mir ist es jedenfalls bis jetzt noch immer nicht gelungen,
> auf dem dem H7-Board wenigstens mal einen pingbaren IP-Stack
> zum laufen zu bekommen.
>
> Und ich habe inzwischen schon viele IDEs ausprobiert.
> Irgendwo hakt es immer.

Kann man das etwas konkretisieren?

* Was genau ausprobiert (welche IDEs)
* Woran hakt es

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Der STM32H7 ist halt recht neu

wenn ich das richtig sehe, ist das Board über 2 Jahre alt.
und nach 2 Jahren findet man immer noch kein
"08/15-ping-mich-mal"-Example.

das heißt doch entweder
der Hersteller will das gar nicht wirklich verkaufen
oder
die Kunden wollen das gar nicht wirklich haben

Ich hatte schon MCs in den Fingern, die fand ich persönlich
ätzend. Aber sie hatten gute, aktuelle, vollständige, lesbare
Dokus und sie hatten Support im Netz (durch viele User, die
viel veröffentlichten).
Das sehe ich hier jetzt grad nicht.

Mag sein, dass ich inzwischen ein bisschen Betriebsblind
oder übervorsichtig geworden bin. Aber überzeugen oder gar
begeistern konnte mich das Teil bislang wirklich nicht.

Aber schweife schon wieder vom Thema ab... ;-)

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> rµ schrieb:
>> Der STM32H7 ist halt recht neu
>
> wenn ich das richtig sehe, ist das Board über 2 Jahre alt.
> und nach 2 Jahren findet man immer noch kein
> "08/15-ping-mich-mal"-Example.

Natürlich findet man das, siehe ST AN5033 und UM1709.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> Mit STM32CubeMX kann ich entweder ein Makfile erzeugen, das nicht
> maket oder ein object-file, das nichts tut :-(

Wo genau hakt es denn beim Makefile? Pqck doch mal die Fehlermeldung 
hier rein.

Das "standard"-Makefile welches CubeMX ausspuckt ist schonmal dermaßen 
schlecht geschrieben, dass es auf einer Linuxkiste nicht gleich läuft, 
obwohl der GCC im "Path" ist. Das lässt sich aber relativ einfach 
beheben.

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"Kann man das etwas konkretisieren?"

ich sagte ja:
reset und alles noch mal von vorn.

diesmal ein versuch mit ./STM32CubeMX

auswaehlen, einstellen, Makefile generieren geht soweit.

und nachdem nun der pfad auf
/mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/
zeigt, funktioniert auch das makefile.

es kommt ein .bin dabei raus und das laest sich sogar
nach /media/user/NODE_H743ZI/ kopieren und aendert
das verhalten.

ob es tut, was es soll? kann ich noch nicht sagen.


eine option "SWD" - serial-wire-debug" finde ich
im STM32CubeMX nicht.


mir reichts auch erst mal fuer heute.
aber das STM32CubeMX ein brauchbares makefile generieren
kann find ich schon mal gut.

von Sebastian (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jaja. Die TTB ( Time To BLINK ) Zeit, also die Zeit, die man braucht, 
bis auf dem Mikrocontroller das erste Blinky läuft, ist bei STM ziemlich 
beschissen.

Deshalb liegen meine 20 STM32 Boards vorwiegend in der Ecke und ich 
verwende statt dessen die ESP32.

von nfet (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Kann eure Probleme mit ST in keinster Weise nachvollziehen. CubeMX ist 
mit das Beste (wenn nicht dass Beste) was ich je von einem MCU 
Hersteller gesehen habe.
Man braucht natürlich weiterhin ein Mindestmaß an Verständnis und 
zugegeben, die Konkurrenz ist auch eher schwach.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
"Die TTB ( Time To BLINK ) Zeit, also die Zeit, die man braucht,
bis auf dem Mikrocontroller das erste Blinky läuft, ist bei STM ziemlich
beschissen."

sehr schön umschrieben ;-)


"CubeMX ist mit das Beste (wenn nicht dass Beste) was ich je von einem 
MCU Hersteller gesehen habe."

es ist nicht schlecht - hat auch niemand behauptet...
aber bis man erst mal dabei landet, hat man schon x verschiedene
wege ausprobiert, etwas zum laufen zu bekommen.
(die auch funktionieren, aber alle auch ihre tücken haben)

und der sicherste weg, mich davon abzuschrecken, eine software zu
testen, ist der, mich erst mal nach meiner mailadresse zu fragen
und eine account-einrichtung zu verlangen.

kommt dann noch ein online-compiler oder ähliches dazu, dann
suche ich erst mal nach freien alternativen.
frueher war mehr GNU.... und weniger cookies.

aber ich schweife schon wieder ab... ;-)

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
so ganz allmaehlich hab ich die faxen echt dicke!

offenbar bin es ja nicht nur ich mit dem problem:

"eth will auf dem stm32h743zi nicht"

problembeschreibungen zu hauf - loesungen keine.


cubex gibt auch bei dein einstellungen einen hinweis aus:

 the eth can only work whe ram is pointing at 24000000

aber ich finde keine einstellmoeglichkeit fuer "RAM".

ob das die ursache des nicht-funktionieren ist? keine ahnung.

compiliert bekomme ich inzwischen alles was ich ausprobieren wollte.
letzter versuch war der hier:
https://github.com/MX-Master/LwIP_HTTP_Server_Netconn_RTOS

geht aber auch nicht. eth ist mausetot....

von wicki (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
der merkt doch nix mehr.....


ich habe jetzt x mal alle einstellungen kontrolliert und
entsprechend des readme in LwIP_HTTP_Server_Netconn_RTOS
eingestellt.
es ruehrt sich nichts auf dem eth.
auch das hier passiert nicht:

LEDs will inform user about ethernet cable status:
 + LED2: ethernet cable is connected.
 + LED3: ethernet cable is not connected.

es leuchten nur die LEDs am eth-connector.

und das er jetzt bei den timings 401 MHz als ein vielfaches
von 4 x 200 / 2 errechnet, das ist ja wohl mehr als schraeg.

laufen tut auf dem board was: wenn ich einen led-blink einbaue
oder seriell was ausgebe - das geht.
nur eth nicht

grmbl

von nfet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In deinem clocktree ist ja auch alles rot und in nicht erlaubten 
Bereichen. Vielleicht liegt es ja daran.

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
"In deinem clocktree ist ja auch alles rot und in nicht erlaubten
Bereichen. Vielleicht liegt es ja daran."

die roten hat er sich allesamt selbst gebastelt.

ich sag ja: der merkt nix mehr :-(

die einzige idee, die ich jetzt noch habe ist das hier:


    All data passed to Ethernet peripheral (ETH) must NOT be stored in 
DTCM RAM, since the ETH DMA can't access DTCM RAM (starting at 
0x20000000)
        Projects generated with STM32CubeMX can put variables by default 
to DTCM RAM. The solution is to place them to D1 SRAM (starting at 
0x24000000).


aber "ram", "sram" oder "d1" kann ich im cubemx nirgends
konfigurieren.

von nfet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> die roten hat er sich allesamt selbst gebastelt

Auch wenn er das selbst gemacht hat, musst du dem Programm helfen, das 
Problem zu lösen. So schlau ist Cube dann doch nicht, das es alle clock 
Kombinationen gelöst bekommt. Wenn du es einfach so lässt wird es nicht 
gehen.

Wo die Dinge aus deinem Programm gespeichert werden kannst du über das 
Linkerscript beeinflussen.

Wenn du gcc als Compiler und linker nimmst, dann hat das Linkerscript 
die Endung .ld

von wicki (Gast)


Bewertung
0 lesenswert
nicht lesenswert
nfet schrieb:
> wicki schrieb:
>> die roten hat er sich allesamt selbst gebastelt
>
> Auch wenn er das selbst gemacht hat, musst du dem Programm helfen, das
> Problem zu lösen.


das hab ich ja auch wieder hingebogen (projekt neu erstellt)
denn korrigieren ließ sich das nicht. er errechnete immer
voellig schraege taktfrequenzen.

aendert aber nichts daran, dass eth mausetot ist.

im .ld steht:


/* Specify the memory areas */
MEMORY
{
DTCMRAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
RAM_D1 (xrw)      : ORIGIN = 0x24000000, LENGTH = 512K
RAM_D2 (xrw)      : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw)      : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw)      : ORIGIN = 0x00000000, LENGTH = 64K
FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 2048K
}

sollte also eigentlich richtig sein.

von wicki (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
leute, mal ganz im ernst:

das ist schlicht und einfach scheisse.
um nicht zu sagen "grosse scheisse".


st.com:
-------------
 5 Monate, 3 Wochen ago.
Hi
Nobody in the ST team is working on Ethernet porting on this board for 
the moment. Any help is welcome !
-------------


warum werfen die son zeugs auf den markt, wenn sie es
selbst nicht supporten?
wird sich schon irgendein depp finden, der das zum laufen bringt?


nun noch mal so eine mbed-nummer versucht:

Hi, I have work on this topic, based on @Francesco branch. Here is my 
current work:
https://github.com/VVESTM/mbed-os/tree/vve_eth_h7. This is on top of 
current master branch.

With this branch, I am able to execute tcp test suite with success : 
mbed test -t IAR -m NUCLEO_H743ZI -v -n tests*netsocket*tcp*

Other ones are not yet working (udp, dns, tls). Any help is welcomed.
-------------------

resultat:
-------------------
/mnt/sda6/mbed-os$ mbed test -t IAR -m NUCLEO_H743ZI -v -n 
tests*netsocket*tcp*
[mbed] Working path "/mnt/sda6/mbed-os" (program)
[mbed] Exec "/usr/bin/python -u /mnt/sda6/mbed-os/tools/test.py -D 
MBED_TEST_MODE -t IAR -m NUCLEO_H743ZI --source . --build 
./BUILD/tests/NUCLEO_H743ZI/IAR --test-spec 
./BUILD/tests/NUCLEO_H743ZI/IAR/test_spec.json --build-data 
./BUILD/tests/NUCLEO_H743ZI/IAR/build_data.json -n tests*netsocket*tcp* 
-v --greentea" in "/mnt/sda6/mbed-os"
Could not find executable for IAR.
Currently set search path: No path set
[mbed] ERROR: "/usr/bin/python" returned error.
       Code: 2
       Path: "/mnt/sda6/mbed-os"
       Command: "/usr/bin/python -u /mnt/sda6/mbed-os/tools/test.py -D 
MBED_TEST_MODE -t IAR -m NUCLEO_H743ZI --source . --build 
./BUILD/tests/NUCLEO_H743ZI/IAR --test-spec 
./BUILD/tests/NUCLEO_H743ZI/IAR/test_spec.json --build-data 
./BUILD/tests/NUCLEO_H743ZI/IAR/build_data.json -n tests*netsocket*tcp* 
-v --greentea"
       Tip: You could retry the last command with "-v" flag for verbose 
output
--------------------


und nun hab ich die schnauze voll.

meine meinung dazu:
finger weg von diesem drecksboard! stm32h743zi

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> warum werfen die son zeugs auf den markt, wenn sie es
> selbst nicht supporten?

Viele Boards und Prozessoren haben überhaupt keinen Software-Support... 
Das muss man dann selber machen.

wicki schrieb:
> finger weg von diesem drecksboard! stm32h743zi

Es gibt jede Menge andere Boards mit Ethernet. So wie ich das sehe hast 
du auch nur versucht die fertigen Software-Pakete zusammenzuklicken. Mit 
einer guten Portion Datenblatt-Studium und Portierung des LwIP-Treibers 
könnte man das schon hinbekommen. Das ist halt der Embedded-Bereich - da 
muss man schon mal selbst Hand anlegen.

von nfet (Gast)


Bewertung
2 lesenswert
nicht lesenswert
wicki schrieb:
> Could not find executable for IAR.
> Currently set search path: No path set

Könnte es daran liegen? Ich habe den Eindruck, dir fehlen so viele 
Grundlagen, dass deine Versuche nichts als stochern im Nebel und damit 
ziemlich aussichtslos sind.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
dann stochern aber ziemlich viele leute ziemlich im nebel
rum.
ich habe bislang keine nachweisbar funktionierende eth-anwendung
von diesem board im netz gefunden. dafuer aber jede menge fragen,
problemschilderungen und unfertige projekte.

und wenn sogar st.com um hilfe im netz bettelt

"Nobody in the ST team is working on Ethernet porting on this board for
the moment. Any help is welcome !"

dann muss mir nicht jemand mit "fehlenden grundlagen" kommen.
dann ist das ein designfehler.

aber ich will das jetzt nicht weiter vertiefen.
sagt mir nur mal eins:

warum soll ich dieses board einsetzen, wenn ich fuer fast
den gleichen preis ein rapsi 4 mit 4 x 1.5GHz bekomme?

und wenn es wirklich so ist (was ich noch nicht sicher weiss), dass
die NIC da jetzt nicht mehr via USB dran haengt, dann sollte das
raspi genau das koennen, was ich gern will.
werde ich aber wohl diese woche erfahren (hoffe ich)

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> /mnt/sda6/mbed-os$ mbed test -t IAR -m NUCLEO_H743ZI -v -n
> tests*netsocket*tcp*

-t wählt die toolchain aus die verwendet werden soll, wenn du IAR 
angibtst solltest du auch IAR installiert haben. Für den gcc musst du 
das durch '-t GCC_ARM' ersetzen.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
"mbed" war nur ein letzter versuch - den ich aber auch
(wieder) zu den akten gelegt habe. denn das ist die klassische
dose wuermer, die man da aufmacht:

pkg_resources.ContextualVersionConflict: (mbed-os-tools 0.0.8 
(/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('mbed-os-tools==0.0.6'), set(['mbed-greentea']))
[mbed] ERROR: "mbedgt" returned error.
------
mbedgt --test-spec ./BUILD/tests/NUCLEO_H743ZI/GCC_ARM/test_spec.json -n 
tests -V
[1562516620.93][root]Generating grammar tables from 
/usr/lib/python2.7/lib2to3/Grammar.txt
[1562516620.94][root]Generating grammar tables from 
/usr/lib/python2.7/lib2to3/PatternGrammar.txt
Traceback (most recent call last):
  File "/usr/local/bin/mbedgt", line 10, in <module>
    sys.exit(main())
  File 
"/usr/local/lib/python2.7/dist-packages/mbed_greentea/mbed_greentea_cli. 
py",  line 332, in main
    gt_logger.gt_log(get_hello_string())
  File 
"/usr/local/lib/python2.7/dist-packages/mbed_greentea/mbed_greentea_cli. 
py",  line 100, in get_hello_string
    version = get_greentea_version()
  File 
"/usr/local/lib/python2.7/dist-packages/mbed_greentea/mbed_greentea_cli. 
py",  line 89, in get_greentea_version
    version = pkg_resources.require("mbed-greentea")[0].version
  File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
898, in require
    needed = self.resolve(parse_requirements(requirements))
  File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
789, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (mbed-os-tools 0.0.8 
(/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('mbed-os-tools==0.0.6'), set(['mbed-greentea']))


usw....

vielleicht mach ich irgendwann mal weiter - wenn sich auch das
neue raspi als unreichend erweisen sollte. aber fürs erste reicht
es mir mit den stm32ern.....

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Ich spüre große Ungeduld gekoppelt mit geringer Erfahrung, daraus 
resultierend eine hektische Unsystematik und wenig Aussicht auf 
nachhaltigen Erfolg.

Ich würds ruhiger angehen. Als erstes streiche mal alle 
(selbstgesetzten?) Deadlines, Du hast alle Zeit der Welt, wenns fertig 
ist ist es fertig, vorher nicht! Als nächstes setzt Du Dich hin, 
entscheidest Dich für genau eine Toolchain, eine Library und arbeitest 
in der vorgesehenen Reihenfolge alle Schritte von ganz unten angefangen 
und alle dabei auftretenden Probleme  oder 
Mißverständnisse/Wissenslücken eins nach dem anderen ab. Eines nach dem 
anderen, so lange bis es eines Abends plötzlich anfängt vollkommen 
erwartungsgemäß zu funktionieren.

Wenn es Dir gelingt einen kühlen Kopf zu bewahren, ganz gleich wie 
unüberwindlich zunächst die Probleme zu sein scheinen, könntest Du 
früher fertig sein als ursprünglich gedacht.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> With this branch, I am able to execute tcp test suite with success :
> mbed test -t IAR -m NUCLEO_H743ZI -v -n tests*netsocket*tcp*

das Kommando ist nicht das reine kompilieren, da wird eine ganze 
Testsuite durchgerattert. Da gibts ein Hilfsframework 'greentea' zu, und 
das wird als fehlend angemeckert. Zum Kompilieren ist das nicht nötig, 
wenn du in dem Projektverzeichnis bist dann starte 'mbed compile -t 
GCC_ARM -m NUCLEO_H734ZI'. Läuft das fehlerfrei durch?

von Michael F. (michaelfu)


Bewertung
2 lesenswert
nicht lesenswert
Wicki W. schrieb:
> ich habe bislang keine nachweisbar funktionierende eth-anwendung
> von diesem board im netz gefunden. dafuer aber jede menge fragen,
> problemschilderungen und unfertige projekte.


Ich kann die ganze Aufregung nicht verstehen...

Time to ping: <10 Minuten, wobei da die Zeit mit drin war, um in die 
Tiefgarage zu laufen und ein STM32H753XI-EVAL aus dem Auto zu holen.

- STM32CubeH7 Firmware Package (v1.4.0) von der ST Website laden und 
entpacken
- eines der mitgelieferten LwIP Beispiele (LwIP_TCP_Echo_Client) für das 
H743I-EVAL in der IAR Embedded Workbench für Arm öffnen
- Target MCU auf STM32H753XI ändern
- Projekt compilieren
- STM32H753XI-EVAL an Strom, Ethernet und Debug-Probe anschließen
- Debug Session starten und warten bis im Display des Boards die 
zugewiesene IP Adresse angezeigt wird
- vom Notebook das Eval-Board per Ping ansprechen


Für das H743ZI-Nucleo gibt es ein HTTP-Server Beispiel, das kann ich 
aber mangels Hardware im Moment nicht testen.

von Harry L. (mysth)


Bewertung
1 lesenswert
nicht lesenswert
Ich hab selten eine so chaotische Vorgehensweise gesehen
.
Wenn man bei jedem kleinen Rückschlag gleich alles hinwirft, und mit der 
nächsten Toolchauin/IDE eine neue Baustelle aufmacht, wird das ganz 
sicher nie was.

Am einfachsten dürfte es sicher sein, wenn man sich innerhalb des 
ST-Cube-Universum bewegt, aber auch das erfordert Einarbeitung und das 
Verständnis der Grundlagen.

Den Willen, das zu leisten, kann ich hier nicht erkennen.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> warum soll ich dieses board einsetzen, wenn ich fuer fast
> den gleichen preis ein rapsi 4 mit 4 x 1.5GHz bekomme?
>
> und wenn es wirklich so ist (was ich noch nicht sicher weiss), dass
> die NIC da jetzt nicht mehr via USB dran haengt, dann sollte das
> raspi genau das koennen, was ich gern will.
> werde ich aber wohl diese woche erfahren (hoffe ich)

realtime (RT PREEMPT) zeug am raspi geht zwar, aber nur so la la. 
Erzeugung von sauberen Schrittfolgen für Schrittmotoren mit Frequenzen 
über 1kHz geht damit meiner Erfahrung nach nicht. Dazu kommt dass die 
GPU hin und wieder für recht große Latenzen sorgt.

Recht gut funktionierts wenn man die Schrittgenerierung an einen µC 
auslagert mit dem man SPI redet (analog zu 
https://github.com/kinsamanka/PICnc-V2). Die Raspberry Pi SPI Hardware 
ist aber einigermassen gehirnamputiert, wechselt von selbst die Baudrate 
und bremst die CPU aus, es hat halt Gründe geben warum diese SOC-Familie 
so günstig ist.

Andere Möglichkeit zur Ansteuerung von Schrittmotoren vom Pi aus ist die 
Schrittgenerierung gleich dem Schrittmotortreiber zu überlassen, 
passende Chips die das können gäbs z.B. von ST und TI. Passend zu den 
Nucleos wäre das X-NUCLEO-IHM03A1.

von PCEngine (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Wicki W. schrieb:
> warum soll ich dieses board einsetzen, wenn ich fuer fast
> den gleichen preis ein rapsi 4 mit 4 x 1.5GHz bekomme?

LOL. Der STM32 ist doch kein Einplatinenrechner zum Spielen. Das Board 
ist
ein Evaluationboard, damit man sich in die Mikrocontroller-Familie 
einarbeiten kann. Mikrocontroller =/= Mikroprozessor. Weißt du 
überhaupt, was du da gekauft hast?

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Also ich hab das ganze hier aufgemacht unter "Einsteigerfragen".
Und ich finde es gut, dass es hier auch sehr hilfreiche
Antworten gab. Dafür nochmals vielen Dank!

Das ist zwar mein erster STM32 aber bei weitem nicht er
erste µPC mit dem ich arbeite.
Ich habe selten eine so verwirrende Welt erlebt wie mit
diesem Teil.

Einige Dinge finde ich faszinierend einfach - andere sind
einfach chaotisch.
Das ganze war auch nicht meine Idee, sondern  - genau wie
die Boardauswahl - eine aus Bulgarien.
Warum also nicht mal probieren?

Aber wenn der Hersteller eine Boards auf seiner Homepage schreibt:
"Da ist zwar n Eth drauf, aber keiner enwickelt was dafür"
bei allem Verstständnis - da hörts bei mir auf.

Und PDF-Dokus mit 3500 Seiten? Um einen "ping" zu bekommen?

Bis das neue Raspi eintrifft, werde ich noch mal ein bisschen
rumprobieren. Mal sehen, was dabei herauskommt.
Bei dem neuen Raspi soll nicht mehr das ganze Eth durchs USB
gepiped werden - was m.E. die Haupturasche der Timingprobleme ist.

Die Alternative "Takt ausgelagert erzeugen" hatte ich auch in
Betracht gezogen. Mir dann aber (wg. des Tipps aus Bulgarien und
der existierenden Software aus Finnland) zunächst dieses
Board angesehen.

Praktische Tests zum Eth-Verhalten dieses Boards konnte ich ja
leider noch nicht machen. Aber ehrlich gesagt:
es fällt mir schwer zu glauben, dass da eine ordentliche
Performance bei raus kommt, wenn das alles über ein 400MHz
single-Core abgewickelt wird. Quasi so nebenbei.
Weil: Ausser kommunizieren soll er ja auch noch ein bisschen
was anderes tun.

von Michael F. (michaelfu)


Bewertung
1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Aber wenn der Hersteller eine Boards auf seiner Homepage schreibt:
> "Da ist zwar n Eth drauf, aber keiner enwickelt was dafür"
> bei allem Verstständnis - da hörts bei mir auf.

Auf einem H743ZI-NUCLEO funktioniert die von ST zur Verfügung gestellte 
Beispielanwendung (Webserver) komplett out of the box.

- Beispielprojekt von ST nehmen
- in einer der unterstützten IDEs / Toolchains compilieren
- Board anschließen, programmieren und darauf warten, dass per DHCP eine 
IP Adresse zugewiesen wird
- fertig

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
pkg_resources.ContextualVersionConflict: (mbed-os-tools 0.0.8 
(/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('mbed-os-tools==0.0.6'), set(['mbed-greentea']))


pip list liefert:

  mbed-greentea                 1.6.5


in requirements.txt steht:

mbed-greentea>=0.2.24,<1.8


da kann ich mich dem hier nur anschliessen:
https://github.com/ARMmbed/mbed-os/issues/10748

 commented on 3 Jun

I'm seeing the same issue all the time with installing a new version of 
Mbed OS :(
It seems the packages in Mbed OS require different versions of the tools 
from mbed-os-tools.
As a workaround, I need to manually install specific versions as shown 
here: https://github.com/ARMmbed/mbed-os-tools/releases/tag/v0.0.8

Please fix the python dependencies, as this issue is very annoying ;-)

Auch die beschriebene Änderung in requirements.txt löst das Problem 
nicht.
Das macht alles einen recht geprutschten Eindruck.
Denn vor 5 Tagen bestand das Problem immer noch.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
"- Board anschließen, programmieren und darauf warten, dass per DHCP 
eine
IP Adresse zugewiesen wird"

hab ich getan.
x mal die Timings kontrolliert - es tut sich nichts auf der
Schnittstelle. Die beiden LEDs am Stecker zeigen Verbindung,
die LEDs 2 und 3 ändern sich nie.

Den unwahrscheinlichen Fall "Schnittstelle kaputt" schliesse ich jetzt
mal aus. Aber ich weiss nicht mehr, wie ich nun weiter suchen soll.



- Beispielprojekt von ST nehmen

check


- in einer der unterstützten IDEs / Toolchains compilieren

check


- Board anschließen, programmieren

.bin-file auf board kopiert (baue ich ein "blink" mit ein,
dann blinkt das auch) - also das board laeuft


- und darauf warten, dass per DHCP eine  IP Adresse zugewiesen wird

und da warte ich mir n wolf...
auch mit statischer IP funktioniert nichts.
es geht einfach nichts rüber.

kein ARP - kein gar nichts....

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Das macht alles einen recht geprutschten Eindruck.
> Denn vor 5 Tagen bestand das Problem immer noch.

Dann lass doch diesen ganzen albernen mbed-Quatsch weg und mach es auf 
die normale Weise wie alle anderen auch, waren ja schon einige hier im 
Thread die gezeigt haben daß es in wenigen Minuten out of the box 
funktioniert wenn man den normalen vorgesehenen Weg geht. Warum willst 
Du es unnötig verkomplizieren?

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> "Da ist zwar n Eth drauf, aber keiner enwickelt was dafür"
> bei allem Verstständnis - da hörts bei mir auf.

Das ist mehr als üblich. Die existierende Software ist nur pure 
Nettigkeit, wenn man was "richtiges" haben will kostet es.

Wicki W. schrieb:
> Und PDF-Dokus mit 3500 Seiten? Um einen "ping" zu bekommen?

Natürlich, der STM32H7 ist ein komplexer Prozessor, soll man den nicht 
vollständig dokumentieren? Unvollständig/Überhaupt nicht dokumentierte 
Prozessoren gibts jede Menge, wie z.B. den vom Raspberry PI. Die 
funktionieren dann ausschließlich mit Linux und den Binär-Treibern vom 
Hersteller.

Für "ping" müssen schon diverse Dinge korrekt zusammen spielen, und die 
Hardware ist nur ein Teil davon. Den Rest muss man selber machen.

Wieso sollte ST dokumentieren, wie man den GNU GCC, den LwIP, GNU make, 
Linux und die eigene Cube-Software verbindet? ST ist ein 
Hardware-Hersteller. Von Drittherstellern wie z.B. Segger bekommst du 
komplette IP-Stacks mit Treibern für STM32H7 und andere. Das ist wohl 
das Rundum-Sorglos-Paket was du haben möchtest. Kostet natürlich.

Wicki W. schrieb:
> es fällt mir schwer zu glauben, dass da eine ordentliche
> Performance bei raus kommt, wenn das alles über ein 400MHz
> single-Core abgewickelt wird.

Die allermeisten Prozessoren dürften weit unter 100MHz haben. Damit 
werden Maschinen, Fahr-und Flugzeuge, Raumfahrzeuge und alle möglichen 
Haushaltsgeräte gesteuert. Der H7 mit 400 MHz ist da schon ziemlich 
üppig!

Wicki W. schrieb:
> warum soll ich dieses board einsetzen, wenn ich fuer fast
> den gleichen preis ein rapsi 4 mit 4 x 1.5GHz bekomme?

Der R-PI ist ohne Linux praktisch nicht nutzbar und mit Linux nicht 
sonderlich echtzeitfähig. Er hat nicht so viel Peripherie wie der STM32 
(z.B. Timer, ADC). Du kannst den Prozessor des R-PI nicht einfach so mit 
5 externen Bauteilen auf eine 2-lagige Platine packen. Der STM32 setzt 
nicht zwingend externen Flash/RAM voraus und braucht weniger Energie. 
Den PI-Prozessor bekommst du sowieso kaum einzeln; STM32-Platinen können 
aber viel kompakter sein.

Ob diese Faktoren für dich relevant sind, musst du wissen; den PI als 
pauschal besser darzustellen ist gewagt. Der Vergleich ist sowieso nicht 
fair - wenn du nur das betrachtest, was Broadcom abliefert, bekommst du 
ein nicht nutzbares Stück Silizium. Nur dank der riesigen Arbeit der 
Open-Source-Community gibt es dafür Software, die ihn (einfach) nutzbar 
macht. Bei dem STM32H7 hat das halt noch keiner gemacht.

Wenn der Blick doch Richtung SBC geht, erwähne ich nochmal:

Niklas G. schrieb:
> Vielleicht wäre ein TI Sitara Prozessor (z.B. in Form eines BeagleBone
> Black) interessant - hart echtzeitfähig, viel Rechenleistung, Ethernet
> mit Industrieprotokollen möglich (z.B. EtherCAT)

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
Hier mein Setup:

STM32H743ZI-NUCLEO:
https://www.st.com/en/evaluation-tools/nucleo-h743zi.html

STM32CubeH7 Firmware Package v1.4.0:
https://www.st.com/en/embedded-software/stm32cubeh7.html
Projects => NUCLEO-H743ZI => Applications => LwIP => 
LwIP_HTTP_Server_Netconn_RTOS => EWARM

IAR Embedded Workbench für Arm 8.40.1:
https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm
(für den Test die 30 Tage Eval-Lizenz nehmen, da das Projekt zu groß für 
die 32kB Eval-Lizenz ist)

Das Board per Micro-USB anschließen, innerhalb der EWARM das Ganze 
compilieren, eine Debug-Session starten und dann das Programm per "Go", 
bzw. F5 laufen lassen.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
danke.
wenn ich genug va-lium beisammen habe, werde ich das vielleicht
mal probieren.
aber 1.5GB kommerzsoftware downloaden um einen http-server zu bauen?

(Version 8.40, 1358.63 MB)


mag sein, dass das nicht zeitgemaesse ansichten sind.
und ich tu mir das vielleicht doch irgendwann mal an, um
herauszufinden, warum es mit make&co nicht geht.
wenn nicht das board ne macke hat, kann es nur das timing oder
die speicherbelegung sein.

Michael F. (michaelfu): vielleicht kannst du ja mal das .bin posten?
dann koennte ich zumindest einen hardwarefehler sicher ausschliessen.



oh, ein forum mit zensurautomat ;-)

 ---> Der Beitrag scheint Spam zu enthalten: "va-lium"

: Bearbeitet durch User
von Johannes S. (jojos)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@wicki:
nochmal zu mbed:
habe diesen branch https://github.com/VVESTM/mbed-os/tree/vve_eth_h7 
genommen, und damit kompiliert das Beispiel ohne Fehler.
Wie geschrieben, das mbedgt ist nur für die automatisierten Tests nötig, 
das mbed compile hatte ja schon bei dir funktioniert.
mkdir eth_test
cd eth_test
mbed new . --create-only
mbed add https://github.com/VVESTM/mbed-os
mbed update vve_eth_h7
dann eine main.cpp anlegen, zB das Beispiel von hier:
https://os.mbed.com/teams/mbed_example/code/TCPSocket_Example/file/50f1485931f1/main.cpp

kompilieren mit
mbed compile -m GCC_ARM -t NUCLEO_H743ZI

das binary landet in ./BUILD/NUCLEO_H743ZI/GCC_ARM

'mbed new . --create-only' erzeugt nur das Projektverzeichnis und eine 
Konfigdatei, 'mbed add' holt eine library (per git oder hg), 'mbed 
update' macht den checkout einer bestimmen Version. Mit dem Schalter 
'--flash' hinter dem compile Kommando wird das binary gleich auf das 
Board kopiert. Die Ausgaben von printf() kommen über die virtuelle 
serielle Schnittstelle im USB Device raus.

: Bearbeitet durch User
von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
danke sehr!

statt

>kompilieren mit
>mbed compile -m GCC_ARM -t NUCLEO_H743ZI


muss es heissen:
mbed compile -t GCC_ARM -m NUCLEO_H743ZI


womit wir dann aber schon wieder bei der dose wuermer waeren:
......
Compile [ 99.8%]: USBSerial.cpp
Compile [ 99.9%]: PolledQueue.cpp
Compile [100.0%]: TaskBase.cpp
Link: eth_test
/mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2. 
1/../../../../arm-none-eabi/bin/ld:  BUILD/NUCLEO_H743ZI/GCC_ARM/main.o: 
in function `__static_initialization_and_destruction_0':
/mnt/sda6/eth_test/./main.cpp:5: undefined reference to 
`EMAC::get_default_instance()'
collect2: error: ld returned 1 exit status
[ERROR] 
/mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2. 
1/../../../../arm-none-eabi/bin/ld:  BUILD/NUCLEO_H743ZI/GCC_ARM/main.o: 
in function `__static_initialization_and_destruction_0':
/mnt/sda6/eth_test/./main.cpp:5: undefined reference to 
`EMAC::get_default_instance()'
collect2: error: ld returned 1 exit status

[mbed] ERROR: "/usr/bin/python" returned error.
       Code: 1
       Path: "/mnt/sda6/eth_test"
       Command: "/usr/bin/python -u 
/mnt/sda6/eth_test/mbed-os/tools/make.py -t GCC_ARM -m NUCLEO_H743ZI 
--source . --build ./BUILD/NUCLEO_H743ZI/GCC_ARM"
       Tip: You could retry the last command with "-v" flag for verbose 
output


was dann wieder fuehrt zu:

[ERROR] 
/mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2. 
1/../../../../arm-none-eabi/bin/ld:  BUILD/NUCLEO_H743ZI/GCC_ARM/main.o: 
in function `__static_initialization_and_destruction_0':
/mnt/sda6/eth_test/./main.cpp:5: undefined reference to 
`EMAC::get_default_instance()'
collect2: error: ld returned 1 exit status


und das kommt wieder aus :
// Network interface
EthernetInterface net;


soifz

was wohl wieder soviel heisst wie: "mbed kennt kein  EthernetInterface 
beim 743zi"

wobei mir jetzt nicht klar ist:
Wieso compiliert das bei Dir ?

Er sollte doch immer das "mbed-os" im aktuellen Verzeichnis verwenden - 
oder ?

ps: diverse mbed-tests hatte ich ja auch schon ausprobiert. klappt auch.
nur mit dem eth-fork, damit will es nicht. und damit auch mit dem 
gesamten eth nicht....

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
der Linkerfehler kann nur daher kommen das du nicht den vve_eth_h7 
branch benutzt, nur der enthält ja die Ethernet Komponente für den H7.

Vor dem 'mbed update vve_eth_h7' fehlte noch ein 'cd mbed-os', das 
update bezieht sich auf das mbed-os repository. Zur Kontrolle kann man 
auch mit 'git branch -v' anzeigen lassen ob man im richtigen branch ist.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
JAU!

nun tut es...


Compile [ 99.9%]: PolledQueue.cpp
Compile [100.0%]: TaskBase.cpp
Link: eth_test
Elf2Bin: eth_test
Unknown object name found in GCC map file: load address 
0x0000000008026ad0
| Module             |          .text |     .data |         .bss |
|--------------------|----------------|-----------|--------------|
| [fill]             |       236(+30) |     9(-4) |      57(-10) |
[....]
| Subtotals          | 125896(+12136) | 3048(+16) | 20400(+1216) |
Total Static RAM memory (data + bss): 23448(+1232) bytes
Total Flash memory (text + data): 128944(+12152) bytes

Image: ./BUILD/NUCLEO_H743ZI/GCC_ARM/eth_test.bin


also, es tut irgendwas.... auch auf dem eth-port.
was er da oben wohl fuer ein unknown object anmeckert?

irgendwas passt ihm offenbar auch zu laufzeit nicht.
s.u.

er nimmt sich auch keine IP-adresse per DHCP, laesst sich nicht
anpingen  - aber er versucht zumindest zu verhandeln. das kann
ich sehen....



Ethernet socket example

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0   : 0100A8C0
R1   : 240064D4
R2   : 0000000E
R3   : 00000008
R4   : 240064D4
R5   : 00000000
R6   : 3004020E
R7   : 30040216
R8   : 24002158
R9   : 00000000
R10  : 00000000
R11  : 00000000
R12  : 08010FD1
SP   : 24006008
LR   : 0800AFA3
PC   : 08005918
xPSR : 61000000
PSP  : 24005FE8
MSP  : 2407FF78
CPUID: 411FC271
HFSR : 40000000
MMFSR: 00000000
BFSR : 00000000
UFSR : 00000100
DFSR : 0000000B
AFSR : 00000000
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --



++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x800EC4B
Error Value: 0x8005918
Current Thread: lwip_tcpip  Id: 0x240019FC Entry: 0x8004539 StackSize: 
0x4B0 StackMem: 0x24005BB0 SP: 0x2407FF10
For more info, visit: 
https://mbed.com/s/error?error=0x80FF013D&tgt=NUCLEO_H743ZI
-- MbedOS Error Info --

= System will be rebooted due to a fatal error =
= Reboot count(=5) reached maximum, system will halt after rebooting ␀


----------------------------

also sich find es gut, dass nun endlich mal was passiert auf dem
port.
nochmals besten dank.

ich werde wahrscheinlich nochmal mit eine statischen IP was probieren.
aber ueberzeugen tut mich das, was ich bislang gesehen habe, wirklich
nicht.....


der error-link aus der ausgabe zeigt ueberigens hier drauf:
Error Code HardFault exception
Cortex-M HardFault exception has occurred. Please see 
https://os.mbed.com/docs/latest/tutorials/analyzing-mbed-os-crash-dump.html 
for more info.

und der zeigt dann auf "Analyzing Mbed OS crash dump"

was fuer einen einstieg aehnlich locker abgeht, wie linux-kernel-crashs
und coredumps analysieren.....

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> also, es tut irgendwas.... auch auf dem eth-port.
> was er da oben wohl fuer ein unknown object anmeckert?

Für die Compiler Statistik wird das Mapfile analysiert, da scheint diese 
Meldung herzukommen. Das wäre dann nur ein kosmetischer Fehler, 
vielleicht weil der gcc8 da etwas anders macht. Aber vielleicht ist der 
gcc8 jetzt noch die Fehlerquelle für das Laufzeitproblem, kannst du das 
mit einem älteren gcc übersetzen? Und hat mein binary das gleiche 
Verhalten gezeigt?
Ich habe das unter Windows kompiliert und diese Meldung nicht erhalten.

: Bearbeitet durch User
von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:

  Und hat mein binary das gleiche
> Verhalten gezeigt?

ups...
das hatte ich gar nicht gesehen!
aber jetzt grad drauf kopiert - resultat siehe unten

> Ich habe das unter Windows kompiliert und diese Meldung nicht erhalten.

bei einem unbelegte eth-stecker bleibt er hier einfach stehen:

Ethernet socket example

aber dann kommt nach einem timeout:
IP address is: No IP
sent -3004 [GET / HTTP/1.1]


stecke ich ein kabel rein, dann kommt (unabhaengig davon, ob das
ein totes netz oder eins mit DHCP drauf ist)  das unten folgende.

kann es sein, dass der nicht haben kann, wenn er IPv6 bekommt?

noe, das ists es nicht. auch mit inaktivem v6 ist es das gleiche.
er moechte wohl gern die 192.168.0.129 haben.
wird sich aber wohl mit dem dhcp nicht einig.

ich schau nochmal - aber irgendwie sind mir das eindeutig viel zu
viele stolpersteine, fuer das, was ich damit vor habe.


␀Ethernet socket example

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0   : 00000000
R1   : 00000000
R2   : 0000FFFF
R3   : 00000240
R4   : 00000014
R5   : 240020D8
R6   : 240064D4
R7   : 00000240
R8   : 3004020E
R9   : 00000014
R10  : 00000000
R11  : 00000000
R12  : 08011009
SP   : 24006020
LR   : 08006F2B
PC   : 080061C8
xPSR : 61000000
PSP  : 24006000
MSP  : 2407FF78
CPUID: 411FC271
HFSR : 40000000
MMFSR: 00000000
BFSR : 00000000
UFSR : 00000100
DFSR : 0000000B
AFSR : 00000000
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --



++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x800EC6F
Error Value: 0x80061C8
Current Thread: lwip_tcpip  Id: 0x2400197C Entry: 0x8004311 StackSize: 
0x4B0 StackMem: 0x24005BB0 SP: 0x2407FF10
For more info, visit: 
https://mbed.com/s/error?error=0x80FF013D&tgt=NUCLEO_H743ZI
-- MbedOS Error Info --

= System will be rebooted due to a fatal error =
= Reboot count(=2) reached maximum, system will halt after rebooting ␀

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Crash Info:
        Crash location = <unknown-symbol> [0x08005918] (based on PC 
value)
        Caller location = <unknown-symbol> [0x0800AFA3] (based on LR 
value)
        Stack Pointer at the time of crash = [24006008]
        Target and Fault Info:
                Processor Arch: ARM-V7M or above
                Processor Variant: C27
                Forced exception, a fault with configurable priority has 
been escalated to HardFault
                Unaligned access error has occurred

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Damit https://github.com/ARMmbed/mbed-os-example-fault-handler sollte 
sich mit dem .elf und/oder .map file rekonstruieren lassen wo das genau 
passiert.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
aber wenn sowas schon bei fertigen demos in einem
08/15-netzsegment passiert, wie viele stolperstellen
sind denn dann noch da drin, wenn man mal
wirklich in einem heterogenen netz mit ganz
viel traffic, auf den die software nicht
vorbereitet ist, landet?

ich leg das nun erst mal wieder an die seite und
warte, ob ich aus finnland oder bulgarien noch eine
tolle idee hoere ;-)

jedenfall erst mal vielen dank - das hat schon echt gut geuebt ;-)

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Diese Zeilen hat der Vincent V. modifiziert:
https://github.com/VVESTM/mbed-os/blob/a0d598863ede1ae9a450a6435a9d82a2ef0a2593/features/lwipstack/lwip-sys/arch/lwip_sys_arch.c#L54
Er arbeitet ja scheinbar mit dem IAR Compiler, bei den anderen steht 
noch ein ,aligned hinter der section für den gcc. Beim H7 fehlt das, das 
würde ich mal dahinter packen.

Der Code ist noch recht frisch, aber wenn beim Vincent schon die TCP 
Tests durchlaufen wird da schon eine Menge getestet: 
https://github.com/VVESTM/mbed-os/tree/vve_eth_h7/TESTS/netsocket/tcp
Das ist kein Spielzeug.

Nachtrag:
das hier scheint faul zu sein:
https://github.com/VVESTM/mbed-os/commit/a0d598863ede1ae9a450a6435a9d82a2ef0a2593
lt. Kommentar hat Vincent die Anzahl Descriptoren erhöht und die Adresse 
für die DMATxDscrTab hat sich von 0x30040200 nach 0x30040400 verschoben. 
Das wurde aber im GCC Linkerscript nicht nachgezogen (ist schon 
gefährlich sowas im Linkerscript/Code zu mischen). Aber mit einer 
Anpassung der Adresse in
https://github.com/VVESTM/mbed-os/blob/a0d598863ede1ae9a450a6435a9d82a2ef0a2593/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld#L182
könnte es klappen.

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Wicki,
hast du schon aufgegeben?
Ich hatte das Board jetzt auch mal bestellt und das Ausprobiert. Den 
Fehler kann ich reproduzieren, aber mit dem Fix den ich genannt hatte 
läuft es. Ich bekomme mit dem Beispielprogramm eine IP per DHCP und der 
HTTP request geht raus und wird beantwortet.

das sind die nötigen Änderungen im Linkerfile:
diff --git a/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld b/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld
index 4e50b43736..31a1d82438 100644
--- a/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld
+++ b/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld
@@ -179,10 +179,10 @@ SECTIONS
         . = ABSOLUTE(0x30040060);
         *(.TxDecripSection)

-        . = ABSOLUTE(0x30040200);
+        . = ABSOLUTE(0x30040400);
         *(.RxArraySection)

-        . = ABSOLUTE(0x30044000);
+        . = ABSOLUTE(0x30044200);
         *(.ethusbram)
     } > RAM_D2 AT > FLASH

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
hi jojos,


> hast du schon aufgegeben?

ja, quasi.... ich hatte das board seitdem nicht mehr angefasst.

mit dem patch tut es in der tat. besten dank.

aber durch wie viele manual-pages muss man sich durchwuehlen, nur um 
diesen patch hin zu bekommen? ganz schoen viele...

und dann hat man einen rudimentaeren IP-stack, der nicht mal auf "ping" 
antworten kann.

gut, bei dem neuen PI4 musste ich auch in den libs rumpatchen, damit sie 
dort wg. der veraenderten adressen laufen. aber das neue PI4 ist auch 
gerade mal 4 wochen alt - und nicht 2 jahre, wie dieses stm-board.

allerdings scheint es auch mit dem neuen PI4 schwierig zu werden, wenn 
man zuverlaessig unter 100usec latency kommen will.

http://erste.de/latency_PI4.png

http://erste.de/timing-tests.PI4.html

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> aber durch wie viele manual-pages muss man sich durchwuehlen, nur um
> diesen patch hin zu bekommen? ganz schoen viele...

keine einzige... ich habe mal angenommen das der Code funktionierte, der 
Unterschied war "nur" der andere Compiler. Ich kenne die mbed Struktur 
einigermassen und habe da gleich die geänderten Linkerfiles gesehen.

LinuxCNC oder eine CNC Steuerung mit diesem Board interessiert mich 
auch, aber längerfristig, habe noch andere Baustellen. Sind die LinuxCNC 
Quellen denn µC tauglich? Im Detail wird so eine Portierung sicher 
aufwändig sein und ein Crash bei einer CNC Fräse ist da wortwörtlich nix 
gut.

von Wicki W. (wicki)


Bewertung
0 lesenswert
nicht lesenswert
> keine einzige... ich habe mal angenommen das der Code funktionierte, der
> Unterschied war "nur" der andere Compiler. Ich kenne die mbed Struktur
> einigermassen und habe da gleich die geänderten Linkerfiles gesehen.

OK - aber das sind natuerlich voraussetzungen, die ich nicht habe...
mich hatte das sicher lange recherchen gekostet.



> LinuxCNC oder eine CNC Steuerung mit diesem Board interessiert mich
> auch, aber längerfristig, habe noch andere Baustellen. Sind die LinuxCNC
> Quellen denn µC tauglich?

was meinst du mit "µC tauglich" ?
entstanden ist der ganze thread hier nur (oben im detail nachzulesen), 
weil es kaum noch PC-boards mit parport gibt. und ich wollte mal sehen, 
ob man den parport per raw-eth auf ein raspberry auslagern kann.
und weil ein finne eine stm32-interfaceloesung fuer linCNC gebaut hat. 
und ein bulgare aufgrund des raspberry projekts meinte, das koennte man 
doch vielleicht gut kombinieren. mit genau diesem stm-board.

so hat das alles angefangen.
dann kam ploetzlich das neuen PI4, dann der RT-kernel dazu und dann das 
auf dem PI4 compilier- und nutzbare linCNC:
http://erste.de/raspi4-RT-kernel-howto.html

und nun versuche ich grade herauszufinden, was denn timingmaessig beim 
PI4 noch drin ist....

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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