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 wrote:
> 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.


You not necessarily need a DSP. Perhaps an FPGA is sufficient or even
better. Is the algorithm doable is silicon ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

"Rahul Agarwal" <ragarwal@fit.edu> wrote in message
news:44c3d712.0401051056.77a2f317@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.


The Analog Devices Blackfin 531/532/533 processor can do what you want.
The dev kit for these guys is also available for $99 through January 2004,
IIRC.

The Blackfin is available in LQFP packages up to 300 or 400 MHz (can't
remember) and up to 600MHz in BGA.

--Keith Brafford

In article <44c3d712.0401051056.77a2f317@posting.google.com>,
Rahul Agarwal <ragarwal@fit.edu> wrote:
>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.

I don't understand what you mean by sampling.  Are you talking about
decoding the RF signal or acquiring the A/D values?  The microchip
parts aren't limited by clock speed for A/D conversion -- in fact you
just have to wait longer for the setup time at higher clockspeeds.
Back of the envelope calculation (based on my foggy memory of 16F
aprts) says you aren't going to get much more than 10-20k analog
samples/sec.

If *that* is what you're talking about you probably need a dedicated
A/D converter.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

> 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.

Don't fall into the comparison by MIPS trap; different architectures
will achieve the same result in fewer or more instructions. PIC for
example is (from memory) heavily accumulator-bound - you spend
a lot of time shuffling data into and out of the accumulator. Other
architectures have several registers that can be used as accumulators,
reducing the number of data movement instructions. ARM also has
an inline barrel-shifter, allowing (for example) the contents of one
32-bit register to be shifted by one to 31 bits, added to the contents
of a second register and the result stored in a third register - all in one
instruction and one clock tick.

Purely in the interests of sparking an off-topic debate, I'd be interested
in hearing how many instructions that would take in other processors
;)

You should be able to do this with the PIC18F, even at much lower clock 
rates than 40MHz. I suggest you re-examine your design, then look at the 
following:-

Sample rate of PIC is > 25kHz, I don't know what the 18's will do, I 
left PIC s behind a few yars ago. Certainly an MSP430 with as low a 
clock rate as 32.768kHz could handle this application. Figure out how to 
do this properly., by studying the PIC18 architecture and get the most 
out of it. These are powerful parts, this application should be an 
absolute no-brainer for them.

Use the UART to drive the RF side, you will need to invert the signals 
from the UART, since it conventionally idles at logic '1', and the rf 
needs a logic '0' idle. Simply add a transistor from TX of the UART to 
TXdata of the RF, something like a Bc85x NPN with 470R series resistor 
in the base, emitter to GND, collector to VCC via 10K , and collector to 
TXD of Rf. reverse this for the receive line, or simply use a pair of 
inverters.

Al

Rahul Agarwal wrote:

> 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

-- 
Please remove capitalised letters to reply
My apologies for the inconvenience
Blame it on the morons that spam the net

hi Rahul 

I guess you have an algorithm that your using and the demodulation
part is a bit heavy. I did somthing like this and when looking for the
right micro/dsp I had to know what I needed for my algorithm before I
looked at chip specs.

The main thing was what frequency was I going to have to demodulate,
to select the sampling rate(assuming no heterodyne). Once I had the
sammpling rate then I knew how much time I had between samples to get
all the processing done. The selection seemed to me to really came
down to MIPs, how many instructions to do things like a MAC (for
demodulating there were a lot of these depending on your number of
taps, rule of thumb is micro MAC = 5 instructions and dsp MAC = 1) and
memory access times (ie wait states for external flash or single
verses double access).

A fast micro may do the trick but then you may have to drop the number
of taps on your filters or how may loops your algorithm runs. A dsp
running at the same clock speed will probably do many times more work
in the same time because its architecture is made for efficient signal
processing, but the circuit may be more complicated and you will have
to learn a new beast.

I think the next step up from your pic would be wither the TI C2000
family of chips or the Motrola 56Fxxx family, others may disagree?
These are 40 MIPS parts too but can do much more per intruction. Then
it would be the C5000 family, which are used a lot in comms
applications but are a lot trickier get running.

Another thing to consider is making your code work on your existing
system. Your demodulator should be in assembly. Is the method your
using the most appropriate for the application. Is your code
efficient. Could you reduce performance to get it to work with higher
freqs e.g lower tolerance to noise or lower baud.

Just some thoughts of the top of my head.
Tony McKay

On Wed, 07 Jan 2004 17:48:55 GMT, in msg
<bEXKb.15$Wa.0@news-server.bigpond.net.au>, onestone
<onestoneXYZ@ABCbigpond.net.au> wrote:

>You should be able to do this with the PIC18F, even at much lower clock 
>rates than 40MHz. I suggest you re-examine your design, then look at the 
>following:-
>
>Sample rate of PIC is > 25kHz, I don't know what the 18's will do, I 
>left PIC s behind a few yars ago. Certainly an MSP430 with as low a 
>clock rate as 32.768kHz could handle this application.

<snip>

>> 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). 

<snip>

Really, you can sample a 10 bit ADC at 50khz using a processor running at 33khz?

What is that, something like 1.5 samples per clock cycle?

That some fancy codin'!  I'm not worthy...  ;-)

-Zonn
--------------------------------------------------------
Zonn Moore
Zektor, LLC
www.zektor.com

Remove the ".AOL" from the email address to reply.

Zonn wrote:

> On Wed, 07 Jan 2004 17:48:55 GMT, in msg
> <bEXKb.15$Wa.0@news-server.bigpond.net.au>, onestone
> <onestoneXYZ@ABCbigpond.net.au> wrote:
> 
> 
>>You should be able to do this with the PIC18F, even at much lower clock 
>>rates than 40MHz. I suggest you re-examine your design, then look at the 
>>following:-
>>
>>Sample rate of PIC is > 25kHz, I don't know what the 18's will do, I 
>>left PIC s behind a few yars ago. Certainly an MSP430 with as low a 
>>clock rate as 32.768kHz could handle this application.
> 
> 
> <snip>
> 
>>>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). 
> 
> 
> <snip>
> 
> Really, you can sample a 10 bit ADC at 50khz using a processor running at 33khz?
> 
> What is that, something like 1.5 samples per clock cycle?
> 
> That some fancy codin'!  I'm not worthy...  ;-)

Obviously you don't know the MSP430, otherwise you wouldn't be so 
sarcastic. Like many other micros (including the PIC) it has more than 
one clock source, In fact the PIC has a dedicatred A/D clock, so while 
the main crystal might be slow internally generated clocks allow much 
faster operation of peripherals. so I agree with you, you're not worthy ;@}

Al

On 5 Jan 2004 10:56:46 -0800, ragarwal@fit.edu (Rahul Agarwal) wrote:


>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

That should not be a problem, so I do not think that you need a DSP.

>and transmit it bit-by-bit after encoding along with some protocol
>overhead to an rf transmit module attached to a pin.

This is the hard part, if you are really planning to use bit banging
to generate the signal.

>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? 

With 50 kHz sample rate at 10 bits/sample, the net bit rate would be
500 kbit/s and adding bit stuffing, self clocking (Manchester coding),
headers etc, the bit banger would have to operate around 1 MHz clock
rate. Thus, for each sample, the bit banger would have to run 20
times. With the 40 MHz processor, 40 clock cycles would be needed for
banging out one bit, but of course also reading the A/D will need some
cycles, so the number of cycles for bit banging would be less. 

> Assume plenty rf bandwidth.

Even if you would have available a noise free bandwidth of at least
1.5 MHz, a line of sight path would be required. However, with
reflections from various objects and especially from the ground, there
are going to be frequency selective multipath dips within the signal
spectrum corrupting the signal. Thus, spread spectrum or similar
systems would be required for such large data rates. You should check
for WLAN and similar devices that operate in the 2.45 GHz ISM band.

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

If you are trying to use some home grown transceiver system, you
should first test it with some external 1 MHz clock (e.g. signal
generator) and observe the waveform at the receiving end with an
oscilloscope or other device that can be used to calculate errors when
the transmitter and/or receiver are moving around in the final
application area, _not_ in the lab. After this, you can decide, is the
RF module usable for this application.

Unless the RF module provide these services, I would suggest that some
external USART chip to be used that can be put into HDLC mode and
capable of generating Manchester coding. The interface between the
processor and USART should be with parallel ports so that only a few
instructions are needed to transfer a complete _sample_ to the USART
compared that multiple instructions are needed to generate a
single_bit_in the bit banging case.

Paul