Visual Studio C++ to PIC

Hi, I'm attempting to compile my C++ application for a PIC microcontroller. I've been told that this can be done, though I'm honestly not sure how to go about doing it. I'd assume I either need a special compiler or some sort of cross-compiler for the specific PIC architecture. However, I have a feeling that my problems will increase even once I get it to compile and run on the microcontroller. For example, the application currents reads in a file from the local disk...what will need to be done to read that same data from some sort of flash memory? If you have any suggestions, hints, tips, books, etc that could point me in the right direction I'd really appreciate it. Thanks in advance for your help,

--Ryan

Feel free to email me as well. ryanscheller(at)comcast.net

Reply to
Ryan
Loading thread data ...

That definitely won't work. A usual approach is to have the VC++ IDE, use the syntax sensitive editor and have a PIC C Compiler do the code.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

Whoever told you that has either been pulling off a cruel joke on you, or he's been wilfully obscure in talking to you, or he has no idea what he's talking about. Whatever it was, he deserves some serious retaliation --- so start planning a nasty one right away.

While there may be some combination of stunted meanings of "C++ application", "compile for a PIC ", and the purported role of MSVC++ in all of it, where the above may actually be possible, stated as it is it's simply utter BS.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Simply No

You can get a C Compiler for a PIC. (i hear CSS is recommended) a PIC is 8 bits, a PC 32bits. A PIC (or 8051,or AVR) does not have the horse power to to do big things fast. There is no files system you can store stuff in flash as some type of array or data structure. If you wrote your program in straight ANSI C you maybe be able to port it to a PIC. If you made extensive use of the windows libs, maybe an embedded WinCE board?

Reply to
Neil Kurzman

Ok, I'm starting to understand, I think. Good news it, my C++ program does not use any windows libs. I understand that I need a specific compiler for the microcontroller architecture. Sounds like most of them are for C and not C++, is this true? My application reads in an image file (jpeg) from the file system (cwd), and does some "stuff" to it. I'm still very foggy as to what type of microcontroller and memory would facilitate this. Any suggestions? I don't have to use a PIC, that's just the only one I'm familiar with right now. If there are some chips out there with some type of memory that would make this easy on me, please point me in that direction. Thanks so much for your help!

--Ryan

ryanscheller(at)comcast.net

Reply to
Ryan

You almost certainly don't want to do anything like that on a PIC. Or anything smaller than a rather powerful 16-bit MCU, for that matter.

You'll have to clarify what you're trying to do, before it becomes viable to discuss choice of platforms or prorgramming languages.

For starters: does it absolutely have to be JPEG, of all possible file formats?

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Ok, good to know.

Basically, I want to have a digital camera output the image it creates to some sort of memory that I can access it from the MCU. Then my application would read the image, and essientially read through the file and return rgb values for certain locations. I've got C++ code I wrote that reads a jpeg, returns rgb values, etc. I could probably port my C++ to C, and then use a specific compiler for whatever MCU I go with. Would that be ok?

I suppose it doesn't absolutely have to be, however I'm thinking that most digital cameras write in jpeg. Does the format of the matter?

Reply to
Ryan

In article , Ryan writes

This is irrelevant. there is no C+ compiler for PIC, AVR etc (there was one for there 8051 but it was little use)

I suggest you do a little more learning before you start to write programs. A compiler is a translator from a High level language to machine code. Different processors have different machine code.

There are no C++ compilers for 8 bit processors. There are some EC++ compilers for 16, 32 but processors.

No it does not and nor will it ever given your comments earlier. Sorry. You have much to learn. Embedded development is 50% software, 50% hardware and 50% systems.

Start with some simple programs to learn about the system and programming. The program you have suggested is not trivial especially for some one who needs to learn the very basic stuff.

It can't be a PIC. It does not have the power. It could be an 8051 but you don't have the experience of embedded programming yet. I know of a couple of commercial cameras that use a 51! (not my choice for it!)

However something 16 bit would be better

You need to do a 101 embedded course first. You can't dive straight in at the level you are trying to. Start small and work you way up.

This may be hard to take when you are full of enthusiasm but you need a learning curve to climb not a vertical cliff to run into.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

Actually I think that gcc-avr will do C++. Not that I would suggest actually using an AVR for this!

--

John Devereux
Reply to
John Devereux

I think that you will be struggling to shoehorn this application into a single-chip solution!. Your best bet would probably be an evaluation board / reference design for a 32 bit CPU, that comes with plenty of external RAM. Perhaps an ARM based system so you could use the free gcc c++ compiler. You could then copy the part of the reference design that you use, if you ever get that far... However this is non-trivial for your apparent hardware skill level. On the bright side, by the time you learn how to do it you will be able to get it as a single chip, so you won't have to :)

--

John Devereux
Reply to
John Devereux

That "some sort of memory" will have to be a flash memory card. Let's keep it simple and say a CF card. But to your micro, that won't be "memory", it'll be mass storage (like a harddisk in a PC).

Hm... sounds like yet another "magic digital picture frame" project, to me. Now there's nothing wrong with that, it's a worthy project. Just not a particularly revolutionary idea.

With the right MCU: sure. Except porting may a waste of effort. Using existing free C code would make better use of your time.

If it's JPEG, it does. Of all the commonly used image file formats, JPEG is the one that blows the most CPU cycles before you get to see

*anything*, by a comfortable margin. And the fact that camera images these days tend to be so friggin' large doesn't exactly help with that, either.

To get a feeling for what you're up against, try to find an old 286 or

386 PC, and try to run a JPEG viewing program on it.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

#Disclaimer: I haven't actually tried this but when has that ever stopped a usenet posting?

I usually work with the smaller AVRs but the ATmega128 plus some off-chip SRAM *should* be OK for the (probable) C++ overhead. Probably be decently fast, too.

OTOH, mixed C and assembly certainly seems to be more natural on the

8-bitters.
--
Rich Webb   Norfolk, VA
Reply to
Rich Webb

That "some sort of memory" will have to be some kind of flash memory card. Let's keep it simple and say a CompactFlash. But to your micro, that won't be "memory" in the conventional sense, it'll be mass storage (like a harddisk in a PC).

Hm... sounds like yet another "magic digital picture frame" project, to me. Now there's nothing wrong with that, it's a worthy project. Just not a particularly revolutionary idea.

With the right MCU: sure. Except porting may be a waste of effort. Using existing free C code would make better use of your time.

If it's JPEG, it does. Of all the commonly used image file formats, JPEG is the one that blows the most CPU cycles before you get to see

*anything*, by a comfortable margin. And the fact that camera images these days tend to be so friggin' large doesn't exactly help with that, either.

To get a feeling for what you're up against, try to find an old 286 or

386 PC, and try to run a JPEG viewing program on it.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

First thing to do is check out

formatting link

You may be able to do what you want with one of the larger 18fxxxx pics or the new dspics. Still wouldn't be as fast as one of the smaller arm chips.

philips lpc2000 range follow the links from

formatting link

Compilers for pic

C There are a few

htsoft

formatting link

css

formatting link

Fed

formatting link

c2c / picant / source boost ide

formatting link

demo version of c compiler HT software compiler

formatting link
formatting link
uses mplab as the ide.

free jal - just another language bit like pascal

formatting link
lots of other links there
formatting link

also check out the yahoo group, very active

formatting link

A good book is Programming and Customising Robot Controllers by Myke Predko uses a 16f627 and c but most programs work fine on a 16f877 as does the latest version of the demo compiler link above

formatting link
uses compiler and phone ring tone file nokia rtttl to play phone ring tones on the 16f877

formatting link
lots of code exampkles and info on the hightec c compiler for 16f87x

Alex

Reply to
Alex Gibson

Sure, I agree. By "this" I meant the AVR would be a bit limited for the OP's application. I expect it could run *some* C++ programs OK, just not ones for manipulating JPEGS written for a PC!

--

John Devereux
Reply to
John Devereux

Let me first thank everyone for some really great feedback. I really do appreciate it. With that said, it sounds like I have under estimated the amount of effort/skill/experience required to implement the functionality I spoke of in an embedded system. My past experience with any type of mcu is limited to PIC's and its interaction with fpga's and eprom's. I do have a great deal of experience with pc/unix/linux based programming, but never trying to (if possible) "port" those programs to an mcu implementation.

Ok quick summary: So, it is clear that C++ is not going to get me any closer to a mcu implementation. Sounds like C is the way to go, and whatever mcu I decide to go with should have a compiler for it.

I agree with the one comment that it would most likely be the path of least resistant to use a camera and mcu that can both use a type of flash for the memory.

I would also agree that the jpeg format has a great deal of overhead associated with it, simply due to the compression algorithm. Which, of course, is why it is desirable for such applications as digital cameras to save CF storage space. However, if possible, I'm hoping to over come this bottleneck with a beefy mcu.

Oh, and in my past posts when I referred to "my application", I was speaking of the C++ desktop level implementation I have already completed that performs the functionality I described. This is complete, reads jpeg files, performs some operations, etc. I'm not exactly sure what the "magic digital picture frame" project is, but this basically to sample colors and patterns in the image and then draw some conclusions based on that information.

Moving forward: I concede that I have lots of learning to do in this area, and you all have already begun to school me (thanks). I was hoping that by describing what I'm trying to do, some folks might suggest a certain MCU that might make things less painful for me. For example, if such a mcu platform exists that has a nice simple, almost abstracted interface to some compact flash...that would be great! Of course the interface is a standard, often times in console level programming these things are abstracted for the programmer. With that said, please correct my above if I've stated anything incorrectly, and if you have more suggestions, ideas, etc. please shoot them my way. Especially if you can recommend a particular mcu for this application.

Thanks again for your time.

--Ryan

Reply to
Ryan

Let me first thank everyone for some really great feedback. I really do appreciate it. With that said, it sounds like I have under estimated the amount of effort/skill/experience required to implement the functionality I spoke of in an embedded system. My past experience with any type of mcu is limited to PIC's and its interaction with fpga's and eprom's. I do have a great deal of experience with pc/unix/linux based programming, but never trying to (if possible) "port" those programs to an mcu implementation.

Ok quick summary: So, it is clear that C++ is not going to get me any closer to a mcu implementation. Sounds like C is the way to go, and whatever mcu I decide to go with should have a compiler for it.

I agree with the one comment that it would most likely be the path of least resistant to use a camera and mcu that can both use a type of flash for the memory.

I would also agree that the jpeg format has a great deal of overhead associated with it, simply due to the compression algorithm. Which, of course, is why it is desirable for such applications as digital cameras to save CF storage space. However, if possible, I'm hoping to over come this bottleneck with a beefy mcu.

Oh, and in my past posts when I referred to "my application", I was speaking of the C++ desktop level implementation I have already completed that performs the functionality I described. This is complete, reads jpeg files, performs some operations, etc. I'm not exactly sure what the "magic digital picture frame" project is, but this basically to sample colors and patterns in the image and then draw some conclusions based on that information.

Moving forward: I concede that I have lots of learning to do in this area, and you all have already begun to school me (thanks). I was hoping that by describing what I'm trying to do, some folks might suggest a certain MCU that might make things less painful for me. For example, if such a mcu platform exists that has a nice simple, almost abstracted interface to some compact flash...that would be great! Of course the interface is a standard, often times in console level programming these things are abstracted for the programmer. With that said, please correct my above if I've stated anything incorrectly, and if you have more suggestions, ideas, etc. please shoot them my way. Especially if you can recommend a particular mcu for this application.

Thanks again for your time.

--Ryan

Reply to
Ryan

Camera modules that provide JPEG images over a serial link are coming available. The image is capture by the camera module, converted to jpeg and stored in internal memory. Commands can then be sent over the serial link to retrieve the data. With the modules on can get away with fairly small MCUs that control the camera module. If you convert your code to C, make sure that you use absolutely as little ram as possible, then it should be possible to compile you code for small MCUs like the 8051, PIC, AVR etc.

Regards Anton Erasmus

Reply to
Anton Erasmus

Your big problem if you use something small like a PIC will be that you won't have anything like enough memory to hold a single image in RAM.

If you want to process the image without holding all of it in memory at once, see if you can avoid jpeg and use a simpler image format such as TIFF [preferably uncompressed].

Or you might consider something like the webcam that I think was in one of the Circuit Cellar competitions, they didn't have enough memory or CPU power to process the image, so their micro loaded a java applet onto the viewing web browser, sent it the raw data and got the viewers PC to do the work.

--
Burn the land and boil the sea,
 You can't take the sky from me.
Reply to
Geoff McCaughan

While MPEG needs memory for at least 1-2 uncompressed pictures to handle the I, P and B pictures, but isn't JPEG just the same as the I-picture in MPEG, with 8x8 or 16x16 DCT blocks ?

Thus running the iDCT for a single block, doing some colour selection and running the DCT on the result should be doable with less than 1 KiB.

Paul

Reply to
Paul Keinanen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.