All,


Ahhhh, and for me, I do work only with PIC's.  I don't have the need, or
inclination, to work with any other microcontroller (or microprocessor).
I work exclusively with PIC's.  This limits me, true.  But that is as
much a feature as it is a handicap.   I don't have to learn or use more
than one type architecture.  I like 
it that way.  It makes my designing and programming life much easier.
If I can't do it in a PIC, then either 
it doesn't get done, or someone else does it with whatever they're
comfortable with.  And since my PIC contracted jobs are not my bread and
butter, I can be as selective as I want to be with them.
But that's just me.  If I had to base my total income around embedded
systems, then that would be a whole other story.  And I can appreciate
those people who do that.  But I have a day job for my main livelyhood.
PIC jobs are supplemental.  They finance my PIC projects and lab
equipment.  It's a good situation for me.


	
Jim

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf
Of Herbert Graf
Sent: Thursday, March 06, 2008 4:33 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Mixing MPASM and C (Hi-Tech PICC)


On Thu, 2008-03-06 at 09:32 -0800, Bob Blick wrote:
> OK, Olin, I'll take you on. Let's see you switch to a different
> architecture(non-PIC) and make that claim. No, you can't have a month 
> to make libraries of needed functions, but you must create those 
> reusable needed functions while developing your program.
> 
> See, it takes more time to do a project in assembler now!
> 
> Also judging from years of experience reading your posts, I think you 
> are an exceptional person, and being an exception, just using you as 
> an example would be a poor sample. To do this properly we need to get 
> a group of programmers, plop them in a room with some weird processor,

> and half of them use assembler and half use C. Then switch and try
again.

Bob, I think you've hit the exact reason I prefer using an HLL:
portability.

If you are just using PICs I can see the argument for sticking with ASM.
Assuming you've accumulated all the libary routines you need it is a
wise choice since you are only open to flaws in the assembler, which is
relatively problem free.

The issue is the MOMENT you want to move to different hardware you're
toast. PICs REALLY lock you in with their weird architecture,
translating PIC ASM to say an 8051 MCU would be more hell then I'd be
willing to endure.

For me, all my routines are in C, purposely written in such a way that
they are relatively immune to hardware changes, and even compiler
oddities (i.e. how many bits is an int, is a char unsigned or signed by
default, what's the compilers default radix, etc.).

This doesn't always result in the simplest of code (i.e. my printstring
routine calls a putchar routine) but it does aid in portability. Taking
the example of a printstring function, since it calls putchar, the only
change I have to make when porting my code is putchar, a very simple
function. The change is often just a single line of code (i.e. calling
the UARTwrite library function of the MCU I'm working on).

I've used my library of routines for PICs (12F/16F, 24Fs and 30Fs),
AVRs, Stellaris MCUs, Windows apps, linux apps, and have ever
"transcoded" some of them to HDL (Verilog!).

I like to keep my options open, who knows what my job or hobby will
require of me with regards to MCU/CPU family, I want at least the option
to leverage my prior work.

All that said, there do come times when the "bloat" of this ideal is of
a concern, in those cases I've had to optimize my code more for the
hardware/compiler then I'd normally like. I've even had to plunk in some
ASM from time to time for REALLY timing critical code. Still, the vast
majority of my coding is C/C++ these days.

> Finally, I'm glad you chose C18 as your example of a bad C compiler. I

> agree with you there :) The only good thing about it is that it does 
> work and is supported.

Even more importantly, Olin choose MChip's TCP/IP stack, a truly
difficult piece of code to get one's head around! :)

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

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