Hi all,
I have different questions , but the most important is the first one I think...
1) Reading the documentation I saw, the what must be done and what should not be done...
Very useful but ....
I am supposed to create some threads but not too much. Here is my question...
What is a typical number of threads on tiny MCUs ?I am targetting Cortex M3 L series or may be Cortex M0+ new chipsets.
My first design implies to create:
- 1 Timer for LCD display (every minute)
- 1 Timer for sensors data collection (every 2 seconds)
- 1 Timer for data synchronization through GSM every minute (if there's something in the alarm queue send it or sleep, so there should not be too many GSM calls)
- 1 Thread awaiting for something in the data queue to make some small computations
So basically my solution has :
- 2 queues
- 3 Timers
- 1 thread + main one
Is it possible to run such design on small devices? Not too ambitious?
Is there somewhere an abacus with typical application complexity for a given hardware ?
2) RIOT sponsoring...
I may need to see a bunch of chipsets and one board integrated quickly into RIOT.
Is it possible to sponsor development ? My company is very small and not rich but it is strategical for me to see my sensors natively supported by RIOT..
3) RIOT training
Is there in France or Germany some training courses available? Google was useless...
4) I saw somewhere in the source code a strange excerpt dealing with message-queue where there 's a problem if 2 messages come (the message queue is sized to one only message) so a new one is created...
Strange, why not sizing the queue to 2 ?
Thanks for your help
Kind regards and thanks again for this beautiful piece of software
Jerome
Hey,
- 2 queues
- 3 Timers
- 1 thread + main one
Is it possible to run such design on small devices? Not too ambitious?
That should well be possible!
Is there somewhere an abacus with typical application complexity for a
given hardware ?
Usually you will run into memory problems first, as every thread needs it's own stack.
Simple threads might be OK with a 200byte stack (like our idle thread), printf needs ~1k of extra stacksize. So in ~2k stack, you can do a lot. If you've got 16k to spare, 10 threads is not ambitious, depending on what exactly they're doing.
4) I saw somewhere in the source code a strange excerpt dealing with
message-queue where there 's a problem if 2 messages come (the message
queue is sized to one only message) so a new one is created...
Strange, why not sizing the queue to 2 ?
IIRC that is taken from one of the test cases.
The issue is that a thread in that test is waiting for messages from an ISR. The ISR cannot block on sending a message, so if it tries to send a message while the thread is busy, that message gets lost. By design of the test that thread can at most miss one message, so it set's up a message queue that can hold exactly that message.
Cheers,
Kaspar
Hi again,
Hey,
- 2 queues
- 3 Timers
- 1 thread + main one
Is it possible to run such design on small devices? Not too ambitious?
That should well be possible!
Nice...
Is there somewhere an abacus with typical application complexity for a
given hardware ?
Usually you will run into memory problems first, as every thread needs it's own stack.
Simple threads might be OK with a 200byte stack (like our idle thread), printf needs ~1k of extra stacksize. So in ~2k stack, you can do a lot. If you've got 16k to spare, 10 threads is not ambitious, depending on what exactly they're doing.
In fact most of the functions are quite simple....
The only difficult thing done is in one thread where data should be archived (between 2 synchronizations) and triggering (or not) alarms.... I will be obliged to implement a kind of diff between structures entries to avoid filling arrays with identical data and sending it over the GSM to the back-end platform...This is algorithm so I may find a solution...
4) I saw somewhere in the source code a strange excerpt dealing with
message-queue where there 's a problem if 2 messages come (the message
queue is sized to one only message) so a new one is created...
Strange, why not sizing the queue to 2 ?
IIRC that is taken from one of the test cases.
The issue is that a thread in that test is waiting for messages from an ISR. The ISR cannot block on sending a message, so if it tries to send a message while the thread is busy, that message gets lost. By design of the test that thread can at most miss one message, so it set's up a message queue that can hold exactly that message.
Ok Kaspar ,thanks for clarification...
I find one of the limits seen in Mbed or FreeRtos with ISR ....
Kind regards