Title: Hilfe beim Flashen via JLink
Post by: dl8mby on 20. March 2016, 18:09:30
Hallo Forum,
hallo Andreas,
ich bin mit dem Aufbau meines UI Boards (V. 0.4) fertig,
und betreibe es nur mit den drei Spannungen (8, 5, 3.3 V)
und GND.
Da ich einen STM32F439 als MC verbaut habe, wollte ich erst
testen, ob dieser soweit funktioniert.
Ich kann den MC ansprechen und via JLink flashen, bin mir aber
noch nicht sicher, ob ich einen 407 bin-Image direkt an Adresse
0x08010000 schreiben kann.
Noch habe ich meine Umgebung nicht eingerichtet, dass ich eine
429/439 Ableger kompilieren kann.
Nun zu meiner Frage:
Läuft die Firmware auch, wenn sie die Komponenten auf dem RF
Board nicht via I2C ansprechen kann und falls ja, sehe ich dann
irgend eine Ausgabe am Display?
Falls dies nicht der Fall ist, muss ich mir aus dem vorhandenen
Code eine Sequenz harausbrechen, die die Anzeige initialisiert,
um mein UI-Board zu testen, oder gibt es bereits Firmwareteile,
die genau das machen?
Danke für Eure Antworten und Hilfe.
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 20. March 2016, 19:12:50
Hallo,
bezüglich der Komponenten: Ja, man sieht was, auch wenn der I2C Bus nicht funktioniert.
Aber eine Bedienung ist nur sehr zähflüssig, wg. der I2C Timeouts.
Versuch macht klug. Vorallem brauchst Du einen Bootloader, sonst geht garnichts.
Auch hier macht der Versuch klug.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 20. March 2016, 19:56:28
Hallo Danilo,
da bin ich mir eben nicht sicher, dass mit dem Bootloader.
Ich bin kein ARM Spezialist, und weiss noch nicht was für
Initialisierungen der Bootloader macht und ob überhaupt.
Meiner Meinung nach müsste ich nach dem Flashen nur
einen Sprung zur Startadresse machen (Vja Jlink
g 0x08010000) und der MC führt ab da den Code aus.
Habe aber noch nicht genug Übung mit dem JTAG Tool
und mache vielleicht noch irgendetwas verkehrt.
Jedenfalls kann ich des *.bin Firmware File an Adresse
0x08010000 schreiben und bekomme einen OK Status
zurück.
Ein Sprung an die besagte Adresse führt aber zu keiner
Display-Aktivität.
Aber ich habe je erst vor einigen Stunden angefangen die
FW in den MC zu laden.
Möglicherweise klappt es ja bald.
Vielleicht kann mir ja auch ein ARM-Kundiger aus dem
mikrocontroller Forum weiter helfen.
Danke für Deine Antwort.
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 20. March 2016, 20:56:14
Hi!
Der Chip bootet immer ab Adresse 0x08000000. Wenn Du eine Firmware ab 0x080100000 flashst, springt er ins Leere. Also entweder eine Firmware flashen, die ohne Bootloader funktioniert, oder eben vorher den Bootloader an Adresse 0x08000000.
vy 73 de Astralix |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 20. March 2016, 21:10:03
Hallo Astralix,
hallo OMs,
inwiefern ist sich die FW eines Bootloaders bewußt?
Ich dachte der Bootloader springt nach getaner Arbeit,
d.h. warten ob eine neue FW geflasht werden soll,
nach einem Timeout, wenn nichts geflasht wird, zur
Startadresse der main Funktion - weiter nichts.
Da wir kein OS im MC haben, dürfte der Bootloader keine
weitere Funktion haben.
Liege ich damit richtig, oder habe ich da noch eine
Verständnissproblem?
Danke für Eure Geduld und Hilfe.
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 20. March 2016, 21:53:15
Hallo Markus,
so einfach ist das nicht. Der Bootloader ist für erste Initialisierungen der HW schon zuständig. Insbesondere hat er einen vollständigen Satz von Interrupthandlern dabei.
Er lädt dann die Application, die dann wiederum ihre Interrupthandler-Tabelle lädt. Der Start ist übrigens nicht direkt bei 0x08000000 (sondern 0x08000004), vorher liegt die Stackpointeradresse. Analog bei 0x08010000, da geht es erst bei 0x08010004 los.
Wenn Du mehr wissen willst, sollest Du Dir den Source-Code vom MCHF anschauen und vorallem auch die entsprechende Doku von ST für den Prozessor, da werden die Abläufe mit ausreichender Ausführlichkeit geschildert.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 20. March 2016, 22:28:13
Hallo Danilo,
danke für Deine Erläuterungen zum Startvorgang.
Ich habe mir bis jetzt nur die make- , project- und
config-Files angesehen, um die Startadressen zu
ermitteln.
Ich werde mir die Tage den Code genauer ansehen
und hoffe daraus noch mehr Infos zu erfahren.
Vor allem muss ich mir erst die ARM-GCC Toolchain
installieren um Code für den STM32F4XX compilieren
und linken zu können.
Werde mich bestimmt noch öfter im Forum melden
und von meinem Fortschritt oder den Schwierigkeiten
berichten.
vy73
Markus
DL8MBY |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 25. March 2016, 20:40:41
Hallo OMs,
habe es nun geschafft unter Linux den MC via STLink
zu flashen und wollte es euch nicht vorenthalten.
Vielleicht hilft es ja jemandem weiter.
Dabei bin ich wie folgt vorgegangen:
P8 um einen Pin für Ground (Masse) erweitern.
Am besten vor dem Einlöten gleich eine 5polige
Pinleiste zuschneiden und Pin #5, für den auf
der UI-Platine kein Loch vorhanden ist wie ein
'L' umbiegen (siehe Bild).
An diesen Pin einen Fädeldraht anlöten und das
andere Ende an Masse von C59 anlöten.
Danach die Stiftleiste mit den verbleibenden vier
Pins in die dafür vorgesehenen Löcher von P8
stecken und anlöten.
Für die Programmierung wird ein STLink USB-Stick
benötigt.
Mittels des beiliegenden fünfpoligem Flachbandkabel
verbindet man den STLink mit dem Pinheader P8 wie
folgt.
P8: STLink:
===============
Pin5-GND Pin5-GND
Pin4-Clk Pin2-SWClk
Pin3-DIO Pin4-SWDIO
Pin2-RST Pin1-RST
HP8730W:/opt/STLink # st-flash write /home/markus/Afu/mcHF/bootloader.dfu 0x08000000
2016-03-25T20:20:46 INFO src/stlink-common.c: Loading device parameters....
2016-03-25T20:20:46 INFO src/stlink-common.c: Device connected is: F42x and F43x device, id 0x10076419
2016-03-25T20:20:46 INFO src/stlink-common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2016-03-25T20:20:46 INFO src/stlink-common.c: Attempting to write 23201 (0x5aa1) bytes to stm32 address: 134217728 (0x8000000)
2016-03-25T20:20:46 WARN src/stlink-common.c: unaligned len 0x5aa1 -- padding with zero
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erasedEraseFlash - Sector:0x1 Size:0x4000
Flash page at addr: 0x08004000 erased
2016-03-25T20:20:47 INFO src/stlink-common.c: Finished erasing 2 pages of 16384 (0x4000) bytes
2016-03-25T20:20:47 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-03-25T20:20:47 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 23202
2016-03-25T20:20:48 INFO src/stlink-common.c: Starting verification of write complete
2016-03-25T20:20:48 INFO src/stlink-common.c: Flash written and verified! jolly good!
HP8730W:/opt/STLink # st-flash write /home/markus/Afu/mcHF/mchf-20160325.bin 0x08010000
2016-03-25T20:20:58 INFO src/stlink-common.c: Loading device parameters....
2016-03-25T20:20:58 INFO src/stlink-common.c: Device connected is: F42x and F43x device, id 0x10076419
2016-03-25T20:20:58 INFO src/stlink-common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2016-03-25T20:20:58 INFO src/stlink-common.c: Attempting to write 245356 (0x3be6c) bytes to stm32 address: 134283264 (0x8010000)
EraseFlash - Sector:0x4 Size:0x10000
Flash page at addr: 0x08010000 erasedEraseFlash - Sector:0x5 Size:0x20000
Flash page at addr: 0x08020000 erasedEraseFlash - Sector:0x6 Size:0x20000
Flash page at addr: 0x08040000 erased
2016-03-25T20:21:01 INFO src/stlink-common.c: Finished erasing 3 pages of 131072 (0x20000) bytes
2016-03-25T20:21:01 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-03-25T20:21:01 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 15980
2016-03-25T20:21:07 INFO src/stlink-common.c: Starting verification of write complete
2016-03-25T20:21:13 INFO src/stlink-common.c: Flash written and verified! jolly good!
Da ich noch nicht die RF-Platine bestückt habe, habe ich mir als
Hilfsmittel auf einer Lochraster-Platine eine kleine Spannungs-
erzeugung für die 3.3V, 5V und 8V gemacht.
Diese Spannungen und GND gehen auf den Pinheader P1
von Pin 25-30, siehe Bild #2.
vy73
Markus
DL8MBY |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 25. March 2016, 20:41:47
Irgendwie sind die Bilder nicht mitgegangen - Sorry!
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 25. March 2016, 20:42:49
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 25. March 2016, 21:41:29
Hallo OMs,
ich habe es nun geschafft eine Anzeige am Display
zu bekommen.
Ich betreibe mein Display im 16-Bit Parrallel-Mode
und habe die fünf Verbindungen für das Toutch-Pad
von R33-R35 und PA9 (Debug Print am P8/1) und
von P1/7 (DAC0) gelegt.
Mir ist nur nicht ganz klar, ob der Parallel-Mode und
die Touch-Aktivierung zusammenspielen oder nur bei
Verwendung der SPI Kommunikation zum Display der
Touch-Mode funktioniert.
Da ja meine RF-Komponenten noch nicht erreichbar sind,
kann ich am UI-Boad nicht viel mit Touch machen - richtig?
Danke für Euren Input
vy73
Markus
DL8MBY
. |
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 26. March 2016, 06:56:53
Alle Touch-Funktionen gehen auch ohne rf-Board. Nur seeehr, seeehr träge (i2c-Timeouts...)
Und Touchscreen-Nutzung funktioniert sowohl im SPI als auch im Parallelmode des LCD.
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 26. March 2016, 11:44:19
Hallo Andreas,
hallo OMs,
danke für die Infos.
Somit ist jetzt bestätigt, dass ein STM32F439IV ohne Anpassung
mit der 407 Firmware läuft.
Da ich meine Toolchain mit Eclipse unter Linux noch nicht zum
Laufen gebracht habe, ich verwende einen gcc Ver. 4.8.5, kann
ich noch nicht den mchf git C-Code compilieren.
Aber immerhin konnte ich den Sourcen genug Informationen
entlocken, um den Bootloader und die FW via STLink zu flashen.
Mittels JLink kann ich die FW auch Schrittweise ausführen, wobei
Mangels gdb, nur eine ARM-ASM Syntax angezeigt wird.
Ich hoffe, wenn die Toolchain unter Eclipse läuft, kann ich die
Source auch direkt debuggen.
Was sind die Plugins, die Ihr dafür einsetzt.
Ich habe je bereits angekündigt, dass ich den Si570 durch einen
LMK61E2 (low jitter) ersetzen möchte.
Da ich den Platinensatz zweimal habe, will ich die erste Version
so aufbauen, wie Ihr im OV und dann die zweite Version, wenn
ich mit dem Aufbau vertraut bin, mit den Modifikationen bis 70MHz,
unter Verwendung der Potato Chips.
Soweit von meiner Seite zum mchf.
Euch schöne Ostern
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 26. March 2016, 12:28:34
Hallo Markus,
was hast Du für ein Linux-System?
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 26. March 2016, 12:59:42
Hallo Andreas,
ein OpenSuse 13.1
uname -r liefert:
Linux HP8730W 3.11.10-34-desktop #1 SMP PREEMPT Wed Jan 20 14:13:45 UTC 2016 (1e76e80) x86_64 x86_64 x86_64 GNU/Linux
markus@HP8730W:/opt/cross> ls -l
insgesamt 24
drwxr-xr-x 10 root root 4096 21. Mär 21:13 arm-linux-gnueabi
drwxr-xr-x 2 root root 4096 23. Feb 19:05 bin
drwxr-xr-x 2 root root 4096 10. Feb 00:42 include
drwxr-xr-x 3 root root 4096 10. Feb 00:42 lib
drwxr-xr-x 3 root root 4096 10. Feb 00:42 libexec
drwxr-xr-x 5 root root 4096 10. Feb 00:42 share
markus@HP8730W:/opt/cross> ls -l ./bin
insgesamt 87032
-rwxr-xr-x 1 root root 4196845 9. Feb 22:24 arm-linux-gnueabi-addr2line
-rwxr-xr-x 2 root root 4360980 9. Feb 22:24 arm-linux-gnueabi-ar
-rwxr-xr-x 2 root root 6328675 9. Feb 22:24 arm-linux-gnueabi-as
-rwxr-xr-x 2 root root 3288118 10. Feb 00:42 arm-linux-gnueabi-c++
-rwxr-xr-x 1 root root 4150272 9. Feb 22:24 arm-linux-gnueabi-c++filt
-rwxr-xr-x 1 root root 3284424 10. Feb 00:42 arm-linux-gnueabi-cpp
-rwxr-xr-x 1 root root 99885 9. Feb 22:24 arm-linux-gnueabi-elfedit
-rwxr-xr-x 2 root root 3288118 10. Feb 00:42 arm-linux-gnueabi-g++
-rwxr-xr-x 2 root root 3281948 10. Feb 00:42 arm-linux-gnueabi-gcc
-rwxr-xr-x 2 root root 3281948 10. Feb 00:42 arm-linux-gnueabi-gcc-4.9.3
-rwxr-xr-x 1 root root 138015 10. Feb 00:42 arm-linux-gnueabi-gcc-ar
-rwxr-xr-x 1 root root 137967 10. Feb 00:42 arm-linux-gnueabi-gcc-nm
-rwxr-xr-x 1 root root 137971 10. Feb 00:42 arm-linux-gnueabi-gcc-ranlib
-rwxr-xr-x 1 root root 2305801 10. Feb 00:42 arm-linux-gnueabi-gcov
-rwxr-xr-x 1 root root 4724952 9. Feb 22:24 arm-linux-gnueabi-gprof
-rwxr-xr-x 4 root root 5755598 9. Feb 22:24 arm-linux-gnueabi-ld
-rwxr-xr-x 4 root root 5755598 9. Feb 22:24 arm-linux-gnueabi-ld.bfd
-rwxr-xr-x 2 root root 4229673 9. Feb 22:24 arm-linux-gnueabi-nm
-rwxr-xr-x 2 root root 5167438 9. Feb 22:24 arm-linux-gnueabi-objcopy
-rwxr-xr-x 2 root root 5945619 9. Feb 22:24 arm-linux-gnueabi-objdump
-rwxr-xr-x 2 root root 4360979 9. Feb 22:24 arm-linux-gnueabi-ranlib
-rwxr-xr-x 1 root root 1314289 9. Feb 22:24 arm-linux-gnueabi-readelf
-rwxr-xr-x 1 root root 4186221 9. Feb 22:24 arm-linux-gnueabi-size
-rwxr-xr-x 1 root root 4185874 9. Feb 22:24 arm-linux-gnueabi-strings
-rwxr-xr-x 2 root root 5167469 9. Feb 22:24 arm-linux-gnueabi-strip
markus@HP8730W:/opt/cross> arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/cross/libexec/gcc/arm-linux-gnueabi/4.9.3/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../configure --prefix=/opt/cross --enable-bootstrap=no --build=x86_64-suse-linux --target=arm-linux-gnueabi --enable-languages=c,c++ --with-float=soft --disable-libmudflap --disable-multilib --with-cpu=arm7tdmi --with-float=soft
Thread model: posix
gcc version 4.9.3 (GCC)
Als
Eclipse SDK
Version: Mars.2 (4.5.2)
Build id: M20160212-1500
Wie Du siehst, habe ich mittlerweile die 4.9.3 Version vom ARM-GCC
Jetzt muss ich noch herausfinden, wo ich die Settings für Eclipse
richtig eintrage, dass der gcc verwendet wird.
Danke für Deine Mühe!
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 26. March 2016, 13:03:37
Nachtrag
zu meinen installierten Eclipse Plugins.
Siehe Bild.
Markus
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 26. March 2016, 13:07:06
und noch was,
das makefile vom mchf habe ich wie folgt angepasst:
#CC=arm-none-eabi-gcc
CC=arm-linux-gnueabi-gcc
#OBJCOPY=arm-none-eabi-objcopy
OBJCOPY=arm-linux-gnueabi-objcopy
Aber es scheint noch was zu fehlen.
Markus |
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 26. March 2016, 13:18:41
SuSE war schon immer bekannt für Extrawürste - ich kann mich noch gut erinnern :) Und weil das partout nicht enden wollte, habe ich SuSE 2004 endgültig verlassen...
Dass sogar die Compiler anders benannt werden, ist wirklich erstaunlich!
Poste doch mal die Ausgabe eines Compilerlaufes - dann kann man mehr sehen.
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 26. March 2016, 13:32:37
Hallo Andreas,
ich habe noch unter Eclipse
include und gcc semantic errors.
Beides hat wohl noch mit einer fehlerhaften
Einbindung der GNU-ARM-Toolchain in Eclipse
zu tun.
Ein Index Rebuild über alle Files des mchf-Projekt-
Verzeichnisses läuft hingegen ohne Probleme durch.
Da ich mich nun mit der XYL auf den Weg zu der
Verwandtschaft mach, kann ich wieder erst nach
Ostern weiter testen.
Danke für Deine Hilfe und Mühe.
Alles braucht seine Zeit.
Sollte ich weiterhin mit der Programmierumgebung
Probleme haben, werde ich mich erst an den Aufbau
der RF-Platine machen.
Man dar sich nicht zu sehr an einer Stelle verbeißen,
sondern muss auch mal Abstand von der Sache nehmen
um wieder etwas Durchblick zu bekommen ;-)
vy73
Markus
DL8MBY
PS.: Ich arbeite hauptsächlich mit Suse und RedHat im QRL.
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 26. March 2016, 13:47:48
Euch auchschöne Ostertage!
Wenn Du mit SuSE im QRL arbeitest, wirst Du die Probleme mit Sicherheit schnell finden können.Es wird nichts Großes sein - nur eben inkompatibel mit der "großen Debian-Welt" ::)
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 29. March 2016, 14:42:17
Hallo Andreas,
hallo OM's,
heute ist es mir gelungen meine ARM GCC Toolchain
zum Laufen zu bringen.
Die neuste FW konnte ich sofort beim ersten Durchlauf
compilieren.
Natürlich waren im Makefile Anpassungen am meine
Programmier-Umgebung erforderlich.
PREFIX = ~/Programming/ARM/ToolChain/gcc-arm-none-eabi-4_8
GCC_LIB_VERSION = 4.8.4
Danach lief das make Kommand problemlos durch.
Dabei habe ich noch keine Anpassungen an die verbaute MCU
vo Type 439 gemacht, d.h. Anpassung an den größeren Flash-
und RAM-Speicher.
markus@HP8730W:~/Programming/eclipse/workspace/mchf-eclipse> make
[CC] main.o
[CC] usb/usbh/core/src/usbh_hcs.o
[CC] usb/usbh/core/src/usbh_core.o
[CC] usb/usbh/core/src/usbh_ioreq.o
[CC] usb/usbh/core/src/usbh_stdreq.o
[CC] usb/usbh/class/HID/src/usbh_hid_keybd.o
[CC] usb/usbh/class/HID/src/usbh_hid_core.o
[CC] usb/usbh/class/HID/src/usbh_hid_mouse.o
[CC] usb/otg/src/usb_core.o
[CC] usb/otg/src/usb_hcd_int.o
[CC] usb/otg/src/usb_dcd.o
[CC] usb/otg/src/usb_dcd_int.o
[CC] usb/otg/src/usb_otg.o
[CC] usb/otg/src/usb_hcd.o
[CC] usb/usbd/core/src/usbd_core.o
[CC] usb/usbd/core/src/usbd_ioreq.o
[CC] usb/usbd/core/src/usbd_req.o
[CC] usb/usbd/class/audio/src/usbd_audio_core.o
[CC] usb/usbd/class/audio/src/usbd_audio_out_if.o
[CC] usb/usbd/class/cdc/src/usbd_cdc_core.o
[CC] cmsis_lib/source/stm32f4xx_usart.o
[CC] cmsis_lib/source/misc.o
[CC] cmsis_lib/source/stm32f4xx_pwr.o
[CC] cmsis_lib/source/stm32f4xx_syscfg.o
[CC] cmsis_lib/source/stm32f4xx_gpio.o
[CC] cmsis_lib/source/stm32f4xx_wwdg.o
[CC] cmsis_lib/source/stm32f4xx_adc.o
[CC] cmsis_lib/source/stm32f4xx_exti.o
[CC] cmsis_lib/source/stm32f4xx_i2c.o
[CC] cmsis_lib/source/stm32f4xx_dac.o
[CC] cmsis_lib/source/stm32f4xx_fsmc.o
[CC] cmsis_lib/source/stm32f4xx_flash.o
[CC] cmsis_lib/source/stm32f4xx_spi.o
[CC] cmsis_lib/source/stm32f4xx_dma.o
[CC] cmsis_lib/source/stm32f4xx_rtc.o
[CC] cmsis_lib/source/stm32f4xx_tim.o
[CC] cmsis_lib/source/stm32f4xx_rcc.o
[CC] drivers/cat/cat_driver.o
[CC] drivers/cat/usb/usbd_usr.o
[CC] drivers/cat/usb/usbd_bsp.o
[CC] drivers/cat/usb/usbd_desc.o
[CC] drivers/cat/usb/usbd_cdc_vcp.o
[CC] drivers/audio/cw/cw_gen.o
[CC] drivers/audio/audio_driver.o
[CC] drivers/audio/codec/codec.o
[CC] drivers/audio/codec/i2s.o
[CC] drivers/audio/softdds/softdds.o
[CC] drivers/keyboard/usb/usbh_bsp.o
[CC] drivers/keyboard/usb/usbh_usr.o
[CC] drivers/keyboard/keyb_driver.o
[CC] drivers/ui/oscillator/ui_si570.o
[CC] drivers/ui/ui_menu.o
[CC] drivers/ui/ui_driver.o
[CC] drivers/ui/encoder/ui_rotary.o
[CC] drivers/ui/lcd/ui_lcd_hy28.o
[CC] drivers/ui/lcd/ui_lcd_hy28_fonts.o
[CC] hardware/mchf_hw_i2c2.o
[CC] hardware/mchf_hw_i2c.o
[CC] hardware/mchf_board.o
[CC] cmsis_boot/system_stm32f4xx.o
[CC] cmsis_boot/startup/startup_stm32f4xx.o
[CC] syscalls/syscalls.o
[CC] misc/v_eprom/eeprom.o
[CC] stdio/printf.o
[LD] mchf.elf
[OBJC] mchf.bin
text data bss dec hex filename
239384 1708 94400 335492 51e84 mchf.elf
copy from `mchf.elf' [elf32-littlearm] to `mchf.bin' [binary]
Andreas, kannst Du mir bitte sagen, was es zu bedeuten hat, wenn
beim Powerdown die Konfiguration gesichert wird, aber das Programm
die MCU nicht ausschaltet.
Liegt es daran, dass ich nicht über die RF-Platine, sondern direkt
über ein NT die Versorgung bereitstelle?
Siehe Anhang.
Danke!
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 29. March 2016, 15:06:48
Richtig!
Das Abschalten geschieht dadurch,dass die MCU den LM2941 auf der RF-Platine abschaltet :)
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 30. March 2016, 19:48:18
Hallo!
Ich bin zwar noch primär in den Prüfungsvorbereitungen, aber ich habe hier auch schon lokal mal die letzten git HEAD Revisionen mit compiliert und geflasht. Bin soweit sehr zufrieden. Ich würde gerne ein paar Kleinigkeiten am Makefile ändern, benötige aber jemanden der nicht Linux als Basis verwendet, um etwas zu prüfen.
Zur Info:
Der gcc 4.8 arbeitet noch nicht so 100% effizient mit dem M4F, der gcc 4.9 hat einige Bugs, die zu Linker- und Dateisystem-Problemen führen. Ich arbeite daher mit dem gcc 5.2. (https://launchpad.net/gcc-arm-embedded/+download)
Da ich aber mit zig verschiedenen Systemen arbeite und privat und beruflich auch etliche unterschiedliche Stände dieser Systeme pflegen muss, habe ich nicht den üblichen arm-none-gnueabi-gcc irgendwo unter /usr/share/lib/.... installiert
Ich bevorzuge die u-boot oder Linux Kernel Methode
export CROSS_COMPILE=/bla/blubb/arm-x-y-
Damit kann man schnell und einfach zwischen beliebigen Compilern umschalten.
Im Makefile sind hart kodierte Links auf die Bibliotheken des Compilers gesetzt, das ist aber nicht nötig, denn der Compiler kennt die Position dieser Bibliotheken relativ zu seiner eigenen Position.
D.h. wenn man unter obigem Link das .tar.bz herunter lädt, es dann in ~/Download/gcc entpackt und dann das Verzeichnis gcc-arm-none-eabi-5_2-2015q4 als root (sudo) komplett nach /opt/ verschiebt, dann kann man sich darauf verlassen, dass der compiler seine Includes und Bibliotheken korrekt findet.
Dazu kann man den compiler mit der option -print-search-dirs aufrufen:
/opt/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc -print-search-dirs
install: /opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/
programs: =/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/arm-none-eabi/5.2.1/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/
libraries: =/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/lib/arm-none-eabi/5.2.1/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/lib/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../arm-none-eabi/lib/arm-none-eabi/5.2.1/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../arm-none-eabi/lib/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../arm-none-eabi/usr/lib/arm-none-eabi/5.2.1/:/opt/gcc-arm-none-eabi-5_2-2015q4/bin/../arm-none-eabi/usr/lib/
Mich würde sehr interessieren, ob dies auch unter Windows so funktioniert. Also oben das Windows kompatible ZIP herunter laden, es entpacken und an einen genehmen Ort verschieben. Dann auf der DOS Eingabe mal aus einem beliebigen anderen Verzeichnis heraus den Pfad mit der EXE vom gcc aufrufen und -print-search-dirs anhängen.
Der Suchpfad sollte korrekt zuerst auf die mitgebrachten Libraries zeigen.
Ist das der Fall, kann das Makefile sehr vereinfacht werden. Dann würde ich CROSS_COMPILE mit gcc-arm-none- vorbelegen, aber das kann dann jeder leicht selber überschreiben.
vy 73 de Astralix |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 30. March 2016, 20:16:12
Hallo Astralix,
"c:\Program Files (x86)\GNU Tools ARM Embedded\5.2 2015q4\bin\arm-none-eabi-gcc.exe" -print-search-dirs liefert:
install: c:\program files (x86)\gnu tools arm embedded\5.2 2015q4\bin\../lib/gcc/arm-none-eabi/5.2.1/
programs: =c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/arm-none-eabi/5.2.1/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/
libraries: =c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/lib/arm-none-eabi/5.2.1/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/lib/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../arm-none-eabi/lib/arm-none-eabi/5.2.1/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../arm-none-eabi/lib/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../arm-none-eabi/usr/lib/arm-none-eabi/5.2.1/;c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../arm-none-eabi/usr/lib/
73
Danilo |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 30. March 2016, 20:35:02
Hallo Astralix,
danke für die nützlichen Erläuterungen zu der Toolchain Installation.
Kannst Du auch erläutern, falls bekannt, wie man Eclipse konfiguriert,
dass es nur das make Kommando zur Compilierung verwendet, ohne
dass man sich um die ganzen Einstellungen (Compiler/Include-Pfade/Libs)
an den vielen verschiedenen Stellen kümmern muss, wie es z.B.
beim QT-Creator der Fall ist.
Danke!
Markus
DL8MBY |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 30. March 2016, 20:36:12
Hallo Markus,
danke für den schnellen Test, dann kann ich das Makefile ja sehr einfach überarbeiten, denn die relativen Pfade stimmen scheinbar.
vy73 de Astralix |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 30. March 2016, 20:41:37
Hallo Astralix,
der Dank gebührt Danilo
Markus ;-)
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 30. March 2016, 20:44:40
Hallo Astralix,
hättest Du für mich eventuell ein stm32_flash.ld Linker File für einen
439VI MC.
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 30. March 2016, 21:38:04
Ups!
Also danke an Danilo und Markus :)
Linker File für den 439VI? Muss ich mal gerade das Datenblatt zupfen und mit dem 407 von mir vergleichen. Dauert ne Sekunde... |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 30. March 2016, 22:28:27
http://pastebin.com/1Gna2YWQ
Hier habe ich mal eine Rohfassung meines Makefiles gepostet. Alten Makefile sichern, meinen drüber pasten und probieren.
1.
Unter Linux kann man vorher per
export CROSS_COMPILE=/opt/mein-arm-compiler/bin/arm-none-eabi-
einen anderen Compiler selektieren. Danach nutzt jeder Aufruf von Make eben diesen. Unter Windows geht das bestimmt auch mit set CROSS_COMPILE="Pfad/bla/arm-none-eabi-" oder so ähnlich (bin da zu lange raus)
2.
Am Anfang vom Makefile kann man ggf. Änderungen machen, wenn man eine andere CPU verwendet.
MCU = STM32F407VG
FLASH = 448K
SRAM = 128K
dafür durch die passenden eigenen Daten ersetzen. Beachtet bitte, dass der Bootloader 64k FLASH benötigt, die Ihr hier abziehen müsst.
Windows-User bitte mal im Makefile die Sektion "ifdef SystemRoot" suchen und da mal vor die $(CROSS_COMPILE) ebenfalls das @ einfügen, wie in der Linux Abteilung darunter. Ich bin sicher, dass das @ eine Make Funktion ist und überflüssigen Output beim Compilieren verhindert. Aber ich möchte das nicht einfach so voraussetzen, weil ich beim Commit an Andreas nicht alle Windows User ausknipsen möchte :)
Markus, ich denke, wenn Du die Daten im Makefile auf
MCU = STM32F439VI
FLASH = 1984K
SRAM = 256K
änderst, kann es schon gehen. Möglicherweise mussst Du 64kB SRAM abziehen (SRAM=192K), weil dieses das CCM ist und anders adressiert wird.
Edit (Es ist schon spät...)
http://pastebin.com/VM5Sq793
Hier das passende Linker-Script
Ebenfalls arm-gcc-link.ld weg kopieren und durch obigen Text ersetzen
Grüße |
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 31. March 2016, 07:18:53
Ich finde die Diskussion sehr interessant und kann die Beweggründe für die Ansätze verstehen.
Allerdings bin ich mir fast sicher, dass bei einer größeren Vielfalt von verwendeten toolchains und Umgebungen wir uns viel öfter an weiteren Baustellen verzetteln, die erst durch diese Öffnung entstanden sind. Da verwenden einige Programmer Syntax, die erst im C99 Mode läuft (und der ist bei der 4.9 fehlerhaft) und andere Programmer, die mit der 4.9 arbeiten, müssen as entweder jedesmal umstricken oder wissen viellleicht gar nicht, was ein C99 Mode ist (zum Beispiel).
Wir müssen davon ausgehen, dass es doch einige (auch Linux!!) User gibt, die mit Umgebungsvariablen, mehreren unterschiedlichen Toolchains auf einem Gerät etc. nicht bewandert sind und damit auch nicht klarkommen.
Deswegen haben wir uns,als ich nicht mehr "Alleinunterhalter" war, auf eine toolchain geeinigt, die aus den Repos aller namhafter Distributionen zu ziehen ist und auch für Windows verfügbar ist - und das ist die 4.9. Erstellter Code muss per se unter der 4.9 zu bauen sein!
Ich sehe zum jetzigen Zeitpunkt auch keine Notwendigkeit, das wieder umzuwerfen. Die Nicklichkeiten des 4.9, die uns hier stören, sind bekannt und können leicht umgangen werden - wir haben keine wirkliche Einschränkung durch die Verwendung des 4.9
Daher würde ich vorschlagen, dass das Makefile derart umgebaut wird, dass die Funktionalität kompatibel mit dem jetzigen bleiben muss. Bedeutet: Wenn die Umgebungsvariable nicht vorher vom User gesetzt wurde, wird der auf dem System default vorhandene Compiler benutzt. In dem Fall wäre das neue Makefile ein "Goodie" für alle, die noch weiter hinaus wollen, aber führt nicht dazu, dass diejenigen, die via yum oder apt eine toolchain installiert haben und mehr auch nicht können, vor verschlossenen Türen stehen.
vy73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 07:47:03
Danke!
Werde es heute Abend versuchen.
Markus
DL8MBY |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 07:49:00
Hallo Andreas,
hast Du Dich nur verschrieben oder ist es wirklich 4.9, denn
laut Makefile steht überall als Version 4.8, oder bringe ich da
was durcheinander.
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 31. March 2016, 07:53:57
Es ist 4.9. Aber mir ist nicht bekannt, dass es da Probleme mit der 4.8 gibt (aber sehr wohl welche mit der 5.2)
@Astralix
Mit deinem Makefile kann ich nicht bauen.Hier die Ausgabe:
[CC] usb/otg/src/usb_otg.o
usb/otg/src/usb_otg.c: In function 'USB_OTG_HandleConnectorIDStatusChange_ISR':
usb/otg/src/usb_otg.c:285:9: error: 'USB_OTG_CORE_HANDLE' has no member named 'otg'
pdev->otg.OTG_State = B_PERIPHERAL;
^
usb/otg/src/usb_otg.c:292:9: error: 'USB_OTG_CORE_HANDLE' has no member named 'otg'
pdev->otg.OTG_State = A_HOST;
^
usb/otg/src/usb_otg.c: In function 'USB_OTG_GetCurrentState':
usb/otg/src/usb_otg.c:402:14: error: 'USB_OTG_CORE_HANDLE' has no member named 'otg'
return pdev->otg.OTG_State;
^
usb/otg/src/usb_otg.c:403:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
Makefile:177: recipe for target 'usb/otg/src/usb_otg.o' failed
make: *** [usb/otg/src/usb_otg.o] Error 1
|
|
vy 73 |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 08:05:43
Hallo Andreas,
dan werde ich mal mir auch die 4.9 (bei mir 4.9.3) als Toolchain
installieren und damit weiter arbeiten.
Hast Du eventuell Erfahrung mit OpenSTM32 für Linux oder der
CooCox IDE unter wine auf Linux?
Mit der reinen Eclipse IDE komme ich noch nicht so zu recht.
Wahrscheinlich mangels entsprechender Erfahrung.
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 31. March 2016, 08:16:47
Ich arbeite "rein auf der Konsole" - keine IDE. Den CoIDE habe ich anfangs (weil es noch kein Makefile gab) unter Windows probiert und ich mag ihn überhaupt nicht.
Es ist sinnvoll, wenn Du Dich in Eclipse einarbeitest. Das habe ich auch getan um die "IDE"ler auch zufriedenzustellen. Eclipse ist leistungsfähig und es gibt auch eine Debuggingschnittstelle zum STLINK V2 - sehr zu empfehlen.
Ich habe auch ie 4.9.3...
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 08:33:18
Hallo Andreas,
ich bin auch mehr der CLI Fan, wobei ich durchaus eine IDE
schätze, wenn ich mit fremden Code zu tun habe und dieser vor
allem über viele Files verteilt ist, wie bei diesem Projekt.
Was mich bei der Eclipse-Installation nervt, wahrscheinlich
Mangels Erfahrung, ist die Tatsache, dass trotz bestehendem
Makefile, überall Konfigurationswerte mit Pfaben und den
Compiler-Tools einzutragen sind.
Weist Du, ob man das Makefile irgendwie importieren kann, um
diese Werte in der Konfiguration von Eclipse automatisch gesetzt
zu bekommen?
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 31. March 2016, 10:50:03
Du brauchst an diesen Einstellungen NICHTS zu schrauben -sie sind in der im pull enthaltenen Struktur bereits alle enthalten!
Du musst das Projekt nur in Eclipse "importieren" (NICHT laden!!) - dann stimmt alles automatisch.
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 10:57:56
Hallo Andreas,
ich hoffe nicht mit meiner Fragerei zu nerven,
aber woher weiss die Eclipse IDE über meine
Installierte ToolChain bescheid.
Es müssen wohl Umgebungsvariablen richtig desetzt sein,
das gcc und make gefunden werden.
Würde das bedeuten, dass ein Import der Projektsource aus
dem Git-Repository in Eclipse automatisch anhand der hinterlegten
Einstellungen im Git-Verzeichnis die richtige Konfiguration setzt.
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 31. March 2016, 11:40:02
Hallo Markus,
schau Dir bitte mal die Infos im Wiki an https://gnuarmeclipse.github.io/ (https://github.com/df8oe/mchf-github/wiki/Setting-up-Firmware-Development-Software]https://github.com/df8oe/mchf-github/wiki/Setting-up-Firmware-Development-Software[/url]. Dort gibt es die Infos, wie die Umgebung einzurichten ist. Für Eclipse wird hier explizit auf die Seiten des GNU ARM Eclipse Projects verwiesen. [url=https://gnuarmeclipse.github.io/) Dort sind alle Schritte zur ordentlichen Einrichtung beschrieben.
Ich habe diese Anleitung 2x (auf verschiedenen Maschinen) durchlaufen und es hat prima funktioniert.
Bei Linux ist die größte Herausforderung, dass die verschiedenen Distributionen unterschiedlich funktionieren. Das Problem wird bei der Anleitung dadurch gelöst, dass hier binäre Dateien (oder Source zum selber compilieren bereitgestellt wird). Das muss man allerdings akzeptieren. Ist nicht jedem recht, kann ich auch verstehen, aber dann ist es auch sehr schwer zu helfen, ohne selbst genau die gleiche Umgebung zu haben.
Bezüglich gcc 4.9 vs. 5.2: Unter Windows gibt es mit gcc 5.2 mit dem aktuellen Build des gccs von der GCC ARM Embedded jedenfalls absolut keine mir bekannten Probleme in Verbindung mit dem mcHF. Und dementsprechend ist das auch für Linux zu erwarten, denn wenn Cross-Compiler Chains aus den gleichen (!) Sourcen gebaut werden, verhalten sie sich in aller Regel auf allen Hostmaschine gleich, wenn es ums kompilieren geht, da die Cross-Umgebung (Header, Libraries etc.) ja identisch ist. Ein gcc 5.2 der von Suse gebaut wurde muss sich nicht wie der Ubuntu oder Debian gcc verhalten, da hier oft noch Distributionspezifsche patches eingespielt werden oder eben ein leicht anderer Softwarestand (minor version).
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 31. March 2016, 11:53:40
Hallo Danilo,
ich kann bestätigen dass Eclipse auch bei mir auf unterschiedlichen Maschinen mit verschiedenen Distris (nicht alle Debian-basiert) einwandfrei gelaufen ist.
Bezüglich der Toolchain möchte ich aber doch, dass die Toolchain, die in "Debian stable" als neuestes zu haben ist, die Basis bilden sollte, auf der sich der Code bauen lassen muss. Die Systempflege bei nicht in das Paketmanagement eingebundenen Toolchains halte ich für die Masse der User nicht für machbar.
Hier gibt es Infos über die verfügbaren Versionen für Debian:
https://packages.debian.org/jessie/gcc-arm-none-eabi (https://packages.debian.org/jessie/gcc-arm-none-eabi)
Wenn man auf einem Debian-System via Eclipse das Projekt importiert, klappt alles out-of-the-box. Das dürfte auch mit allen Forks so sein.
Sollte es Distributionen geben, deren Pakete so schlecht konfiguriert sind, dass die Variablen nicht oder falsch gesetzt sind, dann ist das entweder dem Benutzer vorher schon bekannt gewesen dass er bei seiner speziellen Distri immer nochmal Hand anlegen muss wo andere schon arbeiten (dann kennt er das Problem ja bereits...) oder es wird ihm an dieser Stelle bewusst und er kann sich jetzt Gedanken machen ob er das noch öfter erleben will oder einfach flexibel ist und sich in der Welt der anderen Distris umschaut :)
Man könnte natürlich eine Live-CD basteln wo eine komplette Entwicklungsumgebung schon drauf ist und die das Ergebnis stets auf einem USB-Stick speicherbar macht :) Das ist dann aber wohl doch mit Kanonen auf Spatzen schießen...
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 12:04:49
Danke Andreas,
für die ausführlichen Hinweise und Links.
Werde heute Abend weiter konfigurieren, und installieren.
Wobei im Augenblick ich auf der CLI Ebene erfolgreich
den Code bauen kann und auch das Flashen klappt jetzt
prima.
Wo ich noch dran bin, ist das Einrichten der besonderen
Linker Skripte für meine MC Architektur, den 439-Typen.
Aber da Du für konstante Verhältnisse wirbst, will ich dieses
Forum nicht zu sehr damit behelligen.
Ich bin vom Mainsteam bewusst abgewichen, da ich in den
diversen Foren ja schon Anzeichen für eine Obergrenze des
Codes festgestellt habe, die den 405/407 Chips früher oder
später zusetzen wird.
Zwar stimmt es, dass durch Optimierungen im Code, die jetzt
noch nicht so im Fordergrund stehen, die binäre Image Größe
noch reduziert werden wird, aber dieser Vorgang hat auch seine
Grenze. Mich hat auch der onchip DSP angesprochen, der auch
noch viel Potential bei dem /427/429/437439 MC bietet..
Zudem ist die GUI-Platine mit dem bestehendem Code noch für
viele andere Frontends nach dem DC I/Q SDR prinzip einsetzbar.
Man hat damit neben den eigentlichen mchf noch weitere Möglichkeiten
in unserem Hobby.
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 31. March 2016, 14:00:36
Ich denke die Geschichte mit der Anpassung des Makefiles ist nicht problematisch. Und wenn man das mit einer Umgebunsvariablen macht (die Du bei dir per Autostart setzt) dann kann es soag kompatibel mit dem "alten" sein.
vy73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 14:40:39
Hallo Andraes,
bei meiner Suche nach Infos zu dem STM324xx
bin ich auf den folgenden Link zum Thema CCM gestoßen.
http://sigalrm.blogspot.de/2013/12/using-ccm-memory-on-stm32.html
Dort ist erklärt, wie man Funktionen/Variablen/Arrays in den 64kB
großen RAM vor aufruf der main Funktion transferieren kann,
um auf diese Daten sehr schnell zuzugreifen.
Der CCM ( ein schneller Speicher, der direkt an der CPU ohne
Busmatrix hängt ) ist für Tabellen (LUT's) predisteniert.
Vielleicht bringt das Euch auf neue Ideen, falls nicht schon bekannt.
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 31. March 2016, 15:17:37
Da liegt seit kurzem der Puffer für den Wasserfall / das Scope :)
Aber trotzdem danke für den Link!
vy73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 31. March 2016, 18:36:06
Hallo Markus,
ich genau diesen Artikel genutzt beim Umbau auf die Nutzung des CCM.
BTW, hast Du schon mal ein "normales" Image und Bootloader reingeflasht?
Die Memorymaps sind ja kompatibel. D.h. fürs erste würde auch das normaler Linkerscript reichen (natürlich gibt es dann keinen extra RAM).
Bzw, funktioniert bei Dir schon was?
Würde mir evtl. auch einen 439 aufs "nächste" UI Board packen.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 20:13:16
Hallo Danilo,
zuerst habe ich mit den Projekt *.ld Files gearbeitet,
was auch sofort geklappt hat.
Heute habe ich nach einigen Vorschlägen aus dem
mikrocontroller Foum eigene Linkerfiles benützt.
Wie kann ich in diesem Forum mehrere Anhänge
an einen Beitrag dranhängen?
Ich schaffe es nicht!
Markus
|
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 20:13:57
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 20:14:20
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 20:15:48
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 20:25:07
Hallo Andreas,
hallo Forum,
wie muss ich Eclipse einrichren (Addon), damit ich unter dem
Menu Project ein Github-Project importieren kann.
Im Augenblick finde ich keine Stelle, wo ich einen Project-
Import machen kann.
Markus
DL8MBY |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 31. March 2016, 20:29:22
Habe es gefunden,
Import project using "File->Import->General->Existing Project".
Sorry!
Markus |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 01. April 2016, 06:13:48
Hallo Markus,
bezüglich der Linker Scripts: Der einzig relevant Unterschied ist ja das Ende des RAM (192k statt 128k) und des Flashsizes. Ich denke,wir können das in einem gemeinsamen Linker Script abhandeln, sofern wir für die beiden Prozessorklassen ein Symbol definieren, darauf kann man im Script dann reagieren. Das sollte absolut kein Problem machen, da ja im Code entsprechende #defines gesetzt werden. Werde ich heute abend mal ausprobieren. Alternative natürlich die Behandlung im Makefile. Aber bei soviel Gemeinsamkeiten wäre es besser die Dinger zusammenzuhalten.
Lediglich wie genau man die RAM/FLASH Size Expression im Linker Script schreibt, wäre zu erproben.
73
Danilo |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 01. April 2016, 13:15:51
Leider geht es jetzt doch wieder durcheinander, das sollte so nicht sein...
Ich probier mal das auseinander zu fädeln...
Andreas:
Ich möchte natürlich kein Makefile erstellen, das inkompatibel zu einem der präferierten Systeme ist. Daher die Tests hier mit ein paar Freiwilligen und nicht per Commit im git. Erst wenn alles passt, wird das freigeschaltet.
Offene Punkte:
- Kompatible CPUs auf einfach Art unterstützen
- Compiler generierte Dateien (.a, .o...) in ein Verzeichnis umlenken und gewünschten Output in einem eigenen Ordner mit mehr Aussagekraft im Namen.
- Korrekte Implementation von Speicherbereichen für die verschiedenen Spezialaufgaben (virt. EEPROM, High-Speed RAM...) via Linker File
Mir fällt da noch viel ein...
Die oberste Prämisse ist Kompatibilität und einfache Benutzung, unabhängig von der IDE und unabhängig von der gcc Version.
Leider ist es nicht Einfach, die korrekten Informationen immer parat zu haben, aber es ist einfach zu viel parallel und zu viel für einen alleine alles beieinander zu halten.
Nur mal am Rande: 4.8 bis 4.9.2 sind nicht otimal bzw. buggy, erst 4.9.3 ist halbwegs brauchbar. Ubuntu installiert aus den normalen Paketquellen einen gepatchten 4.9.3, aber nur, wenn man Ubuntu 15.10 einsetzt. Ich weiß aber nur, dass in diesem 4.9.3 einige Bugs in Bezug auf den Linux kernel behoben sind.
Es gibt aus meiner Sicht eine einfache und eine zuverlässige Quelle für einen modernen gcc, das ist entweder die einfache Variante https://launchpad.net/gcc-arm-embedded oder die zuverlässige, da dort aktiv Toolchains auch für automotive und industriellen Einsatz gepflegt werden. Allerdings sind auch deren Versionen mit den bekannten Bugs der 4.8er und 4.9er behaftet, man sollte also auch da keinen Compiler älter als 2015.4 herunter laden.
Danilo,
auch wenn der Umbau auf CCM sinnvoll ist, wäre es nett gewesen nicht meinen Thread dafür zu hijacken. Nun muss ich Markus Posts ausfiltern, denn ich war ja bereits dabei sein Problem zu lösen.
Es kann nur dann ein gemeinsames Linker-Script geben, wenn man einen Compiler > 4.9 einsetzt, der kann per Linker Flags Variablen im Linker Script überschreiben, also so, wie ich es mit sram0_size in meinem Post gemacht habe.
Alle älteren Compiler können das noch nicht. Leider ist Andreas der Überzeugung, dass der 4.8er Compiler der einzige ist, der zuverlässig funktioniert.
Leider ist es tatsächlich so, dass wenn man ein und den selben Code erst mit 4.8 baut und flasht und dann mit 4.9 baut und flasht, einigen Ärger mit dem virtual-EEPROM bekommt. Das wiederum ist aber ein Problem mit dem ungeeigneten Linker Script.
Markus:
Ich nutze den gcc 5.2 (Bitte nicht noch einen ollen 5.0 oder so installieren!) und damit kann ich den mcHF vom git problemlos auch für Deinen 293IV bauen. Es gibt keine Warnings und keine Errors.
Leider weiß ich jetzt nicht mehr so wirklich, was ich tun soll, denn eigentlich sollen alle das unbeherrschbare Eclipse Projekt nutzen, statt eines einfach anpassbaren Makefiles. Parallel wird das Linker Script schon zerlegt und es wird eine komplett veraltete Compiler Version genutzt...
Ich möchte aber ungern forken und einfach alles hier links liegen lassen... Blöde zuzusehen, wie sich die Leute verrennen und keiner hört zu...
73 de Astraliix
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 01. April 2016, 14:32:33
Hallo Ulrich,
Prämisse ist
"Einen Compiler nutzen der in den Repositories der gängigen Linux-Distributionen ist".
Vielfach ist der dort verfügbare noch der 4.8. Ich habe aber (obwohl dass schon einige Distributionen außen vor lässt!!!) den in den Jessie Backports verfügbaren 4.9.2 als unterste "Kompatibilitätszone" gesetzt.
Das bedeutet:
Selbstverständlich kann wer will auch neuere Compiler einsetzen. Der Code, das Makefile und das Linkerscript müssen aber mit dem 4.9.2 bauen.
Die Hürden für Kollaborateure dürfen nicht hoch gesetzt werden. Es geht hier nicht darum was besser ist oder andere Vorteile hat - es geht darum eine gemeinsame, einfach zu schaffende Basis zu definieren.
Und die lautet "Werkzeuge des Repositories benutzen" - bei Debian-Derivaten also apt und bei SuSE/Red-Hat-Derivaten rpm / yum.
Bislang gab es keinen Grund davon abzuweichen. Ich sehe auch aktuell keinen.
eine Kompatibilität mit einem anderen Prozessor ist Zukunftsmusik - und wenn die irgendwann aktuell ist, ist vermutlich auch der 5er gcc in den Backports angekommen.
Sollte ich mich irren und der 4.9er verbaut irgendwelche aktuell benötigten Möglichkeiten dann lasst uns darüber diskutieren.
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 01. April 2016, 16:12:41
Hallo Astralix,
sorry, wenn ich eine Thread gehijackt haben soll, aber den CCM hat Markus reingebracht und ich habe lediglich geschrieben, das diese Info bereits genutzt ist. Tatsächlich ist mir Post #29 durch die Lappen gegangen, in dem Du ein andres Make und Linker-File gepostet hattest.
Ich schlage deswegen zur Beruhigung der Gemüter vor, dem sehr kontroversen Thema "Gestaltung der Build-Umgebung" ein eigenes Thema zu widmen.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 01. April 2016, 16:37:12
Andreas, ich wäre ja voll bei Dir... Das Problem bin aber nicht ich, sondern der gcc...
Der Alte ist buggy, der Neue kann Dinge, die das Leben vereinfachen und mein Makefile macht es egal, wo der gcc installiert ist. Der Alte wird nicht besser, nur weil er zufällig manchmal installiert ist und weil ihn alle nutzen und sich über die Probleme, die er macht, ärgern.
Mit dem modifizierten Makefile können alle den neuen gcc einfach laden, entpacken und irgendwohin kopieren. Man kann sich dann am Anfang im Makefile diesen Ort für die Toolchain eintragen und fertig.
+ gcc Ort egal
+ IDE egal
+ CPU egal
- Extra runterladen, entpacken und verlinken im Makefile
Ich kann den Ansatz verstehen, Eclipse installieren und gnuarmeclipse drüber installieren. Dummerweise verlinkt dieses dann auf den alten 4.8er "https://launchpad.net/gcc-linaro" statt dem richtigen "https://launchpad.net/gcc-arm-embedded".
Damit ist das Problem dann da.
Der 4.9 hat so viele Probleme, dass es egal ist, ob er mitgeliefert wird, er funktioniert erst ab 4.9.3. Die älteren Versionen können vorab gebaute Bibliotheken nicht linken, daher funktionieren 4.9.0-4.9.2 einfach nicht. Das Makefile vom Kernel schließt diese Versionen ebenfalls hart aus.
Ich kann gerne mal eine VM bauen, die Eclipse und einen passenden gcc beinhaltet. Wenn daran Interesse besteht, dann melden. Ich werde aber nur eine VM bauen und pflegen, nicht das jetzt jeder mit seinem eigenen Linux-Derivat kommt.
Wenn sich mehr als 10 Leute finden, die Interesse an einer mcHF VM haben, dann mache ich mir gerne die Mühe.
Müssen dann nur einen Ort finden, wo ich sie lagern kann.
Andreas, kann man dazu einen kleinen Umfrage-Thread starten?
73 de Ulrich aka Astralix |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 01. April 2016, 16:46:40
Hallo Ulrich,
die GNU ARM Eclipse Website sagt ganz deutlich, für bare metal, nimm die GCC ARM Embedded Tool chain. Nur für Linux target apps (also Anwendungen, die auf Linux laufen sollen) wird Linaro empfohlen. Siehe unten.
The build plug-in is highly configurable in terms of executable names and location, so you can use any 32/64-bits ARM GNU toolchain you preffer, but, for better results, the recommended toolchain for bare metal target applications is GCC ARM Embedded (formerly GNU Tools for ARM Embedded Processors); for GNU/Linux target applications, the Linaro family of toolchains provides a large selection of choices, for various specific needs (little/big endian, 32/64-bits, etc).
Ansonsten würde ich trotzdem die Auslagerung in einen anderen Thread vorschlagen.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 01. April 2016, 19:37:29
Hallo Danilo,
ist mir klar, wozu welche der Toolchains gedacht ist. Ich mache ARM Linux, Cortex embedded und ähnliches ja auch schon über 10 Jahre. Es ging mir darum zu verhindern, dass tote Pferde geritten werden, nur weil man einen Schritt beim Aufsetzen der Build-Umgebung sparen kann. Gleichzeitig fängt man sich auch noch unnötige Probleme durch bugs ein und macht sich die Konfiguration und Anpassung schwer.
Aber Andreas hat genug damit zu tun, die Features der eigentlichen Software zu pflegen und noch vieles mehr. Daher mein Angebot für alle eine VM zu bauen, in der alle einfach in die mcHF Entwicklung rein starten können. Das hätte den Vorteil, dass alle auf dem gleichen System entwickeln und die gleichen Tools nutzen. Updates von Toolchains kann man dann einmal einfach beschreiben und muss keine Rücksicht auf Unterschiede nehmen.
Wir arbeiten nämlich gerade auf die String-Theorie hin, die sind jetzt bei ca. 11 Dimensionen und wir haben unterschiedliche Linux Distris teilweise in unterschiedlichem Stand (Debian, Ubuntu 13.x bis 15.x) Windows XP, 7, 8, 10, gcc 4.8, 4.9.x, 5.x und Eclipse K, L, M...
Die paar Hardcore-Entwickler, die gerade im git eine Verbesserung nach der anderen einpflegen (Hochachtung!) sollten auf Linux unterwegs sein, also müssen wir alle anderen nur noch auf den gleichen Stand bringen. Und in der private Edition ist in Virtual-Box auch USB mit drin, man kann also auch fertige Scripte für STLink hinzufügen und das Debugging und Flashen einrichten.
Das würde verhindern, dass Markus mit seinem STM32F493IV keinen Code generieren kann, obwohl das bei mir einwandfrei funktioniert. Keiner der Linux Spezis muss jetzt auf die VM wechseln, aber ein Linux Spezi kann einem Windows User eben besser helfen, wenn der eine Linux VM einsetzt ;)
vy 73
Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 01. April 2016, 20:41:58
Hallo Ulrich,
Kurzzusammenfassung:
ich bin absolut und uneingeschränkt dafür, das die Entwicklung für den mcHF für jeden der mitmachen will, so einfach und bequem wie möglich ist.
Deshalb findet dein Vorschlag, eine VM aufzusetzen und zu pflegen, meine volle Unterstützung, weil das für einen Teil die Hürde stark senken kann. Aber nur für einen Teil der mcHFler.
Für die, die gerne langatmige Ausführungen lesen wollen:
ABER ich darf zu bedenken geben:
Die meisten Leute mit Windows motiviert man nicht mit einer Linux VM.
Und die meisten Leute haben Windows (größer 80%). Dann noch MacOS und dann Linux erst Linux.
Ich kann jetzt noch ein paar Argumente nennen, die eine VM Lösung nicht mehr so einfach für den normalen Anwender erscheinen lassen (übrigens ist das quasi unabhängig vom Betriebssystem der VM):
- Datenaustausch:
Wie kommt das Binary aus der VM?
Mit scp/ssh [Wer kann das]?
Über Netzwerklaufwerk? Muss man das Netzwerk mit der VM ans Laufen bekommen, ist sowohl unter Linux als auch unter Windows für den Laien viel Spass.
- Debugging: Wer weiß wie man einen ST-Link in die VM einbindet?
Git/Github ist übrigens auch eine Hürde, die man nicht unterschätzen darf. Frag mal Frank, DD4WH.
Und hier der nicht noch weniger wichtige Teil:
Und mit Windows kann man auch prima für den mcHF entwicklen: Ich habe Windows 7 und 10 plus Eclipse 4.5 plus gcc 5.2.. Und vorher auch mal CoIDE, weil das wirklich am einfachsten aufzusetzen war/ist (ist beim ernsthaften Entwickeln nicht top, keine Frage, da ist Eclipse besser). Ich bin übrigens absolut kein Linux-Gegner, eher im Gegenteil. Aber bei Windows ist in der Tat die Varianz zwischen den Version sehr viel geringer als zwischen den Linux-Distributionen, da macht sich Micosoft sehr viel Mühe damit. So sind die Anleitung und die Binaries für Windows im Prinzip mindestens von Vista bis 10 so lauffähig, Windows XP weiss ich nicht, geht aber vermutlich auch. Versuche das mal mit einer ausreichend alten Linux-Distribution.
Nochmal die Zusammenfassung:
All das oben geschriebene spricht absolut nicht gegen deine Idee, sollte man diese Gedanken aus meiner Sicht beachten, wenn man andere für die Mitarbeit begeistern will. Nicht das was einem selbst am besten gefällt, ist immer auch für die Mehrheit das Einfachste/Richtige.
Das allerdings ist nur meine persönliche Meinung, das kann jeder anders sehen.
BTW, wenn es so eine VM mit Eclipse vor 3 Monaten zum Download gegeben hätte, hätte ich die vermutlich sofort benutzt. Aber ich habe auch mehr als 25 Unix-Erfahrung und bin da nicht ganz unvoreingenommen. So war für mich Windows einfacher. Meine kleine Debian Jessie VM mit der Kommandozeile haut mich da nicht wirklich vom Hocker, die nehme ich nur, wenn ich mal Spaß mit dem gcc 4.9 und make haben will.
73
Danilo |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 01. April 2016, 20:57:05
Hallo,
noch ein Nachsatz aus technischer Sicht: 40x vs. 439: Der Compiler selbst kennt keinen Unterschied zwischen den Prozessoren, für den ist alles ein Cortex-M4 usw. Der Unterschied entsteht eigentlich erst im Quellcode und beim Linken (da haben wir zur Zeit auch keinen, es wird nirgendwo abgefragt, ob man Prozessor X oder Y hat, nur die Familie STM32F4XX).
Wenn man irgendwelche Spezialitäten vom 439 nutzen will, ganz andere Story, dann muss man sowohl im Code als auch im Linkerscript wissen ob man 40x oder 439 etc. ist.
Was ich AUCH NICHT weiss, ist, ob der Code irgendwelche Unterschiede machen muss, damit er auf dem 439 richtig läuft (Interrupthandler-Tabelle etc.), da habe ich mich nicht eingelesen. Soweit ich aber die Bilder im Thread überblicke, ist der binäre Code auf dem mcHF schon gelaufen.
Da ist noch ein weites Betätigungsfeld, aber es gibt da ja einige mit den 4x7/9 auf der Platine.
73
Danilo |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 01. April 2016, 21:11:58
Danke für die ausführliche Antwort,
das ist ja der Grund, warum ich das hier etwas ausdiskutiere, denn es gibt bei jedem Schritt vorwärts nun mal auch mal Gefahren oder zwei Schritte rückwärts in der Folge.
Der mcHF ist für Funkamateure ein echter Knaller, für Einsteiger und für Profis, weil er so richtig offen ist und für ein SDR auch vergleichsweise preiswert. Dazu kommt der HAM-Spirit, wenn mal wieder Lötzinn in der Luft liegt. ABER er ist von der Software her alles andere als einfach. Das liegt noch nicht einmal an den kleinen Bugs im Design, sondern SDR ist nichts, was man mal eben nebenbei macht. Und alles in Software lösen heißt ja nur, dass die Probleme dann eben nicht in der Hardware, sondern in der Software landen.
Es ist dabei auch völlig egal, welches Betriebssystem man nutzt, die Toolchain muss passen. Und wie ich gerade lese, hast Du Dich auch für die passendere Toolchain entschieden und nutzt gcc 5.2.
Ich würde auch viel lieber in der Software vom mcHF selber arbeiten, als an einer VM, aber es ist schwer un-aufgeblähte Makefiles und Linker-Scripte zu schreiben, wenn man 6 Betriebssysteme mal 6 Compiler mal 4 Build-Tools berücksichtigen muss. Das ist nicht zu pflegen.
Daher bin ich ja unschlüssig, denn wie Du sagst, der "Profi" hat auf seinem System keine Probleme mal schnell das ein oder andere Tool zu wechseln, der Laie scheitert an Dingen, die mit der Auswahl des richtigen gcc nichts zu tun haben.
Selbst wenn ich eine VM aufsetze, muss man sich immer noch die git credentials anlegen um github rein zu kommen oder sich mit gitk und cola vertraut machen.
Also ich arbeite da, wo Ihr es am nützlichsten haltet, Linker Scripte, Toolchain, VM, EPROM Treiber oder ein paar Updates der CMSIS zum Frühstück?
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 01. April 2016, 21:19:48
Auch ich habe nichts gegen eine VM.Nur würde ich sie nicht nutzen, weil ich ein LinuxSystem in meiner Produktivumgebung habe und nicht für den mcHF eine eigene Umgebung benutzen möchte.
Wieviele von Windows auf eine solche VM umstigen woll(t)en, kann ich nicht beurteilen.
Aber ich kann beurteilen, wieviele Bugs des 4.92 mir aufgefallen sind, deit ich für den STM32 compiliere:
2.
1) der C11/C99 mode ist fehlerhaft. Das ist für mich kein Problem - ich nutze die Besonderheiten, die diese Modes voraussetzen, einfach nicht.
) Es gibt eine "Überoptimierung". Aber auch einen guten und funktionierenden Ansatz, wie man diese umschifft.
Also gab es bei all den Aktionen, die ich seitdem gemacht habe KEIN ernsthaftes Problem mit dem 4.92. Und da ich doch recht viel gemacht habe, glaube ich, dass auch andere keine Probleme finden würden. Der gesamte Code aller anderen kompiliert auch ohne Probleme auf dem 4.92.
Ich bin KEIN Freund "stets der neuesten Version". Deswegen habe ich mich bewusst für Debian entschieden - und bin auch in Sachen STM32 Development noch nicht enttäuscht worden.
Kurzfassung:
Eine VM bereichert die Einsteigermöglichkeiten. Sie sollte aber folgende Möglichkeiten beeinhalten:
1) Eclipse sollte mit drauf sein
2) der STLINK-V2 sollte unterstützt werden (sowohl zum Programmieren des STM als auch in den gdb auf Eclipse zum Debuggen).
3) Ein Dateiaustausch via Samba sollte mit dabei sein
Auch habe ich kein Problem damit,sowas zum Download zu hosten. Ich habe einen eigenen Rootserver, auf dem unter anderem unsere OV Seiten liegen. Da ist noch jede Menge Platz, und elbst GitLab könnte ich darauf installieren, wenn es irgendwann mal nötig wäre.
Aus Gründen einer einfacheren Pflege (ich betreue viele Rootserver) aber *NUR* mit Paketen aus Repositories...
vy73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 01. April 2016, 21:44:30
Hallo Ulrich,
meine persönliche (!) Meinung:
- eine voll eingerichtete VM wäre schon gut (trotz aller der negativen Dinge, die ich aufgezählt habe und über die man sich Gedanken machen sollte). Damit können wir dann auch mal Erfahrungen sammeln, ob sich das lohnt. Ohne das es jemand macht, werden wir es nicht rausfinden.
- Super wäre auch wenn jemand mal das Aufsetzen Debugging für die Kommandozeile beschreiben würde. (Da war CoIDE übrigens spitze: ST-Link drangesteckt und auf Debug gedrückt, so muss das sein). Im Eclipse hab ich es ja hinbekommen, aber meine Tage mit dem gdb sind sehr lange her und openocd gab es da noch nicht), da habe ich auch keine Lust dazu, debuggen geht in Eclipse so nett von der Hand, mit den HW und Peripherie-Registern direkt zum Anschauen.
Aber da das jetzt alles nicht wirklich Spass macht, hier noch ein paar Dinge mit möglicherweise mehr Spassfaktor:
- Makefiles etc. fitmachen für Nutzung mit anderer Prozessoren (wieso habe ich das Gefühl, das wir da schon drüber geredet haben ;-) )
- Rausfinden, warum wir diesen verdammten OTG HS (den gr. USB Port) nicht ans Laufen bekommen (sowohl im Bootloader als auch in der Main-App). Bootloader wäre super-praktisch, dann kann man gleich das CAT-Kabel dranlassen und mit dem Stick im USB Port eine neue FW flashen. Für die Armen ohne ST-Link (oder mit geschlossenem Gehäuse).
- Neues ordentliches Verfahren für die Speicherung der Konfiguration machen, das flexibel mit dem Rein und Raus von Parameter umgehen kann (das ist ein bißchen meine Baustelle)
- Code aufräumen, ordentliche Trennung von UI (Anzeige) und eigentlicher Funktion, dann kann man im nächsten Schritt auch endlich ein RTOS wie FreeRTOS (mein aktueller Favorit) einziehen.
- Echtes Touch UI machen, denn nur so kann man bei vielen neuen Funktionen eine ordentliche Bedienung hinbekommen (Z.B. Stations-Speicher mit Namen )
- Code aufräumen (da geht immer noch was)
- neue Funktionen einbauen
- Automatisierte Test entwerfen
- Code aufräumen (wenn man denkt, man ist fertig, ist es schon wieder soweit)
...
Und da gibt es sicher noch mehr Ideen bei anderen... Du hast es so gewollt :-)
73
Danilo
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 01. April 2016, 21:59:05
FreeRTOS war von Anfang an mein Traum. Zur Zeit noch in weiter Ferne - aber es gibt ja auch Ferngläser, warum sollte also nicht auch FreeRTOS...
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 03. April 2016, 17:08:20
Hallo Ulrich,
- eine voll eingerichtete VM wäre schon gut (trotz aller der negativen Dinge, die ich aufgezählt habe und über die man sich Gedanken machen sollte). Damit können wir dann auch mal Erfahrungen sammeln, ob sich das lohnt. Ohne das es jemand macht, werden wir es nicht rausfinden.
|
|
Das sehe ich auch so. Eine eigens dafür gebaute VM kann man ja auch so präparieren, dass der Einstieg ins Projekt leicht fällt, also ein paar Icons auf den Desktop als alles in Menüs versteckt.
- Super wäre auch wenn jemand mal das Aufsetzen Debugging für die Kommandozeile beschreiben würde. (Da war CoIDE übrigens spitze: ST-Link drangesteckt und auf Debug gedrückt, so muss das sein). Im Eclipse hab ich es ja hinbekommen, aber meine Tage mit dem gdb sind sehr lange her und openocd gab es da noch nicht), da habe ich auch keine Lust dazu, debuggen geht in Eclipse so nett von der Hand, mit den HW und Peripherie-Registern direkt zum Anschauen.
|
|
Ich bin mir nicht sicher, ob man gdb auf der Kommandozeile wirklich braucht. Wenn man mit Optimierungen arbeitet, kann der gdb eben oft nicht mehr auf die aktuelle C-Zeile zurück schließen und dann ist eben Assembler angesagt. Aber der ARM Assembler ist gut lesbar :) Aber dagegen hilft auch gcc auf der Kommandozeile nicht. Wenn ich eine VM baue, dann ist da Eclipse vorinstalliert, gcc 5.2 und natürlich werde ich versuchen die stlink rules in udev gleich korrekt unter zu bringen.
Aber da das jetzt alles nicht wirklich Spass macht, hier noch ein paar Dinge mit möglicherweise mehr Spassfaktor:
|
|
Alles was das Projekt voran bringt, führt letztendlich dazu, dass man Spaß damit hat. Ich hatte mir vorgenommen meinen ersten Call mit einem selbst gebauten Gerät zu machen. Ich muss noch ein paar der Änderungen einlöten, die das Senden betreffen, sowie die Endstufen FETs. Dann fehlt nur noch die bestandene Prüfung in knapp 3 Wochen.
Wäre cool, wenn ich das eigene Vorhaben umsetzen könnte
- Makefiles etc. fitmachen für Nutzung mit anderer Prozessoren (wieso habe ich das Gefühl, das wir da schon drüber geredet haben ;-) )
|
|
Das mit den Makefiles, dem Linker und alles was Low-Level ist, ist mein Spezialgebiet. Daher werde ich mich auch in dieser Ecke beschäftigen. So oder so. Viele der seltsamen Erscheinungen, mit denen das Projekt immer wieder mal kämpft, rühren daher. Abund zu verlorene Settings, Optimierungsstufen, die nicht gehen... Das ist sehr oft ein Problem mit Linker und Makefile selten auch mit einem buggy gcc.
- Rausfinden, warum wir diesen verdammten OTG HS (den gr. USB Port) nicht ans Laufen bekommen (sowohl im Bootloader als auch in der Main-App). Bootloader wäre super-praktisch, dann kann man gleich das CAT-Kabel dranlassen und mit dem Stick im USB Port eine neue FW flashen. Für die Armen ohne ST-Link (oder mit geschlossenem Gehäuse).
|
|
Wenn Du mich da mal detailliert drüber aufklärst, wenn alle Stricke reißen und der Fehler ist im ST eigenen Treiber zu vermuten, dann habe ich email Adressen und Telefonnummern bis weit nach ST hinein. Die kann ich dann gerne aktivieren.
- Neues ordentliches Verfahren für die Speicherung der Konfiguration machen, das flexibel mit dem Rein und Raus von Parameter umgehen kann (das ist ein bißchen meine Baustelle)
|
|
Dazu hatte ich mir was feines ausgedacht, und der Code ist an dieser Stelle ohnehin sowas von überarbeitungsbedürftig...
- Code aufräumen, ordentliche Trennung von UI (Anzeige) und eigentlicher Funktion, dann kann man im nächsten Schritt auch endlich ein RTOS wie FreeRTOS (mein aktueller Favorit) einziehen.
- Echtes Touch UI machen, denn nur so kann man bei vielen neuen Funktionen eine ordentliche Bedienung hinbekommen (Z.B. Stations-Speicher mit Namen )
- Code aufräumen (da geht immer noch was)
|
|
da bin ich voll bei Dir! Allerdings haben wir mit FreeRTOS dann schnell wieder die gleichen Probleme wie mit CoIDE. Diese vorgefertigten Systeme tun vieles im Hintergrund automatisch, um den normalen Anwendungsprogrammierer zu entlasten. Muss dieser dann mal die Dinge ganz weit unten optimieren, dann lassen sie das nicht zu oder stolpern über diese Änderungen. CoIDE soll sehr zickig auf Optimierungen von Linker-Scripten reagieren. Mit FreeRTOS fehlt mir die Erfahrung.
Ich habe damals die STM32 in NutO/S (www.ethernut.de) integriert und weiß, dass dieses O/S gut damit umgehen kann, wenn man die Linker-Optionen extrem auf das Projekt anpasst. Dazu kommt, dass man dieses preemptive Multitasking System auch "torpedieren" darf, also zum Beispiel am System vorbei programmierte High-Speed Interrupts laufen lassen kann, ohne dass das ganze dann explodiert.
Die meisten RTOSe nehmen es nicht hin, wenn Dinge unter ihnen laufen, die sie nicht unter Kontrolle haben.
Was das Code aufräumen betrifft, so würde Eclipse uns eigentlich schon eine Menge Arbeit abnehmen, wenn alle Verantwortlichen in Eclipse arbeiten würden, bzw. eine mal hin geht, alle Dateien öffent und den Code-beautifier laufen lassen würde. Ich arbeite grundsätzlich mit dem K&R Style, der auch im Linux kernel verpflichten ist, allerdings mit zwei Änderungen, die der Lesbarkeit und den inzwischen üblichen 16:10 Monitoren geschuldet sind: Tabulator Breite 4 statt 8 und Zeilenende bei 120 Zeichen statt 80.
Mit einer einfachen Tasten-Kombi kann man eine ganze Datei damit aufräumen:
Rechts-Klick -> Source -> Format (oder SHIFT-STRG-F) wird die komplette Datei dan formatiert.
Wenn man nur noch das Einrücken korrigieren muss, tut es ein STRG-I
In Eclipse kann man dann auch automatisiert Header erstellen, wenn man in der Zeile über einer Funktion /** tippt, werden alle Variablen gelistet und man braucht nur noch die Beschreibungen hinzufügen.
Würde man diese Dinge für das Projekt verpflichtend machen, würde der Code sehr schnell und sehr lange gut lesbar werden.
Da die Dateien aber Kraut und Rüben sind, ist es sehr schwer, für neuen Code die Leute zu einem bestimmten Style zu überreden.
vy 73 Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 04. April 2016, 19:56:24
Respekt, Danilo!
Was Du da für das Setup gemacht hast, ist ziemlich exakt das, was ich auch vorhatte. Große Tabelle mit Type, Pointer, Default und valid Range. War selber gerade dabei das aus einem Projekt heraus zu schnipseln, welches ich vor Jahren mal gemacht habe.
So eine Tabelle ist die einzig vernünftige Lösung.
Ich würde jetzt gerne das Virtual-EEPROM an eine feste Adresse im FLASH legen, was aber nur auf unschöne Art geht, denn wenn wir das Linker-Script anfassen und dort ein veeprom anlegen, stolpert die CoIDE darüber.
Vorschläge?
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 04. April 2016, 20:28:56
Hallo Ulrich,
soweit ich den Flash-Code verstehe, liegt der Virtual EEPROM doch an einer festen Adresse (0x8008000). Der Code geht 32k später los, bei 0x8010000.
Wäre natürlich eleganter lösbar, aber 32k sind erstmal ganz ordentlich und soo groß ist der Verschnitt auch nicht. Insgesamt 64k Flash bei min. 512K sind jetzt nicht so schlimm aus meiner Sicht, insbesondere da wir derzeit bei ca. 240k Code plus Daten liegen. Und wenn Bedarf nach mehr besteht, können wir den Code einfach weiter nach hinten legen. Oder nach vorne. Ich würde die Lage ungern verschieben, denn das würde den EEPROM losen mcHFler den Tag vermiesen können. Kann man natürlich auch im Code behandlen, aber das wäre für mich derzeit keine Prio. Verbessert gehört insgesamt die Fähigkeit mit geänderten Konfigurationstrukturen umzugehen. Wenn ein Parameter so nicht richtig ist, müssen wir derzeit die Speicherstelle "aufgeben" und einen neuen Platz verwenden. Hat zwar den Vorteil, das alte Firmware die alten Daten genau da findet, wo sie sie gelassen hat, aber je öfter man das macht, umso mehr Schweizer Käselöcher entstehen im Speicher. Irgendwann sind dann die 32k voll.
Das ist meine nächste Baustelle, aber das sehe ich inzwischen etwas relaxter, wir werden noch ein Weile mit dem Käseverfahren leben können.
Was als nächster kommen wird, ist die Konvertierung von Konfigurationsparameter von alter Firmware auf neue Firmware, so dass man mal bestimmte Daten umstrukturieren kann, ohne das der geneigte OM seine Daten verliert, weil die neuen Parameter ja nichts von den alten Strukturen wissen (sollen).
Derzeit haben wir ca. 360 Werte a 2 Byte zu verwalten, da ist eben noch Platz bis 32k.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 04. April 2016, 20:39:32
Ja, das ist das, was ich im Zuge eines O/S angedacht hatte.
Wir benötigen ohnehin für viele Werte einen Namen, der auch schriftlich dargestellt wird (z.B. im Menu).
Diesen kann man dann auch gleich als Namen in einer Config-Datei nutzen. Nutzt man dann 64kB als zwei 32kB Dateien, könnte man im Zuge eines Updates obsolete Parameter ignorieren und neue mit Default hinzufügen, wenn man beim Speichern immer wechselseitig die 2x 32kB nutzt.Das halbiert die Schreibyklen und mit etwas CRC oder Versions-Info in den Settings kann man sogar 1x ein Downgrade auf die letzte Version machen, ohne dass man ein einziges Setting verliert.
Ist nur so eine Idee :)
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 04. April 2016, 20:59:06
Hallo Ulrich,
ich bin vielleicht nicht so ins Detail gegangen: Genau so läuft es im Prinzip schon, es gibt 2 Pages a 16k, die wechselweise verwendet zu werden scheinen. So genau hab ich mir das nicht angeschaut, schien erstmal zu tun und war dementsprechend nicht die erste Baustelle. Insgesamt etwas verkompliziert wird das durch den I2C EEPROM, der, soweit vorhanden und groß genug, der "Hauptspeicher" für Konfigurationen wird.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 05. April 2016, 06:08:21
Der virtuelle EEPROM kann maximal 16KB fassen. Die gesamte reservierte Speichergröße beträgt 32 KB.
Der Bootloader beginnt bei 0x8000000. er darf maximal 2 Pages (==32KB) groß werden. Die darauf folgenden 2 Pages dienen für den virtuellen EEPROM. Um die Lebensdauer zu verlängern, werden schon jetzt die maximal möglichen 16KB auf zwei Pages "verteilt". Die Schreibvorgänge finden eben nicht immer in einer Page statt...
Und dahinter (bei 0x8010000) beginnt die Firmware.
Der Code für den virtuellen EEPROM ist für mich "höchst suspekt" - er stammt aus einer AN von STM selbst.
vy73
Anreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 05. April 2016, 08:01:04
Hllo Andreas, Danilo, Astralix und weitere Code-Gurus aus diesem Forum.
kann mir einer von Euch mal erklären wie aufwändig es ist die CMSIS
Schiene von ST zu verlassen und hätte das einen Sinn, was die Über-
sichtlichkeit des Codes anberlangt.
Zwar ist mit klar, dass man dadurch die ganzen fertigen Funktionen
selber machem müsste und auch seine eigenen Hardware Includes
bauen und warten müsste, aber auch den genzen ST Overhead los
wäre.
Ist das eine naive Frage?
Ich habe im MC-Forum auch einige Fragen zu dieser Thematik gelesen
und da sind sich die jeweiligen Lager Pro/Contra auch uneinig.
Würde das aber nicht dem Opensource Gedanken nächer kommen.
Bitte nicht missverstehen und gleich schimpfen, aber nach partiellem
Durchsehen des Codes fällt mir als Laie im Bezug auf ST-MCs auf,
dass da viel Komplexität wegen der ARM Compatibilität zu anderen
Controllern steckt, die wir beim mcHF nicht brauchen, da ja die HW
so wie sie ist festgeschrieben ist.
Die eingeführte Zwischenschicht, die z.B. die Entwicklungen im 'auto-
motiv' Bereich im proffesionellem Umfeld beschleunigt, baut ja auch
auf proffesionelle Werkzeuge, die wir im Hobby-Bereich so nicht zur
Hand haben.
Trotzdem bewundere ich die Arbeit derjenigen, die in diesem festgelegten
Schema sich trotzdem gut zurechtfinden, was wohl auch dem beruflichem
Umfeld geschuldet ist.
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 05. April 2016, 21:34:13
Hallo Markus!
Ich darf ganz kurz ausholen :)
Im Grunde ist es garkein Problem die CMSIS zu verlassen. Ich habe bei einigen Projekten die CMSIS ganz oder in Teilen ersetzt. Aber es gibt eigentlich kein Problem in der CMSIS. Denn die CMSIS ist von ARM für alle CortexM Prozessoren da.
Der Code von ST ist eine andere Geschichte, der hat aber mit der CMSIS nichts zu tun, auch wenn jeder glaubt, den in den CMSIS Ordner kopieren zu müssen :) Dieser Code von ST ist auf Erlernbarkeit getrimmt. Daher ist er aufgebläht und an vielen Stellen wenig optimal. Man muss eben einen Bildschirm voll Zuweisungen in ein struct schubsen, bevor man einen einzigen GPIO initialisieren kann. Ich werde meinen NutO/S GPIO Treiber die Tage rüber kopieren. Ein GPIO-Init ist eine Zeile. Viele GPIOS eines Ports mit gleicher Konfiguration sind auch nur eine Zeile.
RTOS / O/S... Es gibt eine Menge Alternativen, die alle ihre Vor- und Nachteile haben. Und eine Alternative ist z.B. CoIDE oder CoCox. Diese Kombination nimmt einem viel Arbeit ab. So erstellt sie diese Linker-Scripte und Makefiles intern und "belästigt" den Anwender nicht mit Dingen, über die man trotz der wenigen Zeilen ganze Master-Arbeiten schreiben kann.
Leider haben diese integrierten Umgebungen den Nachteil, dass sie es eben nicht vertragen, wenn man manuelle Änderungen an diesen intern bestellten Dateien vornehmen muss. Andererseits sind diese internen Dateien aber so essentiell und Änderungen an ihnen so schwierig, dass die meisten Anwender sie niemals sehen wollen und froh sind, dass es automatisch gemacht wird.
Und da ist nun unser Problem. Wir haben eine ganze Reihe Mitarbeiter am Projekt, die ihren Beitrag zu dem Projekt leisten, weil sie sich mit HF und SDR und Mathematik von Filtern auskennen. Sie haben Spaß daran sich in ihrer Welt auszutoben und sich nicht um ein fragiles komplexes System aus zusammen gesteckten Editore, Compilern, Debuggern, USB Treibern... zu kümmern.
Sie starten Windows, klicken auf CoIDE und das Projekt und nach ein paar Stunden gibt es ein paar gefixte Fehler in der Software und das 18m Band kommt ebenso dazu, wie die neuen Frequenzen auf 50Mhz.
----
Andererseits ist allen bewusst, dass durch die Einfachheit auf der einen Seite und durchaus einer Reihe von Leuten, die gewillt sind auf Linux, Eclipse, gdb... sich dieser Komplexität zu stellen, im Projekt selbst gewisse Spannungen auftreten. Jemand der sauberen Code programmiert wird niemals ein Array im Code einer hart codierten Adresse zuweisen, sondern einen entsprechenden Bereich im Linker-Script mit einem aussagekräftigen Namen versehen.
Leider ist genau das der Punkt, an dem CoIDE explodiert oder man, wie bei Keil oder anderen IDEs in Untermenüs mit 15 Etagen seltsame Werte eintragen muss, damit es funktioniert.
-----
Ehrlich gesagt, ich starte NutO/S in etwa 2h auf dem System. Damit haben wir kein Radio, aber ein komplettes O/S mit Threads, Semaphoren und Mailboxen. Dazu Treiber für die meiste ST Peripherie, I2C, SPI und DMA...
Aber die Voraussetzung wäre, dass wir auf Eclipse und gcc und Makefile umsteigen. Natürlich auch ein spezialisiertes Linker-Script.
Aber wie in der Diskussion zuvor durchscheint, es geht eher um die Basics. Wir können erst alle zusammen an dem Projekt arbeiten, wenn wir alle mit dem gleichen Werkzeug in ähnlichem Umfeld arbeiten. Wir müssen dazu nicht alle in einen Hobbyraum einziehen, aber egal ob Linux, Mac, Windows man müsste alle auf die gleiche gcc Version bringen, alle die gleiche gdb Version mit STLink und auch alle Makefile und Linker-Script.
Dann wäre die IDE sogar egal, die Windows Kollegen können sogar problemlos den MS C# Editor einsetzen, dieses Visual-Dingens. Aber das müsste eben beschrieben werden und das so gut, dass das jeder einfach nachvollziehen kann und erkennt, dass das nur ne Stunde kostet und dann kann er an seiner eigentlichen Aufgabe weiter machen.
Und das muss mal einer machen...
Danach steht uns eine Welt voller Möglichkeiten offen. :)
Es gibt noch so viel Code aufzuräumen, dass man noch eine ganze Weile mit diesem fragilen Mischmasch an IDEs und Toolchains leben kann. Aber wenn die Varianten durch Platinen-Revisionen oder verschiedene STM32F4 Typen, EEPROMs und neue Displays mehr werden, dann kommt die Stunde der Spezialisten für Make- und Linker-Scripte :)
Aber dann werden die CoIDE User freiwillig auf Eclipse wechseln. Und wenn es mal ein paar Eclipse-Luna oder Kali .project Dateien geschafft den Eclipse Mars Usern das Projekt zu zerlegen, werden auch die frewillig auf Makefile-Projekt umstellen.
Also arbeiten wir zunächst mal an den Sachen die offensichtlich zu tun sind, und da gibt es noch genug, wie Danilo so schön schreibt. Und der Rest muss nur lange genug kochen, dann kommt es von alleine.
Eine gemeinsame VM zu erstellen ist ein Weg, alle auf einen Stand zu bringen. Das sollte die Hürde senken. Aber Dokumentation wäre auch eine Option.
Ein O/S drunter legen, wäre zunächst eine weitere Hürde und die Auswahl eines passenden O/S ist nicht ohne. Denn wir haben einen recht ansehnlichen DSP Teil in der Software, der recht allergisch auf Unterbrechungen durch ein RTOS reagieren würde. Das NutO/S hatte ich vorgeschlagen, weil ich weiß, dass es auch dann gut funktioniert, wenn es sich einem hart getrieben Interrupt-System unterordnen muss.
War jetzt viel Text, gibt aber im Grunde die Summe der Pros und Cons für die verschiedenen Aspekte und Meinungen wieder, die hier öffentlich und auch privat diskutiert wurden. Wichtig ist im Grunde, dass keiner vergrault werden soll. Und das gilt es in jedem Fall zu versuchen.
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 06. April 2016, 09:09:14
Hallo Uli,
danke für die ausführliche Antwort.
Mir war schon bewußt, dass es da sehr schwer sein wird,
die etablierten Pfade zu verlassen aber ich hatte halt gehofft,
dass man einfacher den MC intiallisieren kann und dann sich
seine eigene main routine zusammensetzt, in der man Schritt
für Schritt die einzelnen Teile des bestehenden Codes einbinden
könnte um diese zu verstehen und sich so an den gesamten Code
anzunähern.
Leider sind die Header/Libs so ineinander verstrickt, dass es schwer
fällt (zumindest mir) kleine Teilfunktionen auszuführen.
Ich habe mir gestern die Keil CMSIS Webseiten durchgelesen, um
die Namensgebung überhaupt zu verstehen und habe dabei feststellen
müssen, dass es wohl einen sehr großen Aufwandt darstellt dieses
System im kleinen zum Laufen zu bringen, ohne die Gesamtheit
begriffen zu haben - leider.
Ich war der naiven Hoffnung verfallen, so ein mchf SW System mit einer
Anzahl von Dateien zum Laufen zu bringen, die man an zwei Händen
abzählen kann. (*.h, *.c, eventuell *.xml für die GUI).
Wahrscheinlich muss ich mich noch wesentlich mehr mit den vorhandenen
Werkzeugen auseinandersetzen als mir einentlich lieb ist.
Die Zeiten, in denen der Code auf wenige Filss verteilt war, sind wohl
schon lange vorbei.
Ich sehe es täglich in meinem Arbeitsumfeld, wo die Projekte mit
Tausenden von JAVA, ADA, C und CPP Fiels daher kommen.
Im Web Umfeld sieht es langsam ähnlich aus.
Ohne entsprechende Werkzeuge ist man bei dem Umfang vollkommen
hilflos.
Unter dem bestehenden Zeitdruck werden nur noch Module verwendet,
die man aneinander häftet und das wars. Der Overhead wird ja duch
Rechenpower und Speichergröße wett gemacht.
Ich kann mich noch gut an eine Kongress erinnern, auf dem eine neue
Software vorgestellt wurde, um ein Problem in der Datenverarbeitung
mit Satellitendaten zu lösen.
Nachdem die Vorrädner die, diese Thematik damals mit JAVA angegangen
sind, einen halben Ordner Folien presentiert haben, (liegt erst fünf Jahre
zurück, trotz Notebook Aera) das Podium verlassen habe, ist mein
Kollege mit zwei DIN-A4 Folien daher gekommen und hat das Problem
mit einem kleinen Perl Skript auf elegante aber einfache Weise gelöst.
Das war aber ganz schön peinlich - wir schmunzeln noch heute wenn wir
daran zurückdenken.
Bin jetzt bischen von Thama abgekommen - sorry.
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 06. April 2016, 09:33:46
Lass Dich nicht auf die falsche Fährte locken!
Die CMSIS ist extrem komplex im Vergleich zu der üblichen Start-Sequenz eines Arduino mit nem 8-bit AVR.
Aber man kann sie in weiten Teilen einfach so verwenden, oder man zupft sich die Teile, die man benötigt.
Ich habe vor etlichen Jahren die STM32F Serie in NutO/S portiert und das war zwar viel Fleißarbeit, aber nicht unmöglich. Dank 2..3 Mitstreiter war das Schlimmste in 2..3 Monaten erledigt. Erfreulicherweise wird das ganze bis heute noch gepflegt und so werde ich nach einigen Jahren Pause neue Projekte wieder darauf aufsetzen.
Die Arbeit ist also bereits getan und man kann leicht auf diesen Zug aufspringen. Aber selbst wenn man von jetzt auf gleich einen Monster-Commit nach git stellt, in dem man die Arbeit auf einmal getan hätte, würde man eine ganze Reihe User abhängen, da entweder ihr Code nicht mehr da ist, wo er mal war oder ihre IDE nicht mehr funktioniert.
Lustig ist eigentlich der psychologische Effekt durch den Einsatz eines O/S. Jeder denkt zuerst, ein O/S würde die Dinge komplizieren und verlangsamen, was aber eigentlich garnicht der Fall ist. Und jeder, der früher seinen Code in 15000 Zeilen in eine main() gehackt hat, schreibt plötzlich abstrahierte Funktionen in Aufgaben-spezifische c und h Dateien.
Im Grunde ist es ein Problem des bestehenden Codes, das der Code in zwei Dateien liegt, die den zwei Platinen entsprechen. Nichts spricht dagegen, wie Danilo schon schrieb, den Code nach Funktionen zu trennen. Aber ein O/S schafft dazu den psychologischen Druck.
Und natürlich ist es viel leichter gemeinsam an einem Projekt zu arbeiten, wenn man sich nicht gegenseitig dauernd in ein und der selben Datei über die Füße fährt.
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 06. April 2016, 10:38:57
Hallo Uli,
meine Überlegung geht eingentlich dahin, nicht nur die HW der
Gemeinde zugänglich zu machen, sondern auch in einem weiten
Bereich die SW.
Die Platine muss man auch selber zusammen löten, wenn auch
man sie nicht selber geroutet und in Auftrag gegeben hat.
Dementsprechend wäre es schön, wenn man z.B. einen einfachen
Rumpf in Form der main() hätte und nach und nach die einzelnen
benötigten Funktionen für den vollen Umfang dazuladen könnte
oder auch eigene statt dessen einbauen würde, um selber zu
experimentieren.
Da ja AFU ein experimmentelles Hobby sein sollte, möchte ich auch auf
dem Gebier der MC SW Programmierung meine Erfahrungen machen
können und es auch anderen ermöglichen.
So zumindest die Theorie, auch wenn das Spektrum der Fähigkeiten
sehr unterschiedlich ist.
Jeder sollte entsprechend seiner Erfahrung und Möglichkeiten seine
experimentellen Spielwiesen haben und ich hoffe im Laufe der Zeit es
auch beim mchf zu schaffen und alle anderen, die noch kämpfen wünsche
ich dies ebenso.
Ohne jetzt die bereits erzielten HW/SW Erfolge aller Projekt-Teilnehmer
in irgendeiner Weise schmälern zu wollen - also bitte meine Ergüsse nicht
als Kritik ansehen, sondern als Gedanken, die mir so durch den Kopf
geistern ;-).
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 06. April 2016, 11:25:43
Diese Gedanken decken sich mit denen Vieler.
Auf lange Sicht wird es eh so kommen. Erst mal Aufräumen. Mit zunehmender Übersichtlichkeit, wird es so kommen, wie Du Dir das gerade wünscht (und ich auch und Danilo auch und....) |
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 06. April 2016, 13:19:45
Hallo Markus,
da auch die überwältigende Mehrheit der im Netz verfügbaren Projekte auf CMSIS aufsetzt spricht nichts dagegen, das zunächst so zu lassen. Jemand mit wenig Programmiererfahrung kann dann ähnliche Strukturen wiederfinden und besser cut&paste machen - selbst, wenn er nicht alles verstanden hat. Ein völlig vom üblichen Procedere abweichender Code würde einen Anfänger eher verwirren als ihm helfen - selbst, wenn er objektiv besser strukturiert ist...
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: DB4PLE on 06. April 2016, 18:00:59
Hallo Zusammen,
Aufwand einer "Reimplementierung der Low-level Hardware Abstraktionen":
In der Regel viel mehr als man sich vorstellt. Und im Fall eines Mikroprozessor der STM32 Klasse: sehr viel, vorallem muss man ja alles debuggen, darf dann auch aus den CMSIS kopieren und und und.
Da ich früher mal selbst mit einem Team Betriebssysteme entwickelt habe und dabei auch einige "nackte" Portierungen auf recht einfach Kontroller selbst durchgeführt oder mitbetreut habe, weiß ich, das ich darauf überhaupt keine Lust habe.
Der Mehrwert wäre absolut fraglich, die Qualität mit Sicherheit nicht wesentlich besser als CMSIS/STM Code. Und einfacher, übersichtlicher Programmkode ist auch nicht schnell mal gemacht, siehe den mcHF Source-Code.
Nutzung einer Open Source Laufzeitumgebung/Betriebssystem:
Ganz anders die Frage nach der zukünftigen Nutzung eines bereits vorhandenen und auf den STM32F4xx portierten Open Source - Betriebsystems/Laufzeitumgebung.
Das macht durchaus Sinn, denn da würden wir ja auf der Arbeit Anderer aufbauen können.
Das erhöht in der Regel die Qualität, wenn man eine häufig benutzte Software verwendet, statt selbst in die Tasten zu greifen.
Hier gibt es eine Spannbreite zwischen eher einfach und mit beschränktem Funktionsumfang (FreeRTOS, im Wesentlich Scheduling).
Oder "richtigen Betriebssystemen wie Nut/OS mit ernsthaftem Funktionsumfang bis hin zu Gerätetreiberabstraktionen und netten Dingen wie File Systems. Da ist dann die richtige Auswahl der vorhandenen Gerätetreiber und Hardwareunterstützung und die Einschätzung des Portierungsaufwand eine wichtige Komponente.
Jeder kann mitmachen:
Ehrlicherweise glaube ich nicht, das wir eine komplexe Software wie eine SDR Anwendung so einfach gestalten können, das jeder sofort überall was anpassen kann, ohne sich groß einarbeiten zu müssen.
Es gibt in der Regel einen Zielkonflikt zwischen sehr hoher Performance, überall sehr gut verständlichem Source-Code und leichter Erweiterbarkeit / Anpassungsfähigkeit.
Was man machen kann und muss, ist die aktuelle Software soweit aufzuräumen und auch umzustrukturieren, das die Erweiterung und Anpassung klaren, einfachen und nachvollziehbaren Regeln folgen.
Will man aber auch gleichzeitig noch anständige Performance (und die ist beim mcHF notwendig, um Audio-Verarbeitung und Bildschirm anständig zu erledigen, siehe vormaliges SPI Rumgetrödel mit der alten Firmware) gibt es schnell eine paar Dinge wie DMA, die schon
etwas mehr Nachdenken erfordern.
Richtig kompliziert wird es, wenn verschiedene Teile des Program mit einander kommunizieren (z.B. der Audio-Interrupt mit der den Filter-Einstellungen). Da muss man sich über viele Sachen Gedanken machen, denn beide Teile laufen ja quasi beliebig verschachtelt ab. Bei der Nutzung eines ordentlichen RTOS gibt es für die geregelte Kommunikation in der Regel wiederum einen Satz von Funktionen, die man verstehen muss.
Das könnte ich noch weiterführen.
Im Bereich der HF Schaltungen gibt es durchaus Analogien: Nur weil eine PA Schaltung einfach aussieht, ist sowohl das Design als auch der Aufbau selbiger durchaus eine komplexe Angelegenheit. Und nur weil ich die Schaltung "lesen" kann, heißt das noch lange nicht, das ich sie verstehe und erfolgreich modifizieren kann.
Andere und ich haben und werden noch eine ganze Menge Zeit in die "Verschönerung" und "Vereinfachung" der mcHF stecken, genau mit dem Ziel möglichst vielen Nutzer die Möglichkeit zu geben, selber Hand anzulegen. (Dazu gehört übrigens auch die möglichst einfache Bereitstellung von Build-Environment(s))
Aber einfach im Sinne von trivial wird es leider wohl nicht.
Ich denke allerdings, für jeden, der mitmachen möchte und sich ernsthaft einbringen will, sollte das mit überschaubaren Aufwand möglich sein.
Da gibt es auch schon tolle Beispiele, das sowas jetzt schon funktioniert, ich sag nur neue Audio Filter (schwarze Magie aus meiner Sicht), die wir Frank verdanken.
73
Danilo
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 06. April 2016, 20:30:27
Full ACK, Danilo.
Eigenhändig ein OS auf den STM32 portieren macht man nur, wenn man Geld dafür bekommt :) Und dann kann es sogar richtig Spaß machen. Schön ist allerdings, dass heute noch an und mit dem OS gearbeitet wird, obwohl ich da schon einige Jahre Pause machen musste.
Generell ist die Zerlegung der mcHF Software von Vorteil, ob in Hinsicht auf ein späteres OS oder einfach nur, damit man sich nicht dauern im Weg steht, ist dabei egal :)
Neben detaillierten und abstrahierten Funktionen machen auch Header-Files mit exakten Beschreibungen der Funktionen Sinn...
Im Hinblick auf NutO/S muss man sagen, dass die Strukturen einfach gehalten sind. Ein verpflichtendes Timing gibt es nicht. Daher ist die massive Nutzung von Interrupts, die high prio ablaufen unkritisch. Auf der anderen Seite ist das OS entstanden, um mit einem ATmega128 und einer alten ISA Ethernet Karte einen Webserver zu bauen. Später ist das Elektor Internetradio daraus entstanden. Es ging dabei also immer um wenig flash und effiziente Nutzung nicht vorhandener Sourcen.
Ein schickes Memory Management mit Stack und Heap ist allerdings etwas, an das man sich leicht gewöhnt und dann nicht mehr missen will. Das Threads, die nicht laufen auch keinen Speicher benötigen, man aber große Strukturen im Code anlegen kann, die diesen Speicher komfortabel beschreiben, wenn er denn genutzt wird, ist schick. Ich gerate schon wieder ins Schwärmen...
Mann, ich will endlich die Prüfung hinter mir haben, dann kann ich mich voll und ganz auf den mcHF konzentrieren :)
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 07. April 2016, 08:16:36
Kann aber auch sein, dass die Windows-User von Linux eingeholt werden und wir eh die gleichen Toolchains nutzen können:
http://www.heise.de/newsticker/meldung/Hands-on-Das-neue-Linux-Subsystem-in-Windows-10-3163994.html
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 08. April 2016, 05:31:34
Hallo Ulrich,
habe von Dir eine Mail mit dem Subject:
Neue Diskussions- und Newsboard des DARC-Ortsverbandes I40-Mitteilung: ((Kein Betreff)) erhalten, konnte aber nicht darauf antworten.
Fehlerbericht vom Server 'Der Mailversand zum folgenden Empfänger ist endgültig gescheitert:'
Eine Suche nach 'Astralix' im Forum brachte auch keine Mailadresse zum Vorschein.
Wie kann ich Dir Antworten - Gibt es hier PN's, wie in anderen Foren?
vy73
Markus
DL8MBY
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 08. April 2016, 06:03:31
Einfach auf den Usernamen im Beitrag klicken und dann im Infofenster, das dann aufgeht, auf "Diesem Mitglied eine private Mitteilung senden" klicken.
vy 73
Andreas |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 08. April 2016, 06:21:36
Hallo Andreas,
Danke hat geklappt.
Wie kann ich dann meine eigenen an Mich adressierten PNs lesen?
Auch auf meinen eigenen Forum-Namen klicken oder auf den
Button 'Benachrichtigungen' im Forumshaeder gehen.
Sorry für die Fragerei.
vy73
Markus
DL8MBY |
Title: Re:Hilfe beim Flashen via JLink
Post by: dl8mby on 08. April 2016, 06:25:40
Hallo Andreas,
was mich noch etwas verusnischert ist die Reaktion der Forum-Web-App:
Nach dem Absenden der vorhergehenden Nachricht bekomme ich
eine fast leere Seite mit folgender Message angezeigt:
=====================================================
Forbidden
You don't have permission to access /forum/index.php on this server.
=====================================================
Mein Beitrag wird aber dennoch ins Forum gestellt.
Irgend eine Idee, woran das liegt?
Markus
|
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 08. April 2016, 07:18:47
Diese Fehlermeldung habe ich auch hin und wieder mal. Seltsam, aber wenn man dann ein paar mal zurück und wieder vorgesprungen ist, ist sie plötzlich weg.
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DC3AX on 08. April 2016, 07:19:18
Diese Fehlermeldung habe ich auch hin und wieder mal. Seltsam, aber wenn man dann ein paar mal zurück und wieder vorgesprungen ist, ist sie plötzlich weg.
Nachtrag:
Genau jetzt hatte ich sie. Ich bin aber als Astralix eingeloggt.
Nachtrag 2:
Scheinbar passiert das, wenn der Browser die Seite nicht vom Server lädt, sondern aus dem Cache ( weil man seine 142 Lieblings-Tabs immer automatisch mit öffnet beimm Start)
Lösung:
Man muss die Seite 1x neu laden, dann ist die Meldung weg. Meistens ist dann aber der angeblich unzulässige Post dann auch schon da.
vy 73 de Ulrich |
Title: Re:Hilfe beim Flashen via JLink
Post by: DF8OE on 08. April 2016, 07:37:56
Richtig - das ist ein Browsercache-Problem.
Don't care about this.
vy 73
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|