Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Preejith,

In the code you attached the Channel A and Channel B DMA thread priorities are set to 9. These can be set to a much higher priority (TSK_MAXPRI = 15 is the max). That might help.

One question I have is whether you are buffering receive calls or not. If you are only calling receive for the next buffer after receiving and processing the previous buffer, this could lead to some delays that might explain your issue.

That is all I can think of based on the information you have given us.

Let us know if any of my suggestions are helpful in resolving your issue, or if you have any further details that you think might be relevant.

Thanks,
\Greg

hi Greg,

We tried both your suggestions but without success. First about the DMA thread priority, we tried setting it to 15 but it didn’t change anything. According to what i understand from the dsp/bios manual it seems 0 is the highest priority level, however it resulted in errors during acquisition when we tried to go below 9, which is the current set level.

Second regarding buffering receive calls, we were not using buffers in our implementation because the time needed for processing was less than the duration between successive interrupts. In our application we are required to process the data in real time so storing and then processing is also out of the question. Our ultimate aim is to acquire and process real time RF data continuously and the algorithm flow required is as given below

step 1: Capture an array of 4096 bytes(1 frame) when a hardware interrupt occurs
step 2: carry out data processing on the captured frame(which takes 5 ms)
step 3: Wait for the next hardware interrupt which happens every 10ms

From what we understood from your suggestion regarding buffering, we tried using a buffer with real time processing. But this didn't succeed.

step 1: capture frame 1-10
step 2: process frame 1
step 3: capture frame 11
step 4: process frame 2 and so on..

We tried buffering without processing for the first few interrupts and later we started processing once a certain amount of data was collected, but even then the processing was carried out between interrupts. Even in this case when no processing is carried out, there are no samples lost at the beginning of the frame, but with processing there are samples lost and the number of samples lost varies from frame to frame as before.

Is my understanding of your suggestion correct if not please elaborate.

I have attached the code we have written till now(without buffering of received calls). Hope you will understand more on what we are trying to achieve.

Thanks,
Preejith

Hi Preejith,

First, in relation to the thread priority, 15 is the maximum priority for a task and 1 is the lowest. I think the confusion comes from that fact the priority for the DMA engine itself ranges from 0-7, with zero being the highest. When I was talking about changing the DMA thread priority I was referring to the nTskPriorityChanA entry in the tsDspUppConfig struct. nTskPriorityChanA refers to the task priority of a thread that runs as part of the DspUpp class that is responsible for programming the uPP DMA. My concern was that if this priority was too low the DMA might not get programmed in time.

Second, I'm not sure on the details of your project, but my suggestion was to queue up a whole bunch of receive buffers, only send valid data on the uPP input every 10 ms (assuming your architecture allows for control of this), process the buffers as they come in and then re-add them to the queue as soon as you could. My concern was that you were only using a single buffer to capture data and this gives you no flexibility if your processing is slowed down for a short time (such as CPU cycles being stolen by another task or something). If you have multiple buffers queued up and you get a temporary CPU slow down the queued buffer can still be filled by the DMA and you might not miss your deadline.

Have you timed how long it takes from the receive() call to when you get data back on the receive MBX? If you are only collecting 4096 samples and running the uPP clock at a decent rate (what is the uPP clock rate by the way?), this really should only take a ms or two at most I would guess. Also, have you measured how long it takes to send the data off to your qT app? If you are getting 4096 samples every 10 ms, and your processing takes 5 ms, that leaves you with 5 ms for capturing the data and sending it off. This should be plenty, but it sounds like something else is eating up that time. Do you perhaps have other tasks running on the DSP that could be stealing CPU cycles?

Thanks,
\Greg

hi Greg,

Thanks a million for all the help, solved the issue finally. I did set the dma thread priority to 15 but that didn't help. Finally enabled STARTA and used it as a handshake signal between UPP and ADC, rather than using external interrupt.

Thanks,
Preejith