Dali bitbang timer deviates

RE: Dali bitbang timer deviates

Tomlee — Tue, 04 Apr 2023 09:28:22 GMT

Hi,

[quote userid="116211" url="~/f/nordic-q-a/90247/dali-bitbang-timer-deviates/378945"]To send two half-bits of the same value in a row, I used the timer cc event to disable the PPI channel that connects the two and re-enable it in the next event.[/quote]

May I know how to do this? could you show me your code , please

RE: Dali bitbang timer deviates

Tomlee — Tue, 28 Mar 2023 09:27:18 GMT

Hi,

I also met this problem(the dali timming is interrupt when blue mesh is always publishing data), could you show me your souce code, please?

I just follow the ..\examples\peripheral\gpiote example, but I don't know how to use gpiote task to change tx_pin value, for example , I want to send 0x23, then how to set in this example?

RE: Dali bitbang timer deviates

Kenneth — Wed, 27 Jul 2022 14:50:47 GMT

[quote user="tim-remoticom"]To send two half-bits of the same value in a row, I used the timer cc event to disable the PPI channel that connects the two and re-enable it in the next event.[/quote]

Good idea, and good to hear it works!

Kenneth

RE: Dali bitbang timer deviates

tim-remoticom — Wed, 27 Jul 2022 14:08:14 GMT

Hi Kenneth,
Thanks for the quick response. I created a toggling GPIOTE task and connected it to a timer cc event, and I got very accurate results (<100ns).

To send two half-bits of the same value in a row, I used the timer cc event to disable the PPI channel that connects the two and re-enable it in the next event.

Thanks again.

Kind regards,

Tim

RE: Dali bitbang timer deviates

Kenneth — Thu, 21 Jul 2022 13:09:27 GMT

I suspect some house keeping by the zephyr rtos that cause delay to the timer execution. Using nrfx directly I suspect will give the same result, though maybe a bit less both in terms of delay caused and the occurance rate.

But if you were to prepare next pin toggling by configuring a gpiote task and a timer CC[] event that would trigger the gpiote task, then I don't really see any way that should fail, since you can then prepare (from your description) up to 400us before it needs to be triggered. The CC[] event that triggered the GPIOTE toggle can also be for the next TIMER interrupt.

[quote user=""]Or would it be a good option to use SPI at 2400bps and leave all pins except for MOSI unconnected? For this the concern is that as part of the multi-master specification, the device must read back the value it set on the bus to detect if there is a collision.[/quote]

You can connect a small resistor (1khom) on the MOSI pin to the MISO pin, and the MISO pin is then connected directly to the peer. Then if you setup a SPI transfer with empty rx_buf, then you should get the same data in rx_buf as tx_buf if there are no collisions (though may consider running SPI on higher datarate to check for potentially collissions), ref setup:

CLK must be defined to a pin even if not connected physically to anything.

Hope that helps,
Kenneth