On Thu, 08 Jan 2004 07:28:52 GMT, in msg
<UE7Lb.608$Wa.338@news-server.bigpond.net.au>, onestone
<onestoneXYZ@ABCbigpond.net.au> wrote:

>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 ;@}

The perceived sarcasm was based on the fact I had assumed you simply misquoted
your "clock rate" as your "external crystal speed". The smiley was to indicate I
felt is was just an oversight on your part, something that I've been known to
have done on quite a few occasions myself!

I'm sorry you mistook it as an insult, but as such a can see your need to
respond in an insulting manner. No problem!  Assuming the original *was* meant
as an insult I'd respond the same way! :-) <-- note smiley.

I don't believe my original response shows a lack of knowledge on the MSP430,
though I have not had the opportunity to use it in a project.

The MSP430 series has a very flexible clock module with a nice thing they call a
Frequency Locked Loop (FLL) but you did not indicate "crystal speed" in your
original post, but instead quoted a clock rate figure.  Using a x32 multiplier
on a 32.768khz crystal (or something similar like I assumed you meant) does not
give a clock rate of 32.768khz, but instead a clock rate of 1.048576 MHz (this
example is from the datesheet), with a large enough multiplier you can indeed
achieve a clock rate that would allow enough MCU clocks to support a 50khz
sample rate, based on an external 32.768khz crystal.

You specified you could sample at 50khz, using a 32.768khz clock rate, not a
1.04mhz clock rate (or whatever clock rate achieved by the programming of your
FLL).  Obviously at one cycle per instruction, using clock rate of 32.768khz
would only allow a 32.768khz sample rate assuming you could write your whole
program in one instruction.

If your clock rate was referring to the external crystal frequency, why stop at
32.768khz? Why not claim you can do it with a "0hz clock rate", since the PIC,
and MSP430 along with other MCUs like the AVR, can all run with no external
clock at all using an internally generated R/C clock?

I'm certain you do not mean to imply in your above paragraph that you can
achieve a 50khz sample rate running a PIC on a 32.768khz crystal, simply because
an ADC sample can be done asynchronously to the MCU clock.

My assumption is that you know that while some of the newer PICs may allow a x4
clock multiplier, using a Phase Lock Loop, their internal sysclock is generated
by dividing the external oscillator by 4, leaving you with a 32.76khz MCU clock
rate.  This assumes you could even use the x4 PLL on the low speed clock, the
datasheets seem to claim this can only be done on the high speed (1-10mhz)
external clocks. The PICs have no where near the versatility in their clock
generation as the MSP430 does.

-Zonn

On Thu, 08 Jan 2004 09:52:14 +0200, Paul Keinanen wrote:

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

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. 

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

Pardon my ignorance as I have very little knowledge of rf. However the rf
engineer at rfm.com 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?

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

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. 

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

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. 

> Paul

Thanks a lot Paul.
Rahul

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

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

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

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

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

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/