Make it Possible to Supply the Stack Mem to RF Drivers

[mattbrown015]

When the Mbed RTOS is present the RF drivers create the IRQ thread with a 1k dynamically allocated stack.

Consider allowing the stack memory to be passed to the drivers so that it can be allocated statically. And in turn, allow improved compile time memory analysis.

The stack memory could be passed into the drivers in a similar fashion to how it can be passed to Thread::Thread.

The obvious downside being further complication to an already complicated constructor parameter list.

It would also allow the stack size to be optimised. In my, very simple, tests only 224 of 1024 bytes are used.

• Type: Enhancement
• Priority: Minor

[ciarmcom]

ARM Internal Ref: IOTCELL-843

[mattbrown015]

I have just watched the Office Hours presentation on EventQueue.

In the presentation Chris talks about how libraries should try to use an EventQueue so that the application can make decisions about execution context and memory allocation.

Obviously changing this driver/library to use EventQueue would be a much bigger deal but I thought it was an interesting idea and vaguely related to my question/concern about the use of a thread the this driver.

[hasnainvirk]

@mattbrown015 Yeah that could save some RAM. What we need here is a high priority event queue for the radio and stack. We may come to a solution later. At the moment we are focusing on testing. However, point taken. A high priority event queue (may be specific for the stack and radio driver) as we can't afford the application to block this particular event queue (e.g., doing some heavy crypto and such). The original issue that you created is interesting but doesn't solve a global problem if you catch my drift :)

[mattbrown015]

I think when I created this issue we were still deciding what MCU we were going to use. At one point there was a distinct possibility that we would be using a STM32L0 or STM32L1 and I was worried about RAM usage.

As it turns out out we've decided to use a STM32L4 with 64 kbytes RAM and at the moment RAM usage isn't a problem.

This is off-topic really but you mentioned priorities: We've created an application with several threads in addition to the main thread and radio driver thread. There is a thread for the LoRaWAN stack and event queue. At the moment all the threads I've created I've given normal priority, osPriorityNormal, but it has been on my mind that perhaps the LoRaWAN stack thread needs to have a higher priority.

Do you have any thoughts or guidelines about thread priority for the LoRaWAN stack and event queue?

Thanks, Matt

[hasnainvirk]

@mattbrown015 Well, a dedicated thread is always the most efficient solution but it comes at a cost. At the moment, the radio driver thread is the highest priority thread 'osPriorityRealTime'. However, as you mentioned you guys are switching platform, and our motivation is that whatever platform you choose we provide a solution for it. Keeping this in mind, we would like to squeeze out as much RAM as possible and to do this what comes in mind is an EventQueue with highest priority dedicated for the Stack and Radio driver. Application can have its own EventQueue and the stack would delegate events between the queues. The goal is to achieve same performance but less RAM consumption. I will get back to you once we have achieved this feat.

Thank you for your time and input.

[hasnainvirk]

@mattbrown015 By the way, did you check out meta data APIs ? I think you were asking about them once.

[mattbrown015]

@hasnainvirk No, which APIs are you talking about?

We've been concentrating on the non-LoRaWAN functions recently but soon we'll have to start thinking about how our sensor performs when the RF conditions are poor.

[hasnainvirk]

@mattbrown015 Check LoRaWANInterface.h , you will find metadata APIs and instructions how to use them. Maybe it didn't get highlighted so much in the release notes. Anyway, check that out. You will love it. :)

[mattbrown015]

@hasnainvirk Thanks, I see the API now and it appears to be what I was asking for! :)

[hasnainvirk]

@mattbrown015 You owe me a bear 🥇 :)

[mattbrown015]

I'll close this as other bigger plans are afoot! Although, I still think it would be relatively easy and useful to make the stack size configurable and/or add an alternative construction that accepts a pointer to the stack.

Thanks, Matt