mikrocontroller.net

Forum: Compiler & IDEs STM32 und Linux - Einsteigerfragen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

wg. eines LinuxCNC-Projekts will ich mal ausprobieren, ob ich vorhandene 
STM32-Sourcen auf einem Nucleo-Board zum laufen bekommen. (ohne jede 
STM32-Erfahrung)

Der Entwickler hat das unter WIN und mit Eclipse erstellt - und ich 
hasse beides wie die Pest.

Offensichtlich benoetigt der STM32 aber einen gewaltigen Overhead an 
Libs, git-Sourcen usw...

Bevor ich mir da jetzt ergebnislos einen Wolf suche:

Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die 
Commandline zu programmieren oder wird man  dann an irgendwas scheitern?

Wenn ich es richtig sehe, dann benoetigt man den hier auf jeden Fall:

 https://github.com/ARMmbed/mbed-os


Ist das hier beschriebene Vorgehen noch aktuell?

https://os.mbed.com/docs/mbed-os/v5.12/tools/working-with-mbed-cli.html


(oftmals findet man ja wunderbare step-by-step-Anleitungen, die dann 
allerdings von der aktuellen Entwicklung überrollt wurden, völlig 
veraltet sind und nicht mehr funktionieren)

Vorhin las ich noch irgendwo:

der GCC waere voellig veraltet und embedded-entwickler wuerde ihn 
hassen.

sehe ich nicht so - aber vielleicht bin ich ja auch voellig veraltet ;-)


wie seht ihr das?

wicki

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die
> Commandline zu programmieren

Ja.

Wicki W. schrieb:
> Wenn ich es richtig sehe, dann benoetigt man den hier auf jeden Fall:

Keineswegs, das ist nur eine Möglichkeit von vielen.

Wicki W. schrieb:
> der GCC waere voellig veraltet und embedded-entwickler wuerde ihn
> hassen.

GCC und Clang sind die einzigen Compiler welcher aktuelle 
Sprachstandards (C++17) unterstützen. GCC wird auch von vielen 
kommerziellen IDEs genutzt. Der ist also sehr gut geeignet.

Du kannst dir problemlos eigene Makefiles schreiben, welche den GCC und 
Linker aufrufen und dann via GDB flashen & debuggen. Natürlich geht das 
mit einer IDE wie Eclipse viel komfortabler; insbesondere das Anzeigen 
von Peripherie-Registern ist hilfreich.
Mit Atollic Studio for STM32 und STM32CubeIDE geht das ganze auch unter 
Linux sehr komfortabel, aber die sind eben Eclipse-basiert.

Wicki W. schrieb:
> Offensichtlich benoetigt der STM32 aber einen gewaltigen Overhead an
> Libs, git-Sourcen usw...

Nö, du kannst auch ganz ohne Library programmieren. Mindestens die 
Register-Definitionen sollte man sich aber beim Hersteller holen, weil 
die selbst zu erstellen ein riesiger sinnloser Aufwand ist. Die 
Bibliotheken für den Hardware-Zugriff (HAL, SPL) kann man verwenden, 
aber die haben auch ihre Nachteile.

Wicki W. schrieb:
> (ohne jede
> STM32-Erfahrung)

Vielleicht wäre es sinnvoll, mit einer etablierten IDE anzufangen 
anstatt direkt alles selbst zu machen und an 25 Baustellen gleichzeitig 
zu arbeiten...

: Bearbeitet durch User
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos!

"Vielleicht wäre es sinnvoll, mit einer etablierten IDE anzufangen 
anstatt direkt alles selbst zu machen und an 25 Baustellen gleichzeitig 
zu arbeiten..."

Im Prinzip ist da was dran.
Aber: wenn ich diesen Klickibunti-Mist mit der Mausschubserei sehe, dann 
kriege ich die Krise...

Ich will ordentlich Commandlines, die man sich auch einfach speichern 
und weitergeben kann.
Ohne jedes mal einen Screenshot und Mails mit File-Attach erstellen zu 
muessen.

Gut, ich gebe zu: Makefiles zu bauen ist auch kein Spass. Aber das 
Ergebnis ist dann eine wenige k grosse Datei. und keine Sammlung von 
Screenshots mit "kier klicken", "da klicken".


mal schauen, wie es weiter geht.... ;-)

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Ich will ordentlich Commandlines, die man sich auch einfach speichern
> und weitergeben kann.

Eclipse kann auch selbstgeschriebene Makefiles aufrufen. Erfahrungsgemäß 
haben viele Leute weniger Probleme damit, per IDE-Installer alle 
Komponenten auf Einmal zu installieren, das Projekt in der IDE zu 
importieren und dann auf "Build" zu klicken...

Wenn man den grundlegenden Workflow erstmal verstanden hat, kann man die 
IDE immer noch weglassen. Es gibt da ja noch diverse Details zu beachten 
(Startup-Code, Linkerscript, Syscalls für malloc, korrekte 
Präprozessor-Makros für Controller, Register-Definitionen, HAL, 
GDB-Server für JTAG/SWD-Hardware) die man nicht alle auf Einmal angehen 
will...

Autor: Lars F. (flemmy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist schon mal ein guter tip.
aber irgendwie mag er nicht mit mir sprechen....

erkannt wird er. die "hd" wird auch gemounted.
aber dann wars das auch:

 kernel: [503966.935386] usb 1-7: new full-speed USB device number 34 
using xhci_hcd
 kernel: [503967.084789] usb 1-7: New USB device found, idVendor=0483, 
idProduct=374b
 kernel: [503967.084795] usb 1-7: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
 kernel: [503967.084800] usb 1-7: Product: STM32 STLink
 kernel: [503967.084803] usb 1-7: Manufacturer: STMicroelectronics
 kernel: [503967.084807] usb 1-7: SerialNumber: 0670FF353638425043013805
 kernel: [503967.140123] usb-storage 1-7:1.1: USB Mass Storage device 
detected
 kernel: [503967.140945] scsi host5: usb-storage 1-7:1.1
 kernel: [503967.141827] cdc_acm 1-7:1.2: ttyACM0: USB ACM device
  mtp-probe: checking bus 1, device 34: 
"/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7"
  mtp-probe: bus: 1, device: 34 was not an MTP device
  kernel: [503967.189440] usbcore: registered new interface driver uas
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.3
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.2
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.1
  upowerd[1264]: unhandled action 'bind' on 
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7
  kernel: [503968.144163] scsi 5:0:0:0: Direct-Access     MBED 
microcontroller  1.0  PQ: 0 ANSI: 2
  kernel: [503968.145033] sd 5:0:0:0: Attached scsi generic sg3 type 0
  kernel: [503968.145367] sd 5:0:0:0: [sdd] 4168 512-byte logical 
blocks: (2.13 MB/2.04 MiB)
  kernel: [503968.145591] sd 5:0:0:0: [sdd] Write Protect is off
  kernel: [503968.145595] sd 5:0:0:0: [sdd] Mode Sense: 03 00 00 00
  kernel: [503968.145755] sd 5:0:0:0: [sdd] No Caching mode page found
  kernel: [503968.145764] sd 5:0:0:0: [sdd] Assuming drive cache: write 
through
  kernel: [503968.165691] sd 5:0:0:0: [sdd] Attached SCSI removable disk


#$ st-info --probe
2019-06-06T12:27:53 WARN usb.c: failed to get libusb device descriptor
Found 0 stlink programmers


woran liegts ?

Autor: zufaulzumanmelden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir lag's daran, dass ich nicht root war.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AUA!

danke ;-)

wenn er jetzt was von "permission den.." gesagt haette,
waer ich auch sofort drauf gekommen.

aber dennoch ist das problem nicht geloest.
es hat sich (mal wieder) nur verlagert:

st-info --probe
Found 1 stlink programmers
 serial: 303637304646333533363338343235
openocd: "\x30\x36\x37\x30\x46\x46\x33\x35\x33\x36\x33\x38\x34\x32\x35"
  flash: 0 (pagesize: 0)
   sram: 0
 chipid: 0x0000
  descr: unknown device


bzw:
# st-flash write main.bin 0x8000000

st-flash 1.5.1-28-gd040db5
2019-06-06T13:16:33 INFO common.c: Loading device parameters....
2019-06-06T13:16:33 WARN common.c: Invalid flash type, please check 
device declaration
Unknown memory region

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt bin ich zwar ein bisschen weiter - aber fuer
den H743 scheint es keinen compiler fuer linux zu
geben :-(

scons kennt nur die unten gelisteten.

oder hat den hier schon mal jemand unter linux gaengig bekommen?

STM32 by ST NUCLEO-H743ZI Nucleo Development Board

https://www.amazon.de/gp/product/B077NDX82H/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1


-------------------------------------------

  <MCU>: f1hd/f1cle/f1mdvl/f042/f051/f030/f4.
    f030   = STM32F030 series.
    f042   = STM32F042 series.
    f051   = STM32F051 series.
    f1hd   = STM32F103HD series.
    f1cle  = STM32F107 series.
    f1md   = STM32100 medium density series.
    f1mdvl = STM32100 medium density value line series.
    f4     = STM32F407/f417 series (maintained for backwards 
compatibility)
    f405   = STM32F405
    f407   = STM32F407
    f415   = STM32F417
    f417   = STM32F417
    f427   = STM32F427
    f437   = STM32F437
    f429   = STM32F429
    f439   = STM32F439

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Jetzt bin ich zwar ein bisschen weiter - aber fuer
> den H743 scheint es keinen compiler fuer linux zu
> geben :-(

Der H743 ist ein cortex-m7, das unterstützt der GCC schon länger 
(zumindest seit 4.9).

Falls die st-utils mit dem H743 (noch) nicht umgehen können würd ich mal 
pyOCD probieren, das kommt von ARM und sollte mit dem st-link auf dem 
nucleo problemlos zusammenarbeiten können.

Gibts mehr Infos zum LinuxCNC-Projekt? Klingt interessant. Wo kommt da 
mbed ins Spiel? mbed ist ja recht praktisch weil man recht schnell zu 
Ergebnissen kommt (fast sowas wie ein Arduino "für Große") und alles 
mögliche vorgekaut integriert ist (RTOS, IPv4, TLS, ...), ich hab aber 
den Eindruck, dass die ARMen oft selber nicht wissen wo sich das alles 
hinentwickeln soll...

Autor: Michael F. (michaelfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> GCC und Clang sind die einzigen Compiler welcher aktuelle
> Sprachstandards (C++17) unterstützen.

Die IAR Embedded Workbench für Arm v8.40.1 unterstützt C++17 und C18.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael F. schrieb:
> Die IAR Embedded Workbench für Arm v8.40.1 unterstützt C++17 und C18.

Ah, gut zu wissen. GCC ist jedenfalls keineswegs veraltet, der wird 
ständig weiter entwickelt, u.a. von ARM selbst. Es gibt nur viele 
veraltete Pakete/Distributionen im Netz, wie z.B. Yagarto und teilweise 
die Pakete von Linux-Distributionen.

Man kann den ST-Link auch als J-Link umflashen, dessen Software 
funktioniert super unter Linux, aber proprietär.

Autor: Stute (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> AUA!
>
> danke ;-)

Ich sehe schon, voll der CmdLine Hengst der noch nicht mal strace 
bedienen kann.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> der wird
> ständig weiter entwickelt, u.a. von ARM selbst.

Die letzten paar offiziellen Releases von ARM enthalten leider ein paar 
kapitale showstopper bugs:

* unter bestimmten Umständen bleiben nach dem Linken Weak-Symbole stehen 
obwohl passende Strong-Symbole existieren
* Die Windows-Version kann keine .hex Dateien erzeugen (Absturz)
* Die Windows-Version kann keine Debug-Informationen generieren wenn LTO 
aktiv ist (Absturz)

Ich bin echt mal gespannt wann (oder ob?) wieder mal eine Version von 
denen rauskommt die zufällig mal wieder funktioniert.

Autor: wicki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi zusammen,


erst mal besten dank fuer die infos.
ich schau nachher mal, ob ich nun weiter komme.

"Gibts mehr Infos zum LinuxCNC-Projekt?"

stelle ich nachher mal zusammen.
im wesentlichen gehts darum: ich bin gefragt worden, ob wir
dieses paket

 Rapsberry/Arduino Treiberpaket fuer LinuxCNC via Raw-Ethernet

http://erste.de/ethraw/readme.de.html

auf stm32 portieren wollen.

aber wie gesagt: hatte noch nie mit dem ding zu tun.
fest steht jedenfalls, dass man mit arduino und raspberry
auf grenzen stoesst, wenn man 5kHz stepperfrequenz
ueberschreitet.
beim ardu aus anderen gruenden als bei rasp.

es gibt zwar die mesa-cards - aber das ist kein open-source.

und genau das ist das ziel.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Wicki W. schrieb:
> Falls die st-utils mit dem H743 (noch) nicht umgehen können würd ich mal
> pyOCD probieren, das kommt von ARM und sollte mit dem st-link auf dem
> nucleo problemlos zusammenarbeiten können.


soifz

 pyocd list
## => Board Name | Unique ID
-- -- ----------------------
 0 => NUCLEO-H743ZI [stm32h743zi] | 0670FF353638425043013805

aber:

  stm32f051               STMicroelectronics      STM32F051 
builtin
  stm32f103rc             STMicroelectronics      STM32F103RC 
builtin
......
  stm32l475xe             STMicroelectronics      STM32L475xE 
builtin
  stm32l475xg             STMicroelectronics      STM32L475xG 
builtin


das war wohl nix....


und das auch nich:
Warning

This platform is not yet available on mbed on-line compiler. Please use 
mbed-cli commands in the meantime.

The following mbed APIs are also not supported yet: CAN, ETHERNET, 
USBDEVICE

: Bearbeitet durch User
Autor: diePoetteringdie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Eingangs schon jemaand schrieb, mit einer fertigen IDE
hat man deutlich weniger Baustellen.

06/01/2019  10:40 PM     1,424,623,034 EWARM-CD-8401-21539.exe

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
diePoetteringdie schrieb:
> EWARM-CD-8401-21539.exe

Und wie benutzt man das unter Linux? Mit wine? Geht da auch der 
Debugger? Da ist eclipse vermutlich doch das kleinere Übel (ich finde 
Eclipse sowieso gar nicht so schlimm).

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also doch....

zumindest comiliert es jetzt

# cd mbed-os-example-blinky

# mbed  compile -t GCC_ARM

[mbed] Working path "...../mbed-os-example-blinky" (program)
[mbed] Detected "NUCLEO_H743ZI" connected to "....../NODE_H743ZI" and 
using com port "/dev/ttyACM0"
[Warning] @,: Compiler version mismatch: Have 8.2.1; expected version >= 
6.0.0 and < 7.0.0
Building project mbed-os-example-blinky (NUCLEO_H743ZI, GCC_ARM)
Scan: mbed-os-example-blinky
Compile [  0.8%]: at24mac.cpp
Compile [  0.9%]: NanostackRfPhyMcr20a.cpp
Compile [  1.0%]: main.cpp
Compile [  1.2%]: NanostackRfPhyAtmel.cpp
Compile [  1.3%]: NanostackRfPhys2lp.cpp
[.....]
Compile [ 99.8%]: USBSerial.cpp
Compile [ 99.9%]: PolledQueue.cpp
Compile [100.0%]: TaskBase.cpp
Link: mbed-os-example-blinky
Elf2Bin: mbed-os-example-blinky
| Module             |         .text |       .data |        .bss |
|--------------------|---------------|-------------|-------------|
| [fill]             |     148(+148) |     12(+12) |     45(+45) |
| [lib]/c.a          | 26000(+26000) | 2472(+2472) |     89(+89) |
| [lib]/gcc.a        |     772(+772) |       0(+0) |       0(+0) |
| [lib]/misc         |     208(+208) |     12(+12) |     28(+28) |
| main.o             |   1066(+1066) |       4(+4) |     36(+36) |
| mbed-os/cmsis      |   1021(+1021) |       0(+0) |       0(+0) |
| mbed-os/components |     104(+104) |       0(+0) |       0(+0) |
| mbed-os/drivers    |     810(+810) |       0(+0) |       0(+0) |
| mbed-os/hal        |   3357(+3357) |       8(+8) |   247(+247) |
| mbed-os/platform   |   5086(+5086) |   260(+260) |   257(+257) |
| mbed-os/rtos       |   9343(+9343) |   168(+168) | 6289(+6289) |
| mbed-os/targets    | 18470(+18470) |       8(+8) | 1457(+1457) |
| Subtotals          | 66385(+66385) | 2944(+2944) | 8448(+8448) |
Total Static RAM memory (data + bss): 11392(+11392) bytes
Total Flash memory (text + data): 69329(+69329) bytes

Image: ./BUILD/NUCLEO_H743ZI/GCC_ARM/mbed-os-example-blinky.bin

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:

> zumindest comiliert es jetzt
> Image: ./BUILD/NUCLEO_H743ZI/GCC_ARM/mbed-os-example-blinky.bin


und es funktioniert sogar.....

dass man einfach nur das .bin nach /media/xxx/NODE_H743ZI kopieren muss, 
das haette ich jetzt nicht erwartet.

ich glaube, das teil faengt an mir zu gefallen ;-)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den integrierten ST-Link auf den Nucleo-Boards kannman auch auf J-Link 
umflashen, dann kann man J-Link-Software für Linux installieren und hat 
dann alle Annehmlichkeiten von J-Link (keine Gesichtslähmung mehr beim 
Debuggen, unbegrenzte Breakpoints, etc).

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> soifz
>
>  pyocd list
> ## => Board Name | Unique ID
> -- -- ----------------------
>  0 => NUCLEO-H743ZI [stm32h743zi] | 0670FF353638425043013805
>
> aber:
>
>   stm32f051               STMicroelectronics      STM32F051
> builtin
>   stm32f103rc             STMicroelectronics      STM32F103RC
> builtin
> ......
>   stm32l475xe             STMicroelectronics      STM32L475xE
> builtin
>   stm32l475xg             STMicroelectronics      STM32L475xG
> builtin
>
> das war wohl nix....

Das verstehe ich nicht. Was war wohl nix? Ich hab gerade kein 
Nucleo-H743ZI herumliegen drum kann ich das nicht testetn, aber was 
funktioniert denn mit pyocd nicht?

$ pyocd list -b | grep 743
  0743   DISCO-F413ZH                     stm32f413zh             None
  0813   NUCLEO-H743ZI                    stm32h743zi             None

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wicki schrieb:
> http://erste.de/ethraw/readme.de.html
>
> auf stm32 portieren wollen.

Muss ich mir genauer anschaun, auf den ersten Blick hab ich nur einen 
Haufen riesen-LEDs gesehen. Die Idee einen RaspberryPi als Ethernet 
IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.

Das wird mit dem Nucleo deutlich besser und deterministischer 
funktionieren, Step-Raten im zig-MHz Bereich sind da dann auch kein 
Problem.

Update-Raten mit richtiger Hardware und mit "privatem" Netzwerk (evt. 
ohne switch) von 4kHz sollten mit RT PREEMPT Kern ohne speziellere 
Ethernet-Tricksereien möglich sein.

> aber wie gesagt: hatte noch nie mit dem ding zu tun.
> fest steht jedenfalls, dass man mit arduino und raspberry
> auf grenzen stoesst, wenn man 5kHz stepperfrequenz
> ueberschreitet.
> beim ardu aus anderen gruenden als bei rasp.
>
> es gibt zwar die mesa-cards - aber das ist kein open-source.
>

Die Mesa-Hardware ist nicht open source, die Software schon. Karten wie 
die 7i90 sind auch nicht besonders teuer IMHO. Die Ethernet-Karten haben 
durch die Bank alle FPGAs mit BGA-Kontaktierung, ob man sowas selber 
löten will...

Ansonsten als Anregung kann ich das STMBL-Projekt (auf github zu finden) 
empfehlen, die interfacen auch mit LinuxCNC.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Die Idee einen RaspberryPi als Ethernet
> IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.
>
> Das wird mit dem Nucleo deutlich besser und deterministischer
> funktionieren, Step-Raten im zig-MHz Bereich sind da dann auch kein
> Problem.

Vielleicht wäre ein TI Sitara Prozessor (z.B. in Form eines BeagleBone 
Black) interessant - hart echtzeitfähig, viel Rechenleistung, Ethernet 
mit Industrieprotokollen möglich (z.B. EtherCAT)

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Muss ich mir genauer anschaun, auf den ersten Blick hab ich nur einen
> Haufen riesen-LEDs gesehen.

das war nur ein daran anschliessendes nebenprodukt - weil die 
schnittstelle grad da war.... hat aber ansonsten nix damit zu tun.


> Die Idee einen RaspberryPi als Ethernet
> IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.

diese diskussion hatten wir schon x mal....
ich wollte es bauen und meine fraese laeuft jedenfalls damit.

und nun gits da einen bulgaren und einen russen(?) die aehnliches
mit einem stm32 gebaut haben - teils aber auf eigener hardware.
(was ebenfalls laeuft, aber den stepgen auf dem stm32 hat)
damit ich mir das ansehen kann, muss ich es erst mal zum laufen 
bekommen.

http://pekka.eu/cnc/
https://github.com/pekkaroi/ethernetcnc

vielleicht bekommen wir es ja hin, aus mehreren halbfertigen loesungen 
eine gesamtloesung zu bauen.

darum sehe ich mir jetzt den 743 an.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die
> Commandline zu programmieren oder wird man  dann an irgendwas scheitern?

Das hängt davon ab, ob es bei Linux eine benutzbare Kommandozeile gibt.

Mal im Ernst:
Selbstverständlich kann man sowohl bei Windows als auch bei Linux die 
komplette Toolchain per Kommandozeile benutzen - präziser gesagt: per 
Batch-Datei (Windows) oder Shell-Script (Linux). Ist ja bis auf 
unterschiedliche Schreibweisen dasselbe.

Wenn du gucken willst, wie man per Kommandozeile den Keil oder den GCC 
(damals yagarto) aufruft, dann guck hier in die Lernbetty, da ist das 
damals vorexerziert worden.


Wicki W. schrieb:
> WIN und mit Eclipse erstellt - und ich
> hasse beides wie die Pest.

Hass ist für den Ingenieur etwas sehr Unbrauchbares und 
Kontraproduktives. Wenn du dich von sowas leiten läßt, wirst du 
lediglich deinen Blutdruck steigern und deine Kreativität kaputtmachen 
und obendrein auch noch deine Möglichkeiten einschränken. Irgend etwas 
aus guten, sachlichen Gründen nicht zu mögen, ist hingegen etwas 
anderes.

Wicki W. schrieb:
> Offensichtlich benoetigt der STM32 aber einen gewaltigen Overhead an
> Libs, git-Sourcen usw...

DER  stm32?

Erstmal: es gibt viele davon, genauso wie es auch viele LPC's gibt oder 
Chips von Nuvoton, Freescale und anderen Herstellern.

Und zweitens: Für die diversen STM32-Chips benötigt man keinesfalls 
einen gewaltigen Overhead. Sowas ist hausgemacht, indem man fröhlich 
diverse Hersteller-Beigaben benutzt, einen Sack voll Indirektionen 
benutzt, obendrein auch noch die gleiche Menge an Datei-Senf von 
irgendeiner IDE dazurührt, Projektfiles und vorkompilierte Header liebt 
und so weiter.

Nein, wenn man es einfach hält und nicht mutwillig so ein Projekt 
ausufern läßt, dann schnurrt das Ganze sehr schnell auf eine 
übersichtliche Anzahl von Dateien zusammen.

Aber gestern war noch nicht Freitag. Also!

W.S.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> Die Idee einen RaspberryPi als Ethernet
>> IO-Expander für LinuxCNC zu verwenden halte ich für pervers, sorry.
>
> diese diskussion hatten wir schon x mal....
> ich wollte es bauen und meine fraese laeuft jedenfalls damit.

Kein Bange, ich will da nix diskutieren.

> und nun gits da einen bulgaren und einen russen(?) die aehnliches
> mit einem stm32 gebaut haben - teils aber auf eigener hardware.
> (was ebenfalls laeuft, aber den stepgen auf dem stm32 hat)
> damit ich mir das ansehen kann, muss ich es erst mal zum laufen
> bekommen.

Die Mesa Ethernet-Karten verwenden ein einfaches UDP Protokoll, analog 
dazu eine  LinuxCNC-Komponente die UDP redet zu schreiben und das 
Gegenstück mit dem LinuxCNC-eigenen Software-Stepgen auf einem STM32 ist 
keine Hexerei.

Mit mbed sollte das auch relativ shcnell zu machen sein.

Der Software-Stepgen aus LinuxCNC bzw. Hostmot2 ist mehr oder weniger 
ein rückgekoppeltes Schieberegister, das mit (mehreren) 100kHz laufen zu 
lassen sollte auch für mehrere Achsen kein Problem für den M7 
darstellen. Wenns nicht reicht kann man immer noch auf die Timer 
zurückgreifen, da muss man dann halt etwas mehr Hirn reinstecken.

> vielleicht bekommen wir es ja hin, aus mehreren halbfertigen loesungen
> eine gesamtloesung zu bauen.

viel Erfolg

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> > WIN und mit Eclipse erstellt - und ich
> > hasse beides wie die Pest.

> Hass ist für den Ingenieur etwas sehr Unbrauchbares und
> Kontraproduktives.

das mag sein. Aber meine Gesundheit und meine Nerven
sind mir wichtiger...

Wenn man jahrzehntelang beobachtet, wie fehlerhafte, proprietäre OSs und 
IDEs den Anwender und Entwickler mehr und mehr entmündigen und 
inzwischen in Online-Compilern und -Libs münden, deren Daten dann 
möglichst noch in der Cloud gespeichert werden - dann ist man es 
irgendwann leid.

Aber ich schweife ab ;-)

Dass es "den" STM32 nicht gibt, ist mir schon klar. Und genau das ist 
das/mein Problem: Die Inflationäre Zahl der Typen und IDEs macht es 
nicht leicht, den Einstieg zu finden.
Selbst der Entwickler brauchte ein paar Tage Recherche, um mir sagen zu 
können, dass das 743-Board das richtige für seine Sourcen ist.
Das ist aber ein WIN/Eclipse Mensch - und ich will das nun unter Linux 
compilieren.

Hinzu kommt, dass es zahlreiche unterschiedliche Herangehensweisen gibt 
um zum gleichen Ergebnis zu kommen und so passiert es, dass man völlig 
aneinander vorbei redet, Anleitungen verwendet, die gar nicht mehr 
aktuell sind, weil sie nicht mehr zum Compiler in der neusten Version 
passen usw...

Wenig Hilfreich sind dann dumme Kommentare wie weiter oben "nicht mal 
strace bedienen koennen"....

Jedenfalls scheint das 743-Board schon ein ziemlicher Exot zu sein. Ich 
versuche, jetzt erst mal eine minimalistische Umgebung aufzubauen, um 
simple "hello words" &Co. gaengig zu bekommen.

Und dann das ganze mal als step-by-step-howto zusammenzufasssen.

mir war z.b. nicht klar, dass es neben
pyocd list --targets

auch noch
pyocd list --boards
gibt

Insofern ist dieses Forum hier doch eine große Hilfe ;-)

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, den ueblichen mbed-spielkram bekomme ich jetzt
gaengig.
ist durchaus irgendwie spannend, das teil ;-)

aber wie bekomme ich solchen exclipse-kram uebersetzt?
geht das mit mbed irgendwie automatisiert?
muss man die project-files von hand auseinanderdroeseln?

https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

hat da jemand eine idee zu?

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Wenn man jahrzehntelang beobachtet, wie fehlerhafte, proprietäre OSs und
> IDEs den Anwender und Entwickler mehr und mehr entmündigen und
> inzwischen in Online-Compilern und -Libs münden, deren Daten dann
> möglichst noch in der Cloud gespeichert werden - dann ist man es
> irgendwann leid.

Der mbed online-Compiler hat schon Vorteile auch, das Ding funktioniert 
einfach und ist sofort von jedem Rechner/Tablet mit Webbrowser zu 
bedienen. Die Supergeheime Raketensteuerung würde ich dort nicht 
entwickeln, aber für die Quellen einer typischen LED-Blink-Anwendung mit 
eingebautem Webserver interessiert sich wirklich niemand. Da ist auch 
kein Know-How drin was ausgespäht werden könnte.

> Selbst der Entwickler brauchte ein paar Tage Recherche, um mir sagen zu
> können, dass das 743-Board das richtige für seine Sourcen ist.
> Das ist aber ein WIN/Eclipse Mensch - und ich will das nun unter Linux
> compilieren.

Kannst du das erläutern. Welcher Entwickler. Und warum braucht der 
mehrere Tage Recherche, um feszustellen, für welche Hardware er sein 
Programm schreibt. Klingt ziemlich absurd.

> mir war z.b. nicht klar, dass es neben
> pyocd list --targets
>
> auch noch
> pyocd list --boards
> gibt

Die Doku von pyocd ist ja jetzt nicht sooo lang, das ist in 2 Minuten 
überflogen, und mit Argumenten wie "-h" oder "--help" oder auch "-?" 
kann man üblicherweise alle Programme zu beschreibenden Ausgaben 
bewegen.

Board-Support etc.. kann man übrigens auch nachrüsten (pyocd pack).

Der H743 ist vermutlich wirklich ein Exot, von der Performance und vom 
Preis her eher kein typischer Mikrocontroller. Für ein Ethernet-BOB aber 
keine schlechte Wahl.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> aber wie bekomme ich solchen exclipse-kram uebersetzt?
> geht das mit mbed irgendwie automatisiert?
> muss man die project-files von hand auseinanderdroeseln?
>
> https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP
>
> hat da jemand eine idee zu?

* herausfinden für welche eclipse ide das gedacht ist

* selbige installieren

* github projekt klonen

* in eclipse als workspace öffnen

* loslegen

Soweit ich sehe tut das verlinkte Projekt aber (noch) nichts, das ist 
nur eine leere Hülle.

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> aber wie bekomme ich solchen exclipse-kram uebersetzt?
> geht das mit mbed irgendwie automatisiert?

Das Projekt benutzt doch überhaupt kein mbed, oder? Habe da auf die 
Schnelle nur HAL-Code gesehen. Dann bringt dir mbed hier eher wenig.

Du musst dir ein Makefile basteln, welches alle Source Files kompiliert 
und linkt. Nötige Parameter für die GCC-Aufrufe finden sich z.B. unter 
ARM GCC.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> * herausfinden für welche eclipse ide das gedacht ist

dürfte SW4STM32 sein 
http://www.ac6-tools.com/content.php/content_SW4L.xphp

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mbed ist schon etwas mehr als nur ein Kommandozeilenwerkzeug.
Es ist ein OS mit Realtime Kernel (rtx5 von ARM), einheitlicher 
Treiberstruktur für HW wie gpio, serial, spi, ethernet und einiges mehr. 
Dazu Multikulti was das HostOS angeht (Windows, Linux, MacOS) sowie die 
die unterstützten Compiler (gcc, ARM, IAR). Mit mbed-cli hast du eine 
Kommandozeilenunterstützung, das ist das bevorzugte Werkzeug der 
Entwickler weil zB die ganzen Tests auch automatisiert ablaufen müssen.
Das CLI ist in den letzten Jahren massiv weiterentwickelt worden und 
sehr mächtig. Man muss sich nicht mit makefiles rumquälen, einfach 
Verzeichnisse anlegen und Quellcode reinwerfen, dann werden die 
mitkompliert. Es gibt ein paar Namenskonventionen die unterschiedlichen 
Code für die verschiedenen Targets vereinfachen.
Dann kann das CLI Projektfiles für verschiedenen IDE erzeugen, findet 
man unter export Funktion. Eclipse war mal mein Favorit, aber das 
Persistenzformat für Eclipse ist eklig kompliziert, VSCode und Co. sind 
da mit ihren JSON Files viel pflegeleichter. Obwohl viele Eclipse IDE 
sehr ähnlich sind können die nicht einfach Projektconfigs anderer lesen, 
nur wenn die das Format kennen und konvertieren (zB Atollic liest und 
konvertiert SW4STM32).
Mittlerweile hat ARM eine eigene IDE veröffentlicht, basierend auf dem 
Atom Editor, ähnlich VSCode. Relativ schlank und gut erweiterbar (wennn 
man in JavaScript einigermassen fit ist). Nebenbei bekommt man da sogar 
den sonst sehr teuren ARM Compiler mitinstalliert. Für meine 
Hobbyprojekte reichte mir der gcc allemal, aber die Unterstützung für 
Cortex-M0 ist immer noch sehr mässig und der ARM Compiler erzeugt 
besonders für die M0 oft 20-30% kürzeren Code.
OS für µC werden hier immer kontrovers diskutiert, aber ich mag mbed-OS. 
Es ist wesentlich besser strukturiert als der Arduino Wildwuchs. Die 
Targets sind in einem Topf mit dem OS und Änderungen werden exzessiv 
getestet. Bei Arduino gibts verschiedene Cores von Drittanbietern und 
das Zusammenspiel ist Glückssache. Auch werden in den Cores pauschal 
Resourcen beschlagnahmt die dann auf Applikationslevel blockiert sind. 
Bei mbed lassen sich spezielle Hardwareunits schöner einbinden und auch 
Targetabhängig in Libs einbauen.
Mit einem OS hast du natürlich mehr Annehmlichkeiten zu Kosten von 
Resourcen. Aber auch das ist gut gelöst durch C++ Interfaces die dann 
Targetabhängig die Implementierung aufrufen.
Ethernet wurde überarbeitet, USB gab es anfangs nur für die LPC, kam 
dann auf ein unsupported Abstellgleis und ist jetzt in eine erweiterte 
Komponentenstruktur übernommen und weiterentwickelt worden. Der H743 ist 
aber auch recht neu und die Unterstützung gibt es noch nicht solange. 
Aber es ist ja alles auf github verfügbar, man muss sich nur etwas durch 
die Quellen hangeln...

: Bearbeitet durch User
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:

> Der mbed online-Compiler hat schon Vorteile auch,
...
>  Da ist auch
> kein Know-How drin was ausgespäht werden könnte.

es geht nicht um "ausgespähtes Know-How" - es geht darum, dass es einen 
Software-Hersteller und/oder Server-Betreiber einen feuchten Kehricht 
angeht, wann, wo, unter welchem OS, mit welchem Browser ich was 
programmiere.
Abgesehen davon, steht man ziemlich dumm da, wenn der Server ausfällt, 
der Betreiber die Oberfläche oder die Nutzungsrechte ändert oder Pleite 
geht oder man einfach keinen Netzzugang hat.


> Kannst du das erläutern. Welcher Entwickler. Und warum braucht der
> mehrere Tage Recherche, um feszustellen, für welche Hardware er sein
> Programm schreibt. Klingt ziemlich absurd.

Das musst Du ihn schon selbst fragen. Es gibt halt auch Leute die 
arbeiten gehen, nicht unbegrenzt Zeit haben - und auch ich könnte dir 
detaillierte Fakten aus Projekten, die Monate zurück liegen, nicht 
nennen, ohne in den Unterlagen oder Sourcen nachzusehen.
Ich bin froh, wenn jemand mit einem interessanten Projektvorschlag kommt 
und einiges dazu beisteuern kann. Ihm vorzuwerfen, dass es absurd ist, 
wenn er eine Frage nach einer optimalen Hardware nicht sofort 
beantworten kann - das ist absurd......


> Die Doku von pyocd ist ja jetzt nicht sooo lang, das ist in 2 Minuten
> überflogen,

ja, das ist in 2 Minuten überflogen.
und da steht genau nichts vom "pyocd list --boards" drin.
wahrscheinlich findet man es irgendwo, wenn man in den tiefen der docs 
nachsieht.


> Der H743 ist vermutlich wirklich ein Exot, von der Performance und vom
> Preis her eher kein typischer Mikrocontroller. Für ein Ethernet-BOB aber
> keine schlechte Wahl.

... und das war wohl auch der Grund, warum man mir genau dieses Board 
genannt hat.

Aber es wäre schön, wenn wir nun diese Philosophischen Betrachtungen 
abhaken könnten...

Wenn mir jemand sagen kann, wie ich bestehende Eclipse-Projekt-Files auf 
mbed (oder irgendetwas anderes commandline-orienteirtes) portieren kann 
- darüber würde ich mich freuen....

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> es geht nicht um "ausgespähtes Know-How" - es geht darum, dass es einen
> Software-Hersteller und/oder Server-Betreiber einen feuchten Kehricht
> angeht, wann, wo, unter welchem OS, mit welchem Browser ich was
> programmiere.
> Abgesehen davon, steht man ziemlich dumm da, wenn der Server ausfällt,
> der Betreiber die Oberfläche oder die Nutzungsrechte ändert oder Pleite
> geht oder man einfach keinen Netzzugang hat.

Der Online Compiler hält sich schon hartnäckig seit über 10 Jahren. War 
auch nicht für professionelle Entwickler gedacht sondern soll die 
Ausbildung einfacher machen: Keine Installation von Software nötig, 
keine teueren Lizenzen, keine Spezialhardware für die Programmierung, 
mur ein USB Kabel. War seiner Zeit voraus weil die meisten da noch mit 
ihren AVR glücklich waren  und das erst mbed Board mit LPC1768 relativ 
teuer war.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das CLI ist in den letzten Jahren massiv weiterentwickelt worden und
> sehr mächtig. Man muss sich nicht mit makefiles rumquälen, einfach
> Verzeichnisse anlegen und Quellcode reinwerfen, dann werden die
> mitkompliert.


wow - das sind ja alles schon wieder hilfreiche Infos. Besten Dank.

Das auf dem Teil ein eigenes OS laufen kann / laeuft habe ich ja jetzt 
auch erst durchs rumprobieren und rumfragen mitbekommen. Gefaellt mir 
recht gut, was ich bislang gesehen habe.

Und ich meine natuerlich das mbd-cli, mit dem ich gern arbeiten moechte.
genau aus den oben genannten Gruenden.

Aber es ist mir halt noch nicht gelungen, dieses hier (das ist nur ein 
beispiel) mittels mbed (und ich meine auch damit mbed-cli) compiliert zu 
bekommen:

https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Der Online Compiler hält sich schon hartnäckig seit über 10 Jahren.

ich sag ja nicht, dass er schlecht ist. er hat auch sicher seine 
berechtigung.
ich sag nur, dass ich das nicht moechte.

ich finde auch einen tesla nicht unbedingt schlecht.
haben moechte ich dennoch keinen....

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Aber es ist mir halt noch nicht gelungen, dieses hier (das ist nur ein
> beispiel) mittels mbed (und ich meine auch damit mbed-cli) compiliert zu
> bekommen:

das ist auch nicht im Sinne der mbed Erfinder, mbed-cli ist das Werkzeug 
um Anwendungen mit dem mbed-OS einfach erstellen zu können. Das OS und 
mbed wegzulassen kann gehen, aber da musst du vermutlich auch den 
Startupcode anpassen, der ruft auch früh die RTOS initialisierung auf. 
Und die Speicherverwaltunf muss man sich auch ansehen.
Also ich würde eher versuchen die Ethernetunterstützung von mbed zu 
nutzen...
Das H743 ist wie es aussieht auch nicht offiziel unterstützt aka 'mbed 
enabled', ich finde es nicht in der board Liste:
https://os.mbed.com/platforms/?q=nucleo
Im Quellcode gibt es mehr Targets, aber die sind dann eben noch nicht 
oder nicht mehr voll unterstützt.
Für Ethernet einfach mal testen ob dieses Beispielzeilen kompilieren:
https://os.mbed.com/docs/mbed-os/v5.12/apis/ethernet.html

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Wenn mir jemand sagen kann, wie ich bestehende Eclipse-Projekt-Files auf
> mbed (oder irgendetwas anderes commandline-orienteirtes) portieren kann
> - darüber würde ich mich freuen....

Wie gesagt - mit entsprechenden Makefiles kannst du das per GCC 
kompilieren. Woran hapert es? Kannst du keine Makefiles schreiben? Dann 
wäre Eclipse keine so schlechte Idee. Wieso mbed? Statt das Projekt 
komplett auf mbed umzubauen, kannst du auch einfach ein neues mbed 
Projekt anfangen. Das ist vermutlich einfacher. mbed ist nicht einfach 
nur ein Konsolen Programm zum Kompilieren, sondern ein ganzes RTOS mit 
diversen Frameworks. Die müsste man dann auch in den Code einpflechten.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> Der mbed online-Compiler hat schon Vorteile auch,
> ...
>>  Da ist auch
>> kein Know-How drin was ausgespäht werden könnte.
>
> es geht nicht um "ausgespähtes Know-How" - es geht darum, dass es einen
> Software-Hersteller und/oder Server-Betreiber einen feuchten Kehricht
> angeht, wann, wo, unter welchem OS, mit welchem Browser ich was
> programmiere.
> Abgesehen davon, steht man ziemlich dumm da, wenn der Server ausfällt,
> der Betreiber die Oberfläche oder die Nutzungsrechte ändert oder Pleite
> geht oder man einfach keinen Netzzugang hat.

Ich hab nur ein paar Vorteile aufgezählt. Dass es nicht nur Vorteile 
gibts ist auch klar, kommt halt drauf an, was man will, aber sowas 
gleich pauschal für alle ablehnen ist übertrieben.

Wicki W. schrieb:
> Selbst der Entwickler brauchte ein paar Tage Recherche, um mir sagen zu
> können, dass das 743-Board das richtige für seine Sourcen ist.
> Das ist aber ein WIN/Eclipse Mensch - und ich will das nun unter Linux
> compilieren.

Wicki W. schrieb:
>> Kannst du das erläutern. Welcher Entwickler. Und warum braucht der
>> mehrere Tage Recherche, um feszustellen, für welche Hardware er sein
>> Programm schreibt. Klingt ziemlich absurd.
>
> Das musst Du ihn schon selbst fragen. Es gibt halt auch Leute die
> arbeiten gehen, nicht unbegrenzt Zeit haben - und auch ich könnte dir
> detaillierte Fakten aus Projekten, die Monate zurück liegen, nicht
> nennen, ohne in den Unterlagen oder Sourcen nachzusehen.
> Ich bin froh, wenn jemand mit einem interessanten Projektvorschlag kommt
> und einiges dazu beisteuern kann. Ihm vorzuwerfen, dass es absurd ist,
> wenn er eine Frage nach einer optimalen Hardware nicht sofort
> beantworten kann - das ist absurd......

Ich fühle mich da sinnentstellend zitiert. Bis jetzt war ja nicht die 
Rede davon dass das Projekt von jemand anderem entwickelt wird.

Auf dem verlinkten github-projekt steht ausserdem gleich auf der 
Einstiegsseite bzw. im README "How to test it? Power up the 
Nucleo-H743ZI".

Es war nirgendwo die Rede von "der optimalen Hardware für" wasauchimmer. 
Der Vorwurf der Absurdität ist ja kein Vorwurf an "den Entwickler" 
sondern an die Salami-Taktik und total unklare Diskussion deinerseits.

Wicki W. schrieb:
> Aber es ist mir halt noch nicht gelungen, dieses hier (das ist nur ein
> beispiel) mittels mbed (und ich meine auch damit mbed-cli) compiliert zu
> bekommen:
>
> https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

Die Frage ist (fast) analog zu "wie bekomme ich diese Android-Sourcen im 
XCode für IPhone kompilieren". Das ergibt keinen Sinn.

In dem github-Projekt ist nichts drinnen was das mbed von Haus aus nicht 
auch tut/kann. Ja, das Ethernet-Interface muss man konfigurieren damit 
der Nucleo auf ICMP Pings antwortet, aber das sind 2 Zeilen:
EthernetInterface eth;
nsapi_error_t status = eth.connect();

https://os.mbed.com/docs/mbed-os/v5.12/apis/ethernet.html

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> In dem github-Projekt ist nichts drinnen was das mbed von Haus aus nicht
> auch tut/kann. Ja, das Ethernet-Interface muss man konfigurieren damit
> der Nucleo auf ICMP Pings antwortet, aber das sind 2 Zeilen:
> EthernetInterface eth;
> nsapi_error_t status = eth.connect();

Leider fehlt beim H473 die Ethernet Unterstützung noch...

Mit einem dieser Boards würde es gehen:
https://os.mbed.com/platforms/?q=nucleo&Communication=Ethernet&sort_by=relevance

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie ich schon sagte:

Aber es wäre schön, wenn wir nun diese Philosophischen Betrachtungen
abhaken könnten...

> Auf dem verlinkten github-projekt steht ausserdem gleich auf der
> Einstiegsseite bzw. im README "How to test it? Power up the
> Nucleo-H743ZI".

ja - und da steht auch:

> How to build?
>     You can build this projest using Eclipse (SW4STM32) IDE

und ich will es ohne eclipse.


> der Nucleo auf ICMP Pings antwortet, aber das sind 2 Zeilen:
> EthernetInterface eth;
> nsapi_error_t status = eth.connect();


warum ich das nicht so mache?

The following mbed APIs are also not supported yet: CAN, ETHERNET, 
USBDEVICE


soifz

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Das H743 ist wie es aussieht auch nicht offiziel unterstützt aka 'mbed
> enabled', ich finde es nicht in der board Liste:
> https://os.mbed.com/platforms/?q=nucleo

In der Beschreibung vom Nucleo auf der ST Website steht schon "arm mbed 
enabled". Da das Reference Manual ein Datum "April 2019" trägt ist das 
vermutlich nur eine Frage der Zeit bis das auch auf den mbed-Seiten 
offiziell wird.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> How to build?
>>     You can build this projest using Eclipse (SW4STM32) IDE
>
> und ich will es ohne eclipse.

Also selber Makefile bauen. Ich kenn SW4STM32 nicht, aber die GNU ARM 
MCU Eclipse plugins legen selber Makefiles an, die kann man dann 
natürlich auch ohne Eclipse weiterverwenden, man muss nur aufpassen, 
dass man sie sich nicht wieder überschreibt. Falls das die SW4STM32 
genauso handhabt kann man die generierten Makefiles ja als Ausgangspunkt 
für eigene verwenden...

Autor: W.S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Aber es wäre schön, wenn wir nun diese Philosophischen Betrachtungen
> abhaken könnten...
>...

> und ich will es ohne eclipse.

Herrjemineh, kannst du eigentlich lesen oder nur schreiben???

Daß das alles ohne aufgeblähten Aufwand geht, habe ich dir ja schon 
geschrieben. Also lade dir die Arm-Toolchain deiner Wahl herunter, 
installiere sie und rufe von der Kommandozeile erstmal den Compiler mit 
einem popligen Winzprogramm auf, etwa sowas:
int main (void)
{ return 0;
}

und guck dir an, ob du das übersetzt kriegst. Mir ist das jetzt zu doof, 
dir die Grundlagen eines Shell-Skripts beizubringen, zumal ich kein 
Linuxer bin. Aber sowas simples wie dieses:
echo Compile Main
ARM-NONE-EABI-GCC @compile_gcc.xcl -o main.thumb.o main.c
if Errorlevel==1 goto ende

echo Linke
ARM-NONE-EABI-LD @link_gcc.xcl
if Errorlevel==1 goto ende

echo Mache Hex
ARM-NONE-EABI-OBJCOPY -O ihex linkedgcc.elf BettyBASEgcc.hex
if Errorlevel==1 goto ende

echo Mache Bin
ARM-NONE-EABI-OBJCOPY -O binary  linkedgcc.elf BettyBASEgcc.bin
if Errorlevel==1 goto ende

echo So, das war's.
goto schluss

:ende
echo ...
echo Hei, da ist was schiefgelaufen!
pause

:schluss

solltest du mit links in ein Shellskript umschreiben können. Wer Linux 
benutzt, der hat sowas gefälligst auch zu können. Du wirst vermutlich 
nicht mehr die yagarto-Distri benutzen, also solltest du das obige 
Beispiel an deine Distri anpassen.
Obendrein sind natürlich auch die beiden .xcl (extended command lines) 
an dein Projekt anzupassen.

Und jetz jammere nicht mehr so herum, sondern mache.

W.S.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:

> Herrjemineh, kannst du eigentlich lesen oder nur schreiben???


liest du eigentliche auch oder kannst du nur pöbeln?

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer mich kennt, weiß daß ich noch ganz anders kann. Du hingegen jammerst 
herum, daß du dies und das hasst und somit nicht weiter kommst.

Und wenn du schon keine Ratschläge haben willst, sondern nur deinem 
angestauten Unmut Ausdruck geben willst, dann sage das. Sowas kann 
auch akzeptiert werden. Manchmal muß man sich halt mal aussprechen...

W.S.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hilfe alarm. Was ist ein .xcl?

So wie sich das bis jetzt entwickelt hat sehe ich 2 Möglichkeiten wie 
das (kurzfristig) weitergehen kann:

* den ursprünglichen Entwickler dazu bringen, dass er ein Build-System 
integriert (z.B. Makefiles)

alternativ

* SW4STM installieren, einmal auf "build" drücken und die dabei 
erzeugten Makefiles zukünftig ohne eclipse weiterbenutzen.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
rµ schrieb:
> Hilfe alarm. Was ist ein .xcl?

Auch du kannst offensichtlich nicht lesen, sonst hättest du die Antwort 
nur 3 Posts über dem deinigen lesen können. Extended Command Line. Eine 
Datei, die all das enthält, was man ansonsten in die Commandline hätte 
geschrieben haben müssen. Sowas spart Schreibarbeit.

W.S.

Autor: rµ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Auch du kannst offensichtlich nicht lesen, sonst hättest du die Antwort
> nur 3 Posts über dem deinigen lesen können. Extended Command Line. Eine
> Datei, die all das enthält, was man ansonsten in die Commandline hätte
> geschrieben haben müssen. Sowas spart Schreibarbeit.
>
> W.S.

natürlich kann ich lesen. Ich kann auch google bedienen, und das liefert 
weder zu .xcl noch zu "Extended Command Line" irgendwas brauchbares, ob 
mit oder ohne Windows- Linux- oder sogar MacOS Kontext.

Normalerweise würde man da ein Makefile bauen. So ein Shellskript 
verursacht ja auf 10 Quelldateien erweitert schon Augenkrebs und Schaum 
vorm Mund.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
>> How to build?
>>     You can build this projest using Eclipse (SW4STM32) IDE
>
> und ich will es ohne eclipse.

Eclipse läuft auch unter Linux - gut hilft nichts, wenn man Eclipse 
selbst nicht mag.

SW4STM32 zB mag ich nicht, ich verwende Eclipse CDT + Gnu-Arm Plugin + 
OpenOCD.

Das Debuggen ist schon echt oft sehr hilfreich.

Ansonsten kannst du OpenOCD auch direkt von der Konsole aus starten und 
per GDB debuggen.

Du kannst alles ohne Eclipse per Makefiles kompilieren.

Du kannst mit OpenOCD auch die STM32 flashen.

Man kommt also schon ohne IDE aus.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ist das prekär hier... Im Anhang ein Makefile, mit welchem das erwähnte 
Projekt kompiliert werden kann. War jetzt gar nicht so schwierig.

Erst den Compiler installieren:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

In der syscalls.c muss man am Anfang noch folgendes einfügen:
int _getpid(void) __attribute__((used));
int _kill(int pid, int sig) __attribute__((used));
void _exit (int status) __attribute__((used));
int _read (int file, char *ptr, int len) __attribute__((used));
int _write(int file, char *ptr, int len) __attribute__((used));
caddr_t _sbrk(int incr) __attribute__((used));
int _close(int file) __attribute__((used));
int _fstat(int file, struct stat *st) __attribute__((used));
int _isatty(int file) __attribute__((used));
int _lseek(int file, int ptr, int dir) __attribute__((used));
int _open(char *path, int flags, ...) __attribute__((used));
int _wait(int *status) __attribute__((used));
int _unlink(char *name) __attribute__((used));
int _times(struct tms *buf) __attribute__((used));
int _stat(char *file, struct stat *st) __attribute__((used));
int _link(char *old, char *new) __attribute__((used));
int _fork(void) __attribute__((used));
int _execve(char *name, char **argv, char **env) __attribute__((used));

In der "Src/lwip.c" muss man die "#if defined ( __CC_ARM )" 
auskommentieren. kA warum die da sind.

Dann kann man per "make" alles automatisch kompilieren.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt mal für den Kollegen aus Bulgarien eine
Linux-Konstellation beschrieben, mit der man zumindest die
einfachen Demo-Sourcen übersetzt bekommt.
s.u.

Da es aber neben den 100ten von STM32-Typen/Board auch noch
unzählige Wege gibt, um Programme dafür zu entwickeln, ist es
nicht eben leicht, die passende Zusammenstellung zu finden.

mbed war bislang der Weg des geringsten Widerstandes. (für mich)
Blöd ist natürlich, dass Eth. nicht unterstützt wird.
Das müsste man dann wohl zu Fuss machen - aber wenn ich das
richtig sehe, ist das ja hier der Fall:


https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

da steigt er aber aus mit:

Compile [ 10.9%]: NanostackRfPhyMcr20a.cpp
[Fatal Error] device.h@41,10: stm32f7xx_hal_rng.h: No such file or 
directory
[ERROR] In file included from ./mbed-os/platform/platform.h:30,
                 from ./mbed-os/drivers/DigitalIn.h:20,
                 from 
./mbed-os/components/802.15.4_RF/mcr20a-rf-driver/mcr20a-rf-driver/Nanos 
tackRfPhyMcr20a.h:23,
                 from 
./mbed-os/components/802.15.4_RF/mcr20a-rf-driver/source/NanostackRfPhyM 
cr20a.cpp:19:
./mbed-os/targets/TARGET_STM/TARGET_STM32H7/device.h:41:10: fatal error: 
stm32f7xx_hal_rng.h: No such file or directory
 #include "stm32f7xx_hal_rng.h"
          ^~~~~~~~~~~~~~~~~~~~~

obwohl "stm32f7xx_hal_rng.h" da ist - und zwar an der gleichen stelle,
wie das eine Zeile früher includete "stm32h7xx_ll_usart.h"

Und zu "issue 4408" habe ich noch nichts gefunden, was mich weiter 
brachte...


#include "objects.h"
/*  WORKAROUND waiting for mbed-os issue 4408 to be addressed */
#include "stm32h7xx_ll_usart.h"
#include "stm32f7xx_hal_rng.h"



----------------------------------
###################################


I use linuxmint (19.1 - xfce) - but any debian/ubunto should work.

And I use mbed-cli. Here are the installation-steps:

https://os.mbed.com/docs/mbed-os/v5.12/tools/linux.html

after installation of the gcc-arm-none-eabi:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

(for testing, I placed it in)
/mnt/gcc-arm-none-eabi-8-2018-q4-major

you should configure the mbed-path:

mbed config GCC_ARM_PATH /mnt/gcc-arm-none-eabi-8-2018-q4-major/bin/
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^path to 
your compiler


copy the blinkey-sources

or some other test-sources like:
wget 
https://os.mbed.com/teams/ST/code/HelloWorld_IKS01A3/archive/44bf486fd3cf.zip


cd 44bf486fd3cf

/usr/local/bin/mbed deploy .

mbed-cli compile -j0 -t GCC_ARM  -m NUCLEO_H743ZI


copy the resulting .bin  from
BUILD/NUCLEO_H743ZI/GCC_ARM/44bf486fd3cf.bin to 
/media/user/NUCLEO_H743ZI

and watch the output:

miniterm /dev/ttyACM0 9600

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Mir ist das jetzt zu doof,
> dir die Grundlagen eines Shell-Skripts beizubringen

Bei einem Projekt mit so vielen Dateien wird ein Shell-Skript schon 
ziemlich langsam. Bei jeder kleinsten Änderung alles neu zu kompilieren 
wird schon nervig. Make kompiliert automatisch nur die benötigten 
Dateien neu. Außerdem kann man mit "make -j 8" o.ä. mehrere Vorgänge 
gleichzeitig laufen lassen. Shell-Scripte sind hier doch ziemlich 
überholt.

Wicki W. schrieb:
> Das müsste man dann wohl zu Fuss machen - aber wenn ich das
> richtig sehe, ist das ja hier der Fall:

Das Projekt nutzt HAL und lwIP - was versprichst du dir davon, da noch 
mbed rein zu pfriemeln? Welche mbed-Features möchtest du nutzen?

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besten Dank fuer das Makefile - aber das
steigt sofort aus mit:

Makefile:31: Release/syscalls.d: Datei oder Verzeichnis nicht gefunden
....
make: *** Keine Regel, um 
„Release/Middlewares/Third_Party/LwIP/src/netif/ppp/utils.d“ zu 
erstellen.  Schluss.


lege ich ihm die .d-files von hand an, dann kommt:

Release/syscalls.d:1: *** Fehlender Trenner.  Schluss.


und nein, ich schreibe normalerweise keine Makfiles von Hand.
Hab also keine Erfahrung damit


> Das Projekt nutzt HAL und lwIP - was versprichst du dir davon, da noch
> mbed rein zu pfriemeln? Welche mbed-Features möchtest du nutzen?

Das weiss ich nicht. Ich weiss nicht viel ueber die STM32. Deshalb steht 
da
oben ja auch "Einsteigerfragen".
Aber grundsätzlich hielt es es für eine gute Idee, das mal 
auszuprobieren.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://os.mbed.com/questions/84077/Ethernet-support-for-STM32H7/

hier ist der mbed fork mit Ethernet für H743:
https://github.com/CurryGuy/mbed-os/tree/test-stm32h7-emac

Ich kenne die Unterschiede im Emac zwischen F7 und H7 nicht, aber durch 
die HAL scheint die Portierung nach H7 nicht so aufwändig zu sein. 
Natürlich können kleine Unterschiede grosse Wirkung haben und manchmal 
benennt ST einfach was um, aber das ist doch schonmal ein Ansatz.
Die Treiber und den Zusatz für den H7 findest du hier:
https://github.com/CurryGuy/mbed-os/tree/test-stm32h7-emac/features/netsocket/emac-drivers/TARGET_STM_EMAC

mbed wird da nicht reingepfriemelt, es ist das OS mit einem 
einheitlichen API. Für die Implementierung wird für die STM32 HAL/LL 
benutzt, daher kann man fehlende Devices gut mit Code von CubeMX 
ergänzen. Bei anderen Targets wie z.B. NXP, Atmel oder Nordic werden 
deren Frameworks benutzt oder bei älteren NXP auch nur 
Registerprogrammierung. Deswegen sind die oft bei den kleineren µC mit 
mbed2 besser geeignet.
Der Vorteil eines OS ist da einfach auf ein anderes Board wechseln zu 
können, sogar Herstellerübergreifend.

: Bearbeitet durch User
Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Besten Dank fuer das Makefile - aber das
> steigt sofort aus mit:

Oh, es muss "-include" sein. Im Anhang ein aktualisiertes Makefile mit 
noch ein paar mehr Verbesserungen. Man kann "make DEBUG=y" übergeben für 
einen Debug-Build.

Wicki W. schrieb:
> und nein, ich schreibe normalerweise keine Makfiles von Hand.
> Hab also keine Erfahrung damit

Wie soll das dann gehen? Kein Makefile, keine IDE, sondern...?

Johannes S. schrieb:
> mbed wird da nicht reingepfriemelt, es ist das OS mit einem
> einheitlichen API.

In ein bestehendes HAL-Projekt mbed einzubauen klingt 
verkehrt/fehleranfällig, gerade weil eben noch keinerlei OS-APIs benutzt 
werden. Vor allem weil das ein leeres Projekt ist, wäre es sinnvoller, 
direkt ein mbed-Projekt anzulegen, wenn man denn überhaupt die mbed-APIs 
nutzen will.

: Bearbeitet durch User
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Oh, es muss "-include" sein. Im Anhang ein aktualisiertes Makefile mit
> noch ein paar mehr Verbesserungen.


ja, danke!
jetzt passt es. und compiliert.
funktionieren tuts aber leider noch nicht.

aber das ist eine basis von der aus ich weiter machen kann.


> Wie soll das dann gehen? Kein Makefile, keine IDE, sondern...?

meine sachen laufen alle per script. makefiles brauche ich
bislang nur selten.




> hier ist der mbed fork mit Ethernet für H743:

ja, ebenfalls danke.
damit komme ich jetzt auch schon ein bisschen weiter.


mal sehen, wohin das noch führt.....

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> meine sachen laufen alle per script. makefiles brauche ich
> bislang nur selten.

Wie erwähnt sind Makefiles für größere Projekte sinnvoller, da 
schneller...

Wicki W. schrieb:
> funktionieren tuts aber leider noch nicht.

Das Projekt ist ja auch praktisch leer und tut nichts.

Im Anhang nochmal eine etwas verbesserte/aufgeräumte Version des 
Makefiles.

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Bei jeder kleinsten Änderung alles neu zu kompilieren
> wird schon nervig.... Shell-Scripte sind hier doch ziemlich
> überholt.

Das war und ist nicht das Thema, sondern wie man OHNE eine IDE und 
dediziert OHNE Windows ne Quelle übersetzt. Alles unter dem Begriff 
Einsteigerfragen.

Ne simple Batch-Datei oder ein ebenso simples Script mögen zwar 
langsamer sein als Make, weil eben alles übersetzt wird.

Aber sie haben einen gewaltigen Vorteil: Sowas kann JEDER (oder sollte 
es zumindest), ohne sich zuvor in die Syntax und das Grundverständnis 
eines jeden MAKE's eingearbeitet zu haben. Batch oder Skript sind wohl 
die simpelsten Methoden und eben deshalb leicht lesbar, überschaubar und 
damit auch zuverlässig. Es gibt keine Fallstricke wie vorübersetzte 
Header, Mismatch von Datumsstempeln und dergleichen.

Und ja, Make's gibt es viele und jedes hat seine eigene Syntax, die 
natürlich komplett inkompatibel ist zu jedem anderen Make.

Aber mal abgesehen davon: Warum meinst du, daß das Übersetzen damit 
langsamer ist als bei Make - das Weglassen wegen Datumsstempel bei Make 
mal außen vorgelassen.

Ich sehe das eher so, daß das Übersetzen immer dann langsam wird, wenn 
in einzubindenden .h Dateien ellenlange Romane geschrieben wurden und 
eben zuviel Indirektion betrieben wird.

Siehe z.B. die blutige Auseinandersetzung hier im Forum, wo es Leute 
gibt, die lieber 30x eine > 1 MB große Headerdatei sich reinziehen 
wollen, um dort das
#define SYSAHBCONTROLSETPLIMPLUMIENOTMASK ~(1<<3)
und das
#define SYSAHBCONTROLSETPLIMPLUMIESETMASK (1<<3)
und das
#define SYSAHBCONTROLSETPLIMPLUMIEBIT 3
zu finden - anstelle nen leserlichen Code zu schreiben, der auf unnötige 
Indirektionen solcher Art verzichtet.

W.S.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Aber sie haben einen gewaltigen Vorteil: Sowas kann JEDER (oder sollte
> es zumindest), ohne sich zuvor in die Syntax und das Grundverständnis
> eines jeden MAKE's eingearbeitet zu haben.

Makefiles schreiben ist aber eine ziemliche Grundlage. Weil das so 
hilfreich und so verbreitet ist, sollte das jeder lernen.

W.S. schrieb:
> Und ja, Make's gibt es viele und jedes hat seine eigene Syntax, die
> natürlich komplett inkompatibel ist zu jedem anderen Make.

GNU Make ist in diesem Bereich sehr verbreitet. Bei der Syntax gibt es 
einen kleinsten gemeinsamen Nenner, der sehr wohl kompatibel ist.

W.S. schrieb:
> Aber mal abgesehen davon: Warum meinst du, daß das Übersetzen damit
> langsamer ist als bei Make

Weil ein simples Shell-Script immer alles neu kompiliert, und ohne 
weiteres nicht mehrere Compiler-Aufrufe parallel startet. Bei make ist 
das gratis mit dabei; damit kann man Mehrkern-Prozessoren effektiv 
nutzen. Bei größeren Projekten wie diesem kann das die Zeit auf einen 
Bruchteil reduzieren.

W.S. schrieb:
> Siehe z.B. die blutige Auseinandersetzung hier im Forum, wo es Leute
> gibt, die lieber 30x eine > 1 MB große Headerdatei sich reinziehen
> wollen, um dort das

Include-Guards verhinden die 29 Aufrufe. Außerdem sind die paar 
Millisekunden für die Konstanten ein gern bezahlter Preis für die 
Vermeidung von Magic Numbers. Bei "1 << 3" weiß keiner was das Bit jetzt 
bedeutet.

Das Schreiben eines Makefiles welches paralleles Kompilieren ermöglicht 
ist immer noch viel besser und effektiver als das Vermeiden von ein paar 
Makros.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das war und ist nicht das Thema, sondern wie man OHNE eine IDE und
> dediziert OHNE Windows ne Quelle übersetzt. Alles unter dem Begriff
> Einsteigerfragen.

Danke!
Sehr schön zusammengefasst.

Wie soll man als Neuling auf diesem Board und mit diesen Werkzeugen auf 
so was kommen:

------------------------
In der syscalls.c muss man am Anfang noch folgendes einfügen:
int _getpid(void) __attribute__((used));
[....]
int _execve(char *name, char **argv, char **env) __attribute__((used));
In der "Src/lwip.c" muss man die "#if defined ( __CC_ARM )"
auskommentieren. kA warum die da sind.
-------------------------

Jetzt hab ich 2 kommandozeilenfaehige Varianten (mit make und mbed)
Besten Dank dafür.

und jetzt muss mich jetzt mal für eine davon entscheiden...

Aber erst werde ich noch ein bisschen rumprobieren.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> Wie soll man als Neuling auf diesem Board und mit diesen Werkzeugen auf
> so was kommen:

Indem man diese Datei von der jeweiligen IDE anlegen lässt oder aus 
einem Beispiel/Template übernimmt. Wenn man alles von Hand macht muss 
man das eben selbst wissen. Konkret ist das "used" nötig, weil es sonst 
bei aktiviertem LTO Linker-Fehler gibt, weil diese Funktionen nicht aus 
dem eigenen Sourcecode sondern aus der C-Library referenziert werden.

Autor: rµ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
>> Bei jeder kleinsten Änderung alles neu zu kompilieren
>> wird schon nervig.... Shell-Scripte sind hier doch ziemlich
>> überholt.
>
> Das war und ist nicht das Thema, sondern wie man OHNE eine IDE und
> dediziert OHNE Windows ne Quelle übersetzt. Alles unter dem Begriff
> Einsteigerfragen.
>
> Ne simple Batch-Datei oder ein ebenso simples Script mögen zwar
> langsamer sein als Make, weil eben alles übersetzt wird.

Einen solchen Einsteiger dann mit ".xcl" in die Wüste zu schicken ist 
aber auch nicht nett.

Makefiles sind schon ein Standard, wenn man sich beschränkt dann 
funktioniert das selbe Makefile mit Microsoft NMAKE, BSD make, GNU make, 
standard SYSV make und vermutlich auch Turbo- oder Borland-make.

Was im Fall des TO den Einstieg natürlich auch erschwert, ist die 
ausgewählte Hardware: der H743 ist aus der STM32 Microcontroller-Reihe 
ja die Maximalvariante. Refman hat >4000 Seiten. Kein Wunder dass da der 
eine oder andere Fallstrick lauert.

So ein Projekt mit Filesystem, RTOS, lwip, diversen Treibern und 
eventuell auch noch einigen C++ Quellen (mbed) hat schon mal einige zig 
bis hundert Quelldateien, wenn man die immer komplett neu übersetzt weil 
das dumme Shellskript nicht weiss was wovon abhängig ist wird das bald 
keinen Spass mehr machen.

Ein richtig erstelltes Makefile übersetzt nur Dateien neu die sich 
gegenüber dem letzten Lauf geändert haben bzw. deren Abhängigkeiten. Da 
man normalerweise ja nicht an allen Stellen gleichzeitig arbeitet spart 
man sich da bald einiges an Wartezeit.

Probleme mit Zeitstempeln gibts normalerweise nur mit Netzlaufwerken und 
nicht synchronisierten Uhren und mit FAT-Dateisystemen, die den 
Zeitstempel nur auf 2s genau aufgelöst abspeichern, aber in den (fast 
schon) 20ern des 21. Jahrhunderts sollten diese Dinge längst überwunden 
sein.

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> und
> dediziert OHNE Windows

Und dann postest du xcl-Scripte?......

kopfschüttel

Als eingefleischter Linuxer mußte ich erst mal googeln, was das 
überhaupt ist.

Daß man sowas bereits seit Jahrzehnten mit makefiles macht wurde ja 
bereits ausreichend oft gesagt.

Autor: Holm T. (holm)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
[..]
>
> solltest du mit links in ein Shellskript umschreiben können. Wer Linux
> benutzt, der hat sowas gefälligst auch zu können.
[..]
>
> W.S.

..warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
die dafür gedacht sind?

Kopfschüttel,

Holm

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Holm T. schrieb:

> warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
> die dafür gedacht sind?
>
> Kopfschüttel,
>
> Holm

Weil ws ein Sturkopf ist der alles ablehnt was andere jemals für 
nützlich befunden haben denn dann hat er es nicht selbst erfunden und es 
kann deshalb nur scheisse sein.

Er hat NIH-Syndrom im letzten Stadium. Wenn er könnte würde er sich 
seinen eigenen Compiler schreiben, in DOS batch, das schafft er aber 
nicht und das nagt an ihm. Deshalb ist er so wie er ist.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist wirklich schön hier bei Euch.
Ihr tut viel gutes für die Menschen.....

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, bei einer handvoll Quellen die in Nullkommanix kompilieren kann 
man ja mit Batchfiles leben wenn man make nicht verwenden will. Aber die 
heutigen Monster-CPUs wie hier ein STM32H743 mit 2 MB Flash / 1 MB RAM 
haben doch mehr Power und eingebaute Peripherie als ein alter 386er PC 
und entsprechend kann man da grössere Projekte mit starten. Alleine mit 
der Taktkonfiguration kann man Tage/Wochen verbringen. Aber sowas 
braucht ein Hobbyist ja alles nicht, der soll sich gefälligst an ein 
paar blinkenden LED erfreuen.

Autor: Michael F. (michaelfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal eine ernst gemeinte Frage an die User, die ihre Projekte per 
Kommandozeile bauen und flashen:

Wie sieht bei Euch das Debugging einer Anwendung aus?

Wie Johannes S. treffend schreibt, kann man bei einem H7 Tage/Wochen mit 
der Konfiguration der Peripherie verbringen und ohne sinnvolle 
Debug-Möglichkeiten (die ich mir in der Kommandozeile sehr übersichtlich 
vorstelle) würde ich den Spaß der ganzen Aktion als sehr gering 
einstufen...

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael F. schrieb:
> die ich mir in der Kommandozeile sehr übersichtlich vorstelle

Über den GDB geht das schon. Die IDE/GUI greift da letztlich auch nur 
drauf zu. In der GUI ist es nur etwas komfortabler, die Möglichkeiten 
sind gleich. Manchmal benutze ich auch den GDB auf der Konsole weil 
Eclipse irgendwas durcheinander bringt...

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
rµ schrieb:
> Einen solchen Einsteiger dann mit ".xcl" in die Wüste zu schicken ist
> aber auch nicht nett.

Hä? Also ich habe davon zwei Stück gepostet, dazu nen auszug aus einer 
Batchdatei. Das ist alles sehr einfach gestrickt und damit les- und 
verstehbar, ohne daß man erstmal irgendwo nachschlagen müßte.

Und .xcl findet sich auch in der Dokumentation des GCC - die allerdings 
muß man wirklich suchen.

Das Problem ist also gar keines.

Und nochwas: lies mal den Eröffnungspost. Wer über Windows und IDE's 
klagt und erst mal sowas anfragt:

Wicki W. schrieb:
> Ist es moeglich, den STM32 unter Linux ausschliesslich ueber die
> Commandline zu programmieren oder wird man  dann an irgendwas scheitern?

..dem ist sehr wohl damit geholfen, wenn er zuvörderst sein 
allerersten HelloWorld mit einer popligen Batchdatei/Shellscript 
übersetzt kriegt.

Von riesengroßen Projekten mit hunderten von Dateien war und ist hier 
nicht die Rede, sondern von der Frage, ob Wicki es ÜBERHAUPT von der 
Kommandozeile hinbekommt.



Holm T. schrieb:
> ..warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
> die dafür gedacht sind?
>
> Kopfschüttel,

Ebenso Kopfschüttel meinerseits, weil du nix kapiert hast.

Grund: Wenn einer hier anfragt, weil er noch nie seinen Compiler auf der 
Kommandozeile aufgerufen hat sondern nur IDE's kennt, dann hat er auch 
noch nie Make benutzt und er kennt deshalb auch noch nicht dessen 
Syntax.

DARUM!

Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

W.S.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Von riesengroßen Projekten mit hunderten von Dateien war und ist hier
> nicht die Rede

Doch:

Wicki W. schrieb:
> https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

W.S. schrieb:
> Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

Schon passiert:

Niklas G. schrieb:
> Im Anhang nochmal eine etwas verbesserte/aufgeräumte Version des
> Makefiles.

Ist ja auch nicht so schwierig. Warum man da erst lange rumeiert...

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> W.S. schrieb:
> > Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

> Schon passiert:
> Ist ja auch nicht so schwierig. Warum man da erst lange rumeiert...

ja - und nochmals besten dank dafuer!

natuerlich habe ich auch schon makefile geschrieben.
das ist aber

a) schon lange her
und
b) immer erst dann passiert, wenn ueberhaupt
   klar ist, wohin der weg fuehren soll


natuerlich findet man auch fuer stm32 1000de beispielsourcen.
deutlich weniger findet man fuer den h743zi und eth.
und das sind alles eclipse&co-beispiele. (jedenfalls die,
die ich gefunden habe)

und ich fuehle mich von dem zeugs entmuendigt.
kann man benutzen, wenn man feststellt, dass man es
irgendwann braucht.

anfangen moechte ich damit aber nicht.

im moment bin ich eh eher geneigt, die ganze stm32-kiste
beiseite zu legen.
interessant, mal rein zu sehen - einige sachen sind toll.
aber zu infaltionaer und unuebersichtlich sind die IDEs,
compiler, libs und board-typen.
zumindest fuer meinen geschmack.


munter bleiben

wicki

Autor: rµ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Niklas G. schrieb:
> W.S. schrieb:
>> Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?

Normalerweise ist es ja nicht nachhaltig zielführend wenn man eine 
vorgekaute Lösung präsentiert, beim nächsten ähnlichen Problem steht der 
Fragesteller dann ja wieder gleich da.

Gscheiter ist es IMHO Möglichkeiten aufzuzeigen wie man dann zu so einem 
Makefile kommt. Von RTFM abgesehen gäbs eben auch die Möglichkeit, sich 
von einer IDE eins erzeugen zu lassen. Die IDE muss man danach ja nicht 
verwenden. Spätestens beim Debuggen wirds ohne GUI aber schnell recht 
unübersichtlich, das ist nur hardcore Textmode-Freaks zu empfehlen, die 
haben aber solche Probleme wie "wie komme ich zu einem Makefile" nicht.

Egal.

Mich interessiert eigentlich die ursprüngliche LinuxCNC-Anwendung, ich 
hoffe es gibt noch Updates wie die Geschichte weitergeht.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> und unuebersichtlich sind die IDEs,
> compiler, libs und board-typen.

Dann fang doch mal mit einem kleineren STM32 an, z.B. dem allseits 
beliebten STM32F103. Den kann man ganz gut ohne Bibliothek (außer 
Register-Definition) programmieren. Dafür gibt's auch die handlichen und 
billigen Bluepill-Boards.

Wenn du den größten Controller der Familie aussuchst, Ethernet und 
TCP/IP haben willst, wird es ohne komplexe Bibliotheken schwierig! Oder 
erwartest du, dass der Prozessor TCP in Hardware spricht?

rµ schrieb:
> Normalerweise ist es ja nicht nachhaltig zielführend wenn man eine
> vorgekaute Lösung präsentiert

Tja, es ist irgendwie irritierend wenn hier so lange um den heißen Brei 
diskutiert wird. Da möchte man manchmal Tatsachen schaffen.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> und ich fuehle mich von dem zeugs entmuendigt.
> kann man benutzen, wenn man feststellt, dass man es
> irgendwann braucht.

Manchmal ist der umgekehrte Ansatz zielführender. Im Codegenerator alles 
reinpappen was man brauchen wird, und so schnell wie möglich auf dem 
Nucleo zumindest prinzipiell zum Laufen zu bringen.

Dann den generierten Code anschauen und eventuell ausdünnen.

> im moment bin ich eh eher geneigt, die ganze stm32-kiste
> beiseite zu legen.
> interessant, mal rein zu sehen - einige sachen sind toll.
> aber zu infaltionaer und unuebersichtlich sind die IDEs,
> compiler, libs und board-typen.
> zumindest fuer meinen geschmack.

Die mbed-seite führt einen haufen unterstützte Boards auf mit Ethernet:
https://os.mbed.com/platforms/?q=&Communication=Ethernet

Eventuell ist es einfacher, vom H743 auf einen gängigeren µC mit 
offiziellem mbed-support zu wechseln wie Nucleo-F429ZI, Nucleo-F746ZI 
o.ä, die 25€ sind schnell an gesparten Nerven/nicht ausgerupften Haaren 
wieder eingespart.

Nur als Hinweis: die selbe Geschichte mit NXP LPC 1769 (LPC xpresso) als 
Basis ist auch nicht weniger komplex (mEn). Ein TCP/IP-Stack ist halt 
mal ein großer Brocken SW der auch einiges an "Verhalten" hat, da 
passiert viel im Hintergrund.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> Mich interessiert eigentlich die ursprüngliche LinuxCNC-Anwendung, ich
> hoffe es gibt noch Updates wie die Geschichte weitergeht.

da bin ich selbst gespannt. die sourcen des bulgarischen entwicklers
habe ich noch nicht compiliert bekommen.
irgendwas stimmt mit den headern nicht.
denn er included  stm32f4xx_hal_conf.h aber laufen soll es
doch auf einer stm32f743-hardware...

und auf seiner seite ist es ein zeitliches problem - und ein problem,
dass er kein linux-mensch ist....

vorschlag:
ich frage den entwickler aus bulgarien, ob er bereit ist, seine
sourcen offen zu legen. (die liegen z.zt. in einer pw-geschuetzten
google-cloud und ich kann sie nicht ohne rueckfrage einfach weitergeben)

es wuerde die sache erheblich einfacher gestalten, wenn die sourcen
offen liegen

so ist die kommunikation doch etwas schwierig.....

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> vorschlag:
> ich frage den entwickler aus bulgarien, ob er bereit ist, seine
> sourcen offen zu legen. (die liegen z.zt. in einer pw-geschuetzten
> google-cloud und ich kann sie nicht ohne rueckfrage einfach weitergeben)

Am besten auf GitHub mit entsprechender Open Source Lizenz (GPL, MIT, 
BSD, ...) dann kann jeder damit arbeiten und Änderungs Vorschläge 
einreichen.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> Michael F. schrieb:
>> die ich mir in der Kommandozeile sehr übersichtlich vorstelle
>
> Über den GDB geht das schon. Die IDE/GUI greift da letztlich auch nur
> drauf zu. In der GUI ist es nur etwas komfortabler, die Möglichkeiten
> sind gleich. Manchmal benutze ich auch den GDB auf der Konsole weil
> Eclipse irgendwas durcheinander bringt...

Es sollte auch nicht verschwiegen werden das es Frontents für den GDB 
gibt ..so wie DDD (Data Display Debugger) die da ein Stück weit Komfort 
ermöglichen.

Von Eclipse habe ich mich verabschiedet nach dem Versuch die für MSP430, 
Atmels und die Host CPU (AMD64) gleichzeitig benutzbar zu machen, 
natürlich nur ein Projekt gleichzeitig. Nach einer Woche habe ich 
eingesehen das das ein Projekt für zukünftige Generationen ist.. und 
nehme die Kommandozeile..über einen Terminalmultiplexer namens x11.

Gruß,

Holm

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Von Eclipse habe ich mich verabschiedet nach dem Versuch die für MSP430,
> Atmels und die Host CPU (AMD64) gleichzeitig benutzbar zu machen,

Host (AMD64) mit C++, Java, Ruby und Target mit Cortex-M (STM32, LPC) 
mit C++ war bei mir kein Problem mit Eclipse (auch wenn alles 
gleichzeitig offen).

Autor: Holm T. (holm)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
[..]
>
> Holm T. schrieb:
>> ..warum zum Teufel sollte man Sowas tun wollen wenn es Tools wie make
>> die dafür gedacht sind?
>>
>> Kopfschüttel,
>
> Ebenso Kopfschüttel meinerseits, weil du nix kapiert hast.
>
> Grund: Wenn einer hier anfragt, weil er noch nie seinen Compiler auf der
> Kommandozeile aufgerufen hat sondern nur IDE's kennt, dann hat er auch
> noch nie Make benutzt und er kennt deshalb auch noch nicht dessen
> Syntax.
>
> DARUM!

...sollte er sich von Begin an auf das falsche Werkzeug einlassen?

Kennst Du exec(), execve(), fork() und system()? Warum schlägst Du dem 
TO nicht vor den Build Prozess durch ein C-Programm zu steuern?
>
> Oder setzt du dich hin und schreibst dem TO dessen Makefile? Für lau?
>
> W.S.

Gegenfrage: Du schreibst Shellscripte (Batch Dateien) für den TO für 
lau?
Mach mir mal eins für DCL bitte...

(evtl. hilfreich: 
https://www.dcl.hpi.uni-potsdam.de/teaching/serveros/OpenVMS/uebung/OpenVMS-DCL.pdf 
)

Für Dich gilt offensichtlich der Ansatz: "wenn ein Hammer das einzige 
Werkzeug ist das man besitzt, dann fängt Alles um einen herum an wie ein 
Nagel auszusehen" ..in verschärfter Form.

Die Shell Scripte sind schon alleine deshalb Kokolores, weil sie 
zwischen verschiedenen OS nicht portabel sind, make aber bis auf geringe 
Unterschiede schon.

Gruß,

Holm

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Holm T. schrieb:
>> Von Eclipse habe ich mich verabschiedet nach dem Versuch die für MSP430,
>> Atmels und die Host CPU (AMD64) gleichzeitig benutzbar zu machen,
>
> Host (AMD64) mit C++, Java, Ruby und Target mit Cortex-M (STM32, LPC)
> mit C++ war bei mir kein Problem mit Eclipse (auch wenn alles
> gleichzeitig offen).

Ok, es ist ein paar Jahre her das ich das auf dem Tisch hatte. 
Möglicherweise hat sich da was verbessert, aber außer seitenlangen Java 
Fehlermeldungen habe ich nicht viel Vernünftiges damit produzieren 
können, mal abgesehen davon das ich mir jedes Mal einen Wolf gesucht 
habe um irgendwelche Pfade oder Compileroptionen irgendwo ändern zu 
können. Da war IMHO noch mit Eclipse Helios.


Gruß,

Holm

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi zusammen,

hier die antwort aus bulgarien

web page
http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=18671&start=200

Files
http://www.cnc-club.ru/forum/download/file.php?id=148983
http://www.cnc-club.ru/forum/download/file.php?id=148984
http://www.cnc-club.ru/forum/download/file.php?id=148987
http://www.cnc-club.ru/forum/download/file.php?id=148988


Im wesentlichen gehts um die Sourcen, die in
http://www.cnc-club.ru/forum/download/file.php?id=148984
drin steckt:

EthernetCNC_ver3

den rest kenne ich auch erst seit gerade eben...

mein russisch ist jetzt auch nicht sonderlich gut... ;-)

aber mir ist nicht klar, wo denn nun der bezug zum h743
herkommen soll...

ich vermute mal fast:
den gibts gar nicht...

Autor: Wicki W. (wicki)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab jetzt mal in

system/include/cmsis/stm32f4xx.h

testweise

    #define STM32F437xx

aktiviert

das Makefile auf meine config angepasst und versucht zu compilieren.
Hier steigt er aus.
Auch wenn ich

system/lwip/src/include/lwip/netifapi.h

in der err_t definiert ist, explizit include:


system/lwip/src/netif/ethernetif_template.c: At top level:
system/lwip/src/netif/ethernetif_template.c:72:8: error: unknown type 
name 'err_t'
 static err_t low_level_output(struct netif *netif, struct pbuf *p)


vermutlich sehe ich grad wieder den Wald vor lauter Baeumen nicht...

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Wicki W. schrieb:
> #define STM32F437xx

Das ist verkehrt; das Makro kommt ins Makefile. Da da schon das Makro 
für den H7 stand, kollidiert das.

Wicki W. schrieb:
> system/lwip/src/netif/ethernetif_template.c: At top level:

Die Datei soll wohl gar nicht mitkompiliert werden ("template").

Mit dem Makefile im Anhang gehts. Ich habe dort mal die Source-Dateien 
explizit angegeben statt sie automatisch zu suchen; ist sauberer und 
vermeidet das Kompilieren dieser "template" Datei und der 
"utils/sendconfig.c".

In der src/main.cpp muss noch die Definition der main-Funktion 
korrigiert werden:
int
main(int, char* [])

Und in der system/src/cmsis/vectors_stm32f4xx.c müssen Zeilen 195-196 
auskommentiert/gelöscht werden.

Autor: Michael F. (michaelfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Es sollte auch nicht verschwiegen werden das es Frontents für den GDB
> gibt ..so wie DDD (Data Display Debugger) die da ein Stück weit Komfort
> ermöglichen.

Danke für die Info :-)

Ich hab mir jetzt einiges zum GDB und dem DDD angeschaut muss 
feststellen, dass das dann doch nicht meine Welt ist...

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Mit dem Makefile im Anhang gehts."


Ja super!
Besten Dank.

und ehrlich gesagt, darauf dass ethernetif_template.c gar nicht
compiliert werden soll, waere ich so schnell nicht gekommen.
hab den namen gar nicht wirklich zur kenntnis genommen...

Mal sehen, wie wir jetzt weiter kommen.

ich meld mich.....

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.