I'd like to know if there are any compilers one could buy to program a PIC or
8051 in C++. I'd like to stay as far away from direct assembly coding as
possible. I'd find it much easier and friendlier to code in C++. Does anyone
have any suggestions.
Thanks in advance.
Yes, I too would like to know more about people's experiences with C
compilers and the PIC. Writing PIC assembler is so simple, it is difficult
to justify a C compiler, however, some larger projects (depending on the
application) could really benefit from C.
>From what I can tell, it looks like HI-Tech Software's C compiler is the
strongest. The demo I downloaded had a lame DOS interface. It would take
all of a week to write a Win32 GUI, so it makes one wonder...
At 14:06 03/04/99 -0500, Justin McSharry wrote:
>I'd like to know if there are any compilers one could buy to program a PIC or
>8051 in C++. I'd like to stay as far away from direct assembly coding as
>possible. I'd find it much easier and friendlier to code in C++. Does anyone
>have any suggestions.
AFAIK no. one more vote for embedded c++ -- there are a number of nice
features of c++ that don't cost anything on the target side and only let
the compiler do more work (and the programmer less work :)
the problem is to come up with a definition that really doesn't put an
extra load on the target. AFAIK they haven't yet finished the discussion
around embedded c++, and probably it won't be practical for the pics
anyway. gotta stay with c.
Justin McSharry wrote:
>
> I'd like to know if there are any compilers one could buy to program a PIC or
> 8051 in C++. I'd like to stay as far away from direct assembly coding as
> possible. I'd find it much easier and friendlier to code in C++. Does anyone
> have any suggestions.
> Thanks in advance.
>
> Justin McSharry
> Drivex, Inc.
Why don4t you ask M$ for a generic WinCE version for 8051 or PIC
processors.
Developement would be easy because you could use all M$ Visual studio
tools
for writing GUI based applications on your PIC 12C508 ;-)
Ok, back to reality:
If you like to have easy programming and dont like to fiddle with
assembler you may try a Basic-Compiler.
There is IMHO no way with 8051 or PIC to do C++ programming.
In this case I refer C++ in using classes and objects. Because
using the particulary features of C++ requires a whole bunch of memory.
You can use a plain C to don4t need to do all things by your own, like
you would have to in assembler.
I would strongly suggest getting into assmbler. Then, after getting
a led switched in assembler you may think about using a C-Compiler.
It4s always good to know the basics.
On the other hand - all above depends on what you like to do with the
microcontroller.
>AFAIK no. one more vote for embedded c++ -- there are a number of nice
>features of c++ that don't cost anything on the target side and only let
>the compiler do more work (and the programmer less work :)
And take more ROM/RAM.
Andy
\-----------------/
\ /---\ /
\ | | / Andy Kunz
\ /---\ / Montana Design
/---------+ +---------\ http://www.montanadesign.com
| / |----|___|----| \ |
\/___| * |___\/ Go fast, turn right,
and keep the wet side down!
Andy Kunz wrote:
>
> >AFAIK no. one more vote for embedded c++ -- there are a number of nice
> >features of c++ that don't cost anything on the target side and only let
> >the compiler do more work (and the programmer less work :)
>
> And take more ROM/RAM.
It's been a while since I did C++, so forgive me if I've got it wrong,
but I thought that C++ could be more or less directly pre-processed into
C, without introducing any real runtime overhead. Unless your methods
are all declared virtual, why should C++ take up any more ROM/RAM?
>It's been a while since I did C++, so forgive me if I've got it wrong,
>but I thought that C++ could be more or less directly pre-processed into
>C, without introducing any real runtime overhead. Unless your methods
>are all declared virtual, why should C++ take up any more ROM/RAM?
Because compilers usually aren't as efficient as writing in the next
language down the totem pole. Why does C take more RAM/ROM than assembly
(usually).
Andy
\-----------------/
\ /---\ /
\ | | / Andy Kunz
\ /---\ / Montana Design
/---------+ +---------\ http://www.montanadesign.com
| / |----|___|----| \ |
\/___| * |___\/ Go fast, turn right,
and keep the wet side down!
> Andy Kunz wrote:
> >
> > >AFAIK no. one more vote for embedded c++ -- there are a number of nice
> > >features of c++ that don't cost anything on the target side and only let
> > >the compiler do more work (and the programmer less work :)
> >
> > And take more ROM/RAM.
>
> It's been a while since I did C++, so forgive me if I've got it wrong,
> but I thought that C++ could be more or less directly pre-processed into
> C, without introducing any real runtime overhead. Unless your methods
> are all declared virtual, why should C++ take up any more ROM/RAM?
Ben,
You're right and Andy is wrong - at least sort of. As long as you
understand C++ it's possible to create software as tight or even tighter
than C (this is obviously compiler dependent...). However, it's mighty
tempting to use virtual functions in some applications and then C++ will
appear to use more RAM/ROM then C. I say appear because the functionality
achieved with the virtual function takes as much overhead if the same
operation is implemented the same way in C. However, most C programmers
don't write in this abstract manner (nor do they need to for relatively
small microcontroller based projects) and consequently always 'know' where
their 'virtual' functions are pointing. The point is, that some of the
elegance C++ offers can use more ROM and RAM if the programmer is not
aware of the implementation details.
> >It's been a while since I did C++, so forgive me if I've got it wrong,
> >but I thought that C++ could be more or less directly pre-processed into
> >C, without introducing any real runtime overhead. Unless your methods
> >are all declared virtual, why should C++ take up any more ROM/RAM?
>
> Because compilers usually aren't as efficient as writing in the next
> language down the totem pole. Why does C take more RAM/ROM than assembly
> (usually).
Right, fair point, but the code-generation side of the compiler, in
this case, is pretty much the same for C as it is for C++.
The gap between C++ and C is very small, compared to the gap between
C and ASM. I believe C++ can be pretty much be translated to C via
some function name mangling, with no additional overhead being
introduced. If the program is sensibly written, and the compiler
isn't stupid, then C++ should be just as efficient.
Of course, I've had no experience using C on a microcontroller,
so I can only extrapolate from PC experience.
At 08:34 03/05/99 -0500, Andy Kunz wrote:
>>AFAIK no. one more vote for embedded c++ -- there are a number of nice
>>features of c++ that don't cost anything on the target side and only let
>>the compiler do more work (and the programmer less work :)
>
>And take more ROM/RAM.
depends. there are some features (eg. inline functions) which don't cost
anything on the target side, not ram nor rom nor rum, but can ease
development. wouldn't you like to be able to turn a function practically
into a macro, without any side effects, by simply putting the modifier
"inline" in the declaration? in case there is some code memory left, but
time seems to be scarce? (of course, in this case it costs more rom, but
that's user controlled and desired.)
If you decide to purchase please tell him I sent you.
Unfortunately, I'm not on commission....
====================== Original Message Follows ====================
>> Date: 05-Mar-99 07:35:22 MsgID: MC2-6CDB-D206 ToID: 73130,2721
From: pic microcontroller discussion list >INTERNET:.....PICLISTKILLspam@spam@MITVMA.MIT.EDU
Subj: Re: methods for programming chips
Chrg: $0.00 Imp: Norm Sens: Std Receipt: No Parts: 1
Yes, I too would like to know more about people's experiences with C
compilers and the PIC. Writing PIC assembler is so simple, it is difficult
to justify a C compiler, however, some larger projects (depending on the
application) could really benefit from C.
>From what I can tell, it looks like HI-Tech Software's C compiler is the
strongest. The demo I downloaded had a lame DOS interface. It would take
all of a week to write a Win32 GUI, so it makes one wonder...