Mailbox for transfer large amounts of data

[kab]

Hello!

I'm using stm32f103ret6 custom board (running at 72 Mzh) and have question.
I need to transfer large amounts of data between ICU and thread, which parse this data.
I choose mailbox for that purpose.

I create interrupt handler for ICU using TIM4 (with frequency 1 mhz), which catch pulses width (minimal pulse width around 30-50 uS):

Code: Select all

static void icu_width_callback(ICUDriver *icup)
{
   msg_t msg;
   pulse_width = icuGetWidthX(icup);
   msg = pulse_width;

   chSysLockFromISR();
   if (chMBPostI(&mailbox, msg)!=MSG_OK)
   {
      // mailbox full, switch led on
      palSetPad(IOPORT2, GPIOB_LED);
   }
   chSysUnlockFromISR();
...
}

And also casual thread is created, which catch this data:

Code: Select all

static THD_FUNCTION(mParseThread, arg) {
   (void) arg;
   msg_t msg;

   /* Thread loop, until terminated.*/
   while (chThdShouldTerminateX() == false) {

      /* Waiting for a message.*/
      chMBFetch(&mailbox, &msg, TIME_INFINITE);
...

In general all working fine, but from time to time i have 'mailbox full' case.

So, my question is: is it good idea to use mailbox for fast trasfer between ISR and Thread or not?
May be simple shared circle buffer is better (less overhead)?

[Giovanni]

Hi,

Mailboxes are simple circular buffers and are meant for ISR->Thread data exchange. Your use case is correct.

Is your thread at higher priority than other threads? scheduling could delay it enough to cause the overflow. You may also increase the mailbox size so you would have more buffer (size is not shown in your example).

Giovanni

[kab]

Hello!

Thanks for an answer! Seems that i'm on right way.

I've start with 256 msg_t buffer, but even 1024 did not helps, in some rare cases 'mailbox full led' is turn on.

Thread have normal prio, because there is also communication thread (usb now for debug, casual serial in real device) and i worry, that higher prio can block communication thread.

Total i have 4 threads:
* usb/serial for communication (i'm using simple shell from your example)
* ICU interrupt handler
* parser
* sleeping thread which blink another led on event

Also, i'm using tickless mode, but power saving is not important.

[Giovanni]

Hi,

Try putting it at highest priority, other threads should not be much affected. If a buffer of 1024 does not help then there is an issue with priorities, other threads are preventing it from empting the queue.

Giovanni

[kab]

Hello!

And which mode is faster (less overhead for switching) - tickless or casual?

[Giovanni]

No impact on switching. Tickless is only heavier on virtual timers and everything else is generally faster because much less interrupts are served.

Giovanni

[kab]

Hello!

Thanks again for detailed answers!
Will try to play with prio.

[samtatasurya]

Hello!

Thanks again for detailed answers!
Will try to play with prio.

Hi kab,

I wonder if you have any update regarding your progress. I'm currently bump into similar problem in my system, so it'd be great if you can share your solution to this problem.
Thank you!

[kab]

Hi!

Giovanni tell everything, set prio to high and that's works.
I'm also lower frequency from 1 mhz to 500 khz (in my case this is acceptable).

However, all depends from your worker thread, if it make some huge calculations, some messages can be missed.

[samtatasurya]

Thanks for your reply!

Yes, after tracking down my issue, I found out that my worker thread delayed the acquisition from the mailbox.