Re: what uC do you prefer?

On Fri, 20 Jul 2007 17:54:39 -0700, John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Harvard is an anomoly. And a nasty anomoly. Decent processors have a
unified code/data/IO address space, without specific i/o opcodes. So
you can apply the same instructions to anything, and put data
structures and code wherever they fit best. A table can contain mixed
data and flags and routine addresses, for example.

I must say that the Harvard has got in the way of what I want to do a
*lot* more times than it helps - in fact I can't think of a single
time when having seperate data/program structures has been anything
better than neutral i.e i don't care about it. I am fully aware of the
dangers of having buffers and data structures butting up to the edges
of code (buffer over-run exploits - spesh of Billy boi) but that is
hardly a problem for a lot of embedded stuff. I guess as we march to
more advanced uCs and solutions it might have a place but I have
always considered buffer over-runs and the like to be ***
programming... I have never written a piece of code that didn't check
limits on storage areas as it worked... oh, wait... I have... years
ago with Z80 stuff... never really kept an eye on the stack pointer
moving down through RAM but never had a crash - code was not
sufficiently complex or recursive enough to use up the DMZ between
last_byte and SP :o). I do hanker for a contiguous RAM area where I
can point to sections of code and modify them on the fly, place data
in line etc. PICs are cheap and pretty well spec'ed but I am starting
to get constrained with constant bank switching on calls and jumps or
checks thereof and the encoding method for tables or even simple
message to be output to having to be wrapped in code and the table
called with a progressing pointer are a real pain. I just feel the
core is limiting things and all the ways of doing stuff, instead of
being "works of creativty" by the programmer are a series of
work-arounds :o( Don't get me wrong, I think PICs are great and dead
easy to program so long but you need to keep constantly aware of the
wrinkles - and I only ever write assembler so I don't have some HLL
keeping a check on this for me - with the resultant increase in code
size and reduction in speed.

Sometimes it would be nuice to
have data available as bytes without having to wrap it in code and
form tables. Tonight I scared myself - I caught myself googling
"microcontroller z80 core" eek!

I mostly use the MC68332, a very CISCy 32-bit machine. It's a pleasure
to program in assembly, and has a beautiful orthogonal instruction
set, including some handy 32 and 64 bit mul/div things. The later
versions of this architecture are the Coldfire parts.

That does sound a nice piece but way beyond what we have a need for
here which are mainly small controllers/converters etc. I really liked
motorola assembler on the 68K family - is it much different - (looks
on shelf - sees "programming the 68000" - sighs :o)


Like, we often use a single 8-bit wide eprom, to save board space. But
that makes instruction fetches slow. So for a subroutine that has to
run fast, we just copy the code from eprom to CPU internal ram, and
run the copy there, blindingly fast. We can even reuse the ram
workspace, overlaying different blocks of code. It's easy, with a
decent architecture.

yep -standard proceedure - the preamble gets everything ready for fast
code - the PIC is fast (in it's place) so the code execution is not a
problem, but if you want to update the code down the phone or
something and store it in a serial eeprom, I think only now are
Microchip producing a part that allows sections of the program to be
"blown on the fly"


The TI 16-bitter, the MSP430, is pretty nice too, and very fast. Like
the 68332, it has a register-rich, symmetric, very PDP-11 looking
architecture.

PDP... <whipes a tear from her eye>

.