PIC microcontrollers and C++

[rtarbell]

I know that many compilers can generate .hex files for assembly and C code, but are there compilers that can do assembly and C++ code into hex? I'm looking for one that is compatible with PIC microcontrollers.

Thanks!
-RT

 

[manojanand]

i am also looking fo rthe same. please help.

 

[coshkun]

Why do you want to work with c++? If you know c++ then that means you also know most of C. Writing PIC programs in C will be much more efficent than others written in C++.C++ is an object oriented language and that's not suitable for 8 bit PICs.

 

[btbass]

Well said! C++ is for large distributed systems. C is for embedded. Unix is written in C (so is most of widows) and there aint nothing wrong with that.
C is elegant, C++ is ugly!

 template <typename T, typename Destroyer>
    void SetLongevity(T* pDynObject, unsigned int longevity,
        Destroyer d)
    {
        using namespace Private;
        
        TrackerArray pNewArray = static_cast<TrackerArray>(
                std::realloc(pTrackerArray, 
                    sizeof(*pTrackerArray) * (elements + 1)));
        if (!pNewArray) throw std::bad_alloc();
        
        // Delayed assignment for exception safety
        pTrackerArray = pNewArray;
        
        LifetimeTracker* p = new ConcreteLifetimeTracker<T, Destroyer>(
            pDynObject, longevity, d);
        
        // Insert a pointer to the object into the queue
        TrackerArray pos = std::upper_bound(
            pTrackerArray, 
            pTrackerArray + elements, 
            p, 
            LifetimeTracker::Compare);
        std::copy_backward(
            pos, 
            pTrackerArray + elements,
            pTrackerArray + elements + 1);
        *pos = p;
        ++elements;
        
        // Register a call to AtExitFn
        std::atexit(Private::AtExitFn);
    }

    template <typename T>
    void SetLongevity(T* pDynObject, unsigned int longevity,
        typename Private::Deleter<T>::Type d = Private::Deleter<T>::Delete)
    {
        SetLongevity<T, typename Private::Deleter<T>::Type>(pDynObject, longevity, d);
    }

I can't see this sort of code siting in a Pic?

 

[kender]

Clarifications

To answer the original question, I don't think that there is a C++ compiler for PICs. The use of objects cause a significant overhead, and today the benefits of C++ don't outweight the overhead in case of a PIC. Don't worry, anything you can do in C++, you can also do in plain C.

I have objections/clarifications to some (rather blunt) posts in this thread.

C++ is for large distributed systems.

Distributed between... what?..
Multiple CPUs?.. No. C++ doesn't even have intrinsic support for multithreading, not to mention multiple CPUs. There are higher level protocols such as DCOM, CORBA and .NET that use C++ to build distributed systems.
Multiple programmers?.. Probably. If you think that there will be more than, say, three programmers working on the same executable, C++ should start to make sense. The platform or the code size often doesn't really matter. Granted, there are seldom more than 2 programmers writing code for the same PIC, because the amount of code on a PIC is relatively small. Although I’ve seen a group of 5 students writing C code for a single 18LF8720 chip for about 3 months, and the only reason why they didn’t spend another X months integrating was that they had the interfaces defined by the Pumpkin OS from the very beginning.

There are larger microcontrollers (such as ARM) that support C++. As time progresses PICs will get more Flash, RAM, and they will become faster. Eventually, writing a C++ compiler for PICs will become economical, and somebody will write it.

C is for embedded.

I would rephrase it. C is most often used for embedded. The survey in 2002 had shown that 80% of embedded programmers write in C and 40% of them write in C++ (obviously, there's an overlap).

 

[coshkun]

C is the king of embedded languages (then assembly is the princess

 

[pete]

There are so many generations of PIC language using C. Which one is the best?
I tried using CCS C, powerful but some commands are quite complicated to use like interrupts, driving LCD and has some bugs as others would say(may be its corrected now). Also, the Micro C is good and easier but library support is not yet abundant? IAR is ANSI compliant but you need to be professional C programmer to understand it all. For 8051, you have the Keil for C. For the ATMEL, what C language package can we use?

 

[escapevn]

What compiler for this?

 

[kender]

C is the king of embedded languages (then assembly is the princess)

"If someone working for you writes in assembly - fire him to keep your own job." Dr. Frank Angle

 

[narfnarf]

C is the king of embedded languages (then assembly is the princess)

"If someone working for you writes in assembly - fire him to keep your own job." Dr. Frank Angle

Why? I have a soft spot in my heart for assembly. A well written assembly code sing out like a beautiful poem.

Not to mention, for space/resource limited situation (like in a PIC) it is usually not a bad idea to write in assembly. Since you need to know the peripherals/registers well anyway, you might as well write the assembly to directly control the hardware.

But the microchip C18 isn't bad either! Too bad C18 only works w/ 18F and sometimes 18F is just too expensive!

 

[btbass]

I recommend Hi-Tech for the low end 16 series, Microchips Mcc18 for the 18 series and Microchips Pic30 tools for the high end 24, 30 33's. The high end chips, dsPic etc are 16 bit. Pic30_tools is a port of the Gcc compiler. It is so nice to work with. A cut above the rest!
I do like assembler, again, the Pic30_tools assembler shines, but with memory sizes approaching 64K, ram 8K, C is the way to go for non trivial programs. Easier to manage.

 

[newelltech]

Why? I have a soft spot in my heart for assembly. A well written assembly code sing out like a beautiful poem.

I too have a soft spot in my heart for assembly. Probably not for the same reason as you. I've been programming since the the 4004 uC was introduced and grew up on assembly. A well-written assembly program is truly a thing of beauty, but it is also a big waste of time.

If you want to see well-written assembly, write a program in C and then look the the ASM file. You will see the most efficient and robust code possible. No programmer could duplicate it. Compiler designers make a big effort to make their compiler produce the fastest, smallest code. So don't buy into the myth that ASM is faster (runtime) than C. It's not. Unless the programmer is really, really good it will be slower, use more memory and have more bugs the its C counter-part.

And C++ ugly? Not to someone who knows how to use it. It's a beautiful thing.

And let's thank kender for clearing up a lot of other inaccuracies in some of the replies!

 

[sp]

C is the king of embedded languages (then assembly is the princess

i think tht assembly is the king's old grandmother (end soon)... it's not for human ...thinking of the complexities of the design...


but hey... tht's just my opinion...

"If someone working for you writes in assembly - fire him to keep your own job." Dr. Frank Angle

understand how powerful assembly can b...

regards,
sp