|
IRQ_CONNECT: enum based line number?
Hi all, I've a question around IRQ_CONNECT macro for Cortex_m defined in include/arch/arm/cortex_m/irq.h In ST CMSIS, we define IRQ line as enum. For instance: typedef enum { /****** Cortex-M3 Process
Hi all, I've a question around IRQ_CONNECT macro for Cortex_m defined in include/arch/arm/cortex_m/irq.h In ST CMSIS, we define IRQ line as enum. For instance: typedef enum { /****** Cortex-M3 Process
|
By
Erwan Gouriou
· #4025
·
|
|
IRQ_CONNECT: enum based line number?
Hi Andrew, Thanks for the detailled explanation. assembly language stubs and a special tool to generate the IDT, I need to check if it also forbids enumerations. If using enums is very desirable we co
Hi Andrew, Thanks for the detailled explanation. assembly language stubs and a special tool to generate the IDT, I need to check if it also forbids enumerations. If using enums is very desirable we co
|
By
Erwan Gouriou
· #4040
·
|
|
STM32Cube SDK in Zephyr
Hi all, There are growing number of STM32 based boards being ported in Zephyr by the community. As part of ST, I can say that we are pleased to contribute this way to Zephyr impact in IoT world. In or
Hi all, There are growing number of STM32 based boards being ported in Zephyr by the community. As part of ST, I can say that we are pleased to contribute this way to Zephyr impact in IoT world. In or
|
By
Erwan Gouriou
· #4066
·
|
|
HALs in Zephyr (was Re: STM32Cube SDK in Zephyr)
Hi Amit, Good point, I had the request to push stm32f7xx as there was some work going on with this series. Pushing the whole family on the same change. Erwan
Hi Amit, Good point, I had the request to push stm32f7xx as there was some work going on with this series. Pushing the whole family on the same change. Erwan
|
By
Erwan Gouriou
· #4092
·
|
|
Trying Nucleo-64 STM32F411RE
Hi Piotr, There was an issue on F411RE clock initialisation steps. I've submitted following change to correct it: https://gerrit.zephyrproject.org/r/9571 Hope it helps. Cheers Erwan
Hi Piotr, There was an issue on F411RE clock initialisation steps. I've submitted following change to correct it: https://gerrit.zephyrproject.org/r/9571 Hope it helps. Cheers Erwan
|
By
Erwan Gouriou
· #4343
·
|
|
Trying Nucleo-64 STM32F411RE
Hi Piotr, You should indeed first look at Zephyr documentation, and particularly i2c API. Then, regarding STM32 driver/IP, there are several sources that could help you to develop I2C driver for STM32
Hi Piotr, You should indeed first look at Zephyr documentation, and particularly i2c API. Then, regarding STM32 driver/IP, there are several sources that could help you to develop I2C driver for STM32
|
By
Erwan Gouriou
· #4450
·
|
|
Zephyr on STM32F042/072/405 with USB?
Hi Christer, Thanks in advance for these tasks. For USB support on STM32, it would be great that this work could benefit to the whole STM32 family. STM32Cube SDK could help you in implementing a singl
Hi Christer, Thanks in advance for these tasks. For USB support on STM32, it would be great that this work could benefit to the whole STM32 family. STM32Cube SDK could help you in implementing a singl
|
By
Erwan Gouriou
· #4451
·
|
|
Trying Nucleo-64 STM32F411RE
Hi Jack If you want to develop driver based on STM32Cube HAL, you could check serial or pwm drivers as example. You can also find other examples of using HAL in Cube SDK that you could download from s
Hi Jack If you want to develop driver based on STM32Cube HAL, you could check serial or pwm drivers as example. You can also find other examples of using HAL in Cube SDK that you could download from s
|
By
Erwan Gouriou
· #4460
·
|
|
[RFC] STM32 pinmux - simplify pinmux logic
Hi Christer, I agree with the observation that gpio/pinmux configuration is overcomplicated. Your proposal is interesting and look rather easy to use. Maybe you can also have a look to Adam's porting
Hi Christer, I agree with the observation that gpio/pinmux configuration is overcomplicated. Your proposal is interesting and look rather easy to use. Maybe you can also have a look to Adam's porting
|
By
Erwan Gouriou
· #4461
·
|
|
[RFC] STM32 pinmux - simplify pinmux logic
Hi Christer, The above pin definition would look like this: I agree this might be clearer for users. Since pinmux is something users might have to play with, the easier to read, the better. I can only
Hi Christer, The above pin definition would look like this: I agree this might be clearer for users. Since pinmux is something users might have to play with, the easier to read, the better. I can only
|
By
Erwan Gouriou
· #4510
·
|
|
i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, but how can i do this with arduino_due board with the same tools?
Hi, Are you using Nulceo_f411RE? If this is the case, this board embeds a ST-LINK debugger/programmer that helps you controling your board with USB. This is specific to ST developpement boards like Nu
Hi, Are you using Nulceo_f411RE? If this is the case, this board embeds a ST-LINK debugger/programmer that helps you controling your board with USB. This is specific to ST developpement boards like Nu
|
By
Erwan Gouriou
· #4580
·
|
|
Inconsistent and ever-changing device naming in Zephyr
Hi Paul, For STM32, my view is as follows: I understand the concern and need for having naming consistency, thought, I'm concerned about different instances numbering. Some starts from 0, some starts
Hi Paul, For STM32, my view is as follows: I understand the concern and need for having naming consistency, thought, I'm concerned about different instances numbering. Some starts from 0, some starts
|
By
Erwan Gouriou
· #80
·
|
|
Daily digests...
+1, is there any action to get them back or should we live with it from now on?
+1, is there any action to get them back or should we live with it from now on?
|
By
Erwan Gouriou
· #251
·
|
|
i2c_burst_write API
Hi all, I'm having trouble using i2c_burst_write to configure several registers in one shot in a sensor (using i2c_stm32lx.c driver). According to API description, it seems to be the adequate use: " T
Hi all, I'm having trouble using i2c_burst_write to configure several registers in one shot in a sensor (using i2c_stm32lx.c driver). According to API description, it seems to be the adequate use: " T
|
By
Erwan Gouriou
· #310
·
|
|
Minimal Zephyr build
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
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
|
By
Erwan Gouriou
· #328
·
|
|
i2c_burst_write API
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
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
|
By
Erwan Gouriou
· #354
·
|
|
i2c_burst_write API
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
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
|
By
Erwan Gouriou
· #360
·
|
|
i2c_burst_write API
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
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
|
By
Erwan Gouriou
· #367
·
|
|
i2c_burst_write API
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
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
|
By
Erwan Gouriou
· #371
·
|
|
i2c_burst_write API
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.
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.
|
By
Erwan Gouriou
· #374
·
|