-
Thread
STM32WL kein Signal auf MISO-Leitung bei SUBGHZ SPI
Hallo, Ich versuche, eine SPI-Kommunikation mit dem integrierten LoRa-Transceiver des STM32WL einzurichten. Die NSS,MOSI und SCK-Datenleitungen scheinen zu funktionieren, jedoch erhalte ich keine Rückmeldung des LoRa-Transceivers auf der MISO-Leitung. Mein Code ist der folgende: [c
Manuel N. schrieb im Beitrag #7909988: > STM32WL kein Signal auf MISO-Leitung bei SUBGHZ SPI Ist nicht alles unter 1 GHz irgendwie "SUBGHZ"? scnr Wie ist die Zeitskala in SPI_SUBGHZ_debug.png?
-
Thread
EnOcean PTM210/PTM215 – Empfänger mit STM32WL3x statt TCM310 realistisch?
Stelligen bereich handelt, habe ich mir aus Kostengründen überlegt, die Empfängerseite neu mit einem STM32WL3x zu machen, da dieser MCU direkt einen Funk-Transceiver integriert hat und auch ein Stück günstiger als die TCM310-Module ist. Nun zu meiner Frage: Lässt sich das überhaupt umsetzen? Ist das
nachgebaut" werden. Wenn Du also in der Lage bist, die in der Luft übertragenen Daten mit einem STM32 in ein gültiges EnOcean-Telegramm zu wandeln und auszuwerten, steht dem nichts im Weg. Allerdings ist der Aufwand, was Entwicklung und Zertifizierung betrifft nicht zu unterschätzen, deshalb bin
-
Thread
STM32 Summit - 18nm-STM32, STM32WL3R, STM32-AI-Assistent und Erweiterungen des Ökosystems
HHGrace als Second Source in China online: asbalding sollen erste komplett in China gefertigte STM32-Chips verfügbar werden. ### Keynote, 2 - STM32V8, ein 18nm-STM32 mit höherer Strahlungsresistenz Die wichtigste Ankündigung betrifft den STM32V8: eine neue Spielart des STM32, die auf 18nm-Technologie
schnellster STM32-Mikrocontroller ist der STM32V8 für hohe Zuverlässigkeit unter rauen Umgebungsbedingungen ausgelegt, wo er deutlich größere, mehr Strom verbrauchende Applikations-Prozessoren ersetzen kann. Der STM32V8
-
Thread
stm32F4Discovery mit Coocox Beispielen und Quickstart
-O3 -Wl,--gc-sections -LC:\CooCox\CoIDE\configuration\ProgramData\STM32F4_GPIO_INPUT_OUTPUT -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\STM32F4_GPIO_INPUT_OUTPU T/arm-gcc-link.ld -g -o STM32F4_GPIO_INPUT_OUTPUT.elf ..\obj\startup_stm32f4xx.o ..\obj\main.o ..\obj\stm32f4xx_rcc.o ..\obj\stm32f4xx_gpio.o ..\obj\system_stm32f4xx.o ..\obj\stm32f4xx_tim.o [cc] arm-none-eabi-gcc: error: unrecognized command line option '-Wl
-
Thread
CooCox CoIDE mit STM32F4-Discovery Board
.\obj\stm32f4xx_adc.o ..\obj\stm32f4xx_dcmi.o ..\obj\stm32f4xx_cryp_des.o ..\obj\stm32f4xx_cryp.o ..\obj\stm32f4xx_fsmc.o ..\obj\stm32f4xx_gpio.o ..\obj\stm32f4xx_flash.o ..\obj\system_stm32f4xx.o ..\obj\stm32f4xx_dma.o
] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -g -nostartfiles -Wl,-Map=OpenMCP.map -O0 -Wl,--gc-sections -LC:\STM32\CoIDE\configuration\ProgramData\myWeb_ENC28J60 -Wl,-TC:\STM32\CoIDE\configuration\ProgramData\myWeb_ENC28J60/arm-gcc-link.ld -g -o OpenMCP.elf ..\obj
-
Thread
Wo minimal board für ARM ( z.B. STM32U031K8U3) holen
Niklas G. schrieb im Beitrag #8069072: > STM32 + LoRa gibt's sogar in Form eines einzelnen Chips, der STM32WLE5 / > STM32WL55 . Der basiert auf der gleichen Ultra-Low-Power- Technologie > wie die STM32Uxx, hat aber ein paar extra Gimmicks um die Integration > der beiden Chips zu verbessern. > > Den STM32WLE5 kann man z.B. in Form der Wio-E5 -Module bekommen wo die > nötigen HF-Komponenten integriert sind: Ich würde den STM32WL5MOC nehmen, der auf dem STM32WL55 ohne E basiert. Der hat nämlich
-
Thread
STM32F4Discovery mit CooCox :: GPIO,SDIO,Timer,SoftTimer,USART,printf
link [cc] arm-none-eabi-gcc -O0 -nostartfiles -Wl,-Map=Stm32F407_blink.map -mcpu=cortex-m4 -mthumb -LC:\Users\tw\Documents\CooCox\Stm32F407_blink -Wl,--gc-sections -Wl,-TC:\Users\tw\Documents\CooCox\Stm32F407_blink\arm-gcc-link.ld -g -o Stm32F407_blink.elf
\ProgramData\Stm32F407_blink -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\Stm32F407_blink/arm-gcc-link.ld -g -o Stm32F407_blink.elf ..\obj\stm32f4xx_syscfg.o ..\obj\stm32f4xx_sdio.o ..\obj\fswrapper.o ..\obj\stm32f4xx_usart.o
-
Thread
STM32 linker scripts
Natürlich muß die newlib auf dem STM32 laufen.
Lite\lib Somit werden die korrekten libc und libgcc jetzt ausgewählt. Außerdem habe ich mir die STM32F10x_StdPeriph_Lib_V3.1.2 von ST heruntergeladen. Aus dem Verzeichnis ..\STM32F10x_StdPeriph_Lib_V3.1.2\Libraries\CMSIS\Core\CM3\startup\gcc benutzte ich startup_stm32f10x_md.s als Startup-Code. Als
-
Thread
LoRa-Parameter
self.ser.write(data), und damit direkt an Serial... Rahul D. schrieb im Beitrag #7909115: > Ein STM32-Modul, wie es auch auf dem NUCLEO-Board verwendet wird. Das Nucleo-Board hat kein Modul, sondern einen nackten STM32WL55JC plus diskretes Anpassungsnetzwerk und LP/HP-Umschaltung, da ist dann nur
ein Modul, weil da mehrere einzelne ASICs in einem Gehäuse gebondet sind. Fakt ist, dass der nackte STM32WL55 wie er auf den Nucleo zu finden ist, nicht so einfach in ein eigenes PCB zu integrieren ist (layouttechnisch), aber sowas wie Wio-E5, STM32WL5MOC, Wio-E5 etc. aber schon. Gleiches gilt für den
-
Thread
Runtime Libs aus gcc-arm-none-eabi
#6616845: > Den Linker nicht direkt aufrufen, das führt zu [c] arm-none-eabi-gcc -mcpu=cortex-m3, -Wl,-gc-sections -Wl,-M=map.txt -Wl,-T./link.ld ./o/stm32f10x_dma.o ./o/main.o ./o/stm32f10x_rcc.o ./o/stm32f10x_flash.o ./o/cpuinit.o ./o/stm32f10x_it.o ./o/flop.o ./o/misc.o ./o/stm32f10x_tim.o ./o/stm32f10x_adc.o
die neue Brille hat dabei etwas nachgeholfen: [c] make arm-none-eabi-gcc -mcpu=cortex-m3 -Wl,-gc-sections -Wl,-M=map.txt -Wl,-T./link.ld ./o/stm32f10x_dma.o ./o/main.o ./o/stm32f10x_rcc.o ./o/stm32f10x_flash.o ./o/cpuinit.o ./o/stm32f10x_it.o ./o/flop.o ./o/misc.o ./o/stm32f10x_tim.o ./o/stm32f10x_adc.o
-
Thread
[arm] Kompileroption -flto bewirkt daß der uart (ungefähr) doppelt so schnell läuft
=cortex-m4 -mthumb-interwork -Wl,--gc-sections Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c arm-none-eabi-gcc -c -o stm32f4xx_hal_rcc.o -Isrc/ -IDrivers/STM32F4xx_HAL_Driver/Inc/ -IDrivers/CMSIS/Device/ST/STM32F4xx/Include/ -IDrivers
/ -DSTM32F401xE -Os -flto -ffunction-sections -mlittle-endian -mthumb -mcpu=cortex-m4 -mthumb-interwork -Wl,--gc-sections Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_uart.c arm-none-eabi-gcc -c -o stm32f4xx_hal_dma.o
-
Thread
STM32 GCC Compilereinstellungen für Minimum Size -Os
0xb4 stm32f1xx_hal_msp.o 0xb8 stm32f1xx_hal_msp.o 0xb8 stm32f1xx_hal_msp.o 0xd8 stm32f1xx_hal_msp.o 0xd8 stm32f1xx_hal_msp.o 0x104 stm32f1xx_hal_msp.o
-mcpu=cortex-m3 -mthumb -mfloat-abi=soft -L Drivers/CMSIS -specs=nosys.specs -specs=nano.specs -T"STM32F103C6Tx_FLASH_Bootloader.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "build/EBiCS_Firmware.elf" @"objects.list" -larm_cortexM3l_math -lm arm-none-eabi-gcc: error: build/startup_stm32f103x6.o: No
-
Thread
doppelte deklaration einer funktion
DHSE_VALUE=8000000 -g -Wa,--warn -x assembler-with-cpp -o ..\src\real\arm\asmpoly_thumb2.s -lm -o STM32F105RB_SDCARD.elf -mthumb -mcpu=cortex-m3 -T..\stm32_flash.ld -static -Wl,-cref,-u,Reset_Handler -Wl,-Map=STM32F105RB_SDCARD.map -Wl,--gc-sections -Wl,--defsym=malloc_getpagesize_P=0x1000[/code]
\asmmisc.o -lm -o STM32F105RB_SDCARD.elf -mthumb -mcpu=cortex-m3 -T..\stm32_flash.ld -static -Wl,-cref,-u,Reset_Handler -Wl,-Map=STM32F105RB_SDCARD.map -Wl,--gc-sections Wl,--defsym=malloc_getpagesize_P=0x1000 [/code
-
Thread
Wer sucht ein Wettbewerbsthema?
'"D:\stm32\stm103gui\STM103_LCD_GUI\MDK_Project\Project_Target 1\User\system_stm32f10x.c"' '"D:\stm32\stm103gui\STM103_LCD_GUI\MDK_Project\Project_Target 1\Lib\Embedded_GUI_HAL\src\LcdHal.c"' '"D:\stm32\stm103gui
[cc] arm-none-eabi-gcc -O0 -nostartfiles "-Wl,-Map=Project_Target 1.map" -mthumb "-LD:\stm32\stm103gui\STM103_LCD_GUI\MDK_Project\Project_Target 1" -Wl,--gc-sections "-Wl,-TD:\stm32\stm103gui\STM103_LCD_GUI\MDK_Project\Project_Target 1/link.ld"
-
Thread
Linker: cannot find libc.a
*************************************************************************** arm-none-eabi-gcc -Wl,-Map=main.map -nostartfiles -mcpu=cortex-m3 -mthumb -Tadditionals/ST_SimpleMAC/STM32W108/hal/micro/cortexm3/stm32w108/gnu-stm32w108xB.ld -Tadditionals/ST_SimpleMAC/STM32W108/hal/micro/cortexm3/stm32w108/gnu-stm32w108.ld -mthumb -Wl,additionals/ST_SimpleMAC/STM32W108/simplemac/library/simplemac-library.a crt_stm32w108.o context-switch.o spmr.o adc.o temperature_sensor.o system-timer.o board.o uart.o mfg-token.o
-
Thread
STM3240G-EVAL Beispielprogramm
/inc -I../../../../Libraries/CMSIS/Device/ST/STM32F2xx/Include -I../../../../Libraries/STM32F2x7_ETH_Driver/inc -I../../../../Utilities/STM32_EVAL -I../../../../Utilities/STM32_EVAL/Common -I../../../../Utilities/STM32_EVAL/STM322xG_EVAL -I../../.
musst Du dem Linker noch sagen, was er machen soll: -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -T"..\STM32F207IG_FLASH.ld" -static -L../../../../Utilities/STM32_Audio/Addons/SpiritDSP_Equalizer -L../../../../Utilities/STM32_Audio/Addons/SpiritDSP_LoudnessControl -Wl,-cref,-u,Reset_Handler,--no-wchar-size-warning
-
Thread
sscanf() mit -mfloat-abi=hard
..\obj\common_data.o ..\obj\stm32f4xx_usart.o ..\obj\stm32f4xx_can.o ..\obj\epos.o ..\obj\drive.o ..\obj\startup_stm32f4xx.o ..\obj\main.o ..\obj\stm32f4xx_rcc.o ..\obj\printf.o ..\obj\can.o ..\obj\default_hardware.o ..\obj\odometry.o ..\obj\can_drive.o ..\obj\stm32f4xx_gpio.o ..\obj\stm32f4xx_flash.o ..\obj\system_stm32f4xx.o ..\obj\syscalls.o ..\obj\misc.o ..\obj\serial.o ..\obj\spline.o ..\obj\circular_buffer.o ..\obj\stm32f4xx_tim.o "-L..\..\..\..\..\..\.
-
Thread
Cortex M4/STM32F4: Problem mit BLX Instruktion
'"C:\Program Files\arm-none-eabi-gcc-4_6\arm-none-eabi\lib\fpu\libc.a"' ..\obj\startup_stm32f4xx.o ..\obj\main.o ..\obj\stm32f4xx_rcc.o ..\obj\timers.o ..\obj\tasks.o ..\obj\stm32f4xx_gpio.o ..\obj\list.o ..\obj\system_stm32f4xx.o ..\obj\port.o ..\obj\queue.o ..\obj\croutine.o ..\obj\heap
'"C:\Program Files\arm-none-eabi-gcc-4_6\arm-none-eabi\lib\fpu\libc.a"' ..\obj\startup_stm32f4xx.o ..\obj\main.o ..\obj\stm32f4xx_rcc.o ..\obj\timers.o ..\obj\tasks.o ..\obj\stm32f4xx_gpio.o .. [/code]
-
Thread
STM32VL-Discovery & printf
linken schief: [code] [cc] Starting link [cc] arm-none-eabi-gcc -O0 -nostartfiles -Wl,-Map=Print1.map -mcpu=cortex-m3 -mthumb -LC:\CooCox\CoIDE\workspace\Print1 -Wl,--gc-sections -Wl,-TC:\CooCox\CoIDE\workspace\Print1\link.ld -g -o Print1.elf ..\obj\startup_stm32f10x_md_vl.o ..\obj\core_cm3.o ..\obj\system_stm32f10x.o ..\obj\stm32f10x_pwr.o ..\obj\stm32f10x_gpio.o ..\obj\main.o ..\obj\stm32f10x_rcc.o ..\obj\stm32f10x_usart.o ..\obj\maiin.o [cc] c:/program files/arm-none-eabi-gcc-4_6/bin/../lib/gcc
-
Thread
STM32F103 USB CDC von W.S.
nano.specs -mfloat-abi=soft -mthumb Die Compiler Optionen sind: -mcpu=cortex-m3 -std=gnu11 -DSTM32 -DSTM32F1 -DSTM32F103C8Tx -c -I"/home/stefan/Programmierung/STM32/STM32F103_usb_test/CMSIS/core" -I"/home/stefan/Programmierung/STM32/STM32F103_usb_test Die Linker Optionen sind: -mcpu=cortex-m3 -T"/home/stefan/Programmierung/STM32/STM32F103_usb_test/LinkerScript.ld" --specs=nosys.specs -Wl,-Map="${ProjName}.map" -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
-
Thread
STM32CubeMX C++ SW4STM32 TrueStudio
weak=__attribute__((weak)) -D__packed=__attribute__((__packed__)) -DUSE_HAL_DRIVER -DSTM32F411xE -I"D:/10_STM32F411/14_SW4STM32/test1/Inc" -I"D:/10_STM32F411/14_SW4STM32/test1/Drivers/STM32F4xx_HAL_Driver/Inc" -I"D:/10_STM32F411/14_SW4STM32/test1/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy" -I"D
sp-d16 -D__weak=__attribute__((weak)) -D__packed=__attribute__((__packed__)) -DUSE_HAL_DRIVER -DSTM32F411xE -I"D:/10_STM32F411/14_SW4STM32/test1/Inc" -I"D:/10_STM32F411/14_SW4STM32/test1/Drivers/STM32F4xx_HAL_Driver/Inc" -I"D:/10_STM32F411/14_SW4STM32/test1/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy" -I"D
-
Thread
STM32F4 CoOS
\STM32F4_Discovery_CoOs\UART\usart.c:107:0: warning: ignoring #pragma import [-Wunknown-pragmas] [cc] Starting link [cc] arm-none-eabi-gcc -O1 -nostartfiles -Wl,-Map=STM32F4_Discovery_CoOs.map -mcpu=cortex-m4 -mthumb -LC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs -Wl,--gc-sections -Wl,-TC:\CooCox\CoIDE\workspace\STM32F4_Discovery_CoOs/link.ld -g -o STM32F4_Discovery_CoOs.elf ..\obj\kernelHeap.o ..\obj\core.o ..\obj\timer.o ..\obj\utility.o
-
Thread
STM32F4 zieht zu viel Strom
kommen auf unter 1mA im "Run" Modus bei niedriger Frequenz, und < 1μA im Standby... Die modernen STM32WL können aber auch >100mA ziehen bei voller Sendeleistung 😉
Niklas G. schrieb im Beitrag #7979922: > Die modernen STM32WL können aber auch >100mA ziehen bei voller > Sendeleistung 😉 Äpfel und (funkende) Birnen? Der eine spricht von unprogrammierten F4-Controllern, der andere von WL.
-
Thread
STM32 - Problem beim Compilieren mit CooCox ([cc] collect2.exe: error: ld returned 1 exit status)
[cc] Starting link [cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -g -nostartfiles -flto -Wl,-Map=Test2.map -O0 -Wl,--gc-sections -Wl,--entry=main -LC:\CooCox\CoIDE\configuration\ProgramData\Test2 -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\Test2/arm-gcc-link.ld -g -o Test2.elf ..\obj\stm32f4xx_syscfg.o ..\obj\startup_stm32f4xx.o ..\obj\main.o ..\obj\stm32f4xx_rcc.o ..\obj\stm32f4xx_gpio.o ..\obj\system_stm32f4xx.o ..\obj\stm32f4xx_exti.o ..\obj\misc.o ..\obj\stm32f4xx_tim.o [cc] C:\Users\JanW\AppData\Local\Temp
-
Thread
C++ mit CooCox
.\obj\stm32f4xx_syscfg.o ..\obj\stm32f4_discovery_audio_codec.o ..\obj\stm32f4xx_usart.o ..\obj\stm32f4xx_dac.o ..\obj\startup_stm32f4xx.o ..\obj\stm32f4_discovery.o ..\obj\main.o ..\obj\stm32f4xx_rcc.o ..\obj\stm32f4xx_gpio.o ..\obj\system_stm32f4xx.o ..\obj\stm32f4xx_dma.o ..\obj\stm32f4_discovery_callbacks.o ..\obj\stm32f4xx_spi.o ..\obj\stm32f4xx_i2c.o ..\obj\stm32f4xx_exti.o ..\obj\misc.o ..\obj\stm32f4_
-
Thread
STM32 mit Simulink und TrueSTUDIO
gut kenne ich mich leider nicht in C aus das Problem zu beheben :/ [code] .......startup\startup_stm32f407xx.o -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -T../STM32F407VG_FLASH.ld -specs=nosys.specs -static -Wl,-Map=test3.map -Wl,--gc-sections -Wl,--defsym=malloc_getpagesize_P=0x80 -Wl,--start-group -lc -lm -Wl,--end-group -specs=nano.specs Src\main.o: In function `main': C:\Users\Desktop\stm32board_test\test3\Debug/..\Src/main.c:149: undefined reference to `test_initialize'
-
Thread
includes in Cube IDE
die Fehler kommen, auch wenn ich es in die Main schreibe. [c] arm-none-eabi-g++ -o "Exxcellence STM32U599 Rev1.elf" @"objects.list" -l:libtouchgfx-float-abi-hard.a -mcpu=cortex-m33 -T"C:\Users\tola5\Desktop\Exxcellence\STM32U599ZJTXQ_FLASH.ld" --specs=nosys.specs -Wl,-Map="Exxcellence STM32U599 Rev1
++ -lsupc++ -Wl,--end-group c:\st\stm32cubeide_1.12.1\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.200.202301161003\tools\arm-none-eabi\bin\ld.exe: ./TouchGFX
-
Thread
CubeMX mit Coocox verwenden
-g -o Test.elf ..\obj\stm32f4xx_hal_tim.o ..\obj\stm32f4xx_hal_flash.o ..\obj\stm32f4xx_hal.o ..\obj\stm32f4xx_hal_rcc.o ..\obj\stm32f4xx_hal_tim_ex.o ..\obj\stm32f4xx_hal_rcc_ex.o ..\obj\startup_stm32f407xx.o ..\obj\stm32f4xx_hal_msp.o ..\obj\stm32f4xx_hal_dma.o ..\obj\stm32f4xx_hal_pwr.o ..\obj\system_stm32f4xx.o ..\obj\stm32f4xx_hal_cortex.o ..\obj\stm32f4xx_hal_pwr_ex.o ..\obj\stm32f4xx_hal_flash_ex.o ..\obj\stm32f4xx_it.o ..\obj\syscalls.o
-
Thread
Programm unter Busybox nicht ausführbar
Binärdatei auf mein Board gebracht. Auf einer x86/amd64 Maschine? Dir ist schon klar, dass ein STM32 Prozessor kein x86/amd64 Binary ausführen kann? Du musst den gcc des embedded Linux als cross compiler nehmen, sprich, du musst die eine Toolchain installieren. > Ich habe auf einem STM32 ein
µCLinux in der Version 2.6.33. Ich hab das ganze hier nach gemacht: https://github.com/AdrianHuang/stm32f429-linux-builder 2⁵ schrieb im Beitrag #4684524: > Auf einer x86/amd64 Maschine? Dir ist schon klar, dass ein STM32 > Prozessor > kein x86/amd64 Binary ausführen kann? Inzwischen schon.
-
Thread
CrossStudio / CrossWorks
‘stm32l1xx_hal_i2c.c’ 4> Compiling ‘stm32l1xx_hal_pwr.c’ 1> Compiling ‘stm32l1xx_hal_pwr_ex.c’ 2> Compiling ‘stm32l1xx_hal_rcc.c’ 3> Compiling ‘stm32l1xx_hal_rcc_ex.c’ 1> Compiling ‘stm32l1xx_hal_rtc_ex.c’ 4> Compiling ‘stm32l1xx_hal_rtc.c’ 2> Compiling ‘stm32l1xx_hal_spi.c’ 1> Compiling ‘stm32l1xx_hal_uart.c’ 3> Compiling ‘stm32l1xx_hal_spi_ex.c’ 2> Compiling ‘stm32l1xx_hal_cortex.c’ 4> Compiling ‘stm32l1xx_hal_usart.c
-
Thread
STM32F4Discovery mit CooCox CoOS-RTOS und printf
C:\Users\daniel\Dropbox\stm32f4\STM32F4_Discovery_CoOS\CoOS\kernel\task.c C:\Users\daniel\Dropbox\stm32f4\STM32F4_Discovery_CoOS\cmsis_boot\startup\startup_stm32f4xx.c C:\Users\daniel\Dropbox\stm32f4\STM32F4_Discovery_CoOS\stm32f4
[cc] Starting link [cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -g -nostartfiles -Wl,-Map=STM32F4_Discovery_CoOS.map -Os -Wl,--gc-sections -LC:\CooCox\CoIDE\configuration\ProgramData\STM32F4_Discovery_CoOS -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\STM32F4_Discovery_CoOS/arm-gcc-link.ld
-
Thread
Welchen Controller für C++ Programmierung? Gesperrt
AVR Studio + Atmel (8bit/32bit) Cocox + STM32 Codecomposer (Eclipse) + MSP430xxxx
Arduino gibt es hält massig Tutorials. Deshalb nahm ich das ja. Wobei halt noch nicht alles auf den stm32 portiert ist. Die Details gibt es im Forum www.stm32duino.com .
-
Thread
gdb breakpoint setzen
mecrisp-stellaris-stm32f407.bin : memmap mecrisp-stellaris-stm32f407.o $(ARMGNU)-ld -e Reset -o mecrisp-stellaris-stm32f407.elf -T memmap mecrisp-stellaris-stm32f407.o $(ARMGNU)-objdump -D mecrisp-stellaris-stm32f407
all : mecrisp-stellaris-stm32f407.bin mecrisp-stellaris-stm32f407.o : mecrisp-stellaris-stm32f407.s $(ARMGNU)-as -al mecrisp-stellaris-stm32f407.s -o mecrisp-stellaris-stm32f407.o >mecrisp-stellaris-stm32f407.lst
-
Thread
STM32 USB Übertragungsproblem mit Code von S.F.
fstack-usage --specs=nano.specs -mfloat-abi=soft -mthumb GCC Linker: -mcpu=cortex-m0 -T"C:\Users\Alex\STM32CubeIDE\workspace_1.4.0\SFusbTest2\STM32F042F6PX_FLASH.ld" --specs=nosys.specs -Wl,-Map="${ProjName}.map" -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group -mcpu=cortex-m0 -T"C:\Users\Alex\STM32CubeIDE\workspace_1.4.0\SFusbTest2\STM32F042F6PX_FLASH.ld" --specs=nosys.specs -Wl,-Map="${ProjName}.map" -Wl,--gc-sections -static --specs=nano.specs
-
Thread
STM32F4 adc atan2 problem
-I../Libraries/STM32_USB_Device_Library/Core/inc/ -I../Libraries/STM32_USB_OTG_Driver/inc/ -Wl,-T,stm32_flash.ld main.c init.c syscalls.c stm32f4xx_it.c system_stm32f4xx.c stm32f4_discovery.c printf.c ../Libraries/STM32F4xx_StdPeriph_Driver
-I../Libraries/STM32_USB_Device_Library/Core/inc/ -I../Libraries/STM32_USB_OTG_Driver/inc/ -Wl,-T,stm32_flash.ld main.c init.c syscalls.c stm32f4xx_it.c system_stm32f4xx.c stm32f4_discovery.c printf.c ../Libraries/STM32F4xx_StdPeriph_Driver
-
Thread
ATMEL SAM3X8 (Arduino Due) printf auf beliebiges Device umleiten?
falls da auch der gcc-arm-embedded mit newlib genutzt wird: https://www.mikrocontroller.net/articles/STM32_Eclipse_JLink_Linux/Windows#Optional:_Syscalls_implementieren
du mit dem Atmel nicht klar kommst, dann such dir hier im Forum eines meiner Klein-Projekte mit nem STM32F103C8T6 heraus, da findest du die Eagle-Dateien, die Quellen und ein fertiges Image, so daß du erstmal damit anfangen kannst. Also stell dich nicht so an. W.S.
-
Thread
LoraWan Projekt Antenne-/Layout
man keinen vollständigen LoRaWAN Gateway. Da reicht ein LoRa-Empfänger mit einem Kanal, zumal der STM32WL5 zwar LoRa-Modulation kann, es aber von da aus zu einem LoRaWAN Modul noch ein weiterer Schritt ist.
dann aber doch. Für den STM32WL5 gibt's LoRaWAN-Stacks, alles kein Problem. Der LoRa-Empfänger mit einem Kanal ist ziemlich blöd, weil man dann die ganze Software umbasteln muss, sobald man LoRaWAN fahren will und spätestens dann
-
Thread
Versorgung LoRa Waveshare SX1268 LoRa HAT
Rahul D. schrieb im Beitrag #7885855: > oder in > einem Gehäuse mit einem STM32 Dualcore als STM32WLEx Ironisch, dass ausgerechnet der STM32WLEx die Single-Core Version ist; die Dual-Core Version ist der STM32WL5x. Und wenn schon sind hier natürlich nur der STM32WLE5 bzw. STM32WL55 relevant, da nur diese LoRa können. Kannst statt "x" also "5" schreiben.
-
Thread
[STM32/CLion] snprintf verursacht HardFault
/*.*" "Drivers/*.*" "Src/*.*") include_directories(Inc Drivers/STM32F1xx_HAL_Driver/Inc Drivers/STM32F1xx_HAL_Driver/Inc/Legacy Drivers/CMSIS/Device/ST/STM32F1xx/Include Drivers/CMSIS/Include) add_executable(${PROJECT_NAME}.elf ${SOURCES} ${LINKER_SCRIPT}) set
Jahr €159.00 /2. Jahr €119.00 /ab dem 3. Jahr Wau. Ist das fürs Hobby oder Zwang? Nur für STM32?
-
Thread
stm32f103 3phase-generator
Ich hab mal einen FU mit einem STM32F405 und dessen TIM1 gebaut. Code für den Timer ist hier: https://gitlab.com/higaski/stm32f405_vfd/blob/master/Src/Periph/pwm.c Deadtime hab ich damals keine gebraucht, da die in Hardware realisiert
grundschüler schrieb im Beitrag #4853964: > Das stm32f426-disco kostet unter 30€ So etwas gibt es nicht. Es gibt ein F407 Discovery und ein F429 Dicovery Board. http://www.st.com/en/evaluation-tools/stm32-mcu-discovery-kits.html?querycriteria=productId
-
Thread
STM32 arm-none-eabi Linking Problem..
Nach einer Weile compilierte das auch weitgehend fehlerfrei..aber: [code] ... arm-none-eabi-gcc -Wl,--gc-sections,-Map=main.elf.map,-cref,-u,Reset_Handler -L lib -T stm32.ld main.o usart.o stm32f10x_it.o eeprom.o lib/libstm32.a --output main.elf $ arm-none-eabi-objdump -d main.elf|less
estack = ORIGIN(RAM) + LENGTH(RAM); /* include the section management sub-script */ /* (either "STM32_SEC_FLASH.ld" or "STM32_SEC_RAM.ld") */ INCLUDE "STM32_SEC_FLASH.ld" [/code] lib/STM32_COMMON.ld: [code] /* Common part of the linker scripts for STR32 devices Copyright RAISONANCE 2007
-
Thread
[ARM]DiscoverF4 CycloneTCP Stack Webserver/Client Demo mit CoIDE
..\obj\yarrow.o ..\obj\mpi.o ..\obj\dsa.o ..\obj\cipher_mode_ecb.o ..\obj\stm32f4xx_can.o ..\obj\slaac.o ..\obj\stm32f4_discovery_sdio_sd.o ..\obj\ripemd128.o ..\obj\stm32f4xx_wwdg.o ..\obj\ipv4_frag.o ..\obj\stm32f4xx_hash_md5.o ..\obj\str.o ..\obj\stm32f4xx_dac.o ..\obj\tiger.o ..\obj\discard.o ..\obj\startup_stm32f4xx.o ..\obj\stm32f4x7_eth.o ..\obj\stm32f4_discovery.o ..\obj\sha512_256.o ..\obj\base64.o ..\obj\stm32f4xx_crc.o ..\obj\stm32f4xx_iwdg.o ..\obj\echo.o ..\obj\main.o ..\obj\dhcpv6_client.o ..\obj
-
Thread
ST Motor Control Firmware Library unter Coocox
-Wl,-Map=blam1.map -Os -Wl,--gc-sections -LC:\CooCox\CoIDE\configuration\ProgramData\blam2 -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\blam2/arm-gcc-link.ld -g -o blam1.elf ..\obj\stm32f30x_opamp.o ..\obj\UITask.o ..\obj\stm32f30x_rcc.o ..\obj\USART_F30X_PhysicalLayerCommunication_Class.o ..\obj\stm32f30x_adc.o ..\obj\UserInterfaceClass.o ..\obj\stm32f30x_it.o ..\obj\stm32f30x_comp.o ..\obj\stm32f30x_gpio.o ..\obj\main.o
-
Thread
STM32F3 Fehlermeldungen beim Buildvorgang
Fehlermeldungen: Building target: Template_Project.elf Invoking: Cross GCC Linker arm-none-eabi-gcc "-Wl,-Map=Template_Project.map" -o "Template_Project.elf" ./src/main.o ./src/stm32f30x_it.o ./src/system_stm32f30x.o ./STM32F3_Discovery/stm32f3_discovery.o ./STM32F30_StdPeriph_Library/stm32f30x_adc.o ./STM32F30_StdPeriph_Library/stm32f30x_can.o ./STM32F30_StdPeriph_Library/stm32f30x_comp.o ./STM32F30_StdPeriph_Library/stm32f30x_crc.o ./STM32F30_StdPeriph_Library/stm32f30x_dac.o ./STM32F30_StdPeriph_Library
-
Thread
BLDC ansteuerung die x-te
Für mein Projekt würde ich gerne einen BLDC via FET-Halbbrücke und PWM mittels STM32 controller und Blockkommutierung ansteuern. Leider scheitere ich schon an der Theorie. Ich habe gelesen das Hi- und Low Side Transistoren invers gesteuert werden müssen mit deadtime wegen shoot-through
aktiviert oder deaktiviert. Hier z.B. ist die Kernroutine für Block Kommutation aus einem meiner STM32 Projekte, STM32F103, Timer 1 ist hier der Advanced Timer: [c] // PHASES to position in TIMx_CCER register #define UH 0x0004 #define UL 0x0001 #define VH 0x0040 #define VL 0x0010 #define
-
Thread
Projekt GPS Datenlogger + OpenStreetMap
by doing". Hier http://www.stm32circle.com/resources/stm32primer2.php findest du das STM32-Primer2 user manual. Darin findet sich eine step-by-step Anleitung für deine erste Applikation. Dann kannst du daran gehen die Applikation
Update zum Contest: http://www.stm32circle.com/hom/index.php
-
Thread
GCC als Crosscompiler für ARM auf ARM
ich mir http://regalis.com.pl/en/arm-cortex-stm32-gnulinux/ ausgesucht.
arm-none-eabi-gcc -T../../common/stm32_f103_gcc.ld -mcpu=cortex-m0 -mthumb -nostartfiles -Wl,-M -o build/leds.elf build/src/main.o build/../../common/startup_stm32f10x_hd.o build/../../common/CMSIS_v3.6.1/Device/ST/STM32F10x/Source/
-
Thread
STM32H7 stemwin
arm-none-eabi-gcc -o "H743_STemwin_NT35510.elf" @"objects.list" -l"" -mcpu=cortex-m7 -T"D:\Users\Sasch\STM32CubeIDE\workspace_1.5.0\H743_STemwin_NT35510\STM32H743VITX_FLASH.ld" --specs=nosys.specs -Wl,-Map="H743_STemwin_NT35510.map" -Wl,--gc-sections -static -L"D:\Users\Sasch\STM32CubeIDE\workspace_1.5.0\H743_STemwin_NT35510\STemWinLib\Lib" --specs=nano.specs -mfpu=fpv5-d16 -mfloat-abi=hard -mthumb -Wl,--start-group -lc -lm -Wl,--end-group d:\st\stm32cubeide_1.5.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi
-
Thread
Library in Linker einbinden: Fehler not found
soft -L"C:\CMSIS_5-develop\CMSIS_5-develop\CMSIS\/Lib/ARM" -specs=nosys.specs -specs=nano.specs -T"../STM32F103C6Tx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "LishuiFOC_01.elf" @"objects.list" -larm_cortexM3l_math -lm c:/gnu_arm/eclipse/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.16.0.201807130628
soft -L"C:\CMSIS_5-develop\CMSIS_5-develop\CMSIS\Lib\GCC" -specs=nosys.specs -specs=nano.specs -T"../STM32F103C6Tx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "LishuiFOC_01.elf" @"objects.list" -llibarm_cortexM3l_math -lm c:/gnu_arm/eclipse/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.16.0.201807130628
-
Thread
CooCox neue Entwicklungsumgebung
Compilation of src/blinky.c:" "" arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -g2 -Wall -O0 -DSTM32F401VC -I./src -ID:/stm32/gnu/include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc src/blinky.c -o src/blinky.o "" "------------