Exact match. Not showing close matches.
PICList
Thread
'[PIC] dsPIC vs PICxxF'
2009\09\23@173617
by
Tamas Rudnai
(added [PIC] tag otherwise many piclister would not be able to read it)
dsPIC is a 16bit microcontroller and it supports instructions used for DSP
algorithms. If you are SW engineer you would understand the analogy of Intel
x86 CPU: dsPIC is like a Pentium with MMX/SSE extention, while others
(PIC12xxx PIC16xx, PIC18xxx) without it (like a 386 or 486). PIC24 is also a
16bit one but without the DSP support -- like it was a Pentium without
MMX/SSE (which is a non-existent product as far as I know, but for the sake
of analogy).
Asking C or Assembly leads to a big-bigwar here.... so better not even
asking such a question :-) As far as I concern most people program dsPIC in
C as they need heavy maths like furier transform and is easier to develop
and maintain it in a HLL.
Tamas
---------- Forwarded message ----------
From: Quintin Beukes <spam_OUTquintinTakeThisOuT
last.za.net>
Date: Wed, Sep 23, 2009 at 7:05 PM
Subject: dsPIC vs PICxxF
To: "Microcontroller discussion list - Public." <.....piclistKILLspam
@spam@mit.edu>
Hey,
This is purely out of curiosity.
What are some practical applications of the dsPIC. I'm actually a
software developer and have only started learning about electronics
about 2months ago when our lead engineer resigned. I did, however,
notice on Microchip's website that it's a DSP/Signal Controller. But
what exactly would you use this for.
Further, do you also program them in C/ASM?
Quintin Beukes
2009\09\23@223403
by
Adam Field
> like it was a Pentium without
> MMX/SSE (which is a non-existent product as far as I know, but for the sake
> of analogy).
>
Actually, to push this into OT territory, the Pentium didn't get MMX
until it reached 166MHz. Pentiums from sockets 4 & 5, 60MHz onto
166MHz didn't have any extra instruction sets. I believe there were
some non MMX 166MHz ceramic chips produced as well. SSE didn't become
available until the Slot 1 Pentium at 450MHz.
2009\09\24@075048
by
olin piclist
Tamas Rudnai wrote:
> (added [PIC] tag otherwise many piclister would not be able to read
> it)
I would have left it. Anyone that can't follow such simple directions has
no hope of understanding something with a multi-page datasheet like a PIC.
From: Quintin Beukes <quintin
KILLspamlast.za.net>
> This is purely out of curiosity.
>
> What are some practical applications of the dsPIC. I'm actually a
> software developer and have only started learning about electronics
> about 2months ago when our lead engineer resigned. I did, however,
> notice on Microchip's website that it's a DSP/Signal Controller. But
> what exactly would you use this for.
Look up something called DSP, which stands for digital signal processing.
I'm sure there's loads about it out there. From the hardware point of view,
DSP capability means special hardware optimized to do convolutions, since
these are the heart of finite impulse respose (FIR) filters. Again, there
will be lots on convolution and FIR filters out there.
Performing a convolution means multiplying the corresponding elements of two
arrays together, with the result being the sum of all these individual
products. To do this efficiently in hardware, it needs fast
multiply-accumulate capability. It also needs some way to advance the array
indexes and check for loop termination. Generally in DSP hardware these
things are all overlapped so that successive multipy-accumulates can be
performed as rapidly as the multiply and add hardware allows, with the other
operations concurrent. This hardware may be optimized for doing a block of
these things, so it's acceptable to pipeline it where it may take a few
cycles to fill the pipeline initially and a few more to get that last result
out.
> Further, do you also program them in C/ASM?
Generally if you're using a dsPIC, you're pushing speed limits somewhere.
That somewhere is likely coded in assembler so that the inner couple loops
or so can be carefully optimized. The C30 compiler is pretty reasonable, so
you can use it for the higher level control code that is less speed
critical. The calling conventions make sense (unlike those of C18), so
there is not much trouble mixing C30 code with ASM30 code.
For example, I've got one application that samples the analog outputs of two
radio receivers at 100KHz, meaning I get two 10 bit samples every 10uS. The
A/D interrupt routine needs to be in assembler because every cycle matters.
It grabs the readings, converts the logarithmic output of the radios to
linear via a lookup table, averages them, updates the recent history, uses
the history to find the recent high and low, uses that to decide a high/low
data slicing threshold, uses that to decide whether the current sample is
high or low, checks for a transition, and if there was a transition, pushes
that onto a FIFO for processing by foreground code.
The next level up that drains the FIFO and performs the front end of the
manchester interpretation is still pretty speed critical, but the logic gets
less speed critical as it gets into higher levels. I could have written
those in C30, but stuck with assembler because everything else was already
in assembler, I've got more toolchain support for assembler, I'm very
comfortable with it and dsPIC assembler is particularly easy to write, and I
can't stand C as a language.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000.
More... (looser matching)
- Last day of these posts
- In 2009
, 2010 only
- Today
- New search...