Re: Need DSP recommendation

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Quoted text here. Click to load it

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,

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

--Keith Brafford

Re: Need DSP recommendation
Quoted text here. Click to load it

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

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

Ben Jackson
We've slightly trimmed the long signature. Click to see the full one.
Re: Need DSP recommendation
Quoted text here. Click to load it

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

Re: Need DSP recommendation
Hi, the short answer is no. You do need an ad conv that will sample that fast.
What you need in MIPS depends on what you intend to do with the data you

Re: Need DSP recommendation
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

Re: Need DSP recommendation

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: Need DSP recommendation

Quoted text here. Click to load it

Yes all of that is correct. 40 clock cycles on pic means 10 instruction
cycles. The way I have the program written it is impossible to have it
sending out a bit with only 10 instructions. Keep in mind it is not just
a bit shift, I have to encode the sample every sample period and have
flags to check to see whether I am transmitting header or data etc.

Quoted text here. Click to load it

Pardon my ignorance as I have very little knowledge of rf. However the rf
engineer at said that we could get 1 mbps throughput from the
TR1100 transceiver module over short distances. We are transmitting a
maximum of 50 yards. It is not possible to use a standard WLAN card with
TCP/IP due to the extremely high delays (~milliseconds) and protocol
overheads. However, would it help to have a rf trasmitter/receiver in 2.4
Ghz frequency? Is there anything available out there?

Quoted text here. Click to load it

Well, the final application is also in the lab. This is a reasearch
project at a university. I do plan to see the signal delay and accuracy
using A/D->micro->transmitter->receiver->micro->D/A and comparing the
original and obtained analog signal.

Quoted text here. Click to load it

This would be ideal. Do you know of any USART chip that can do this? A
12-bit encoding will be even better as that will save 50% overhead
compared to Manchester.

Quoted text here. Click to load it

Thanks a lot Paul.

Site Timeline