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...
:
Bearbeitet durch User
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...
Moin, Vielleicht hilft dir ja https://blog.podkalicki.com/how-to-compile-and-burn-the-code-to-stm32-chip-on-linux-ubuntu/
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.
Wicki W. schrieb: > AUA! > > danke ;-) Ich sehe schon, voll der CmdLine Hengst der noch nicht mal strace bedienen kann.
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
:
Bearbeitet durch User
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).
also doch.... zumindest comiliert es jetzt # cd mbed-os-example-blinky # mbed compile -t GCC_ARM [mbed] Working path "...../mbed-os-example-blinky" (program) [mbed] Detected "NUCLEO_H743ZI" connected to "....../NODE_H743ZI" and using com port "/dev/ttyACM0" [Warning] @,: Compiler version mismatch: Have 8.2.1; expected version >= 6.0.0 and < 7.0.0 Building project mbed-os-example-blinky (NUCLEO_H743ZI, GCC_ARM) Scan: mbed-os-example-blinky Compile [ 0.8%]: at24mac.cpp Compile [ 0.9%]: NanostackRfPhyMcr20a.cpp Compile [ 1.0%]: main.cpp Compile [ 1.2%]: NanostackRfPhyAtmel.cpp Compile [ 1.3%]: NanostackRfPhys2lp.cpp [.....] Compile [ 99.8%]: USBSerial.cpp Compile [ 99.9%]: PolledQueue.cpp Compile [100.0%]: TaskBase.cpp Link: mbed-os-example-blinky Elf2Bin: mbed-os-example-blinky | Module | .text | .data | .bss | |--------------------|---------------|-------------|-------------| | [fill] | 148(+148) | 12(+12) | 45(+45) | | [lib]/c.a | 26000(+26000) | 2472(+2472) | 89(+89) | | [lib]/gcc.a | 772(+772) | 0(+0) | 0(+0) | | [lib]/misc | 208(+208) | 12(+12) | 28(+28) | | main.o | 1066(+1066) | 4(+4) | 36(+36) | | mbed-os/cmsis | 1021(+1021) | 0(+0) | 0(+0) | | mbed-os/components | 104(+104) | 0(+0) | 0(+0) | | mbed-os/drivers | 810(+810) | 0(+0) | 0(+0) | | mbed-os/hal | 3357(+3357) | 8(+8) | 247(+247) | | mbed-os/platform | 5086(+5086) | 260(+260) | 257(+257) | | mbed-os/rtos | 9343(+9343) | 168(+168) | 6289(+6289) | | mbed-os/targets | 18470(+18470) | 8(+8) | 1457(+1457) | | Subtotals | 66385(+66385) | 2944(+2944) | 8448(+8448) | Total Static RAM memory (data + bss): 11392(+11392) bytes Total Flash memory (text + data): 69329(+69329) bytes Image: ./BUILD/NUCLEO_H743ZI/GCC_ARM/mbed-os-example-blinky.bin
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.
rµ schrieb: > * herausfinden für welche eclipse ide das gedacht ist dürfte SW4STM32 sein http://www.ac6-tools.com/content.php/content_SW4L.xphp
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:
1 | EthernetInterface eth; |
2 | nsapi_error_t status = eth.connect(); |
https://os.mbed.com/docs/mbed-os/v5.12/apis/ethernet.html
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:
1 | echo Compile Main |
2 | ARM-NONE-EABI-GCC @compile_gcc.xcl -o main.thumb.o main.c |
3 | if Errorlevel==1 goto ende |
4 | |
5 | echo Linke |
6 | ARM-NONE-EABI-LD @link_gcc.xcl |
7 | if Errorlevel==1 goto ende |
8 | |
9 | echo Mache Hex |
10 | ARM-NONE-EABI-OBJCOPY -O ihex linkedgcc.elf BettyBASEgcc.hex |
11 | if Errorlevel==1 goto ende |
12 | |
13 | echo Mache Bin |
14 | ARM-NONE-EABI-OBJCOPY -O binary linkedgcc.elf BettyBASEgcc.bin |
15 | if Errorlevel==1 goto ende |
16 | |
17 | echo So, das war's. |
18 | goto schluss |
19 | |
20 | :ende |
21 | echo ... |
22 | echo Hei, da ist was schiefgelaufen! |
23 | pause
|
24 | |
25 | :schluss |
solltest du mit links in ein Shellskript umschreiben können. Wer Linux benutzt, der hat sowas gefälligst auch zu können. Du wirst vermutlich nicht mehr die yagarto-Distri benutzen, also solltest du das obige Beispiel an deine Distri anpassen. Obendrein sind natürlich auch die beiden .xcl (extended command lines) an dein Projekt anzupassen. Und jetz jammere nicht mehr so herum, sondern mache. W.S.
W.S. schrieb: > Herrjemineh, kannst du eigentlich lesen oder nur schreiben??? liest du eigentliche auch oder kannst du nur pöbeln?
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.
Ist das prekär hier... Im Anhang ein Makefile, mit welchem das erwähnte Projekt kompiliert werden kann. War jetzt gar nicht so schwierig. Erst den Compiler installieren: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm In der syscalls.c muss man am Anfang noch folgendes einfügen:
1 | int _getpid(void) __attribute__((used)); |
2 | int _kill(int pid, int sig) __attribute__((used)); |
3 | void _exit (int status) __attribute__((used)); |
4 | int _read (int file, char *ptr, int len) __attribute__((used)); |
5 | int _write(int file, char *ptr, int len) __attribute__((used)); |
6 | caddr_t _sbrk(int incr) __attribute__((used)); |
7 | int _close(int file) __attribute__((used)); |
8 | int _fstat(int file, struct stat *st) __attribute__((used)); |
9 | int _isatty(int file) __attribute__((used)); |
10 | int _lseek(int file, int ptr, int dir) __attribute__((used)); |
11 | int _open(char *path, int flags, ...) __attribute__((used)); |
12 | int _wait(int *status) __attribute__((used)); |
13 | int _unlink(char *name) __attribute__((used)); |
14 | int _times(struct tms *buf) __attribute__((used)); |
15 | int _stat(char *file, struct stat *st) __attribute__((used)); |
16 | int _link(char *old, char *new) __attribute__((used)); |
17 | int _fork(void) __attribute__((used)); |
18 | int _execve(char *name, char **argv, char **env) __attribute__((used)); |
In der "Src/lwip.c" muss man die "#if defined ( __CC_ARM )" auskommentieren. kA warum die da sind. Dann kann man per "make" alles automatisch kompilieren.
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.
:
Bearbeitet durch User
> 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.
ist wirklich schön hier bei Euch. Ihr tut viel gutes für die Menschen.....
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: > Von riesengroßen Projekten mit hunderten von Dateien war und ist hier > nicht die Rede Doch: Wicki W. schrieb: > https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP W.S. schrieb: > Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau? Schon passiert: Niklas G. schrieb: > Im Anhang nochmal eine etwas verbesserte/aufgeräumte Version des > Makefiles. Ist ja auch nicht so schwierig. Warum man da erst lange rumeiert...
> 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
hi zusammen, hier die antwort aus bulgarien web page http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=18671&start=200 Files http://www.cnc-club.ru/forum/download/file.php?id=148983 http://www.cnc-club.ru/forum/download/file.php?id=148984 http://www.cnc-club.ru/forum/download/file.php?id=148987 http://www.cnc-club.ru/forum/download/file.php?id=148988 Im wesentlichen gehts um die Sourcen, die in http://www.cnc-club.ru/forum/download/file.php?id=148984 drin steckt: EthernetCNC_ver3 den rest kenne ich auch erst seit gerade eben... mein russisch ist jetzt auch nicht sonderlich gut... ;-) aber mir ist nicht klar, wo denn nun der bezug zum h743 herkommen soll... ich vermute mal fast: den gibts gar nicht...
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. Das NUCLEO_H743ZI ist hier zumindest aufgeführt. Beitrag "Re: STM32 Core Arduino Framework" Im "Official" Core ist's wohl auch drinn: https://github.com/stm32duino/Arduino_Core_STM32/tree/master/variants
mbed mit ethernet sollte auf diesen Boards "out of the box" laufen: https://os.mbed.com/platforms/?q=&Communication=Ethernet&Interface+Firmware=ST-Link&Board+vendor=STMicroelectronics Falls der fürs H7 Board von CubeMX-generierte Code nicht funktioniert würd ich mir die Nerven sparen und die 30€ für ein Nucleo mit einem M4 oder M7 ausgeben.
"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....
Angehängte Dateien:
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.
"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)
Hier mein Setup: STM32H743ZI-NUCLEO: https://www.st.com/en/evaluation-tools/nucleo-h743zi.html STM32CubeH7 Firmware Package v1.4.0: https://www.st.com/en/embedded-software/stm32cubeh7.html Projects => NUCLEO-H743ZI => Applications => LwIP => LwIP_HTTP_Server_Netconn_RTOS => EWARM IAR Embedded Workbench für Arm 8.40.1: https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm (für den Test die 30 Tage Eval-Lizenz nehmen, da das Projekt zu groß für die 32kB Eval-Lizenz ist) Das Board per Micro-USB anschließen, innerhalb der EWARM das Ganze compilieren, eine Debug-Session starten und dann das Programm per "Go", bzw. F5 laufen lassen.
danke. wenn ich genug va-lium beisammen habe, werde ich das vielleicht mal probieren. aber 1.5GB kommerzsoftware downloaden um einen http-server zu bauen? (Version 8.40, 1358.63 MB) mag sein, dass das nicht zeitgemaesse ansichten sind. und ich tu mir das vielleicht doch irgendwann mal an, um herauszufinden, warum es mit make&co nicht geht. wenn nicht das board ne macke hat, kann es nur das timing oder die speicherbelegung sein. Michael F. (michaelfu): vielleicht kannst du ja mal das .bin posten? dann koennte ich zumindest einen hardwarefehler sicher ausschliessen. oh, ein forum mit zensurautomat ;-) ---> Der Beitrag scheint Spam zu enthalten: "va-lium"
:
Bearbeitet durch User
@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.
1 | mkdir eth_test |
2 | cd eth_test |
3 | mbed new . --create-only |
4 | mbed add https://github.com/VVESTM/mbed-os |
5 | mbed update vve_eth_h7 |
dann eine main.cpp anlegen, zB das Beispiel von hier: https://os.mbed.com/teams/mbed_example/code/TCPSocket_Example/file/50f1485931f1/main.cpp kompilieren mit
1 | mbed compile -m GCC_ARM -t NUCLEO_H743ZI |
das binary landet in ./BUILD/NUCLEO_H743ZI/GCC_ARM 'mbed new . --create-only' erzeugt nur das Projektverzeichnis und eine Konfigdatei, 'mbed add' holt eine library (per git oder hg), 'mbed update' macht den checkout einer bestimmen Version. Mit dem Schalter '--flash' hinter dem compile Kommando wird das binary gleich auf das Board kopiert. Die Ausgaben von printf() kommen über die virtuelle serielle Schnittstelle im USB Device raus.
danke sehr! statt >kompilieren mit >mbed compile -m GCC_ARM -t NUCLEO_H743ZI muss es heissen: mbed compile -t GCC_ARM -m NUCLEO_H743ZI womit wir dann aber schon wieder bei der dose wuermer waeren: ...... Compile [ 99.8%]: USBSerial.cpp Compile [ 99.9%]: PolledQueue.cpp Compile [100.0%]: TaskBase.cpp Link: eth_test /mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2. 1/../../../../arm-none-eabi/bin/ld: BUILD/NUCLEO_H743ZI/GCC_ARM/main.o: in function `__static_initialization_and_destruction_0': /mnt/sda6/eth_test/./main.cpp:5: undefined reference to `EMAC::get_default_instance()' collect2: error: ld returned 1 exit status [ERROR] /mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2. 1/../../../../arm-none-eabi/bin/ld: BUILD/NUCLEO_H743ZI/GCC_ARM/main.o: in function `__static_initialization_and_destruction_0': /mnt/sda6/eth_test/./main.cpp:5: undefined reference to `EMAC::get_default_instance()' collect2: error: ld returned 1 exit status [mbed] ERROR: "/usr/bin/python" returned error. Code: 1 Path: "/mnt/sda6/eth_test" Command: "/usr/bin/python -u /mnt/sda6/eth_test/mbed-os/tools/make.py -t GCC_ARM -m NUCLEO_H743ZI --source . --build ./BUILD/NUCLEO_H743ZI/GCC_ARM" Tip: You could retry the last command with "-v" flag for verbose output was dann wieder fuehrt zu: [ERROR] /mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2. 1/../../../../arm-none-eabi/bin/ld: BUILD/NUCLEO_H743ZI/GCC_ARM/main.o: in function `__static_initialization_and_destruction_0': /mnt/sda6/eth_test/./main.cpp:5: undefined reference to `EMAC::get_default_instance()' collect2: error: ld returned 1 exit status und das kommt wieder aus : // Network interface EthernetInterface net; soifz was wohl wieder soviel heisst wie: "mbed kennt kein EthernetInterface beim 743zi" wobei mir jetzt nicht klar ist: Wieso compiliert das bei Dir ? Er sollte doch immer das "mbed-os" im aktuellen Verzeichnis verwenden - oder ? ps: diverse mbed-tests hatte ich ja auch schon ausprobiert. klappt auch. nur mit dem eth-fork, damit will es nicht. und damit auch mit dem gesamten eth nicht....
:
Bearbeitet durch User
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
Damit https://github.com/ARMmbed/mbed-os-example-fault-handler sollte sich mit dem .elf und/oder .map file rekonstruieren lassen wo das genau passiert.
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 ;-)
Diese Zeilen hat der Vincent V. modifiziert: https://github.com/VVESTM/mbed-os/blob/a0d598863ede1ae9a450a6435a9d82a2ef0a2593/features/lwipstack/lwip-sys/arch/lwip_sys_arch.c#L54 Er arbeitet ja scheinbar mit dem IAR Compiler, bei den anderen steht noch ein ,aligned hinter der section für den gcc. Beim H7 fehlt das, das würde ich mal dahinter packen. Der Code ist noch recht frisch, aber wenn beim Vincent schon die TCP Tests durchlaufen wird da schon eine Menge getestet: https://github.com/VVESTM/mbed-os/tree/vve_eth_h7/TESTS/netsocket/tcp Das ist kein Spielzeug. Nachtrag: das hier scheint faul zu sein: https://github.com/VVESTM/mbed-os/commit/a0d598863ede1ae9a450a6435a9d82a2ef0a2593 lt. Kommentar hat Vincent die Anzahl Descriptoren erhöht und die Adresse für die DMATxDscrTab hat sich von 0x30040200 nach 0x30040400 verschoben. Das wurde aber im GCC Linkerscript nicht nachgezogen (ist schon gefährlich sowas im Linkerscript/Code zu mischen). Aber mit einer Anpassung der Adresse in https://github.com/VVESTM/mbed-os/blob/a0d598863ede1ae9a450a6435a9d82a2ef0a2593/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld#L182 könnte es klappen.
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:
1 | diff --git a/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld b/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld
|
2 | index 4e50b43736..31a1d82438 100644
|
3 | --- a/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld
|
4 | +++ b/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/STM32H743xI.ld
|
5 | @@ -179,10 +179,10 @@ SECTIONS
|
6 | . = ABSOLUTE(0x30040060); |
7 | *(.TxDecripSection) |
8 | |
9 | - . = ABSOLUTE(0x30040200);
|
10 | + . = ABSOLUTE(0x30040400);
|
11 | *(.RxArraySection) |
12 | |
13 | - . = ABSOLUTE(0x30044000);
|
14 | + . = ABSOLUTE(0x30044200);
|
15 | *(.ethusbram) |
16 | } > RAM_D2 AT > FLASH |
hi jojos, > hast du schon aufgegeben? ja, quasi.... ich hatte das board seitdem nicht mehr angefasst. mit dem patch tut es in der tat. besten dank. aber durch wie viele manual-pages muss man sich durchwuehlen, nur um diesen patch hin zu bekommen? ganz schoen viele... und dann hat man einen rudimentaeren IP-stack, der nicht mal auf "ping" antworten kann. gut, bei dem neuen PI4 musste ich auch in den libs rumpatchen, damit sie dort wg. der veraenderten adressen laufen. aber das neue PI4 ist auch gerade mal 4 wochen alt - und nicht 2 jahre, wie dieses stm-board. allerdings scheint es auch mit dem neuen PI4 schwierig zu werden, wenn man zuverlaessig unter 100usec latency kommen will. http://erste.de/latency_PI4.png http://erste.de/timing-tests.PI4.html
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.