Slightly offtopic (perhaps)

I've been studying dsPIC for a few days now and the following thing puzzles 
me a little:

According to the manuals, constant data in programspace is meant to be 
fetched using the PSV. PSV allows the upper 32kByte RAM addressingspace to 
be mapped onto a selectable (PSVPAG-register) 32 kByte programspace. The 
alternative way of accessing programspace ( TableReads ) is said to be 
intended only for self-programming or when you want to fetch entire 
programwords (instead of only the lower 16 bits of each word). Ok, this all 
makes sense.

But:
Does this mean that we will never see dsPIC's with more than 32kByte RAM? Or 
are we then supposed to switch PSV on/off as needed?
>From what I've seen, the C30 compiler does not dynamically enable/disable 
PSV. Does this mean C30 is limited to 32kByte RAM?

Yes, I know 8kByte RAM is the most you can get currently. :-)

Marcel

Olin Lathrop wrote:
> John J. McDonough wrote:
>> Like ... 16 bit registers,
>
> Right, it's a 16 bit machine.
>
>> except for the 40 bit ones (why 40?)
>
> You failed to mention that these are the two DSP accumulators.  They are
> meant to perform 16 bit multiply-accumulate operations, so it makes sense
> for the them to be 32 bits wide.  The extra 8 bits are for overlow, which 
> is
> a very nice touch.  Some DSPs have don't have such a wide accumulator, and
> it gets to be a pain.
>
> However unless you are doing DSP operations, just ignore the DSP
> accumulators and the DSP instructions.  They are different because of what
> they need to do, but you don't have to use them.
>
>> Some memory accessible to some instructions some of the time
>
> Think of it this way.  RAM is addresses indirectly thru another register,
> but some instructions give you a way to address the first K or so (I don't
> remember right now) directly as a bonus.
>
>> Two different ALUs with pretty different behavior ... probably a good
>> thing, but odd
>
> Not at all for a DSP.  Again, if you're not doing DSP, just ignore that
> part.
>
>> Almost all instructions 1 cycle except for a few 18 cycle ones ...
>
> You neglected to mention these are divide instructions.  It would be a 
> true
> miracle if they could put a 32 by 16 bit divider for that price and power 
> in
> there that took only one cycle.  As it is, you get a 16 x 16 into 32 bit
> multiply in one cycle.  The other PICs don't have dividers at all.  What
> would you rather have, no divide instruction or one that takes 18 cycles?
>
>> and the few that take two cycles unless you hold your head just right
>> in which case they take 3.
>
> Of coures branches take 2 cycles, just like on other PICs.
>
>> And no, not simple and predictable like btfsc.
>> GP registers useable as GP registers some of the time
>>
>> Hardly orthogonal!
>
> Mostly orthogonal except where the feature dictated otherwise.  Overall I
> think the dsPIC is a really nice well designed microcontroller that does a
> real good job at what it is intended for.
>
>> And yeah, I make it sound worse than it is.
>
> Yes, you are being rather unfair.  Everything is a tradeoff.  Keep in mind
> these things go into cost sensitive applications.  The important part is 
> how
> much capability and performance can be squeezed out of silicon that has to
> sell for $5 packaged.  Whether the instruction set is 100% orthogonal or
> every instruction takes the same number of cycles is not that important in
> the scheme of things.
>
> Personally I find the dsPIC easy to program, even compared to other PICs.
>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist