Need DSP recommendation

Hi,

I have been developing an application using a Microchip 18F452 with 40
Mhz clock. Unfortunately, it seems like the device is too slow for the
application and I need something faster. Hence I am asking for some
recommendations.

My application is the following. The processor is connected to an
analog sensor. It needs to sample the sensor to a 10-bit digital value
and transmit it bit-by-bit after encoding along with some protocol
overhead to an rf transmit module attached to a pin.

The reverse procedure happens on the receiving end where the mcu
receives data bit-by-bit from the rf receiver module and it needs to
decode it and spit out the value through digital i/o.

With the 18F pic (10 MIPS) I can acheive a sampling rate of 5 Khz. I
would like to sample at 50 Khz (or more). Does that mean I need 100
MIPS processor roughly? Assume plenty rf bandwidth.

What is the cheapest solution to this? I cannot use a SPI module since
the rf module doesn't like them.

Thanks,
Rahul

"Rahul Agarwal" <ragarwal@fit.edu> wrote in message
news:44c3d712.0401051055.34c0261e@posting.google.com...
> Hi,
>
> I have been developing an application using a Microchip 18F452 with 40
> Mhz clock. Unfortunately, it seems like the device is too slow for the
> application and I need something faster. Hence I am asking for some
> recommendations.
>
> My application is the following. The processor is connected to an
> analog sensor. It needs to sample the sensor to a 10-bit digital value
> and transmit it bit-by-bit after encoding along with some protocol
> overhead to an rf transmit module attached to a pin.
>
> The reverse procedure happens on the receiving end where the mcu
> receives data bit-by-bit from the rf receiver module and it needs to
> decode it and spit out the value through digital i/o.
>
> With the 18F pic (10 MIPS) I can acheive a sampling rate of 5 Khz. I
> would like to sample at 50 Khz (or more). Does that mean I need 100
> MIPS processor roughly? Assume plenty rf bandwidth.
>
> What is the cheapest solution to this? I cannot use a SPI module since
> the rf module doesn't like them.

The PIC chip should be fine for the processing that you desire, although I
question why you are wanting to do the demodulation of the rf signal on the
PIC itself.  I would see a better way being to use some PIC external
hardware to perform the demodulation and then allow the PIC to do what it
does best, just process the digital data. I'm not sure whether this
particular PIC has a pin-state-change interrupt but if so then it would make
it super simple to interface to the external circuitry, just have some
toggling preamble to the data sent, use the pin-state-change interrupt to
detect the preamble, then start up a timer interrupt that occurs when a new
bit should be expected (and shut down the pin-state-change interrupt), count
down the number of bits, once all are received (and possibly some error
checking has been performed) then shut down the timer interrupt and perform
the processing on the digital bits that you received.

ragarwal@fit.edu (Rahul Agarwal) wrote in message news:<44c3d712.0401051055.34c0261e@posting.google.com>...
> Hi,
> 
> I have been developing an application using a Microchip 18F452 with 40
> Mhz clock. Unfortunately, it seems like the device is too slow for the
> application and I need something faster. Hence I am asking for some
> recommendations.
> 
> My application is the following. The processor is connected to an
> analog sensor. It needs to sample the sensor to a 10-bit digital value
> and transmit it bit-by-bit after encoding along with some protocol
> overhead to an rf transmit module attached to a pin.
> 
> The reverse procedure happens on the receiving end where the mcu
> receives data bit-by-bit from the rf receiver module and it needs to
> decode it and spit out the value through digital i/o.
> 
> With the 18F pic (10 MIPS) I can acheive a sampling rate of 5 Khz. I
> would like to sample at 50 Khz (or more). Does that mean I need 100
> MIPS processor roughly? Assume plenty rf bandwidth.
> 
> What is the cheapest solution to this? I cannot use a SPI module since
> the rf module doesn't like them.
> 
> Thanks,
> Rahul


I would think about using an Atmel AVR device. A 16Mhz device will
give you 16 mips (ish), the step up (in learning curve terms) isn't
too great from a PIC.

Other than that you may wish to consider the Motorola DSP56F801. The
development tools are pretty good and the device doesn't cost the
earth.

"Bevan Weiss" <kaizen__@NOSPAMhotmail.com> wrote in message news:<9zmKb.2922$9k7.68318@news.xtra.co.nz>...

> The PIC chip should be fine for the processing that you desire, although I
> question why you are wanting to do the demodulation of the rf signal on the
> PIC itself.  I would see a better way being to use some PIC external
> hardware to perform the demodulation and then allow the PIC to do what it
> does best, just process the digital data. 

Even though that is a good idea, I think that will really hard (for
me) to implement in circuit. To give you an idea, before we have the
actual data the processor receives 1 bit at a time and waits for the
preamble. Then it syncs it clocks and receives the 12-bit encoded
data. Then it uses a table to find out the decoded byte. I don't want
to do all of that in hardware.

> I'm not sure whether this
> particular PIC has a pin-state-change interrupt but if so then it would make
> it super simple to interface to the external circuitry, just have some
> toggling preamble to the data sent, use the pin-state-change interrupt to
> detect the preamble, then start up a timer interrupt that occurs when a new
> bit should be expected (and shut down the pin-state-change interrupt), count
> down the number of bits, once all are received (and possibly some error
> checking has been performed) then shut down the timer interrupt and perform
> the processing on the digital bits that you received.

As I mentioned, the data coming in after the preamble is not the real
data. If I really want to send just the real data to the pic, I will
have to decode it before that which will be a pain. Therefore, I will
stick with doing all of these tasks in software and just try to find a
faster MCU.

sfisher@cwcom.net (Simon J Fisher) wrote in message news:<953e41b4.0401060038.4f05ed2f@posting.google.com>...

> I would think about using an Atmel AVR device. A 16Mhz device will
> give you 16 mips (ish), the step up (in learning curve terms) isn't
> too great from a PIC.
> 
> Other than that you may wish to consider the Motorola DSP56F801. The
> development tools are pretty good and the device doesn't cost the
> earth.

Both of those devices seem slow. The Motorola and the Atmel devices
are in the range of 16 MIPS. Assuming it takes the same amount of
instructions as in a PIC 18F452, I am looking at something atleast a
100 MIPS. Till now I found these devices. Does anyone have any
experience with them. I am coming from a pic background primarily.

Blackfin with 300 Mhz - 600 Mhz (According to them that should
correspond to atleats 300-600 MIPS)
http://www.analog.com/processors/processors/blackfin/index.html

SI LABS (Cygnal) C8051f120/1/2/3 with 100 MIPS
http://www.silabs.com/products/microcontroller/mixsig_matrix.asp

Thanks,
Rahul

"Rahul Agarwal" <ragarwal@fit.edu> wrote in message
news:44c3d712.0401061022.b02b24d@posting.google.com...
> "Bevan Weiss" <kaizen__@NOSPAMhotmail.com> wrote in message
news:<9zmKb.2922$9k7.68318@news.xtra.co.nz>...
>
> > The PIC chip should be fine for the processing that you desire, although
I
> > question why you are wanting to do the demodulation of the rf signal on
the
> > PIC itself.  I would see a better way being to use some PIC external
> > hardware to perform the demodulation and then allow the PIC to do what
it
> > does best, just process the digital data.
>
> Even though that is a good idea, I think that will really hard (for
> me) to implement in circuit. To give you an idea, before we have the
> actual data the processor receives 1 bit at a time and waits for the
> preamble. Then it syncs it clocks and receives the 12-bit encoded
> data. Then it uses a table to find out the decoded byte. I don't want
> to do all of that in hardware.
>
> > I'm not sure whether this
> > particular PIC has a pin-state-change interrupt but if so then it would
make
> > it super simple to interface to the external circuitry, just have some
> > toggling preamble to the data sent, use the pin-state-change interrupt
to
> > detect the preamble, then start up a timer interrupt that occurs when a
new
> > bit should be expected (and shut down the pin-state-change interrupt),
count
> > down the number of bits, once all are received (and possibly some error
> > checking has been performed) then shut down the timer interrupt and
perform
> > the processing on the digital bits that you received.
>
> As I mentioned, the data coming in after the preamble is not the real
> data. If I really want to send just the real data to the pic, I will
> have to decode it before that which will be a pain. Therefore, I will
> stick with doing all of these tasks in software and just try to find a
> faster MCU.

This sounds like the wrong approach to the problem....

You have some binary data that is being sent via FM/AM/some modulation
method to your device.  You seem to want to demodulate this signal back into
binary and then process it all inside the processor.
Is that correct?

What does the processing of the binary data actually require?

The most sensible way that I can see of doing such a system is to demodulate
back into the baseband binary using some external hardware, then allow the
processor to retrieve this binary data and perform the processing on it.  If
the processor isn't fast enough to perform all the required processing, then
get a faster processor.  But getting a faster processor just to allow you to
perform some simple rf processing allowing you to obtain the original
digital signal is just daft, the processing of the rf is best done using
external hardware.

"Rahul Agarwal" <ragarwal@fit.edu> wrote in message
news:44c3d712.0401051055.34c0261e@posting.google.com...
> Hi,
>
> I have been developing an application using a Microchip 18F452 with 40
> Mhz clock. Unfortunately, it seems like the device is too slow for the
> application and I need something faster. Hence I am asking for some
> recommendations.
>
> My application is the following. The processor is connected to an
> analog sensor. It needs to sample the sensor to a 10-bit digital value
> and transmit it bit-by-bit after encoding along with some protocol
> overhead to an rf transmit module attached to a pin.
>
> The reverse procedure happens on the receiving end where the mcu
> receives data bit-by-bit from the rf receiver module and it needs to
> decode it and spit out the value through digital i/o.
>
> With the 18F pic (10 MIPS) I can acheive a sampling rate of 5 Khz. I
> would like to sample at 50 Khz (or more). Does that mean I need 100
> MIPS processor roughly? Assume plenty rf bandwidth.
>
> What is the cheapest solution to this? I cannot use a SPI module since
> the rf module doesn't like them.

Ahh I think I lost the plot on the previous postings...
So it's the sampling and the bit-banging that's making this difficult.

Well then I still think that dedicated hardware is the best option.
Using some kind of serial controller for the serial interface would be best,
something with a manchester encoding feature would allow you to insert
timing information in the serial stream, and at the receiving end would also
be able to extract the timing and data from the manchester encoded output
from the rf receiver.
The analog-digital sampling is most likely the big limiting factor in this
system, as the ADC on the PIC series aren't very high speed at all.  50kHz
might be a bit tricky to handle, though using interrupts should be possible.

I'm not sure of many processing chips with a nice serial interface and also
a high speed ADC, but then again I've never really had the need for such a
chip so haven't looked into it.  But I think this is more what you should go
for.  If you need more actual processing power (ie for data manipulation
inside the processor) then you would also have to look at a chip with higher
processing power.

"Rahul Agarwal" <ragarwal@fit.edu> wrote in message
news:44c3d712.0401051055.34c0261e@posting.google.com...
>[...]
> My application is the following. The processor is connected to an
> analog sensor. It needs to sample the sensor to a 10-bit digital value
> and transmit it bit-by-bit after encoding along with some protocol
> overhead to an rf transmit module attached to a pin.
>
> The reverse procedure happens on the receiving end where the mcu
> receives data bit-by-bit from the rf receiver module and it needs to
> decode it and spit out the value through digital i/o.
>
> With the 18F pic (10 MIPS) I can acheive a sampling rate of 5 Khz. I
> would like to sample at 50 Khz (or more). Does that mean I need 100
> MIPS processor roughly? Assume plenty rf bandwidth.
> [...]

From what you've said, I can't see any reason why you couldn't get the
sampling rate you want out of the device you have.  Are you, perhaps,
wasting cycles by using busy loops to wait for data or time delays instead
of using interrupts?  Or did you just forget to mention some big processing
step like sophisticated filtering or triple-DES decryption?

Also, I'm interested in knowing which RF module you chose?  Can you tell us?

"Matt Timmermans" <mt0000@sympatico.nospam-remove.ca> wrote in message news:<xEJKb.16173$BA6.580398@news20.bellglobal.com>...
 
> From what you've said, I can't see any reason why you couldn't get the
> sampling rate you want out of the device you have.  Are you, perhaps,
> wasting cycles by using busy loops to wait for data or time delays instead
> of using interrupts?  Or did you just forget to mention some big processing
> step like sophisticated filtering or triple-DES decryption?

I do have the code implemented in interrupts. For each 8-bit sample
data I am sending about 24 bits of data. 12 bits of header and the
encoded 12-bit data. The processor is interrupted every bit time to
transmit/receive a bit. The problem is that when the receiver receives
the 24th bit, it needs to decode the data using a look up table I have
in there. This task takes up quite a few instructions as it searches
through the table. And I have to make the time period long enough so
that it can do all of that when it receives the last bit. So most of
the time (the other 23 bits) there are lot of wasted cycles waiting in
an infinite loop for the timer interrupt.

Let me know if it is still not clear and I will post the code here. 


> Also, I'm interested in knowing which RF module you chose?  Can you tell us?

I am using TR1100 module from rfm.com which has a data rate of upto 1
Mbps working at a frequency of 916.6 Mhz.
http://www.rfm.com/products/vwire.htm (look for TR1100)

Rahul Agarwal wrote:
> I do have the code implemented in interrupts. For each 8-bit sample
> data I am sending about 24 bits of data. 12 bits of header and the
> encoded 12-bit data. The processor is interrupted every bit time to
> transmit/receive a bit. The problem is that when the receiver receives
> the 24th bit, it needs to decode the data using a look up table I have
> in there. This task takes up quite a few instructions as it searches
> through the table. And I have to make the time period long enough so
> that it can do all of that when it receives the last bit. So most of
> the time (the other 23 bits) there are lot of wasted cycles waiting in
> an infinite loop for the timer interrupt.

Can you move the "24th-bit code" into a background routine?  Your last 
interrupt could set a flag indicating that it should run, and the 
infinite loop you have running in the background should poll that flag 
and crunchthe bits when it gets set:

while(1)
{
   if (bit24_ready)
   {
     bit24_ready = 0;
     crunch_bits();
   }
}

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com          (703) 779-7770
A pessimist is an optimist with experience