Re: [Gumstix-users] Need advice on multithreading in Gumstix between ADC via SPI and storing data in CF card

[Ned F. <nfo...@wh...>]

Peck Hui Koh wrote:
> Dear All,
> 
> Thanks for the advice.
> 
> To answer some of your queries, I've attached the multithreaded program here
> (a simplified version just to illustrate the overall structure) for your
> comments. I've used exactly the same SPI example to collect my ADC samples,
> as shown in http://docwiki.gumstix.org/index.php/Sample_code/C/SPI.

I've looked at your code.  If the statement in the read thread:
for (t=0;t<1200;t++);
is supposed to be a delay to determine your sample rate, that will cause
no end of problems, partly because it is un-reliable (it only works if
no other thread anywhere on the system ever runs), and partly because
the code has no way to empty the FIFO quickly when it has been away
doing something else.  Besides which, no thread should ever busy-loop
(except for very clearly defined and limited purposes) on a
multi-tasking system, because you are stealing time that could be used
elsewhere.

In just a quick look at the threading, I don't see anything in the read
thread that waits for the write thread to finish with the data buffer,
before the buffer gets written again.  However, since I don't see any
declarations of mymutex2 and cond_sample_limit2, perhaps too much stuff
got trimmed.

I'm not sure why the write thread keeps mymutex locked the whole time.
I think it only needs to lock it while calling pthread_cond_wait, so
long as something is added to the read thread to make it wait on
cond_sample_limit2 before overwriting data[].

> 1. Mutex - I've used mutex in my program so that there will be no conflict
> between the two threads when accessing the same data array (I used
> pthread_cond_broadcast() in my readval() thread and pthread_cond_wait() in
> my writeval() thread). I may have done it in the wrong way so I need your
> advice on this.
> 
> 2. fopen - I've only opened the file once (in the writeval() thread where
> the fwrite command is). I hope this is not a problem. I've also include a
> fflush command towards the end of each thread.
> 
> As advised by Ned, one problem is that I do not know how to put my thread to
> sleep when the other thread is running. He does some blocking which I don't
> really understand. Will the mutex help? I was wondering if Ned can send me
> his program to see how he implements his multiple threads?

Unfortunately, I can't distribute it.  Sorry.

> I've implemented a binning approach to store the data in readval() i.e. to
> "broadcast" to the write thread whenever the sample bin in readval() is
> full. However, the result from the log file shows a delay between the two
> threads.
> I've no idea if the memcpy command helps as it just creates another array
> for the writing function (possibly to avoid data conflict).

Looking at the graph you sent in your second message, it looks like this
might just be a simple case of not servicing the SPI bus and ADC during
the time the write thread is busy.  It looks like you are uniformly
missing a group of samples from the ADC.

You say above that you are using the  direct register access method for
driving the SPI.  I don't think that that method does, or even can, use
DMA, so your code must service the SPI within the time it takes to fill
the FIFO on the SPI bus.  The FIFO is only 16 words deep, so you have a
maximum of 16x(1/7khz)=2.2ms during which you must service the FIFO or
you will lose samples.  If your write thread (or even a write call
within the read thread) takes longer than 2.2ms, you will drop data.

You may do better by using a smaller buffer.  50Ksamples means 100Kbytes
to write, and that may take too long.  This might not be a threading
problem at all, unless you have tried rolling your code read/write into
a single thread a know that it works that way.

My code uses the kernel driver for the SPI bus (pxa2xx_spi.c) to load
4096byte buffers.  At my data rate, that only takes 3ms.  I know that
even the kernel driver cannot reliably service the FIFO that often
(though of course it can do it on average), so it would not surprise me
if you had trouble doing that.  To make my system work, I had to do a
massive rewrite of pxa2xx_spi to enable the use of DMA descriptors so
that the DMA hardware can keep the FIFO serviced for 100ms without
processor intervention.

-- 
Ned Forrester                                       nfo...@wh...
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079