PIC18 back end for XCode - Is there such an animal?
Don Bruder
talks to a PIC18F4550 chip.
I don't expect to need a LOT of PIC18 code for the project I have in
mind, but it seems to me that writing it in C (even a pretty sharply
restricted subset, if need be) would be a whole lot less headache than
trying to hand-assemble a brand-new-to-me, totally foreign assembly
language.
What I'm *HOPING* to find is a back end that I can attach to XCode to
make it produce hex that's ready to be loaded into the PIC18 for
execution.
Anybody around here know if such a beast exists, and if so, where I can
find it?
Seems to me like there ought to be something out there to take care of
this dilemma, considering we've already got gcc as the "guts" of XCode.
As I understand things, gcc is supposed to mix and match back ends to
produce code for whatever system/device somebody has coded a back end to
handle - Two prime examples being the production of both PPC code
(possibly in multiple flavors, if needed) and Intel code in a single
build session.
Failing that, can anyone point me to any tools, free/cheap preferred,
targeting the PIC18 chip-family on the Mac?
Oh, and yes, I'm aware of the one at the htsoft.com website - I've
downloaded it three times now, and all three downloads have given me the
same "Verifying archive integrity...Error in checksums: <10-12 digit
number> is different from <different 10-12 digit number>" output when I
try to execute the install script.
Lotsa cross-post, I know - But they all seem to be relevant for the
query.
--
Email shown is deceased. If you would like to contact me by email, please
post something that makes it obvious in this or another group you see me
posting in with a "how to contact you" address, and I'll get back to you.
Frank-Christian Krügel
> Looking to get into playing with a USB-connected experimenter board that
> talks to a PIC18F4550 chip.
Well, if you'd replace the PIC with an Atmel AVR 90USB162 or an
90USB1287 your life yould me MUCH easier. The PIC arcitecture is
unsuitable for gcc, for the AVR architecture with it's 32 GP registers
there is a nice gcc port.
Or skip the 8 bit world totally and choose an STM32F103 Cortex M3. The
price is nearly the same, and you'll get much more power.
Just think about it.
--
Mit freundlichen Gr��en
Frank-Christian Kr�
don
You mean the Xcode cross compiler for Apple computers ??
I have never seen cross compiler tools for Macs that really work in the
embedded world.
Good luck
don
Sherm Pendley
> Seems to me like there ought to be something out there to take care of
> this dilemma, considering we've already got gcc as the "guts" of XCode.
> As I understand things, gcc is supposed to mix and match back ends to
> produce code for whatever system/device somebody has coded a back end to
> handle - Two prime examples being the production of both PPC code
> (possibly in multiple flavors, if needed) and Intel code in a single
> build session.
I haven't created such a beast, but I do know that Xcode can be convinced
to use toolchains other than those provided by Apple. Cocotron, for
example, uses a MingW32-based toolchain to cross-compile Windows apps
from within Xcode. You might try asking those folks how they did it.
sherm--