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...)
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.
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 ....
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...
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.
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 ?
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.
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.
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.
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!
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.....
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.
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.
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:
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...
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.
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?
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.
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.
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.
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.
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).
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 ?
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.
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.
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.
CORTEX_M7_Parameter_Settings: Cortex Memory Protection Unit Control Settings - MPU Control Mode -> Privileged accesses only + MPU Disable During hard fault, NMI and Faultmask
CORTEX_M7_Parameter_Settings: Protection Unit 0 Settings: Enabled, 0x30000000, 32kB, level 1
in Linker-Skript STM32H743ZITX_FLASH.ld lwip-Sektion einbauen
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:
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.
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.
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.
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.
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.
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, 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.
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.
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.
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.
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.
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.
das ist nun alles drin (glaube ich) - und ohne das hier:
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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 ......
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)
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.
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.
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
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.
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.
