> 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

"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

>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

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.

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.

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
 

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

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