Visual Studio C++ to PIC

Ryan <scheller@student.umass.edu> wrote:

> 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.  

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.

> could probably port my C++ to C, and then use a specific compiler
> for whatever MCU I go with.  Would that be ok?

With the right MCU: sure.  Except porting may a waste of effort.
Using existing free C code would make better use of your time.
 
> > For starters: does it absolutely have to be JPEG, of all possible
> > file formats?

> 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?

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.

On 09 Jun 2004 19:19:33 +0100, John Devereux
<jdREMOVE@THISdevereux.me.uk> wrote:

>Chris Hills <chris@phaedsys.org> writes:
>
>> In article <1edcb178.0406080550.14791206@posting.google.com>, Ryan
>> <scheller@student.umass.edu> writes
>> >Ok, I'm starting to understand, I think. 
>> >Good news it, my C++ program does not use any windows libs.
>> 
>> This is irrelevant. there is no C+ compiler for PIC, AVR etc (there was
>> one for there 8051 but it was little use)
>
>Actually I think that gcc-avr will do C++. Not that I would suggest
>actually using an AVR for this!

#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

Ryan <scheller@student.umass.edu> wrote:

> 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.  

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.

> could probably port my C++ to C, and then use a specific compiler
> for whatever MCU I go with.  Would that be ok?

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.
 
> > For starters: does it absolutely have to be JPEG, of all possible
> > file formats?

> 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?

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.

"Ryan" <scheller@student.umass.edu> wrote in message
news:1edcb178.0406071314.eb9d707@posting.google.com...
> 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

First thing to do is check out www.piclist.com

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 www.lpc2100.com

Compilers for pic

C
There are a few

htsoft
http://www.htsoft.com/

css
http://www.ccsinfo.com/

Fed
http://www.fored.co.uk/

c2c / picant / source boost ide
http://www.picant.com/c2c/c.html

 demo version of c compiler
HT software compiler
http://www.htsoft.com/
http://www.htsoft.com/downloads/download.php?product=PIC%20C
uses mplab as the ide.

free
jal - just another language
bit like pascal
http://jal.sourceforge.net/
lots of other links there
http://x.webring.com/hub?sid=&ring=jal&id=&hub

also check out the yahoo group,  very active
http://groups.yahoo.com/group/jallist/


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

http://www.beyondlogic.org/pic/ringtones.htm
uses compiler and phone ring tone file nokia rtttl
to play phone ring tones on the 16f877

http://www.microchipc.com/
lots of code exampkles and info on the
hightec c compiler for 16f87x

Alex

Rich Webb <bbew.ar@mapson.nozirev.ten> writes:

> On 09 Jun 2004 19:19:33 +0100, John Devereux
> <jdREMOVE@THISdevereux.me.uk> wrote:
> 
> >Chris Hills <chris@phaedsys.org> writes:
> >
> >> In article <1edcb178.0406080550.14791206@posting.google.com>, Ryan
> >> <scheller@student.umass.edu> writes
> >> >Ok, I'm starting to understand, I think. 
> >> >Good news it, my C++ program does not use any windows libs.
> >> 
> >> This is irrelevant. there is no C+ compiler for PIC, AVR etc (there was
> >> one for there 8051 but it was little use)
> >
> >Actually I think that gcc-avr will do C++. Not that I would suggest
> >actually using an AVR for this!
> 
> #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.

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

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

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

On 9 Jun 2004 09:58:59 -0700, scheller@student.umass.edu (Ryan) wrote:

>> 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.
>
>Ok, good to know.
> 
>> You'll have to clarify what you're trying to do, before it becomes
>> viable to discuss choice of platforms or prorgramming languages.
>
>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?
> 
>> For starters: does it absolutely have to be JPEG, of all possible
>> file formats?
>
>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?

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

Ryan <scheller@student.umass.edu> wrote:
> 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.

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.

On Fri, 11 Jun 2004 01:38:02 GMT, Geoff McCaughan
<geoffm@spam.fqdn.com> wrote:

>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].

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