gnupic: Re: [gnupic] What About GCC and PIC's


Previous by date: 8 May 2005 04:23:12 +0100 Re: [gnupic] What About GCC and PIC's, Martin McCormick
Next by date: 8 May 2005 04:23:12 +0100 gpsim font problems, Peter Onion
Previous in thread: 8 May 2005 04:23:12 +0100 Re: [gnupic] What About GCC and PIC's, Martin McCormick
Next in thread:

Subject: Re: [gnupic] What About GCC and PIC's
From: Iain Dooley ####@####.####
Date: 8 May 2005 04:23:12 +0100
Message-Id: <427E14C2.8030607@iaindooley.com>


Martin McCormick wrote:
> [...]
> Even if one develops
> lots of code blocks for doing whatever strikes one's fancy in
> assembler, it seems like there is always something in one's new
> program that keeps the code from fitting without a little hammering
> so to speak.

i found the MATH18 libraries which are the C18 routines provided by microchip reproduced in standalone assembler by Chris Twigg (available as MATH18.zip from http://www.picbook.com) relatively painless to use (just beware of the byte ordering in return values!!)

> 	The best of both worlds will come if we can write modules in C
> and other modules in assembler, if necessary.

i do this by providing an interface header file which contains sub-program call macros that put arguments in global memory locations and allow me to call assembler sub-programs as if they were C functions.

> 
> 	The late Admiral Grace Hopper was the creator of the first
> assembler when she and her team got tired of having to do so much work
> each time just to write a simple program.  The bottom line to me is to
> get as much done with as little repeat effort as possible.
> 
> 	Higher level languages are force multipliers.  As long as they
> produce efficient code that has some hope of fitting on the device in
> question, we are talking about an advancement in the state of the
> art.  It's not better than assembler, but kind of picks up where the
> assembler leaves off.

i find that for micro controller programming, the experiences of writing in C or writing in assembler are remarkably similar. by farming out menial repetitive assembler tasks to convenience macros much of the grunt work can be taken out of coding.

i also find that i write more highly modular code in assembler. for example, a particular project will usually require a few particular arithmetic operations (such as compensating for air temperature to calculate the time of flight of a sonar sensor or calculating points on a set of bezier curves). if i was working in C i would probably just write these calculations out in a function, but in assembler i create a module, include the math routines i need and provide an external interface to the module that behaves in the same way as a C function anyway. as well as saving on assembling time when the code base gets large enough, i have found that it aids thourough testing of detailed aspects of the program. in other words, it's more difficult to make a mistake.

as for portability, having portable design patterns is enough for me. being able to reuse the exact same code doesn't excite me all that much. by applying the same design patterns to a new chip with a new assembly language you not only have the chance to refine those patterns, but also ensure that weird bugs due to differing C compilers don't surface at weird times and cause you to do weird things to your hair.

iain

Previous by date: 8 May 2005 04:23:12 +0100 Re: [gnupic] What About GCC and PIC's, Martin McCormick
Next by date: 8 May 2005 04:23:12 +0100 gpsim font problems, Peter Onion
Previous in thread: 8 May 2005 04:23:12 +0100 Re: [gnupic] What About GCC and PIC's, Martin McCormick
Next in thread:


Powered by ezmlm-browse 0.20.