hi zusammen, hat inzwischen mal irgendwer ein NUCLEO-H743ZI-board mit ethernet-funktionalität zum laufen bekommen? 2019 ging das nicht und auch ein erneuter versuch am WE (diesmal mit arduino-ide) führte nur zu haufenweisen fehlermeldungen. (inkompatible libs, fehlende header usw...) dieser hier: https://github.com/windsorschmidt/stm32h7-nucleo-h743zi-ethernet-lwip läasst sich zwar mit gcc-arm-none-eabi compilieren. aber das eth-interface rührt sich nicht. auch alles andere, was ich bislang fand, war nicht dazu zu bewegen, irgendwas übers eth zu senden... ausser einer leuchtenden eth-link-led tut sich nichts.
Wicki W. schrieb: > auch alles andere, was ich bislang fand, war nicht dazu zu bewegen, > irgendwas übers eth zu senden... Was tust du denn um dem LWIP zu sagen dass es irgendwas senden oder empfangen soll? Man bekommmt zwar das komplette Firmware- Gerüst zur Verfügung gestellt, aber das tut für sich allein erst mal nichts. Ausserdem darf "man" sich noch ein bisschen Gedanken machen den Controller im eigenen LAN korrekt mit Adressen zu versorgen, sonst geht auch nix. Diese meine Aussagen da du dich zu deiner Vorgehensweise nicht weiter äusserst. Aber vielleicht rede ich zu sehr an deinen Bedürfnissen vorbei. Du fragtest ja nach einem lauffähigen Beispiel. Ich schau mal in meiner Code-Sammlung nach, soweit ich mich erinnere hatte ich LWIP bereits am Laufen auf dem H743. Wenn nicht, dann mache ich es noch .... l8r ....
Wastl schrieb: > Wicki W. schrieb: >> auch alles andere, was ich bislang fand, war nicht dazu zu bewegen, >> irgendwas übers eth zu senden... > > Was tust du denn um dem LWIP zu sagen dass es irgendwas senden > oder empfangen soll? M hi wastl, ich hatte mich vor 4 jahren daran schon festgebissen. mit ählich geringem erfolg. alle sourcen, die ich jetzt am WE getestet hatte (und das waren einige - bei denen sich dann bei näherem nachforschen aber herausstellte: sie laufen explizit nicht mit dem 743) haben i.d.r. eine IP fest verdrahtet. also sollte man eigentlich wenigstens eine ping-antwort erwarten können. wie es auch in der doc des o.g. paketes steht: "Open console/terminal window and use commad - ping 192.168.1.100" aber es kommt nichts... und das problem habe offenbar nicht nur ich. posts wie diese finde ich zu hauf: 2 years ago "ST is incapable of providing a working network solution... [....] By quickly searching it seems many people tried to do that but without any success." usw... das ist echt frustrierend
Ich hab mal NuttX (https://nuttx.apache.org/) auf dem Ding getestet, und es hat alles funktioniert, was ich machen wollte. fchk
Bei mir funktioniert das auf nem F746 mit HAL und FreeRTOS. War relativ problemlos. Nur die Stacksize für die Tasks musste ich anpassen, damit das auch mit Debugger lief.
Angehängte Dateien:
-
UDPWrite_Test_App.png
24 KB
Hier mal eine Testfirmware für das Nucleo H743ZI. Die Firmware holt sich per DHCP aus dem LAN eine IP Adresse und nennt sich selbst H743, kann also mit seiner IP-Adresse oder mit diesem Namen adressiert werden. Damit kann man per UDP von aussen einen (null-terminierten) String empfangen und die Firmware sendet das dann als Echo zurück. Zu verwendender Port ist 100. Die Firmware hatte ich mal mit einer älteren Version von CubeMx generiert. Ein Versuch mit einer aktuellen Version von CubeMx eine lauffähige Firmware zu generieren gelang mir nicht. Solche Mißerfolge sind auch im Netz nachzulesen. Bei STM wird zugegeben dass sich Datenstrukturen im Ethernet- bzw. LWIP Treiber geändert haben und damit nicht mehr fehlerfrei kompiliert werden kann. Ich hänge momentan bei CubeMx v5.6 fest, evtl. sind neuere Versionen besser in der Lage einen fehlerfreien Build auszuführen. Wohlgemerkt bezieht sich das Fehlerbild auf die Konfiguration der Sourcen, es hängt also auch an den Versionen der Firmware- Librarie von STM (CubeH7vX.x.x). Eine Firmware auf dem Nucleo F429 (dieses Board steht mir auch zur Verfügung) zu bauen und auszuführen macht dagegen keine Probleme, es ist nur der H743 der die Probleme macht.
danke für die info! also praktisch alles, was ich mit gcc-make oder arduino zu compilieren versuchem das scheitert, sobald es irgendwie mit ethernet zu tun hat. obwohl ich alles was ich irgendwie an stm32-libs finden konnte mit dazu gepackt habe. wie bekomme ich dein test-.elf auf das board? st-flash sagt mir addr too high stlink_fwrite_flash() == -1 obwohl 0x80000000 doch nicht zu hoch sein sollte - oder ? der hier https://github.com/windsorschmidt/stm32h7-nucleo-h743zi-ethernet-lwip der lässt sich compilieren - ist aber stumm. und ich hab ihn auch noch nicht dazu bewegen können, debug-infos über USB-seriell auszugeben. also ich hatte es noch nie mit einem board zu tun, das sie so vehement widersetzt hat.
Wicki W. schrieb: > wie bekomme ich dein test-.elf auf das board? Oh, ich habe es aus der Entwicklungsumgebung (Atollic Truestudio) auf mein Board geflasht. Habe es gerade ausprobiert: der STM32 CubeProgrammer kann auch *.elf Files flashen. Wenn alles nichts hilft dann schicke ich auf Nachfrage noch ein Binary.
St-flash kann offensichtlich nur .bin flashen, da ist das modernere STM32CubeProgrammer deutlich besser. Dann liefert STM in den Cube Packages auch Beispiele mit, z.B. https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/NUCLEO-H743ZI/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS Wie sieht es damit aus?
also ich habe bislang nur arduino-ide und gcc dafür benutzt. LwIP_HTTP_Server_Netconn_RTOS will wieder cube haben, andere wollen eclipse und jede hat ihre eigenen nervigen besonderheiten. chatgp und die üblichen suchmaschinen liefern immer hinweise, die nicht mehr aktuell sind - usw.... wastl: ein bin für das obige .elf wäre gut. dann kann ich zmindest ausschliessen, dass es ein simpler hardwaredefekt ist. offenbar benutzt kaum jemand das h743zi. wegwerfen wäre vielleicht schon vor 4 jahren die beste lösung gewesen. welches board ist denn aktueller, hat ungefähr ebensoviele IOs und mach nicht so viele probleme ?
Wicki W. schrieb: > wastl: ein bin für das obige .elf wäre gut. Voilá. Ist zwar kein Binary, aber hex ist sicherer.
Wicki W. schrieb: > LwIP_HTTP_Server_Netconn_RTOS will wieder cube haben, andere > wollen eclipse und jede hat ihre eigenen nervigen besonderheiten. die Cube IDE ist Eclipse und nun mal das was der Hersteller am besten unterstützt. Mit der alten Arduino IDE kann man nicht debuggen und bei Kalibern von H7 macht das keinen Spaß ohne dem. Komponentenbasierte Software ist nicht einfach auf H7 mit verschiedenen Bussen und Speichern, da muss man schon anwendungsbezogene Linkerskripte bauen können und da wird es schwierig mit Arduino.
Wastl schrieb: > Voilá. Ist zwar kein Binary, aber hex ist sicherer. auch damit kann das st-flash nix anfangen. Warum nicht STM32CubeProgrammer? Muss das jetzt noch unter Windows98 laufen?
Wicki W. schrieb: > LwIP_HTTP_Server_Netconn_RTOS will wieder cube haben, andere > wollen eclipse und jede hat ihre eigenen nervigen besonderheiten. Ja, wasch mir den Pelz aber mach mich nicht nass. Ich habe den Eindruck du willst viel, aber wenig dafür tun. Dann stelle dir einen Programmierer ein der das für dich tut. Die sichere Metzhode ist: nimm dir eine IDE deiner Wahl, hole dir eine komplette LwIP-Sourcensammlung und baue alles von Grund auf selbst zusammen. Dann verstehst du alles und kannst alle Fehler beheben die dir so begegnen. Auf diese Art haben vermutlich alle Leute die früher noch kein CubeMX kannten bzw in den Genuss dessen kommen konnten, ihre Applikationen selbst geschaffen.
J. S. schrieb: > auch damit kann das st-flash nix anfangen. Von welcher Applikation du genau redest weiss ich jetzt nicht, auf jeden Fall kann das ST-Link Utility *.hex Dateien korrekt verarbeiten. J. S. schrieb: > Muss das jetzt noch unter Windows98 laufen? Was schreibst du da für Käse?
Wastl schrieb: > Was schreibst du da für Käse? das ist nichts gegen deine Hilfsbereitschaft, sondern ich frage mich wie unbeweglich man sein kann. Aus dem .elf kann man im übrigen auch selber ein .bin machen wenn man sich bemühen würde. Wastl schrieb: > auf jeden Fall kann das ST-Link Utility *.hex Dateien korrekt > verarbeiten. der TO benutzt aber das st-flash, das ist etwas anderes.
J. S. schrieb: > Aus dem .elf kann man im übrigen auch selber > ein .bin machen wenn man sich bemühen würde. Da brauch ich mich nicht bemühen. Ich halte nur *.bin für unsicher.
also st-flash kann .hex schreiben. und das ergebnis sieht auch gut aus: st-flash --reset write 743ZI_LwIP_Test.hex 0x08000000 st-flash 1.7.0 2023-05-02T16:13:54 INFO common.c: H74x/H75x: 128 KiB SRAM, 2048 KiB flash in at least 128 KiB pages. file H743ZI_LwIP_Test.hex md5 checksum: ffe8c2f14a5b707fca956874d2494734, stlink checksum: 0x00a937bc 2023-05-02T16:13:54 INFO common.c: Attempting to write 207652 (0x32b24) bytes to stm32 address: 134217728 (0x8000000) 2023-05-02T16:13:55 INFO common.c: Flash page at addr: 0x08000000 erased 2023-05-02T16:13:56 INFO common.c: Flash page at addr: 0x08020000 erased 2023-05-02T16:13:56 INFO common.c: Finished erasing 2 pages of 131072 (0x20000) bytes 2023-05-02T16:13:56 INFO common.c: Starting Flash write for H7 207652/207652 bytes written 2023-05-02T16:13:59 INFO common.c: Starting verification of write complete 2023-05-02T16:14:01 INFO common.c: Flash written and verified! jolly good! 2023-05-02T16:14:01 INFO common.c: Go to Thumb mode aber danach passiert nichts auf dem interface. wenn ich aber dein erstes .elf-file mit objcopy in ein .bin unwandel und das ins /NODE-verzeichnis kopiere, dann passiert etwas: Name: H743 IPv4: 192.168.0.153 IPv6: MAC Address: 00:80:E1:00:00:00 (STMicroelectronics SRL) froy! irgendwas ist schräg hier...... aber zumindest ist es wohl nicht der eth-port, der defekt ist. danke sehr! nochmal gegenprobe: st-flash --reset write H743ZI_LwIP_Test.hex 0x08000000 st-flash 1.7.0 2023-05-02T16:35:48 INFO common.c: H74x/H75x: 128 KiB SRAM, 2048 KiB flash in at least 128 KiB pages. file /home/ralf/Downloads/H743ZI_LwIP_Test.hex md5 checksum: ffe8c2f14a5b707fca956874d2494734, stlink checksum: 0x00a937bc 2023-05-02T16:35:48 INFO common.c: Attempting to write 207652 (0x32b24) bytes to stm32 address: 134217728 (0x8000000) 2023-05-02T16:35:49 INFO common.c: Flash page at addr: 0x08000000 erased 2023-05-02T16:35:50 INFO common.c: Flash page at addr: 0x08020000 erased 2023-05-02T16:35:50 INFO common.c: Finished erasing 2 pages of 131072 (0x20000) bytes 2023-05-02T16:35:50 INFO common.c: Starting Flash write for H7 207652/207652 bytes written 2023-05-02T16:35:53 INFO common.c: Starting verification of write complete 2023-05-02T16:35:55 INFO common.c: Flash written and verified! jolly good! nichts... kein traffic, kein lauflicht... eth# arm-none-eabi-objcopy -O binary H743ZI_LwIP_Test.elf output.bin eth# cp output.bin media..../NODE_H743ZI/ eth# ping 192.168.0.153 PING 192.168.0.153 (192.168.0.153) 56(84) bytes of data. 64 bytes from 192.168.0.153: icmp_seq=1 ttl=255 time=10.8 ms 64 bytes from 192.168.0.153: icmp_seq=2 ttl=255 time=2.14 ms 64 bytes from 192.168.0.153: icmp_seq=3 ttl=255 time=4.78 ms 64 bytes from 192.168.0.153: icmp_seq=4 ttl=255 time=5.11 ms 64 bytes from 192.168.0.153: icmp_seq=5 ttl=255 time=5.49 ms jetzt geh ich erstmal irgendwohin und krieg n herzinfarkt.....
https://www.mankier.com/1/st-flash#Description du kannst mit st-flash in den Controller schreiben was du willst, auch dein Linux Image wenn es in den Controller passt. Es ist halt kein Code den der M7 ausführen kann... Deshalb muss es ein .bin sein, mit richtiger Startadresse. Das alles kann man sich sparen wenn man das .elf und ein Werkzeug nimmt das damit umgehen kann. Aber das musste ich auch schon 'Profis' erklären.
>> LwIP_HTTP_Server_Netconn_RTOS will wieder cube haben, andere >> wollen eclipse und jede hat ihre eigenen nervigen besonderheiten. > > Ja, wasch mir den Pelz aber mach mich nicht nass. Ich habe > den Eindruck du willst viel, aber wenig dafür tun. Dann > stelle dir einen Programmierer ein der das für dich tut. hätt ich glatt öfter getan, wenn es welche gegeben hätte. aber wir haben nicht nur fachkräftemangel bei kellnern, heizungsbauern und krankenpflegern. > Die sichere Metzhode ist: nimm dir eine IDE deiner Wahl, > hole dir eine komplette LwIP-Sourcensammlung und baue alles das ist ja die frage: welche IDE ? ich sag doch: jede hat ihre eigenen nervigen besonderheiten und für jede muss man tage investieren um beurteilen zu können, welche die "beste" für die eigenen vorhaben ist. das zu beurteilen fällt aber schwer, wenn eine profane anwendung, wie eine pings-antwort auf eine statische IP schon beim compilieren und bei libs scheitert. und dass es da bei dem 743 einige probleme gibt, dass kann man ja seit mehr als 4 jahren im netz nachlesen. mir persoenlich ist eigentlich ein schlichter gcc am liebsten.
Wicki W. schrieb: > das ist ja die frage: welche IDE ? > ich sag doch: jede hat ihre eigenen nervigen besonderheiten Warum nimmst du nicht einfach CubeIDE? Da ist alles dabei, was du benötigst, inkl. funktionierender Beispiele.
Harry L. schrieb: > Da ist alles dabei, was du benötigst, inkl. funktionierender > Beispiele. Nur die für Ethernet/LwIP für den H743 nicht.
Wastl schrieb: > Harry L. schrieb: >> Da ist alles dabei, was du benötigst, inkl. funktionierender >> Beispiele. > > Nur die für Ethernet/LwIP für den H743 nicht. Verdammt! du hast Recht! Was soll das denn???
also für mein H743ZI2 geht es. Man muss wie es im Tooltip steht (das knallrot auf grau muss man aber erstmal lesen können) den Cache aktivieren, dann lässt sich lwip und Ethernet aktivieren. Beim Nucleo H743ZI genauso.
:
Bearbeitet durch User
J. S. schrieb: > also für mein H743ZI2 geht es. Code generieren kann man für alles. Nur zum Laufen bringt man es nicht so einfach ... Wer es kann sei herzlich eingeladen seine lauffähige , funktionsfähige Implementierung hier zu präsentieren. Bloss Sprüche machen kann jeder. Einschränkungen mögen gelten, die ich bereits erwähnt habe: Wastl schrieb: > Ich hänge momentan bei > CubeMx v5.6 fest, evtl. sind neuere Versionen besser in > der Lage einen fehlerfreien Build auszuführen.
Wastl schrieb: > Wer es kann sei herzlich > eingeladen seine lauffähige hatte ich gemacht, kann Harry bestätigen. Für den Debug Build muss der FreeRTOS Stack vergrößert werden. Ich benutze Mbed OS und da funktioniert es. Der Stack Fehler war da aber genauso drin...
J. S. schrieb: > Für den Debug Build muss der FreeRTOS Stack vergrößert werden. > Ich benutze Mbed OS und da funktioniert es Beim Build ohne RTOS oder Ähnlichem funktioniert aber fast gar nichts. Wir reden hier von CubeMX Sourcecode generieren für Ethernet/LwIP ohne OS, für den H743. In diesem Fall lassen sich (fast) keine lauffähigen Binaries erstellen.
ich rede von CubeMX generierten Code incl. FreeRTOS, der hat funktioniert. Mit FreeRTOS war schwieriger wg. Stackfehler, ohne FreeRTOS ging es meine ich auch. Ist schon wieder ein paar Monate her.
nochmal fürs Protokoll: Der generierte Code funktioniert, das war aber ein F7. Der H7 ist da doch zickiger und der generierte Code funktioniert erstmal nicht. Man muss einige weitere Einstellungen vornehmen die hier zusammengefasst sind: https://community.st.com/s/article/How-to-create-project-for-STM32H7-with-Ethernet-and-LwIP-stack-working Man kann es z.T. einfacher machen und den D-Cache abschalten, aber wenn man das in CubeMX macht, dann wird lwip deaktiviert. Sehr merkwürdig. Mit den Einstellungen aus dem KB Artikel funktioniert es jedenfalls mit dem H743ZI2, auch mit DHCP. Da das schon länger bekannt ist, wundere ich mich schon das es nicht in CubeMX integriert ist. Auch wenn einiges Empfehlungen sind und für die jeweilige Anwendung angepasst werden müsste, bei der Menge an Einstellungen ist das schon heftig. Hilfreich ist dann ein _write zu implementieren um die lwip Debugmeldungen über den seriellen USB zu bekommen. Im github: https://github.com/JojoS62/Test-H743ZI2-lwip
:
Bearbeitet durch User
Wastl schrieb: > Beim Build ohne RTOS oder Ähnlichem funktioniert aber fast > gar nichts. Wir reden hier von CubeMX Sourcecode generieren > für Ethernet/LwIP ohne OS, für den H743. In diesem Fall lassen > sich (fast) keine lauffähigen Binaries erstellen. nun bin ja ja ein wenig beruhigt, dass es a) kein hardwareproblem ist und b) nicht ich allein auf diese ganze probleme laufe die arduino-ide habe ich nun wirklich mit allem gefüttert, was irgendwie nach stm32 aussah - da laufe ich immer noch nur auf errors (sobald irgendwas mit eth auftaucht). mit arm-none-eabi-gcc bekomme ich H743ZI_LwIP_ADC+ETH und ich bekomme auch netztraffic. den hier kann ich ebenfalls compilieren: stm32h7-nucleo-h743zi-ethernet-lwip aber netztraffic gibt es keinen der hier H743ZI_LwIP_Test.elf (umgewandelt in .bin) mach ein schönes lauflicht und antwortet auf ping. womit mache ich nun sinnigerweise weiter? ein kommndzeilenorietierte umgebung wäre mir deutlich lieber als eine 100-fenster-ide. aber das scheint für einen h743 ziemlich schwierig aufzubauen zu sein. hab ich ne chance, ein RTOS da drauf zu bekommen, mit dem dann eth und serial-usl angesprochen werden können?
Wicki W. schrieb: > ein kommndzeilenorietierte umgebung wäre mir deutlich lieber > als eine 100-fenster-ide. CubeMX kann ein makefile Projekt erzeugen. Die Quälerei tue ich mir aber nicht an.
Für mich klingt das alles eher so, als würde man einen Fahranfänger in einen F1-Boliden setzen... Fang doch erst mal mit was Überschaubaren an! (F4xx mit Ethernet z.B.) Projekte, die einen F7/H7 brauchen sind i.d.R. auch deutlich grösser, und sowas macht man heute nicht mehr ohne komfortable IDE mit Debugger, Refactoring etc. Wenn dich so eine IDE bereits überfordert, wird es ein H7 erst recht.
> Wenn dich so eine IDE bereits überfordert, wird es ein H7 erst recht.
das hat nicht mit "überfordern" zu tun, sondern mit persönlichen
präferenzen.
warum muss ich mich seit jahrzehten dafür rechtfertigen, dass
ich keine viele-fenster-IDEs mag?
Wicki W. schrieb: > warum muss ich mich seit jahrzehten dafür rechtfertigen, dass > ich keine viele-fenster-IDEs mag? Wenn du die Sinnhaftigkeit moderner IDEs und ihrer Möglichkeiten nicht erkennst... Wer nicht mit der Zeit geht, geht mit der Zeit...
Harry L. schrieb: > Wer nicht mit der Zeit geht, geht mit der Zeit... Erzürne nicht, setze dich ans Ufer des ruhigen Flusses und warte.... und wenn ich nicht von der grossartigen openai auf eine falsche fährte gelockt worden wäre, dann wäre ich vermutlich schon füher weiter gewesen. jedenfalls liess sich nuttx relativ problemlos compilieren (danke für den hinweis an on Frank K.) und ich hab zumindest erst mal eine shell. eth zickt aber immer noch "es hat alles funktioniert, was ich machen wollte." frank: war bei dem, was du machen wolltest, auch eth dabei ?
Wicki W. schrieb: > jedenfalls liess sich nuttx relativ problemlos compilieren Nur weil der Compiler nicht meckert, bedeutet das noch lange nicht, daß das Ergebnis auch wie gewünscht funktioniert. Wicki W. schrieb: > eth zickt aber immer noch Was du da treibst, hat mit "Entwickeln" nicht viel zu tun. Das ist Try&Error in bester Maker-Manier. So wird das nix bei so komplexen Systemen.
Harry L. schrieb: > Was du da treibst, hat mit "Entwickeln" nicht viel zu tun. > Das ist Try&Error in bester Maker-Manier. > > So wird das nix bei so komplexen Systemen. also diese grundsatzdiskussion hier ist ganz schön nervig! ich will nichts entwicklen, ich will testen. und wenn ein webserver nicht mal eben einfach so läuft, dann ist das ein schlechtes testergebnis.
Wicki W. schrieb: > und wenn ein webserver nicht mal eben einfach so läuft, > dann ist das ein schlechtes testergebnis. Versuchs mal mit CycloneTCP; ich habe selber damit super Erfahrungen gemacht und die haben fixfertige Beispiele für alle gängigen Nucleo Boards mit Ethernet. https://www.oryx-embedded.com/products/CycloneTCP Als Entwicklungsumgebung am besten STM32CubeIDE verwenden.
:
Bearbeitet durch User
Wicki W. schrieb: > jedenfalls liess sich nuttx relativ problemlos compilieren > (danke für den hinweis an on Frank K.) > und ich hab zumindest erst mal eine shell. > > eth zickt aber immer noch > > "es hat alles funktioniert, was ich machen wollte." > > frank: > war bei dem, was du machen wolltest, auch eth dabei ? ja. fchk
J. S. schrieb: > nochmal fürs Protokoll:...... > ................. Ausdrücklichen Dank an dich für diesen Beitrag. Ich wäre auch der Meinung gewesen dass CubeMX alle diese Parameter bereits richtig einstellt. So ist es doch ein heilloses Gefrickel bis das alles stimmt. Ich hatte mir auch einen Wolf gesucht und den von dir genannten Artikel von STM über Ethernet, LWIP und H743 nicht gefunden oder im Wust der Suchergebnisse nicht erkannt. Bleibt zu hoffen dass ein einmal erzeugter Sourcen-Satz mit lauffähigem, funktionsfähigem Ergebnis nicht durch Re- Generieren von CubeMX wieder zerstört wird.
Wicki W. schrieb: > der hier H743ZI_LwIP_Test.elf (umgewandelt in .bin) > mach ein schönes lauflicht und antwortet auf ping. In aller Bescheidenheit: "Er" antwortet auch mit einem Echo auf UDP Messages ;-)
Wastl schrieb: > Bleibt zu hoffen dass ein einmal erzeugter Sourcen-Satz mit > lauffähigem, funktionsfähigem Ergebnis nicht durch Re- > Generieren von CubeMX wieder zerstört wird. Ja, das ist mittlerweile recht sicher. Nur immer schön brav auf die User Code Tags achten. Das Linkerskript bleibt auch erhalten. Trotzdem nie mehr ohne git.
Frank K. schrieb: > Wicki W. schrieb: > >> jedenfalls liess sich nuttx relativ problemlos compilieren >> (danke für den hinweis an on Frank K.) >> und ich hab zumindest erst mal eine shell. >> >> eth zickt aber immer noch >> >> "es hat alles funktioniert, was ich machen wollte." >> >> frank: >> war bei dem, was du machen wolltest, auch eth dabei ? >>>ja. hast du vielleicht die .config noch? bei mir steigt der compiler aus, sobald ich networking nur irgendwie aktiviere (und sämtliche darunter liegenden einstellungen deaktiviert lasse).
moin zusammen, nachdem hier ja jetzt ziemliche funkstille herrscht, kome ich nochmal auf meine frage vom 2.5. zurück. bevor ich einen neuen thread dafür aufmache: Wicki W. schrieb: > dann kann ich zumindest ausschliessen, dass es ein simpler > hardwaredefekt ist. das kann ich inziwschen ja ausschliessen. dennoch ist es mir nicht gelungen, im nuttx irgendwie das netz zu aktiviereno ohne dass der compiler aussteigt. > offenbar benutzt kaum jemand das h743zi. > wegwerfen wäre vielleicht schon vor 4 jahren die beste > lösung gewesen. zu diesem schluss komme ich immer mehr - denn die zahl relevanter projekte, die auf diesem board basieren, die ist doch auch heute noch sehr überschaubar RIOT-OS,libopencm3 und eine handvoll andere, die dann auch mal locker 5GB nur die umgebung benötigen - und dann auch gern mal nicht aktuell oder irgendwie buggy sind. was sie alle gemeinsam haben: eth geht nie problemlos. also komme ich wieder zu der frage: welches board ist denn aktueller, hat ungefähr ebensoviele IOs und macht nicht so viele probleme ? zu welchem würdet ihr raten?
Wicki W. schrieb: > also komme ich wieder zu der frage: > welches board ist denn aktueller, hat ungefähr > ebensoviele IOs und macht nicht so viele probleme ? Nutze die parametrische Suche in CubeMX, da werden sie geholfen. Nur mit dem Parameter "aktueller" wirst du dir schwer tun. Ich verstehe auch nicht warum ein aktuelleres Board zu deinen Bedürf- nissen besser passt als ein weniger aktuelles. Die wichtigen Anforderungem wie RAM-Grösse, Flash-Grösse, Arbeitsgeschwindigkeit und Schnittstellen-Art und -Zahl hast du nicht genannt, also scheint es für dich nur wichtig zu sein möglichst aktuell zu sein. Hier noch meine bescheidene Erkenntnis: Wastl schrieb: > Eine Firmware auf dem Nucleo F429 (dieses Board steht mir > auch zur Verfügung) zu bauen und auszuführen macht dagegen > keine Probleme.
Wastl schrieb: > Nutze die parametrische Suche in CubeMX, da werden sie geholfen. > Nur mit dem Parameter "aktueller" wirst du dir schwer tun. Ich > verstehe auch nicht warum ein aktuelleres Board zu deinen Bedürf- > nissen besser passt als ein weniger aktuelles. cubex wehrt sich auch beahrrlich. und ist ja sowas von gierig... 7GB für eine grundinstallation halt ich schon für etwas überzogen. aber ich versuche es grade noch einmal. > Die wichtigen Anforderungem wie RAM-Grösse, Flash-Grösse, > Arbeitsgeschwindigkeit und Schnittstellen-Art und -Zahl hast du > nicht genannt, also scheint es für dich nur wichtig zu sein > möglichst aktuell zu sein. "aktuell" ist mir vollkommen egal. ordentlich supported sollte es sein. und der eindruck ist beim 743 bislang nicht entstanden. ich bin inzischen sehr bescheiden geworden: eine halbwegs schnelle CPU, ein bisschen RAM und eine handvoll I/Os und ein eth, dessen hardware man nicht von hand auf bitebene konfigurieren muss - das reicht mir, für das, was ich testen möchte. wobei ich grad über taktraten in den datenblättern stolpere: 32.768 kHz crystal oscillator da hatte ich doch was anderes in erinnerung ? > Hier noch meine bescheidene Erkenntnis: >> Eine Firmware auf dem Nucleo F429 (dieses Board steht mir >> auch zur Verfügung) zu bauen und auszuführen macht dagegen >> keine Probleme. OK - davon gibt es auch wieder x varianten. und mouser.de sagt: Lieferzeit ab Hersteller: 92 Wochen räusper das datenblatt bei voelkner von 2018 ist 2 seiten lang und eher werbesprospekt als aussagekräftig. aber ich schau mal....
Wicki W. schrieb: > welches board ist denn aktueller Wicki W. schrieb: > "aktuell" ist mir vollkommen egal. So so, was sollen wir von deinen widersprüchlichen Aussagen halten?
Wicki W. schrieb: > Lieferzeit ab Hersteller: 92 Wochen > > räusper https://www.conrad.de/de/p/stmicroelectronics-nucleo-f429zi-entwicklungsboard-1-st-2365182.html?hk=SEM&WT.mc_id=google_pla&gclid=EAIaIQobChMI28Oi7ufs_gIVzAaLCh3zwAbgEAQYAiABEgI92vD_BwE Wicki W. schrieb: > 32.768 kHz crystal oscillator > > da hatte ich doch was anderes in erinnerung ? Du darfst auch mal Datenblatt und Refernce Manual lesen. Man braucht dir hier nicht jeden Pipifax erklären müssen. Wicki W. schrieb: > aber ich schau mal.... Ja, schau erst mal bevor du hier dauernd unqualifiziert herumplapperst.
Wastl schrieb: > Wicki W. schrieb: >> welches board ist denn aktueller > > Wicki W. schrieb: >> "aktuell" ist mir vollkommen egal. > > So so, was sollen wir von deinen widersprüchlichen Aussagen halten? mit "aktueller" meinte ich: besser unterstützter als das 743 zu dem cubemx 6.8.1 immer noch sagt: "STM32CubeMX Minimum Compatible Version NA" was soll ich davon halten?
Angehängte Dateien:
-
Clocktree01.JPG
180 KB -
Conf_Cortex_M7.JPG
180 KB -
Conf_Eth_GPIO.JPG
190 KB -
Conf_Eth_Settings.JPG
120 KB -
Conf_LWIP_Checksum.JPG
180 KB -
Conf_LWIP_Generell.JPG
150 KB -
Conf_LWIP_KeyOptions.JPG
200 KB -
Conf_LWIP_PlatformSettings.JPG
140 KB -
Conf_RCC.JPG
120 KB -
Project01.JPG
85 KB
Hi, ja - H743ZI und Ethernet läuft. Ist aber eine Frickelorgie. Probier mal meine Schritt für Schritt-Anleitung. Das "Speicheraufteilungsgedöns" geht aus den Screenshots hervor. Quellen: https://www.youtube.com/watch?v=8r8w6mgSn1A https://controllerstech.com/ https://controllerstech.com/stm32-ethernet-1-connection/ 1. USB_OTG (Device) abschalten 2. RCC Power Regulator Voltage Scale => Scale 1 (High Performance) 3. Clock Tree CPU = 400MHz 4. ETH-GPIO RMII-Pin überprüfen mit Schaltplan MB1364 (Eth-Mode = RMII) 5. ETH-Parameter Descriptor+Buffer-Adresse ändern, alt: 0x30040000 (SRAM3) neu: 0x30000000 Rx-Desc., 0x30000080 Tx-Desc., 0x30000100 Rx-Buffer. (SRAM1) Erklärung: SRAM1-Base = 0x30000000 Größe Rx-Descr. = 0x80 = 128Byte Größe Tx-Descr. = 0x80 = 128Byte Größe Rx-Buffer => Rx-Bufferlenght = 1524 * 4 = 6096Byte = 0x17D0; Rx-Descr.: 0x30000000..0x3000007F Tx-Descr.: 0x30000080..0x300000FF Rx-Buffer. 0x30000100..0x300018D0 Heap-Memory: 10*1024Byte = 10k = 0x2800; 0x30002000..0x30004800 Gesamtbedarf-RAM = 18432Byte ca. 18k 6. CORTEX_M7_Parameter: CPU ICache = enable, CPU DCache = enable 7. DANACH: LWIP = enable 8. LWIP_Plattform_Settings Driver_PHY = LAN8742 9. LWIP_General_Settings DHCP = disable; IP-Adresse/Netmask/Gateway eintragen 10. CORTEX_M7_Parameter_Settings: Cortex Memory Protection Unit Control Settings - MPU Control Mode -> Privileged accesses only + MPU Disable During hard fault, NMI and Faultmask 11. CORTEX_M7_Parameter_Settings: Protection Unit 0 Settings: Enabled, 0x30000000, 32kB, level 1 12. in Linker-Skript STM32H743ZITX_FLASH.ld lwip-Sektion einbauen .lwip_sec (NOLOAD) : { . = ABSOLUTE(0x30000000); *(.RxDecripSection) . = ABSOLUTE(0x30000080); *(.TxDecripSection) . = ABSOLUTE(0x30000100); *(.RxArraySection) } >RAM_D2 13. im main.c::while(1) ethernetif_input(&gnetif); + sys_check_timeouts(); einbauen 14. Laden und starten; Ping 192.168.10.104 -> "Antwort von 192.168.10.104: Bytes=32 Zeit<1ms TTL=255" -Projekt aus "c:\xxx\CubeMx\H7\EmMxEth_STM32H743ZI_01" erzeugt -Projekt mit VGD-Wizard erzeugt (Cube-IDE-Import)
:
Bearbeitet durch User
Wastl schrieb: > Wicki W. schrieb: >> 32.768 kHz crystal oscillator >> >> da hatte ich doch was anderes in erinnerung ? > > Du darfst auch mal Datenblatt und Refernce Manual lesen. Man braucht > dir hier nicht jeden Pipifax erklären müssen. > > Wicki W. schrieb: >> aber ich schau mal.... > > Ja, schau erst mal bevor du hier dauernd unqualifiziert herumplapperst. gäbe es anständige und verlässliche datenblätter, dann könnte man da auch mal reinschauen. dass man sich über einen "32.768 kHz crystal oscillator" im "datenblatt" wundert, wenn doch irgendwo mal was mit 400Mhz stand, ist wohl nachvollziehbar. aber allein von dem 743 gibt es ja schon deutlich mehr als eine version. und sowas hier, das will ja wohl niemand ernsthaft "datenbaltt" nennen: https://asset.re-in.de/add/160267/c1/-/gl/002365182DS00/DA_STMicroelectronics-NUCLEO-F429ZI-Entwicklungsboard-1St..pdf und das sind alle dinge die wenig hilfreich sind, wenn man überlegt, auf welche hardware mit welchem compiler und welcher toolchain/ide man sich denn nun einlassen soll.
Ich tendiere ja für meine Pläne eher für ein kleines Blackboard: Man nimmt das hier https://www.ebay.de/itm/385440603731 Dann noch einen PHY DP83848 dazu https://www.ebay.de/itm/163535996543 und verbindet die beiden Teile mit nur 11 Leitungen (RMII Interface) plus Versorgungs-Spannung und Masse. Damit läuft LwIP praktisch out-of-the-box. Vorteil dieses Blackboards ist dass man jede Menge freie Leitungen hat ohne die Einschränkungen eines vorverdrahteten Nucleo Boards.
Wicki W. schrieb: > gäbe es anständige und verlässliche datenblätter, dann könnte man > da auch mal reinschauen. > dass man sich über einen "32.768 kHz crystal oscillator" im > "datenblatt" wundert, wenn doch irgendwo mal was mit 400Mhz > stand, ist wohl nachvollziehbar. Unqualifiziertes BlaBla. Mach nur weiter so. Wicki W. schrieb: > und das sind alle dinge die wenig hilfreich sind, wenn man überlegt, > auf welche hardware mit welchem compiler und welcher toolchain/ide > man sich denn nun einlassen soll. Wastl schrieb: > Ja, wasch mir den Pelz aber mach mich nicht nass. Ich habe > den Eindruck du willst viel, aber wenig dafür tun. Dann > stelle dir einen Programmierer ein der das für dich tut.
Wicki W. schrieb: > nachdem hier ja jetzt ziemliche funkstille herrscht Naja, was solls einem noch kümmern, wenn gute Ratschläge ignoriert werden und stattdessen nur gejammert wird, dass es nicht funktioniert. Wie gesagt, nimm CycloneTCP und in 15 Minuten läuft auf deinem Nucleo ein Webserver. Beitrag "Re: STM32 NUCLEO H743ZI - Ethernet / WebServer-Probleme"
hi thomas, vielen dank! ich werde das mal durchgehen. Thomas T. schrieb: > Hi, ja - H743ZI und Ethernet läuft. > Ist aber eine Frickelorgie. ja, so scheint es.... > Probier mal meine Schritt für Schritt-Anleitung. > Das "Speicheraufteilungsgedöns" geht aus den Screenshots hervor ok - den versuch mache ich dann noch. vielen dank für deine mühe! aber normal ist das alles nicht mehr.... 8GB ide-zeug-installation um einen kleinen controller zu programmieren? da ist ja kernel-conpilieren ein kinderspiel gegen.
Wicki W. schrieb: > ich bin inzischen sehr bescheiden geworden: > eine halbwegs schnelle CPU, ein bisschen RAM und eine > handvoll I/Os und ein eth, dessen hardware man nicht > von hand auf bitebene konfigurieren muss - das reicht mir, > für das, was ich testen möchte. Kannst Dir ja mal das hier anschauen. https://www.microchip.com/en-us/development-tool/DM320209 Du bräuchtest dann noch entweder das hier: https://www.microchip.com/en-us/development-tool/AC320004-6 oder https://www.microchip.com/en-us/development-tool/AC320004-7 Microchip hat alles passende für Dich im Angebot, inkl. eigenem IP-Stack usw. Siehe Harmony 3, wenn Du dafür einen Suchbegriff brauchst. fchk
Wicki W. schrieb: > 8GB ide-zeug-installation um einen kleinen > controller zu programmieren? Das passiert, weil die IDE mit Programmbeispielen, Frameworks, Code-Generatoren und Datenblättern zahlreicher Mikrocontroller angereichert wird. Andererseits wollen nur die wenigsten Leute mit einer IDE arbeiten, die nur eine Hand voll sehr ähnlicher Controller unterstützt. Wenn du eine Arduino IDE mit MightyCore (für mehr ATmegas), ATtinyCore, dem STM32 Core, den ESP32 Core und dem ESP8266 Core ausstattest, dann ist die auch viele GB groß. Code Generatoren sind dann noch nicht dabei.
Hier ist offensichtlich jeder Versuch, weitere Hilfestellung zu leisten vollkommen sinnlos. Der TO ist offenbar in keinster Weise qualifiziert, Projekte dieses Umfangs und Bauteile dieser Komplexität zu beherrschen. Das mag teilweise an mangelnder Erfahrung liegen, aber sein grösstes Problem ist die vollkommene Beratungs-Resistenz.
wisst ihr, ich finde es immer wieder faszinierend, mit welcher überheblichkeit hier teilweise miteinander umgegangen wird.... und dennoch finde ich es schön, wenn man dann doch den einen oder anderen seht nützlichenhinweis bekommt. manchmal reicht ja wirklich schon ein stichwort aus. microchip hatte ich wirklich gar nicht mehr auf dem schirm. stimmt die gibts ja auch noch. wobei ich USD/unit: $61.97 schon sportlich finde... und manche machen sich ja wirklich mühe - wofür ich mich nochmals ausdrücklich hier bedanke.
Wicki W. schrieb: > wisst ihr, ich finde es immer wieder faszinierend, mit welcher > überheblichkeit hier teilweise miteinander umgegangen wird Wie man in den Wald hineinruft so schallt es zurück. In diesem deinen Fall kann man dir sagen was man will, du machst einfach deinen eigenen Stiefel weiter. Beratungsresistenz heisst die Krankheit die dir schon Andere genannt haben. Daher kommen eben andere Töne als die die du erwartest. Wicki W. schrieb: > und manche machen sich ja wirklich mühe Wenn du dich schon beratungsresistent zeigst könntest du dir ja mal Mühe geben und wenigstens die Netiquette bezüglich Groß-/Kleinschreibung beachten. Auch das hilft eine andere Einstellung zu dir zu finden.
hi thomas, also compilieren tut er es - und die einstellungen sollten nun eigentlich auch mit deinen übereinstimmen. Thomas T. schrieb: > Ist aber eine Frickelorgie. ja, das ist es... > Probier mal meine Schritt für Schritt-Anleitung. das ist nun alles drin (glaube ich) - und ohne das hier: > 13. im main.c::while(1) ethernetif_input(&gnetif); + > sys_check_timeouts(); einbauen compiliert er auch. mir ist nicht ganz klar, ob "gnetif" nun ein typo oder gewollt ist. bei beiden steigt er jedenfalls aus. bei gnetif schllägt er "netif" vor und bei "netif" meint er "kenn ich nicht". und ohne antwortet er nicht auf pings.... dsa ganze mit cube 6.8.1-jar unter linux aber mal weiter sehen....
Ein Dokument von ST mit den nötigen Einstellungen für Ethernet auf H7 habe ich schon vor einer Woche gepostet. Und ein lauffähiges Cube Projekt auch. Soviel zu 'Funkstille' hier.
ok, der "gnetif" ist kein fipptehler sondern was externes. extern struct netif gnetif; damit klappt dann auch das compilieren der geänderten main.c. aber eth ist noch immer tot. vielleicht ein firmware-problem ? STM32Cube FW_H7 V1.11.0
also mit cubeide Version: 1.12.1 Build: 16088_20230420_1057 (UTC) FW_H7_V1.11.0 lässt sich LwIP_HTTP_Server_Netconn_RTOS aus den examples des h743 compilieren _und_benutzen. was definitiv nicht geht: https://github.com/hahnec/stm32h7_adc_eth wunderbar dokumentiert, mit schritt-für-schritt-readme. make all st-flash --reset write ./build/H743ZI_LwIP_ADC+ETH.bin 0x8000000 st-flash 1.7.0 [....] 2023-05-13T10:20:23 INFO common.c: Flash written and verified! jolly good! aber es passiert überhaupt nichts auf dem interface und python py_udp_receiver/udp_receiver.py liefert somit auch nichts.... es ist explizit für diese hardware - und sollte damit dann eigentlich auch lauffähig sein. vielleicht finde ich es irgendwann heraus. aber da cubeide ja auch cmdline kann, ist ja erst mal alles in ordnung.
1 | stm32cubeide -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data /[....]/STM32CubeIDE/workspace_1.12.1 -build LwIP_HTTP_Server_Netconn_RTOS &&st-flash --reset write STM32CubeIDE/Debug/LwIP_HTTP_Server_Netconn_RTOS.bin 0x8000000 |
damit kann ich leben. vielen dank für eure mithilfe.
Moin zusammen, nach rund 3 Wochen machen ich dann hier mal eine Zusammenfassung zum STM32 H743ZI. Für die, die so ein Teil auch noch irgendwo rumliegen haben. Diese Zusammenfassung ist geprägt von persönlichen Erfahrungen, jahrelanger µC-Abstinenz und nichts weiter, als meine persönliche Sicht der Dinge. Vor mehr als vier Jahren habe ich den H743ZI mehr oder weniger wahllos bestellt, da ich mal sehen wollte, was damit machbar ist und was nicht. PICs und Arduinos kamen bei dem, was ich vorhatte an ihre Grenzen. Also mal testen, was es sonst so gibt. Und den gab es damals und das las sich auch gut: 35 "Peripheriegeräte", 11 x Analog, 22 Timer, 480MHz, 2MB Flash, 1MB RAM Das klang gut. Schon 2 Jahre am Markt und preisgünstig. Kann man mal versuchen. Meine Abneigung gegen "Vielfenster-IDEs" bestand damals schon. Aber damals konnte man noch recht gut mit Makefiles arbeiten. Heute erweist sich das (bislang) als nahezu unmöglich. Ebenso erweist es sich als nahezu unmöglich, "mal eben" ein funktionierendes Stück Code aus einem Projekt in ein anderes zu transferieren, weil an jedem Stück Code unzählige Register, Parameter, Taktfrequenzen und Speicherbereiche dran hängen, ohne die es dann in der nur minimal anderen Umgebung nicht mehr läuft. Oder Seiteneffekte auf bereits vorhandene Programmteile hat.... Was tatsächlich ohne graphische IDE zum laufen zu bekommen war, das war Nuttx - ich konnte es kaum glauben. Aber nur, wenn man alle Netzwerkkomponenten deaktiviert. (Stand etwas KW18/23) Also musste irgendeine brauchbare IDE her. Die Wahl da zu treffen, das ist sehr schwer. Weil man i.d.R. mehrere Tage braucht, um halbwegs beurteilen zu können, ob diese IDE den eigenen Vorstellungen einigermassen entspricht und man sich vorstellen kann, damit zu arbeiten. Nachdem alle diese IDEs ja Unmengen an Ressourcen fressen, (1-10 GB sind vollkommen normal) und man ja irgendeinen Tod sterben muss, fiel die Wahl dann auf CubeIDE und -MX. Wobei die Option "create Makefile" von CubeMX eigentlich nie brauchbare Resultate lieferte. Compilieren ließ es sich manchmal - funktionieren taten diese Resultate nie (oder fast nie, wenn ich mich recht erinnere). Was beim testen mit CubeIDE herauskam: Aus den vielen Demos, Tests, Branches, Foren zusammengesucht blieben diese Projekte übrig, mit denen ich testen konnte und verwertbare Ergebnisse erreicht habe. FreeRTOS_ThreadCreation GPIO_EXTI LwIP_HTTP_Server_Netconn_RTOS SPI_FullDuplex_ComDMA SPI_FullDuplex_ComPolling und seit grade eben Nuttx! (mehr dazu ganz unten) ThreadCreation ist die Standard-Demo, mit der man sich erst mal ein Bild davon machen kann, wie das Thread-Handling auf diesem Controller gehandled werden kann. LwIP_HTTP_Server_Netconn_RTOS ist ein HTTP-Server, der seine IP per DHCP holt, auf Pings antwortet und HTTP-Seiten ausliefert. Die "Seiten" kommen aber nicht aus einem echten Filesystem, sondern aus einem, das man mit einem perl-Script erst generieren muss. Gab es in mehreren Varianten auch im Netz zu finden GPIO_EXTI - fürs Herumspielen mit GPIOs. Gehört zum ST-Demo-Paket. SPI_FullDuplex_ComDMA wollte nicht so wirklich SPI-Signale erzeugen. Habe das schnell dran gegeben und bin zu SPI_FullDuplex_ComPolling gewechselt, das sich dann als sehr schöne Basis für Erweiterungen erwies und dann immerhin zu einer lauffähigen 7-Segment-Anzeige mit 7219 ausbauen ließ. Die dann wiederum zur Anzeige von Taktzählern für Zeitmessungen verwendet werden konnte. Das ganze auf die Punktmatrix zu erweitern sollte nun relativ einfach sein. Nach diesen zwar sehr langwierigen und oberflächlichen Versuchen kann ich aber wohl sagen, dass Mess- und Responszeiten im 1-stelligen Mikrosekundenbereich eigentlich kein Problem darstellen sollten. Unter einer Mikrosekunde wird es dann (ist mein augenblicklicher Eindruck) schnell grenzwertig. Allein schon, weil dann die Rechteck- Signale auf den Leitungen nicht mehr wirklich Rechteckig sind.... Und eigentlich habe ich ja nur damit angefangen, weil ich gern Responsezeiten von unter 100µSec. sicher realisieren wollte. (und nebenbei noch genug Zeit habe auch komplexere Tasks laufen zu lassen). Zu den grade eben erst gemachten Nuttx-Tests kann ich noch nicht viel sagen - jedenfalls bin ich sehr froh, dass das nun auf dem 743 jetzt auch läuft. Das eröffnet ganz neue Möglichkeiten. Womit ich zur abschließenden Frage komme: Der H743 erwies sich ja nun nicht gerade als ein Glücksgriff.... Und nicht ohne Grund wird man ja inzwischen auch auf "deprecated" hingewiesen, wenn man Cube benutzt. Welche Board nimmt man stattdessen sinnigerweise? Und vielleicht ha ja noch jemand eine Idee, wie man die Entwicklungsumgebung mit Makefiles handlen kann? Von Hand schreiben möchte ich sie nicht. Im Grunde finde ich die Cube ja gar nicht so schlecht. Aber dass man bei jeden Firmware-Wechsel immer 2-3GB Zeugs um die Ohren gehauen bekommt und in diesem Zeugs dann auch noch immer ein paar 100MB .avis drin stecken - das finde ich weder lustig noch sinnvoll. Und dass man Stunden damit verbringen muss, um die Oberfläche so einzurichten, dass man keinen Augenkrebs beim Arbeiten bekommt, das stört mich doch sehr. Von dem undurchsichtigen File-Handling (temporäre Kopien unter User...) mal ganz zu schweigen. Munter bleiben Wicki Hier die neusten h743zi-Resultate mit Nuttx:
1 | https://github.com/apache/nuttx.git |
2 | https://github.com/apache/nuttx-apps.git |
3 | nuttx-apps-Inhalt nach /apps in /nuttx kopieren |
4 | und in .config |
5 | CONFIG_APPS_DIR="./apps" |
6 | eintragen. Sonst Aua: |
7 | Kconfig:2204: can't open file "/Kconfig" |
8 | |
9 | tools/configure.sh -L|grep 743 |
10 | tools/configure.sh -E nucleo-h743zi:netnsh |
11 | |
12 | (wie gesagt: "./apps" eintragen.... |
13 | |
14 | make menuconfig |
15 | (X) STM32H743 Nucleo H743ZI |
16 | ....
|
17 | Register: renew |
18 | Register: nsh |
19 | Register: sh |
20 | Register: ping |
21 | Register: telnetd |
22 | ....
|
23 | |
24 | .bin-File nach /media/.../NODE_H743ZI kopieren |
25 | und mit |
26 | minicom -D /dev/ttyACM0 |
27 | hat man eine Shell. |
28 | |
29 | Mit der Version von Heute (21.05.2023) vom Gitbub funktioniert |
30 | auch das Compilieren _mit_ aktivierten Netzwerk. |
31 | |
32 | Und wann man in der .config manuell eine statische IP angibt, |
33 | dann klappts auch mit dem Netzwerk: |
34 | 64 bytes from 192.168.0.55: icmp_seq=157 ttl=64 time=9.13 ms |
35 | 64 bytes from 192.168.0.55: icmp_seq=158 ttl=64 time=3.61 ms |
36 | |
37 | ...und der Shell via Netzwerk. |
38 | |
39 | |
40 | Wenn das vor 4 Wochen schon so gewesen wäre, dann wäre vieles |
41 | einfacher gewesen. |
42 | |
43 | ok... perfekt ist das noch nicht ;-) |
44 | |
45 | 2 pings zugleich sind etwas viel - aber hey, man |
46 | kann nicht alles haben.... |
47 | |
48 | |
49 | assert: Current Version: NuttX 12.1.0 1de1b8adb7 May 21 2023 07:25:23 arm |
50 | _assert: Assertion failed panic: at file: armv7-m/arm_hardfault.c:175 task: 0x8035e6d |
51 | up_dump_register: R0: 38004578 R1: 000000ca R2: 0803ec1b R3: 000000ca |
52 | up_dump_register: R4: 00000000 R5: 00000000 R6: 000000c0 FP: 000000a8 |
53 | up_dump_register: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000 |
54 | up_dump_register: IP: 00000038 SP: 38004560 LR: 0803ebb7 PC: 0803eca4 |
55 | up_dump_register: xPSR: 01000000 PRIMASK: 00000000 CONTROL: 00000000 |
56 | up_dump_register: EXC_RETURN: ffffffe9 |
57 | dump_stack: User Stack: |
58 | dump_stack: sp: 0x38004560 |
59 | dump_stack: base: 0x38004008 |
60 | dump_stack: size: 00001992 |
Ikebana oder häkeln wäre die bessere Alternative für dich.
Wicki W. schrieb: > sowas hier, das will ja wohl niemand ernsthaft "datenblatt" nennen Das ist auch nicht das Datenblatt des Mikrocontrollers, sondern die kürzeste Kurzbeschreibung der Platine. Dazu gibt es auf der Produkt-Webseite eine - ausführlichere Kurzschreibung. - Einsteiger Anleitung - Detaillierte Beschreibung der Platine Außerdem sollte man imstande sein, die Doku des Mikrocontrollers selbst zu finden: - Datenblatt - Reference Manual - Errata Sheet - Application Notes Ich denke mal, wer diese Unterlagen nicht selbst findet, den will ST nicht beliefern. Solche Kunden machen nur Probleme. Wicki, mir sagt dieser Thread, dass du dich da gehörig übernommen hast. Du bist noch lange nicht bereit, mit solchen Boards zu hantieren. Ich empfehle dir, dich einige Jahre lang mit einfacheren Mikrocontrollern zu befassen. Erst wenn du damit sattelfest bist, nimm noch einen externen Ethernet Controller dazu (z.B. den CP2201) und programmieren ihn selbst, also ohne Bibliothek. So kommst du langsam an das Know-How, das ST voraus setzt. Wicki W. schrieb: > dass man sich über einen "32.768 kHz crystal oscillator" im > "datenblatt" wundert, Der ist für die Uhr! Wicki W. schrieb: > aber normal ist das alles nicht mehr.... > 8GB ide-zeug-installation um einen kleinen > controller zu programmieren? Das kommt daher, dass die IDE eine umfangreiche Sammlung von Code-Beispielen für mehr als 1000 Mikrocontroller enthält. Zudem sind alleine die Header Dateien mit den Register-Adressen bei jedem STM32 bereits mehrere Megabytes groß, weil sie halt so groß sind. Wicki W. schrieb: > Und eigentlich habe ich ja nur damit angefangen, weil ich gern > Responsezeiten von unter 100µSec. sicher realisieren wollte. Bei Ethernet? Sorry, das kannst du vergessen. Bei Ethernet Netzen rechnet man mit Zeiten zwischen 1 und 10ms, wenn alles in Ordnung ist. Ich empfehle dir einen ATmega328, der liegt vielleicht auf einem Level, dass du begreifen kannst. Übrigens geht es mir nicht viel anders: Schon die deutlich kleineren STM32 Modelle bringen auch mich an die Grenzen. > Und vielleicht ha ja noch jemand eine Idee, wie man die > Entwicklungsumgebung mit Makefiles handlen kann? Makefiles sind out. Dafür bringt die IDE allerdings eine Möglichkeit mit, das Projekt auf der Kommandozeile zu kompilieren. Man will dich und eine Projekte binden, damit du nicht mehr so einfach davon los kommst. Gewöhne dich dran. Ich finde das auch doof, aber so ist es halt. Man bekommt, was man bezahlt. Eventuell ist dieses Projekt für dich besser: http://stefanfrings.de/net_io/index.html Zum Compilieren brauchst du nur den avr-gcc und make. Du brauchst nur zwei Datenblätter und die verwendete µIP Implementierung ist gut dokumentiert.
Wicki W. schrieb: > Welche Board nimmt man stattdessen sinnigerweise? Vorschlag: https://www.ti.com/product/TM4C1294NCPDT https://www.ti.com/tool/EK-TM4C1294XL Das schöne daran: - In dem Prozessor ist nicht nur der Ethernet MAC drin (wie bei STM32), sondern auch der Ethernet PHY. Du brauchst Dich also nicht mit MII oder RMII rmschlagen und verlierst auch keine Pins dadurch. Du kannst direkt einen RJ45 mit integrierten Übertragern anschließen. - Es gibt eine schöne Driverlib dafür. - TI hat ein TI RTOS dafür, das leider nicht mehr so richtig gepflegt wird. - Die Dokumentation ist ganz brauchbar. - NuttX sollte darauf auch laufen. Nachteile: - Den Chip gibts entweder als 0.5mm BGA oder 0.4mm TQFP. Ist also nicht ganz einfach zu verarbeiten. Aber wozu gibts Bestücker, die das für einen machen. TI liefert dazu den Code Composer (Eclipse basierend) mit eigenem Compiler (kein gcc, aber den gibts natürlich auch), und als Debugger nimmst Du entweder einen JLink oder einen XDS110. Auf dem Launchpad ist ein XDS110 quasi mit drauf. Oder halt PIC32EF. Hatte ich ja auch schon mal vorgeschlagen. Wobei ich das eben beruflich mache und auch Boards dafür selber entwickle. Deswegen sind mir 60€ für ein Demoboard auch eher egal, das ist in den Entwicklungskosten eh mit drin. fchk
hey Frank, danke für die Rückmeldung! - das EK-TM4C1294XL klingt echt gut. Und sieht auch gut aus ;-) nuttx sagt u.a.: tm4c129e-launchpad:ostest tm4c129e-launchpad:nsh tm4c129e-launchpad:ipv6 Ich werde das mal ausprobieren. Verlöten muss ich die überigens nicht. Ich will weder Einzelstücke noch Kleinserien bauen. Ich will einfach nur ausprobieren was geht und was nicht. Mit dem PICs hatte ich vor Jahren mal viel gemacht. Aber ich wollte ja jetzt mal sehen, was es sonst noch so gibt. Beim H743 fand ich die angegeben 480MHz schon beindruckend. Brauchen würde ich sie wahrscheinlich nie. Aber zum ausprobieren.... Um mehr ging es mir eigentlich nie. Und das tu ich gern - und stelle da sicher auch mal die eine oder andere dumme Frage. Damit habe ich kein Problem. Und auch nicht mit denen, die mir dann erklären, dass "Ikebana oder häkeln" eine bessere Alternative ist. Hab ich vor weit mehr als 50 Jahren gemacht und fand ich damals schon stinklangweilig... ;-) und zu anderen Anmerkungen anderer User wie: > 100uSec > Bei Ethernet? Sorry, das kannst du vergessen. Bei Ethernet Netzen > rechnet man mit Zeiten zwischen 1 und 10ms, wenn alles in Ordnung ist. 5,12 µSec benötigt ein 64-Byte Paket von MAC-Adresse zu MAC-Adresse. Und in 64 Byte habe ich - abzüglich des MAC-usw-Headers immer noch viel mehr Informationen drin, als ich eigentlich brauche. (In einem 100Mbit-Segment) Doch, ich denke, dass 100µSec ein realisierbarer Wert ist. In 90µSec sollte man einiges rechnen können... auch bei "nur" 100MHz. Ich müsste jetzt mal die 4 Jahre alten Resultate raussuchen, aber der Grund, warum ich es mal mit dem STM versuchen wollte, das waren Timingprobleme beim RT-Raspi und beim Arduino wenn es um die Verarbeitung der ETH-Pakete ging. Das hier werde ich mir auf jeden Fall mal ansehen > http://stefanfrings.de/net_io/index.html Klingt interessant, aber die Hardware gibts (wenn ich das auf den ersten Blick richtig sehe) nicht von der Stange und das ist ja auch schon 4 Jahre alt. Aber schaun wir mal....
Wicki W. schrieb: > hey Frank, > > danke für die Rückmeldung! - das EK-TM4C1294XL klingt echt gut. > Und sieht auch gut aus ;-) > > nuttx sagt u.a.: > > tm4c129e-launchpad:ostest > tm4c129e-launchpad:nsh > tm4c129e-launchpad:ipv6 > > Ich werde das mal ausprobieren. Das ist ein TM4C129E, kein TM4C1294. Der 129E hat noch eine Cryptoeinheit. Dafür brauchst Du dann das passende Lauchpad EK-TM4C129EXL. https://www.ti.com/tool/EK-TM4C129EXL > Mit dem PICs hatte ich vor Jahren mal viel gemacht. > Aber ich wollte ja jetzt mal sehen, was es sonst noch > so gibt. Wobei zwischen PIC32 und PIC16 schon einiges an Leistungsdifferenzen steckt - und auch komplett andere Prozessorarchitekturen. fchk
Wicki W. schrieb: > Womit ich zur abschließenden Frage komme: > Der H743 erwies sich ja nun nicht gerade als ein Glücksgriff.... > Und nicht ohne Grund wird man ja inzwischen auch auf "deprecated" > hingewiesen, wenn man Cube benutzt. Das einzige was hier deprecated ist, ist das NUCLEO-H743ZI, da es durch die NUCLEO-H743ZI2 ersetzt wurde. Der Controller ist weiterhin "ACTIVE" Stefan F. schrieb: > Makefiles sind out. Dafür bringt die IDE allerdings eine Möglichkeit > mit, das Projekt auf der Kommandozeile zu kompilieren. Man will dich und > eine Projekte binden, damit du nicht mehr so einfach davon los kommst. > Gewöhne dich dran. Ich finde das auch doof, aber so ist es halt. Man > bekommt, was man bezahlt. Wenn man sich ein CubeIDE Project ansieht, wird man feststellen, das Eclipse (auf dem die CubeIDE basiert) in den Konfigurationsordner ein Makefile angelegt hat und abarbeitet.
Wicki W. schrieb: > aber die Hardware gibts (wenn ich das > auf den ersten Blick richtig sehe) nicht von der Stange Doch, bei Chip45. Und ja, das Projekt ist schon etwas älter, wie auch die verwendeten Bauteile. "Gut abgehangen" würde mein Chef sagen :-)
Hi Frank, Frank K. schrieb: >> tm4c129e-launchpad:ostest ..... > Das ist ein TM4C129E, kein TM4C1294. Der 129E hat noch eine > Cryptoeinheit. Dafür brauchst Du dann das passende Lauchpad > EK-TM4C129EXL. ich hatte nur die ersten 2 zeilen der liste gepostet. diese hier kommen auch noch: tm4c1294-launchpad:nsh tm4c1294-launchpad:ipv6 >> Mit dem PICs hatte ich vor Jahren mal viel gemacht. >> Aber ich wollte ja jetzt mal sehen, was es sonst noch >> so gibt. > > Wobei zwischen PIC32 und PIC16 schon einiges an Leistungsdifferenzen > steckt - und auch komplett andere Prozessorarchitekturen. das dachte ich mir damals auch schon - aber ich wollte halt auch mal was anderes sehen als PICs. ------- > > Das einzige was hier deprecated ist, ist das NUCLEO-H743ZI, da es durch > > die NUCLEO-H743ZI2 ersetzt wurde. > Der Controller ist weiterhin "ACTIVE" Aber ein Development-Board scheint es dafür nicht mehr zu geben ? Stefan F. schrieb: > Man will dich und > eine Projekte binden, damit du nicht mehr so einfach davon los kommst. > Gewöhne dich dran. Ich finde das auch doof, aber so ist es halt. Welcher Grund dahinter steckt, das ist schon klar. Und genau das ist der Grund, warum ich mit diesen IDEs nicht gerne arbeiten will. > Wenn man sich ein CubeIDE Project ansieht, wird man feststellen, das > Eclipse (auf dem die CubeIDE basiert) in den Konfigurationsordner ein > Makefile angelegt hat und abarbeitet. Dass er sowas intern irgendwo tut, das hatte ich erwartet. Aber gefunden habe ich bislang keins. Makefiles gibt es weder in .stm32... noch in .eclipse
:
Bearbeitet durch User
Wicki W. schrieb: > Makefiles gibt es weder in .stm32... noch in .eclipse Aber sicher gibt es die. ...und die tuen genau Das, was man erwartet.
Harry L. schrieb: > Wicki W. schrieb: >> Makefiles gibt es weder in .stm32... noch in .eclipse > > Aber sicher gibt es die. > ...und die tuen genau Das, was man erwartet. das wäre schön. Bei mir sieht das so aus: tree .stm32cubeide/ .stm32cubeide/ ├── favorites.boards.txt ├── favorites.examples.txt └── favorites.mcus.txt 0 directories, 3 files tree .eclipse .eclipse └── org.eclipse.platform_3.8_155965261 └── configuration └── 1560003293509.log 2 directories, 1 file Der cubeMX, der kann Makefiles anlegen. Andere habe ich noch nicht gefunden.
Da haben die Makefiles auch nix zu suchen. Die sind Projektabhängig und liegen im Projekt wo sie hingehören. Nicht über Gigabytes Installation jammern, mal Doku lesen. Oder die avi anschauen, da hat sich STM extra Mühe gegeben für Leute die es mit dem Lesen nicht so haben. Und in den Gigabytes ist ein genialer Debugger mit viel Komfort drin. Den könnte man glatt mal dazu benutzen Code zu analysieren oder Fehler aufzuspüren. Aber wenn man TI Controller ohne Doku zu lesen benutzen kann, dann sind die wohl was du suchst.
J. S. schrieb: > Da haben die Makefiles auch nix zu suchen. Die sind Projektabhängig und > liegen im Projekt wo sie hingehören. Wo bitte "im Projekt" sollen sie denn liegen? Wenn weiter oben zu lesen ist: > Wenn man sich ein CubeIDE Project ansieht, wird man feststellen, das > Eclipse (auf dem die CubeIDE basiert) in den Konfigurationsordner ein > Makefile angelegt ... Es wäre sehr hilfreich, wenn die, die immer auf "Doku lesen" verweisen, einfach mal einen konkreten Pfad benennen. Aber es bringt ja das eigene Ego deutlich mehr nach vorn, wenn man anderen erklärt, wie doof sie sind. Jedenfalls sind hier keine Makefiles enstanden.
Angehängte Dateien:
-
makefile.png
13 KB
Wicki W. schrieb: > Es wäre sehr hilfreich, wenn die, die immer auf "Doku lesen" > verweisen, einfach mal einen konkreten Pfad benennen. Offenbar bist du nicht einmal in der Lage die Datei-Suchfunktion deines Betriebssystem zu nutzen... Akzeptiere am besten einfach, daß dich Controller dieses Kaliber deutlich überfordern! Das Bild, was du hier abgibst, ist einfach nur noch zum fremdschämen.
:
Bearbeitet durch User
Wicki W. schrieb: > Jedenfalls sind hier keine Makefiles enstanden. wie soll ein Makefile für Projekt 1 2 3 gleich sein das in den Konfigurationen liegt? Wenn man das build in der IDE startet steht da als erstes 'make' im Terminalfenster, ist das nicht Hinweis genug das mit make gearbeitet wird? Mit der IDE und Eclipse wird ein Tutorial dazu installiert, das ist bei so einer komplexen Umgebung einfach Pflicht. Wicki W. schrieb: > Aber es bringt ja das eigene Ego deutlich mehr nach vorn, wenn > man anderen erklärt, wie doof sie sind. Es gibt so unendlich viel Input verschiedenster Art zur Eclipse IDE im allgemeinen und zu STMCubeIDE im besonderen. Wenn man schon mit dem Beharren auf die Shell vorgibt Profi zu sein, dann sollte man wenigstens etwas Ahnung von make haben. Und ohne IDE und CubeMX schreibt man das makefile halt selbst, auch das geht. Das sollte man schon können wenn man die Entwicklungen der IDEs und Tools so runterputzt.
Wie gesagt, ich finde es immer wieder toll, welcher Ton hier herrscht. Und wenn man zum Darstellen eines Verzeichnisinhaltes ein .png posten muss, dann weiss man, welche Generation von Entwicklern hier unterwegs ist. Richtige Betriebssysteme unterscheiden zwischen Makefile und makefile. Aber das müssen wir jetzt nicht auch noch ausdiskutieren ;-) Wenn man sich nicht an strenge Anweisung "Do not edit!" hält, das "makefile" in "Makefile" umbenennt - welches sinnigerweise unter "projektverzeichnis/STM32CubeIDE/Debug" zu finden ist, und die cyclomatische komplexität rauswirft (warum sich der gcc dagegen wehrt, das muss ich mir mal ansehen), dann hat man tatsächlich ein Makefile, das benutzt werden kann: make clean make all arm-none-eabi-objcopy -O binary projekt.elf projekt.bin st-flash --reset write projekt.bin 0x8000000 läuft.... find ich gut. Nein, richtig gut finde ich das! Ein Kommandzeilen-Einzeiler ohne Mausschubsen vom Editieren bis zum on-board-Test. Genauso wollte ich das haben. Nun könnt Ihr gerne wieder weiterlästern ;-)
:
Bearbeitet durch User
Wicki W. schrieb: > Wenn man ... das "makefile" in "Makefile" umbenennt. > dann hat man tatsächlich ein Makefile, das benutzt werden kann Man kann es auch ohne Umbenennen benutzen. > Wenn man sich nicht an strenge Anweisung "Do not edit!" hält Wird es beim nächsten Rebuild/Cleanup von der IDE weg gelöscht. Du solltest deine eigene Datei besser in ein anderen Verzeichnis verschieben und entsprechend anpassen.
Steve van de Grens schrieb: > Man kann es auch ohne Umbenennen benutzen. natürlich aber es sind halt alte gewohnheiten: ------------ Normally you should call your makefile either makefile or Makefile. (We recommend Makefile ....... ------------ > Wird es beim nächsten Rebuild/Cleanup von der IDE weg gelöscht. na klar. das ist kein problem - damit kann ich gut leben.
Wicki W. schrieb: > das ist kein problem - damit kann ich gut leben. es ist und bleibt Pfusch die generierten Makefiles zu verändern, damit bekommt man keine reproduzierbaren Ergebnisse und wie will man solche Projekte weitergeben/weiterbearbeiten? Das Makefile wird vom CDT generiert und ist auf die Umgebung abgestimmt die das CDT bereitstellt. Da sind viele Dinge möglich, z.B. Verzeichnisse/Dateien vom Build auszuschließen oder ihnen andere Compilereinstellungen mitzugeben. Es liegt auch nicht immer in Debug, sondern in dem Build den man eingestellt hat, kann also auch Release sein. Und diese Verzeichnisse sind per default von der Quellcodeverwaltung ausgenommen. Ebenso ist die Umgebung Systemunhängig (für die unterstützten OS). Das fegt man mit der Fruckelei einfach vom Tisch. Das ist eine Sackgasse und definitiv nicht empfehlenswert. CubeMX kann Makefile Projekte erstellen, das schrieb ich schon. Diese sind wesentlich einfacher aufgebaut und eher als Basis zu gebrauchen. Allerdings sind nicht alle Beispiele und Demo Apps von ST mit CubeMX gebaut und enthalten daher nicht alle eine .ioc Datei.
Entweder ist Wicki ein sehr talentierter Troll, oder ein vollkommen talentfreier Programmierer....da bin ich mir noch nicht sicher.
Harry L. schrieb: > Entweder ist Wicki ein sehr talentierter Troll, oder ein vollkommen > talentfreier Programmierer....da bin ich mir noch nicht sicher. Auf jeden Fall hält er hier den Laden am Laufen - seine beste Fähigkeit. Ansonsten nochmal - wie früher schon erwähnt - die Bitte an den Admin den Thread umzubenennen ......
Wastl schrieb: > die Bitte an den Admin den Thread umzubenennen ...... ..... ich meinte eigentlich diesen hier: Beitrag "Re: Mit dem ATMEL STUDIO 7 klarkommen" Aber die Person und dessen Probleme sind hier die gleichen.
ich könnte jetzt noch ein wenig zu makefiles und deren handling durch diese "IDE"s schreiben. es ist - aus meiner sicht - jedenfalls kein wirklicher fortschritt, was sowohl cube als auch ccstheia so bieten. ja, wenn man sich stur an die vorgaben hält, möglichst ein standard-OS benutzt und nicht so viel nachdenkt - dann ist das durchaus hilfreich, was so an support durch diese oberflächen geboten wird. das dumme ist nur: sie machen vollkommen abhängig. statt kurzer statements "sh blah&&make blubb&&flash blubber" kann man das handling nur über screenshots oder langatmige erklärungen weitervermitteln/dokumentieren. auf registerebene der uCs muss man sich gar nicht mehr begeben - das klickt man an oder aus. dadurch geht der "zwang zum lernen" verloren. ja, es ist bequem keine frage. aber ich habe hier von TI und ST und allein im letzten monat ein gefühltes TB nur an updates der IDEs runtergeladen. und brauche ich eine IDE, die mich zyklisch mit werbung vollmüllt, wie die bildzeitung mit (früher mal) tittenbildern? nein, brauche ich nicht. der tip it dem tm4c1294 war ein guter. weil ich damit mal sehe, was andere so anbeiten und wie es sich handlen lässt. die einfache aufgabe "miniwebserver" war mit dem 1294 schneller zu bauen als mit dem h743. dafür ist die installation der "cloudumgebung" von TI eine seuche. aber gehen tut beides. und beides hat seine tücken. die eigentliche aufgabe, weswegen ich das alles wieder ausgegraben habe - "raw-eth" - ist noch ein bisschen entfernt - aber nicht mehr ganz so weit, wie noch vor wochen. momentan tendiere ich mehr zum h743 als zum 1294 - weil 400/480MHz, das ist schon ne imposante hausnummer für einen uC. webserver läuft, SPI mit max7219 läuft auch und gpio löuft auch (naja, noch nicht so ganz wie ichs gern hätte) aber ich bin grade mal wieder recht zuversichtlich ;-) nuttx finde ich auch sehr nett - aber da gibt es dann ja leider nicht für jede hardware passende configs. sehr oft klemmt irgendwas, was man gerne hätte (gpio scheint weder mit dem 743 noch mit dem 1294 so richtig zu wollen. wenn es dann läuft, dann fass ich das mal als anleitung zusammen. (aber vermutlich ist das dann eh wieder binnen wochen veraltet)
:
Bearbeitet durch User
Wicki W. schrieb: > es ist - aus meiner sicht - jedenfalls kein > wirklicher fortschritt, was sowohl cube als auch > ccstheia so bieten. Nur weil du ganz offensichtlich nicht in der Lage bist, das zu verstehen. Wicki W. schrieb: > dadurch geht der "zwang zum lernen" verloren. Nein! Geht er nicht! Wicki W. schrieb: > und brauche ich eine IDE, die mich zyklisch mit werbung > vollmüllt, wie die bildzeitung mit (früher mal) tittenbildern? > > nein, brauche ich nicht. Wo gibt es in CubeIDE "Werbung"? Ist mir noch nie begegnet. Wicki W. schrieb: > die eigentliche aufgabe, weswegen ich das alles wieder ausgegraben > habe - "raw-eth" - ist noch ein bisschen entfernt - aber nicht mehr > ganz so weit, wie noch vor wochen. Davon bist du sogar noch meilenweit entfernt! Wicki W. schrieb: > gpio löuft auch > (naja, noch nicht so ganz wie ichs gern hätte) Wenn du nicht einmal das in den Griff bekommst, such dir besser ein anderes Hobby! Wicki W. schrieb: > wenn es dann läuft, dann fass ich das mal als anleitung zusammen. > (aber vermutlich ist das dann eh wieder binnen wochen veraltet) Das wird in diesem Leben sicher nix mehr!
Wicki W. schrieb: > es ist - aus meiner sicht - jedenfalls kein > wirklicher fortschritt, was sowohl cube als auch > ccstheia so bieten. Deine Kritik ist albern und geht an die Falschen. Die makefiles werden vom CDT generiert und das ist schon grottenalt. STM hat das nicht entwickelt, die nutzen das wie zig andere. Das CDT war nicht für µC exklusiv gemacht, sondern das war/ist auch für komplexere Desktop Programme. Es erleichtert das Handling mit vielen Quellcodeverzeichnissen und mit dem makefile hat der Anwender gar nichts zu tun, Compiler/Linker Optionen werden in Dialogen eingestellt. Man kann auch auf eigene makefiles umschalten, aber dann geht eben der Luxus der Dialoge verloren. Und wenn CubeMX dir kein Grundgerüst für die ganze Initialisierung der Peripherie und Clock geliefert hätte, dann hättest du heute nicht mal ein Blinky. Das müsste man sich dann erstmal aus Reference Manual und Datasheet zusammensuchen. Andere verwenden mittlerweile CMake, das ist noch komplexer weil da auch makefiles generiert werden, aber mit einer zusätzlichen Metasprache. Das Eclipse ist da sowas von oldschool dagegen. Wicki W. schrieb: > alle sourcen, die ich jetzt am WE getestet hatte (und das waren > einige Wicki W. schrieb: > dadurch geht der "zwang zum lernen" verloren. > ja, es ist bequem keine frage. ja und durch googlen nach fertigem Code lernt man besser?
:
Bearbeitet durch User
Es ist immer wieder erfrischend und aufbauend, wenn man so manche Einschätzungen - auch über Entferungen - hier so liest. Und ja, men lernt schenller, wenn man fertige Codesegmente im Netz sucht und anpasst, als wenn man sich seine Anwendung zusammenklickt. Das ist zumindest meine Erfahrung. Aber das soll jetzt nicht das Thema sein. Da gibts ein paar Fragen, auf die ich gerne ein Antwort hätte. Und man kann nicht alles glauben, was man so an Informationen erhält. Genauso wie nicht alle Codesegmente, die Suchmaschinen so finden, sinnvoll und funktionierend sind... Mein neuer Freund ist z.B. der festen Überzeugung, dass Cubeide z.b. "printf" oder "LWIP_DEBUGF" auf der Console anzeigen kann. Das habe ich bislang nicht geschafft und das Netz sagt auch was anderes dazu. Aber mein neuer Freund hat halt etwas von einem autistischen Savanten, dem man klar darlegen kann, dass er sich irrt. Dann entschuldigt er sich freundlich, dass er sich geirrt hat und behauptet das Gegenteil. Bösartig oder zynisch wird er aber nie. (er ist ja auch noch so jung...) Also ich gehe davon aus, das mit der "printf"-Consolausgabe, das hat er sich ausgedacht. Oder weiss hier jemand, wie das geht? Die nächste Frage ist: Wie kann ich "*raw*"-funktionen (aus "core/raw.c") sicher benutzen? Solange ich noch keinen Thread gestartet habe, sollte das doch eigentlich möglich sein. Und somit auch deren Debugging. Aber schon "raw_new" schmiert einfach ab. Es kommt nach pcb = (struct raw_pcb *)memp_malloc(MEMP_RAW_PCB); nicht zurück und der Debugger strandet im Asm-Code. Da mir mir diesem Board und dieser IDE die Erfahrung fehlt, weiss ich nicht, ob das nun daran liegt, dass man an dieser Stelle nicht debuggen kann oder weil "malloc" aufgrund der Einstellungen versucht auf falsche Speicherbereiche zuzugreifen und dann crasht. Also falsche Einstellungen in ..FLASH.ld die Ursache sind. Es wäre schön, wenn mir dazu jemand etwas sagen könnte.
du bist ein hoffnungsloser Ignorant. Frage weiter irgendwelche Möchtegern KI anstatt die Antworten hier mal sinnerfassend zu lesen. Nano, oder? Passt zu dem Schwurbler.
Wicki W. schrieb: > Es wäre schön, wenn mir dazu jemand etwas sagen könnte. Zu soviel Gelabere und sehr wenig konkreten, nachvollziehbaren Angaben? Nein danke!
hi zusammen, nur mal so zur info: nachdem das hier alles so freundlich, nett und höflich vor sich geht, lasse ich das mit dem posten weiterer zusammenfaasungen erst mal sein. es ist einfach draussen viel zu schön, um seine zeit mit swoas zu verbringen. wenn das wetter wieder schlechter wird, dann mache ich vermutlich weiter. bis dahin verabschiede ich mich in die sommerpause. und tschüss....
Thread beobachten
Seitenaufteilung abschaltenBitte 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.