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
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...
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.... ;-)
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...
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 ?
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
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
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...
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.
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.
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.
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.
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
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
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).
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 ;-)
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).
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
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.
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)
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.
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.
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
> > 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 ;-)
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?
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.
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.
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.
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...
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....
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.
> 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
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....
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
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.
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:
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
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
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.
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...
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:
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.
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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.
> 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.....
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.
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.
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.
> 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.
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.
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.
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.
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
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.
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.
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...
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...
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.
> 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
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.
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.
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.
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.....
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.
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
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).
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
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
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...
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:
1
int
2
main(int,char*[])
Und in der system/src/cmsis/vectors_stm32f4xx.c müssen Zeilen 195-196
auskommentiert/gelöscht werden.
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...
"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.....
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?
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.
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.
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.
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.
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...
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....
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.
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.
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. :)
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?
"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.
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.
"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....
"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.
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.
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
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... ;-)
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.
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.
"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.
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.
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.
"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... ;-)
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....
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
"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.
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
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.
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
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.
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.
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)
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.
"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.....
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.
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?
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.
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.
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.
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?
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.
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
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.
"- 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....
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?
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)
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"
@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.
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.
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....
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.
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.....
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.
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 ␀
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
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 ;-)
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:
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.pnghttp://erste.de/timing-tests.PI4.html
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.
> 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....
Thread beobachten
Seitenaufteilung abschalten