Forum: Mikrocontroller und Digitale Elektronik STM32 NUCLEO H743ZI - Ethernet / WebServer-Probleme

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.

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.

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

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.

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?

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)

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

Wicki W. schrieb:
> vielleicht ein firmware-problem ?

Nein!
Ein Level-7-Problem.

Unfähiger User.

Harry L. schrieb:

> Unfähiger User.

wird er dir eigentlich grösser dabei?

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:

> 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.

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

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.

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.

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 ;-)

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)

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?

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....