Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How do I handle real-time data??

Status
Not open for further replies.

milesguidon

Member level 2
Joined
Dec 4, 2010
Messages
52
Helped
8
Reputation
16
Reaction score
8
Trophy points
1,288
Location
Los Angeles, CA
Activity points
1,753
I am using a PIC24F to receive and decode a signal. I then use the UART to send a packet containing the decoded information to an XBee, where it is then received by another XBee, which connects to the UART of another PIC24F.

The problem that I'm currently having is my limited time window--my incoming data comes in 33ms "packets", and my decoding algorithm finishes (obviously) at the end of these packets, leaving me with very little time to get the UART to push data out the door, before I must decode the next packet.

I am wondering what the correct method would be here, as I have a feeling this is a common problem encountered in handling real-time data. As soon as the data packet is complete, only then do we know completely what the packet contains (obviously), but that's pretty much when another packet is incoming, and must be dealt with. In general, what are my options for processing the data? Am I limited to the small amount of time between the end of one packet and the beginning of another?
 

Can you not write the uart routines so that they are fully interrupt driven?
Then receiving and sending the packets would happen in the background.
 
If it's possible, do processing data since first incoming data, do what we can do with this part of packet. Don't stay wait for each complete 8-bit UART, you can do anything before RX complete flag is set. And when RX complete flag it set, move it to buffer to be processed further. And also when you transmit data. Optimize your program to make no time wasted.
 
Hi,

Perhaps if you give some more specifics we can help optimise your flow better.

What speed is the Pic24 running at, what lines are receiving the packet, how many bytes does the packet contain, how many bytes does your decoded packet consist of, how may instructions does your decode routine take, what is the max speed of the USART to Xbee.
 
Hello!

I have never used PIC24, but what you can usually do is to use DMA to receive data to
a buffer while you process another buffer.
When the DMA transfer finishes, you get an interrupt. At that time, you give the DMA
the address of the other buffer and you process the buffer that was received.

Of course this supposes that your CPU has a DMA.

One thing to be careful about is that for instance on MSP430, there is a DMA, but there
is only 1 bus. So the CPU hardware allocates cycles for the DMA and cycles for your program
therefore you have less processing power when you use the DMA, but anyway you can do
parallel operations.

Dora.
 
Hi,

Perhaps if you give some more specifics we can help optimise your flow better.

What speed is the Pic24 running at, what lines are receiving the packet, how many bytes does the packet contain, how many bytes does your decoded packet consist of, how may instructions does your decode routine take, what is the max speed of the USART to Xbee.

My PIC24FJ48GA004 is running off of the 8MHz internal RC oscillator. My signal is a manchester-encoded timecode signal that I'm receiving on a pin I have configured to utilize the input capture function (with the PIC I am using, the pins do not have dedicated functions, but rather you have a group of functions and a group of pins, and you map them to each other with a set of commands). The signal is about 90 bytes--it's a linear timecode signal that represents data in hours:minutes:seconds:frames used in the film industry, and the useful data appears scattered across the 90 bits (there are a lot of interspersed bits containing "fluff" data that is not important to me). The signal is an audio signal, so it arrives at the PIC (after a comparator stage to get it logic-level) at a frequency in the low kHz.

My Baud rate for UART to Xbee is 9600. I noticed that setting a baud rate any higher messes something up with the Xbee (I of course programmed both the TX/RX UART for this higher Baud rate, and changed the Baud rate command given to the Xbee upon TX or RX initialization sequence).

The free time that I have is at bit 58 out of 90--from bit 0 to bit 58, I have been grabbing the bits that are important to me, and I have been building an array of integers (which are the decoded bits). At bit 58, I build an array of 8 characters based on my array of integers. Then I transmit. So far, the only thing I can think of is transmitting each character as it is put into the array, and not building the whole array of 8 characters, THEN transmitting everything. My code for transmitting exists at the end of my while(1){} loop (where *everything* is happening, all the decoding, etc), and consists of the following:

if (U1STAbits.TRMT==1)
{
U1TXREG = timecodeArray[0];
}
if (U1STAbits.TRMT==1)
{
U1TXREG = timecodeArray[1];
}
if (U1STAbits.TRMT==1)
{
U1TXREG = timecodeArray[2];
}

And so on until timecodeArray[7] is transmitted. I think I have written this code incorrectly. I want it to transmit character by character, but am unsure about the correct way to "wait" until the TXREG is empty, without stalling the whole loop.

If you've read this far, thank you, and I would appreciate any further guidance anybody has!
 

You can get the PIC24 running at 32MHz to give you 16 MIPS operation. This would decrease the instruction time 4 times, giving you 4X as much time as you had before. So, now you have 4X as many instruction cycles available for UART transmission than before.

Then, as stated before, you should set the UART programming such that it keeps on happening during interrupts, so that all the data reception goes on in the main code. Thus, you don't have to worry as much about limited UART time.

Hope this helps.
Tahmid.
 
You can get the PIC24 running at 32MHz to give you 16 MIPS operation.

Looking at the datasheet, it seems that I can get 32 MHz either with an external oscillator, or by using the PLL frequency multiplier applied to the Fast Internal Oscillator (8MHz internal RC oscillator).

Thanks for the info, I hadn't considered this.
 

It has a 4x PLL facility. So, all you need to do is use FRCPLL mode.
From the PIC24F reference manual:
6.8.3 FRC Oscillator with PLL Mode (FRCPLL)
The FRCPLL mode is selected whenever the COSC bits are '001'. In addition, this mode only func-tions when the direct or divide-by-2 FRC postscaler options are selected (RCDIV2:RCDIV0 = 000
or 001).
For devices with the basic 4x PLL block, the output of the FRC postscaler block may also be
combined with the PLL to produce a nominal system clock of either 16 MHz or 32 MHz. Although
somewhat less precise in frequency than using the Primary Oscillator with a crystal or resonator, it
still allows high-speed operation of the device without the use of external oscillator components.

Hope this helps.
Tahmid.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top