> ilt sensor (Michel Tremblay , Thu 12:21)
>
> Do you guys know about a tilt sensor I could use in my project ??? I am lookin
g for a device that would either return a bynary
> or analog value proportionnal to it's tilt level.
>
> I looked in Digi-Key, Marshall and NuHorizon web site without success.
> Could I use a fluxgate device like the Vector 2 Compass module in the vertical
axis if I use the raw magnetometer output???
>
> Thanks in advance

Look for the Analog Devices ADXL202. They also have some sample PIC code
for it(16C6x)
and even an evaluation board with a PIC running it. Also check Crossbow
who are using their chips in their modules.

Well, I have been reading the gcc manual (the one that comes with the
source) and I have been studying Otto
Lind's port of gcc to the 68HC11. As far as I can see there is nothing
that would make porting gcc to the PIC 16F84 impossible or unfeasible.

Sure the Pic has no builtin stack, so you have to simulate one in RAM. But
gcc's optimization seems to be so good that most stack invokations are
eliminated anyway.

Furthermore the Pic has only one register, so you have to work with
virtual registers (as is the case for the 68HC11 port). This has the
potential of generating unnecessary store's and load's, but again gcc
seems to optimize these away. In fact the optimization power of gcc seems to
be truly awesome!

The fact that the Pic is 8bit, does not make it impossible to work with
16bit (or higher) variables. Gcc will store these in consecutive
(virtual)registers or stack locations.

One thing I was worried about was the implementation of the "const"
directive (this should be implemented through a lookup
table). However gcc will place constant array's in
code space (see the 68HC11 port), with the correct directive to make
them lookup tables.

As far as needing a new linker, I don't see why. The compiler would
generate MPASM files, which can be linked with Microchip's MPLINK and
MPLIB. I think there is enough code around to make a good standard 16
bit library.

To port gcc one would only need to write three files:

picxxxx.md : The machine description: describes the types of
instructions availabe. This is a kind of rule based expert system.

picxxxx.c : Support for picxxxx.h (some things are a little to
complicated to be implemented as macros). Also, when using makefiles,
it is better to have a .c file than a .h file. The latter tends to trigger
recompilation of everything.

If I find the time then I plan to try write some of these. I wouldn't
follow the 68HC11 port too closely, since I think Otto Lindt might have missed s
ome
potential optimizations (like the possibility of eliminating entirely a stack
frame for a function, which will happen quite often I think).

If other people are interested please email me (people from gnupic?). But please
read the
manual (Richard Stallmann's "Using and porting gcc") and study the 68HC11 port f
irst (a
search with altavista for the words 68hc11 and gcc will turn up the latter).

Well, I have been reading the gcc manual (the one that comes with the
source) and I have been studying Otto
Lind's port of gcc to the 68HC11. As far as I can see there is nothing
that would make porting gcc to the PIC 16F84 impossible or unfeasible.

Sure, but there is little point. The majority of the WORK involved will
be simulating a gcc-compatible archiecture, meaning that about all you'd
be able to use from gcc is the top-level parser. A top-level parser for
C isn't hard, and you'd have a quicker time starting from something like
pcc with a less "big" idea of how the processor works. Most of the value
of gcc is in the code generation and in the generality of the intermediate
machine model, and all of that would be worthless for a PIC C compiler.

I think you will end up close to targeting gcc to a 32-bit
architecture and interpreting that architecture on the PIC.
But of course I am prejudiced because I choose a different
route. I'd be interested in your experiences!
(I once stared targeting gcc to some weird space-grade
processor but I had to give up because there wasn't even a
good assembler or CPU decription available.)

Keep a few things in mind when you target PICs:
- the 8 (or even 2) level stack is a real trouble,
so consider to
- check the amount of stack needed at compiler time
- replace tail calls with jumps
- inline at least the single-called routines
- provide some alternative (store a return indication
and use a goto insetad of a call)
- accessing all data via some index register is
slow and uses lots of code; a static-stack
requires more work from the compiler (and
cannot cope with recusion) but is otherwise
much better

> From: Michel Van den Bergh <spam_OUTvdberghTakeThisOuTZOLA.LUC.AC.BE>
> To: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU
> Subject: Re: PICLIST Digest - 13 Jan 1999 to 14 Jan 1999
> Date: Saturday, January 16, 1999 13:05
>
> Hi,
>
> Well, I have been reading the gcc manual (the one that comes with the
> source) and I have been studying Otto
> Lind's port of gcc to the 68HC11. As far as I can see there is nothing
> that would make porting gcc to the PIC 16F84 impossible or unfeasible.
>
> Sure the Pic has no builtin stack, so you have to simulate one in RAM.

But
> gcc's optimization seems to be so good that most stack invokations are
> eliminated anyway.
>
> Furthermore the Pic has only one register, so you have to work with
> virtual registers (as is the case for the 68HC11 port). This has the
> potential of generating unnecessary store's and load's, but again gcc
> seems to optimize these away. In fact the optimization power of gcc seems
to{Quote hidden}

> be truly awesome!
>
> The fact that the Pic is 8bit, does not make it impossible to work with
> 16bit (or higher) variables. Gcc will store these in consecutive
> (virtual)registers or stack locations.
>
> One thing I was worried about was the implementation of the "const"
> directive (this should be implemented through a lookup
> table). However gcc will place constant array's in
> code space (see the 68HC11 port), with the correct directive to make
> them lookup tables.
>
> As far as needing a new linker, I don't see why. The compiler would
> generate MPASM files, which can be linked with Microchip's MPLINK and
> MPLIB. I think there is enough code around to make a good standard 16
> bit library.
>
> To port gcc one would only need to write three files:
>
>
> picxxxx.md : The machine description: describes the types of
> instructions availabe. This is a kind of rule based expert system.
>
> picxxxx.h : Macro definitions describing the stack outline, register
> usage, memory addressing schemes, function prologue and epilogue,
> passing of arguments in registers, etc...
>
>
> picxxxx.c : Support for picxxxx.h (some things are a little to
> complicated to be implemented as macros). Also, when using makefiles,
> it is better to have a .c file than a .h file. The latter tends to

trigger
> recompilation of everything.
>
> If I find the time then I plan to try write some of these. I wouldn't
> follow the 68HC11 port too closely, since I think Otto Lindt might have
missed some
> potential optimizations (like the possibility of eliminating entirely a
stack
> frame for a function, which will happen quite often I think).
>
> If other people are interested please email me (people from gnupic?). But
please read the
> manual (Richard Stallmann's "Using and porting gcc") and study the 68HC11
port first (a
> search with altavista for the words 68hc11 and gcc will turn up the
latter).
>
>
> Regards,
> Michel