Inconsistent GPIO pulse timing when bit-banging (ws2812) on nrf9160 in Zephyr

RE: Inconsistent GPIO pulse timing when bit-banging (ws2812) on nrf9160 in Zephyr

Voxorin — Tue, 21 May 2024 13:40:12 GMT

I don't think the LFCLK is has a high enough resolution for this case unfortunately.

I also posted on stackoverflow regarding the assembly and got some good suggestions. Not luck so far though.

stackoverflow.com/.../assembly-nop-delays-in-c-code-have-inconsistent-timing-on-nrf9160-arm-in-zep

RE: Inconsistent GPIO pulse timing when bit-banging (ws2812) on nrf9160 in Zephyr

Susheel Nuguru — Tue, 21 May 2024 11:37:20 GMT

[quote user="Voxorin"]I haven't worked with assembly in C before so I'm a little lost on how to fix this.[/quote]

I have used assembly but not to this extent. You can try to use XTAL LFCLK with better accuracy for RTC to eliminate this reason.

Regarding the GPIOTE driver, it do have more predictable timings with hardware events than gpio driver. So I can also suggest you to try this like others did.

RE: Inconsistent GPIO pulse timing when bit-banging (ws2812) on nrf9160 in Zephyr

Voxorin — Thu, 16 May 2024 20:47:08 GMT

The assembly instructions for both Arm processors are the same as far as I can tell. The timing also seems correct for all of the pulses other than the first "zero" and "one" pulses.

It seems like a few extra clock cycles are spent on something when calling the nop delays for the first time. I'm not sure how to remove whatever is causing those wasted cycles though.

I haven't worked with assembly in C before so I'm a little lost on how to fix this.

RE: Inconsistent GPIO pulse timing when bit-banging (ws2812) on nrf9160 in Zephyr

Susheel Nuguru — Fri, 10 May 2024 10:51:06 GMT

Hi,

The Zephyr driver you are using to bit-bang clearly says that it is designed for nRF51 which is using Cortex-M0. On nRF91, which uses Cortex-M33, the core speed and the pipelines is very different. Also I think the way it handles the "nop" instruction is also very different. There are also compiler optimizations that can happen to a series of nop.

I do not think the delays you are using are guaranteed predefined delays. You might have to find a different and more effective way to have a distinct and predefined delay when you want to bit bang this on nRF91.