Hi Neil, +1 for me too. This would really be handy in long range. Obviously, one point to solve is how to deal with pinmuxing. I see at least 3 options: a) Keep board independant pinmuxing, and up to

Hi Erwin, Indeed, make flash functionality has been lost when moving to dts description. The issue is reported in JIRA: https://jira.zephyrproject.org/browse/ZEP-2119 Andy proposed a PR to correct thi

Hi Neil, all, I can only acknowledge that, despite hard work from community, we still currently miss important drivers on STM32 SoCs. On ST side, roadmap was to port Disco L475 IoT board, and after ad

Hi Erwin, I'm not aware of anyone working on this. Do you intend to work on it? Erwan

Hi Siddharth, Switch should be created by ext/hal/st/stm32cube/Makefile from CONFIG_SOC flag. The right way to configure this flag is to define your SoC in arch/arm/soc/st_stm32/stm32f1/Kconfig.defcon

If we rely on stm32cube SDK, compilation switch "STM32F103x8" was not created because STM32F103xB was enough to specify both STM32F103x8 and STM32F103xB from software point of view. One difference obv

According to ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h, you should use STM32F103xB: /* #define STM32F103xB */ /*!< STM32F103C8, STM32F103R8, STM32F103T8, STM32F103V8, STM32F103CB, STM32F103RB, ST

Hi Siddharth, Thanks for the update. I'll have a look about STM32F103x8 and get back to you. This is indeed strange not having a define for this part. Erwan

Hi Daniel, I think I spotted the bug, which is indeed in the commit you pointed. It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4. I've pushed following commi

Hello Siddharth, It seems your porting miss the pinmux configuration driver file, cf: drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c Then, you'll have to create a new CONFIG value "SOC_STM32F103X8"

To answer your initial question, below example should work struct device *uartGPS; uartGPS = device_get_binding(CONFIG_UART_STM32_PORT_1_NAME); while (1) { unsigned char recvChar; while (uart_poll_in(

Hi Dhamu, I saw the task you entered in Jira afterwards and now better understand your question. Indeed, you might need additional settings to get these ports working: One point is that you should act

Hi Digidhamu, If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2. Erwan

Hi Paul, Daniel, About stm32 driver and Cube HAL, I'd like to mention that a Low Level cube API is now available on almost all stm32 families (LL). This API intends to be lightweight and modular and h

Hi Jon Ok, This is indeed a valid reason, even if a bit confusing. What about making this explicit in the API? Thanks anyway for the input.

Exact, I just don't see why we specify 2 messages in API (msg[0] and msg[1]), if we want driver to send one single message. There should be a reason, but I don't get it, and this was basically my init

My view (but this could be an error from my part), is that defining a message involves having a header byte (Slave Address | Write) being issued before payload. Payload being: *subaddress (or start ad

Invalid and not working, it has to be fixed. My issue is which part Agreed. Driver should be fixed to generated RESTART instead of STOP/START. Sorry if I missed an element, but I'm not sure to get you

Hi Piotr, Sure, I'm glad to be able to discuss this topic. Agreed. Problem is actually a bit different. Generated message is as follows (2 separated messages actually) S Addr Wr [A] subAddr [A] P S Ad

Same on stm32: UART driver uses HAL for driver initialization. I made an update of stm32cube today and Low Level API is now supported on stm32f4/f3/l4 based boards. We can save around 1K moving from H