On Thu, 2005-10-27 at 20:34 -0700, William Chops Westfield wrote:
> On Oct 27, 2005, at 3:34 PM, Peter wrote:
> 
> > management decides to go with a slightly different code.
> > The programmer gets to port it.
> 
> Portability is an important part of the advantages of a high level
> language, although a bit overrated for typical microcontrollers.  OTOH,
> perhaps it works really well between the different PIC cores (which,
> after all, have SIMILAR architectures and peripheral sets.)  Does anyone
> have good things to say about going between 12, 14, and 16 bit PIC cores
> using a high level language vs assembler?  (Of course, something like
> Olin's environment makes this easier to do in assembler as well.)

It all depends on how you've done your HLL stuff.

For example, if you have a software I2C routine in C you can code it in
a bunch of ways. Some of those ways lead to almost zero portability (the
routine twiddles the port bits directly). Some of those ways lead to
almost universal portability (i.e. the routine calls a generic bit
twiddling routine).

In my case I had an I2C routine written for a DOS based PC that directly
ported to a PIC. The reason being the I2C routine called a very simple
IO function that I simply rewrote for the PIC in question (about 4 lines
of code to rewrite).

Later on, I wanted to use the hardware I2C. Obviously the bit twiddling
routine I used wasn't an option for that, but all I did was write a new
routine that accepted the interface to the old bit twiddling routine and
mapped that to the I2C hardware. More then 4 lines of code to mod, but
not that much more.

This sort of idea can be expanded on to make almost any function pretty
much independent of the actual hardware. The trick is to take the time
up front to ensure what you're doing is as "universal" as possible. 

Lastly, let me add that this idea leads to code that isn't always the
most efficient (mostly due to the function calls, which can be helped by
in-lining things), and that is a trade off (you never get something for
nothing). But in the end being able to reuse code is often worth the
extra price of a few cycles and ROM locations lost.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

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