Hey Anas, Yeah newlib offers hooks for a lot of things, but that not just means changing Zephyr, but also the toolchains (if I understood correctly). And here is where the 1.9 features come in, if

Not following how this is related to Posix and feature of 1.9. AFAIK, What is missing is a hook for gettimeofday in lib/libc/newlib/libc-hooks.c which can then get the needed information from the

Hello Erwin, Erwin Rol <mailinglists@...> wrote: I'm sure everyone would agree, so it's worth considering how to "fix" it (even it will be a workaround or incomplete fix) and do

hi Yannis, This is great timing. I have a working stm32f4x driver based on HAL (did a little bit of rework on one of Neil's Armstrong prototypes but nothing major just, enough to get it working). I

Hi Erwan, I actually my plan is to finally create a generic i2c_ll_stm32 driver but I started small with the stm32f4 finally because it is my first attempt to code a driver and I only have stm32f1

Hi Yannis, Thanks for this proposition. We are indeed missing I2C driver for STM32F4 family. What would be really nice is to get a generic STM32 I2C driver, working on all series (based on LL

Hey Paul, time() was just the first thing I tried to see how well newlib works, and the results was it doesn't. And that it compiles without warning and than hangs in an endless loop sounds like a

Hello, I am developing an I2C driver based on the stm32cube LL API. The driver can be found here: https://github.com/ydamigos/zephyr/tree/i2c_ll_stm32f4 The driver supports both polling and

Hey All, I rewrote it by using CONTAINER_OF() and it works fine and is lot cleaner. Tanks for the hint. - Erwin

Hi Andy, Erwan, Anas, I will send an RFC when I have some free time for it and thanks for the hints. Neil

Hello Erwin, Erwin Rol <mailinglists@...> wrote: When you want time(NULL), what are your expectations? Because as you know, what it's supposed to do is to return number of seconds

Hey all (yeah there he is again), I was wondering what the status and planning is for the C-library? I tried a simple example and I guess I directly hit a problem. The "buildin" mini C-lib doesn't

No problem, I understand it is not easy to jump in. And agreed we might miss some material to make all this clear. Great! We look forward to see it upstreamed Seems right!

Hey Neil, Erwan, thanks for the infos. I guess the confusions are largely because Zephyr is still such a young project. Under Linux there are so many drivers to look at as examples and if 10 use HAL

Indeed, for the little story I was trying to test the sensor (to upstream support for it) on the stm32f4discovery board, but when I hoocked up everything (driver, ...) to test the driver, I realized

Hi Erwin, LL based version was initiated without knowing Neil had a HAL based driver, and from what I am aware of (unless I missed this information), Neil never proposed to upstream it. I let him

Hey Erwan, Yes, I will rewrite it to use CONTRAINER_OF. So the I2C driver is being rewritten even though there is a working version (I assume Neil's HAL version is working)? Now you are making

Hi Erwin, As mentioned by Neil, CONTAINER_OF is a good solution that is used in other projects using STM32Cube. About your last point: There won't be any branching from STM32Cube for Zephyr. Generic

Hi Baohong, thanks for the clarification. I suppose: source_transfer_width should be source_data_size ? dest_transfer_width should be dest_data_size ? It is a little redundant, what is the