Timing requirements for BT Mesh

[einar]

Hello Nordic supporters!

We are developing a system using BT Mesh alongside a software DALI protocol driver with certain timing requirements.

Right now we're trying to figure out how strict the timing requirements of BT Mesh are compared to normal BLE, and how they would interact with the DALI requirements. We were thinking there could be a difference since BT Mesh is advertising based and not connection based. We would appreciate some help in finding exact numbers.

For the driver we're considering, these timing requirements are given:

• One function must be called at least every 5ms by the user application and must not be blocked (e.g. through storage of persistent data).
• Another function should be called every 10ms to ensure functionality

During these function calls the driver would be doing bit-banging on the gpio, which we would like to not have interrupted by the BT part of the code.

Do you think these requirements could realistically be satisfied while running BT Mesh on an nRF52840?

Thank you in advance,

Einar

[einar]

Hi

Yes I can confirm that input is more difficult than output. The DALI driver we are working with is monitoring incoming DALI bus activity through gpio callbacks (the bus is fairly slow btw at 2400 bps), saving this in a buffer. The function we have to run at least every 5ms then forwards this to the main function.

Personally I don't think it is critical to miss one or two of these 5ms function calls, maybe the other function that should be called every 10ms might be more critical as it has to do with the timing of the bus interface. The documentation of the DALI driver on the other hand states very clearly that these timing criteria have to be met, and that the driver must have the highest priority in the system. So if we want to do our best to meet these criteria using the timeslot API, how would we best approach that?

And maybe more important, how busy should we expect the cpu to be with mesh? Both regarding overall cpu usage and the size of single timeslots.

-Einar

[PaKa]

have you considered using the ADC with easydma to sample the pin on the 5ms rate? That would give you all the input data without having to use the CPU in timing critical parts at all. Will use more RAM of course and you can't toggle output pins in the read loop though. I have never looked at DALI but I know the ADC option has been used for sampling input sequences by others.

[einar]

Hi PaKa, thanks for the suggestion!

We have actually considered this as an option yes, but I doubt this would be compatible with the driver we are working with, so this would mean writing our own driver from scratch.

[Edvin]

Hello,

einar said:

the bus is fairly slow btw at 2400 bps

I assume that at these 5ms intervals, you will sample more than one bit every 5ms? The ADC is not a terrible idea. Alternatively, maybe you can do some tricks to store it in an I2S buffer or something. But if loosing one interrupt every now and then, I believe it is mostly when you are doing flash operations that you risk loosing these events. And that isn't that often, perhaps. Just make sure your interrupt priority is high enough.

Best regards,

Edvin