Visual Studio C++ to PIC

Geoff McCaughan <geoffm@spam.fqdn.com> wrote:

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

This must be the first time I ever saw someone claim TIFF to be a
simpler image format than something else...  If you want simple, think
BMP or PBM.  TIFF is about the most complex image file format on the
planet.  It's actually so complex and diverse that some would deny it
having a right to call itself one file format --- it's more like an
entire family history of formats.

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

Paul Keinanen <keinanen@sci.fi> wrote:
> 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.

If it were just for the DCT, sure.  But JPEG involves quite a bit of
Huffman encoding, too, and that'll take considerably more memory to
decode.  

And that's before you consider that you'll have to buffer the final
output somewhere.  From the OP's outline, it appeared he'll need *at
least* a frame buffer to hold the output image for the LCD to display,
on top of whatever the algorithm needs for temporary storage.

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

>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

I am a little unsure the reason why you need to run this on a small
processor like a PIC.  What is the reason you can't run it on a PC?

There are embedded processors such as ARM7 from several manufacturuers
that will support lots of memory and versions of C++ or versions of
Linux/GNU tools.  However the hardware may end up being  more
expensive that some of the low power PC platforms available, not to
mention the cost of development tools. If you are not deterred I
suggest to look at the following links:

http://www.iar.com/Products/?name=EWARM
http://www.ghs.com
http://www.uclinux.org

hope this helps.

regards,
Johnny

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

Either dsp chip  or 32 bit micro.
One of the smaller arm7 chips
philips lpc2000 range
http://www.semiconductors.philips.com/catalog/219/282/45988/45993/index.html#45993

or similar chips from sharp , oki, Analog, etc (Atmel soon as well)

The cmucam s (color tracking)
http://www-2.cs.cmu.edu/~cmucam/home.html
http://www-2.cs.cmu.edu/~cmucam2/
uses a scenix pic clone
http://www.scenix.com/processors/sx-family.htm

motorola 56fxxx series dsp ??

Analog devices or Ti dsp chip
may be able to get a dev board

Analog
http://www.analog.com/processors/processors/blackfin/crosscore/index.html
http://www.analog.com/processors/processors/blackfin/index.html

http://www.analog.com/processors/epProductPage/0,2542,BF533%252DHARDWARE,00.html
http://www.analog.com/Analog_Root/static/promotions/BlackfinGO/index.html
These were going for US$99 back in Jan.
May be able to get one cheaper than the standard price($US400 ??)
through their university program.(Worth a try)
Come with  c and c++ compiler which is program memory size limited.
can't remember what the size was ??

Other companies produce modules as well
http://www.fidalgo.net/~wa7gxd/dsp.html

I don't know about TI.

Could try asking in comp.dsp as well.

Alex Gibson

> And that's before you consider that you'll have to buffer the final
> output somewhere.  From the OP's outline, it appeared he'll need *at
> least* a frame buffer to hold the output image for the LCD to display,
> on top of whatever the algorithm needs for temporary storage.

To me it is quite unclear what the OP actually wants to do.  I found
no hint that he actually wants to display the picture on an LCD of any
kind.  He could just as well plan to implement optical triggers or
motion detection.  He might want to only process parts of the image,
maybe even just a single pixel, and never output any pixel data at all.

I'm convinced that unless he gives greater insight into what he's
planning to do, nobody can point him to an efficient solution.

Currently the only useful advice can be:  given that his software
already works on the VC++ platform, he should stick to it, and
declare his project finished.  There are many small PC boards out
there, that can fit windows software into an "embedded" container.
http://www.bluechiptechnology.co.uk/product_group.php?group_id=3

Marc

> And that's before you consider that you'll have to buffer the final
> output somewhere.  From the OP's outline, it appeared he'll need *at
> least* a frame buffer to hold the output image for the LCD to display,
> on top of whatever the algorithm needs for temporary storage.

To me it is quite unclear what the OP actually wants to do.  I found
no hint that he actually wants to display the picture on an LCD of any
kind.  He could just as well plan to implement optical triggers or
motion detection.  He might want to only process parts of the image,
maybe even just a single pixel, and never output any pixel data at all.

I'm convinced that unless he gives greater insight into what he's
planning to do, nobody can point him to an efficient solution.

Currently the only useful advice can be:  given that his software
already works on the VC++ platform, he should stick to it, and
declare his project finished.  There are many small PC boards out
there, that can fit windows software into an "embedded" container.
http://www.bluechiptechnology.co.uk/product_group.php?group_id=3

Marc