Okay, you've all convinced me. After using CCS's compiler for 4 years,
with varied success, I have decided to follow Andy's advise (after
weeding out the sarcasm ;) and have purchased the HiTech compiler. Call
me a "Potential Convert".
Now before I spend boku hours discovering them for myself, can someone
answer the following concerns for me?
1) Are there any potential shortcomings to the HiTech compiler that
I should be aware of?
2) Any unresolved bugs that require work arounds?
3) Anything I need to know before converting my CCS C code to
compile using HiTech?
> 1) Are there any potential shortcomings to the HiTech compiler that
>I should be aware of?
START SIMPLE! I prefer to use an external editor (Programmers File Editor)
as my development environment. This means I use the command-line compiling
rather than the IDE. It works nicely.
I prefer this because I can see EXACTLY what options are being done, rather
than having a project file to hold these settings for me. I add a couple
lines of code to each source file to specify the compile command.
is typical of my line. Note that this includes several things I've added
to my header files: an "idfuse" and "chiptype" psects for holding chip
fusing and chip type (for Parallax/Tech-Tools/Carmacon compatibility).
> 2) Any unresolved bugs that require work arounds?
None that I know of, in the version currenly on the web (requires PL1 RTP
file).
> 3) Anything I need to know before converting my CCS C code to
>compile using HiTech?
Inline assembly will be different.
ISR declaration is different.
You now have access to all the RAM in your chip. To get to banks other
than bank0, you specify the bank it is on.
Any questions there's the HTC list (see their site), the forum, and you can
always ask me either on this list or privately. Their Tech Support is
excellent.
> > 1) Are there any potential shortcomings to the HiTech compiler that
> >I should be aware of?
>
> START SIMPLE! I prefer to use an external editor (Programmers File Editor)
> as my development environment. This means I use the command-line compiling
> rather than the IDE. It works nicely.
>
> I prefer this because I can see EXACTLY what options are being done, rather
> than having a project file to hold these settings for me. I add a couple
> lines of code to each source file to specify the compile command.
Does the compiler use these lines, or are they just comments?
>This is not very good if your syntax contains many errors at the last count
>Hi-tech had so many different error formats that it was almost impossible
>to use an off the shelf editor and customise the error filter to put the
>cursor on teh erred location, of course this situation may have changed.
I don't even worry about that. It puts out line numbers, and those are
shown by the editor. Easy enough to not have to worry about error
formatting. Besides, I don't think PFE supports that feature, although
CodeRight does (the other editor used here).
It is the ONLY way to do it if you have very complex link requirements,
which often is the case for me.
At 19:09 19/08/99 -0400, you wrote:
>>This is not very good if your syntax contains many errors at the last count
>>Hi-tech had so many different error formats that it was almost impossible
>>to use an off the shelf editor and customise the error filter to put the
>>cursor on teh erred location, of course this situation may have changed.
>
>I don't even worry about that. It puts out line numbers, and those are
>shown by the editor. Easy enough to not have to worry about error
>formatting. Besides, I don't think PFE supports that feature, although
>CodeRight does (the other editor used here).
>
>It is the ONLY way to do it if you have very complex link requirements,
>which often is the case for me.
>
I don't agree with this one at all. The IDE offers full path and library
searches for all object modules and you can format the exact location for
each one. So please explain WHY it is the ONLY way to do it. Of course it
can beconme very slow and arduious if there are several paths containing
header files etc. This can become a nightmare to maintain over long periods
with stuff being moved all over the place. If this is embedded into each
file then the task becomes an order of magnitude larger, but still if the
other method is used then the link files need to be modified and the user
must be aware of the path for header stuff etc when creating and compiling.
So I may have answered my own question but it is not the ONLY way, just one
of several
>I don't agree with this one at all. The IDE offers full path and library
>searches for all object modules and you can format the exact location for
>each one. So please explain WHY it is the ONLY way to do it. Of course it
Well, Dennis, it isn't unusual for me to have two modules which are
seemingly separate programs in my chips.
For instance, I've done several products which use a BIOS at a fixed
address, plus an application layer at another fixed address. The entry
point to the apps "main()" must, therefore, be provided at the same point
in every compile of the app (the BIOS is compiled separately).
It takes multiple passes with the linker (4 actually) to get the two
modules compiled from scratch. I get two hex files for some products (they
are factory programmed with the BIOS, I just drop the application on
afterwards).
Here's a neat trick, for those who like this approach: Have your boostrap
code (part of the main() of the BIOS) exit to the application with a GOTO
<last address in memory> (or, if you have a big chip, last address - a
couple so you can set the banks up correctly). In an unprogrammed chip,
this will be an ADDLW -1 command which will essentially wrap you back to
address 0, starting the bootstrap again. If part of the bootstrap code
initializes pins and toggles something, you can verify operation by looking
for the pin to buzz at the right frequency.
This technique is especially handy for the 17C parts with external memory.
The Hitech IDE is simple, my brain is simf sym simm simpu
simple. Do everything from there. I do it this way.
Everything is saved in the project file (1 place =good). I have spent
enough time rummaging through other peoples code to know that
the less places you have to look for things the better.
Also, save your .prj .c and .hex files for every version of your code
in a subdirectory like V101, V102 etc. This makes it easy to
retrieve old versions at a moments notice. Eg, customer says that
they liked the features in version X.XX better can you email them
the file for their programmer.
...plus lots more reasons, but then it wouldn't be simple anymore...
Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile: 025 334 069
eMail: KILLspambrent.brownKILLspamclear.net.nz
montanadesign.com
