Need recommend a MCU that is to creat jpg file.

Dear All,

Looking for a suitable MCU.

For create jpg file.

The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
(x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
point. ( and I want to draw it as black in screen)

So, the MCU will collect the information. ( of course, need some basic
protocol control, but I think it doesn't cost too many MIPS )

So, I think the key point will be in jpeg convert from those raw data,
right ?

I will use mono color first ( and upgrade to multi color then ), so I
only have to handle single color jpeg ( or you suggest to use GIF ? png
? ... ).

Could you please advice which MCU is suitable for this job?

Best regards,
Boki.

"Boki" <bokiteam@ms21.hinet.net> wrote in message 
news:1159869225.424238.197700@m73g2000cwd.googlegroups.com...
> Dear All,
>
> Looking for a suitable MCU.
>
> For create jpg file.
>
> The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
> (x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
> point. ( and I want to draw it as black in screen)
>
> So, the MCU will collect the information. ( of course, need some basic
> protocol control, but I think it doesn't cost too many MIPS )
>
> So, I think the key point will be in jpeg convert from those raw data,
> right ?
>
> I will use mono color first ( and upgrade to multi color then ), so I
> only have to handle single color jpeg ( or you suggest to use GIF ? 
> png
> ? ... ).
>
> Could you please advice which MCU is suitable for this job?
>
> Best regards,
> Boki.

1) How fast do you need to do it?
2) How much raw data is there?
3) If you are using an LCD controller then why not just write the points 
to the screen directly and not bother messing around with compressed 
images? 

"Boki" <bokiteam@ms21.hinet.net> wrote in message 
news:1159869225.424238.197700@m73g2000cwd.googlegroups.com...
> Dear All,
>
> Looking for a suitable MCU.
>
> For create jpg file.
>
> The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
> (x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
> point. ( and I want to draw it as black in screen)
>
> So, the MCU will collect the information. ( of course, need some basic
> protocol control, but I think it doesn't cost too many MIPS )
>
> So, I think the key point will be in jpeg convert from those raw data,
> right ?
>
> I will use mono color first ( and upgrade to multi color then ), so I
> only have to handle single color jpeg ( or you suggest to use GIF ? png
> ? ... ).
>
> Could you please advice which MCU is suitable for this job?
Not without a lot more data.
Lkely image size is the 'obvious' extra bit of data?. Second, is how fast 
the conversion needs to be?. JPEG, in common with most formats of it's 
'type', is harder to compress, than to decompress. You talk about 
collecting the data 'from a UART', but unless you are using a seriously 
fast data rate, if the images are any sort of size, this will take a _lot_ 
of time. For example, a relatively low resolution 'webcam' type image, 
will take 53 seconds, to send over a serial link at 57600bps. If you 
intend to handle colour latter, then you need to include this in your 
calculations at the start. What colour model is the source data in?. If 
(for instance), it is going to be RGB, then this will need to be converted 
to YCbCr, before the start of jpeg encoding.
Seriously, if you need good speed, then you should probably be looking at 
an off the shelf hardware encoder chip, or doing the core work in a gate 
array, rather than using a simple processor. This will involve a lot of 
development work, but will give fast results. The 'cheapest' solution in 
terms of software development, would be to use a simple 'embedded PC', and 
run one of the minature Linux kernels.

Best Wishes 

Tom Lucas wrote:
> "Boki" <bokiteam@ms21.hinet.net> wrote in message
> news:1159869225.424238.197700@m73g2000cwd.googlegroups.com...
> > Dear All,
> >
> > Looking for a suitable MCU.
> >
> > For create jpg file.
> >
> > The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
> > (x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
> > point. ( and I want to draw it as black in screen)
> >
> > So, the MCU will collect the information. ( of course, need some basic
> > protocol control, but I think it doesn't cost too many MIPS )
> >
> > So, I think the key point will be in jpeg convert from those raw data,
> > right ?
> >
> > I will use mono color first ( and upgrade to multi color then ), so I
> > only have to handle single color jpeg ( or you suggest to use GIF ?
> > png
> > ? ... ).
> >
> > Could you please advice which MCU is suitable for this job?
> >
> > Best regards,
> > Boki.
>
> 1) How fast do you need to do it?
> 2) How much raw data is there?
> 3) If you are using an LCD controller then why not just write the points
> to the screen directly and not bother messing around with compressed
> images?

1) I not sure, of course, as fast as good, due to it is not for real
time, how about <1s, will to high level, or no problem by using a
general MCU ?

2) Depends user drawing, I guess the common case will be 800x600.

3) no, no LCD, MCU to come out jpg, device ( PC/ Handset /..) to
recevie jpg.

so, this MCU ( or MCU + MEMORY ( should flash ? or EEPROM ? ) can save
many pages of jpg, and then send to device.

Best regards,
Boki.

On 3 Oct 2006 02:53:45 -0700, in sci.electronics.design "Boki"
<bokiteam@ms21.hinet.net> wrote:

>Dear All,
>
>Looking for a suitable MCU.
>
>For create jpg file.
>
>The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
>(x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
>point. ( and I want to draw it as black in screen)
>
>So, the MCU will collect the information. ( of course, need some basic
>protocol control, but I think it doesn't cost too many MIPS )
>
>So, I think the key point will be in jpeg convert from those raw data,
>right ?
>
>I will use mono color first ( and upgrade to multi color then ), so I
>only have to handle single color jpeg ( or you suggest to use GIF ? png
>? ... ).
>
>Could you please advice which MCU is suitable for this job?
>
>Best regards,
>Boki.

http://www.analog.com/en/prod/0,,765_810_ADV202%2C00.html


martin

"Boki" <bokiteam@ms21.hinet.net> wrote in message 
news:1159877805.964839.240370@b28g2000cwb.googlegroups.com...
>
> Tom Lucas wrote:
>> "Boki" <bokiteam@ms21.hinet.net> wrote in message
>> news:1159869225.424238.197700@m73g2000cwd.googlegroups.com...
>> > Dear All,
>> >
>> > Looking for a suitable MCU.
>> >
>> > For create jpg file.
>> >
>> > The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
>> > (x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
>> > point. ( and I want to draw it as black in screen)
>> >
>> > So, the MCU will collect the information. ( of course, need some 
>> > basic
>> > protocol control, but I think it doesn't cost too many MIPS )
>> >
>> > So, I think the key point will be in jpeg convert from those raw 
>> > data,
>> > right ?
>> >
>> > I will use mono color first ( and upgrade to multi color then ), so 
>> > I
>> > only have to handle single color jpeg ( or you suggest to use GIF ?
>> > png
>> > ? ... ).
>> >
>> > Could you please advice which MCU is suitable for this job?
>> >
>> > Best regards,
>> > Boki.
>>
>> 1) How fast do you need to do it?
>> 2) How much raw data is there?
>> 3) If you are using an LCD controller then why not just write the 
>> points
>> to the screen directly and not bother messing around with compressed
>> images?
>
> 1) I not sure, of course, as fast as good, due to it is not for real
> time, how about <1s, will to high level, or no problem by using a
> general MCU ?
>
> 2) Depends user drawing, I guess the common case will be 800x600.
>
> 3) no, no LCD, MCU to come out jpg, device ( PC/ Handset /..) to
> recevie jpg.
>
> so, this MCU ( or MCU + MEMORY ( should flash ? or EEPROM ? ) can save
> many pages of jpg, and then send to device.
>
> Best regards,
> Boki.

I'd be thinking about an ARM with a good bit of RAM for what you are 
trying to do or a dedicated codec like the one Martin suggests. If you 
need non-volatile storage I'd consider battery backed ram more than 
flash because you'll wear flash out quite quickly by decompressing to it 
for every picture. 

Boki wrote:

> The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
> (x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
> point. ( and I want to draw it as black in screen)
> 
> So, the MCU will collect the information. ( of course, need some basic
> protocol control, but I think it doesn't cost too many MIPS )
> 
> So, I think the key point will be in jpeg convert from those raw data,
> right ?

If your images are a collection of single points or line drawings, jpeg 
is a poor choice.  GIF, PNG, or one of the TIFF sub formats should work 
much better.  Jpeg is great for photos with generally many shades of 
color, but poor for line art.  The other formats mentioned are good at 
compressed storage when there are only a few colors with sharp 
demarcations.  Unfortunately, many people misuse jpegs, especially in 
PDF screen dumps.

-- 
Thad

> ...
> > > The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
> > > (x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
> > > point. ( and I want to draw it as black in screen)
> ...
> 2) Depends user drawing, I guess the common case will be 800x600.

That's 60K per page (1 bit mono), which rule out the internal memory of
all 8051/PIC/AVR.  So, you need to look into external memory with fast
enough interface.

>
> 3) no, no LCD, MCU to come out jpg, device ( PC/ Handset /..) to
> recevie jpg.

With what?  RS232 or USB?

>
> so, this MCU ( or MCU + MEMORY ( should flash ? or EEPROM ? ) can save
> many pages of jpg, and then send to device.

Do you have to save through power cycle?  If not, SDRAM.

> 
> Best regards,
> Boki.

"Boki" <bokiteam@ms21.hinet.net> wrote:

>Dear All,
>
>Looking for a suitable MCU.
>
>For create jpg file.

First look for a jpeg compression algorithm and find out if you can
compile it for a certain MCU. I'd start looking at an MCU which can
address more than 64KB.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

>> > The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]
>> > (x,y) = 20,20 ........ ) from UART. Each pair of data means a (x,y)
>> > point. ( and I want to draw it as black in screen)
>> >
>> > So, the MCU will collect the information. ( of course, need some basic
>> > protocol control, but I think it doesn't cost too many MIPS )
>> >
>> > So, I think the key point will be in jpeg convert from those raw data,
>> > right ?
>> >
>> > I will use mono color first ( and upgrade to multi color then ), so I
>> > only have to handle single color jpeg ( or you suggest to use GIF ?
>> > png
>> > ? ... ).
>> >
>> > Could you please advice which MCU is suitable for this job?
>> >
>> > Best regards,
>> > Boki.
>>
>> 1) How fast do you need to do it?
>> 2) How much raw data is there?
>> 3) If you are using an LCD controller then why not just write the points
>> to the screen directly and not bother messing around with compressed
>> images?
>
> 1) I not sure, of course, as fast as good, due to it is not for real
> time, how about <1s, will to high level, or no problem by using a
> general MCU ?
>
> 2) Depends user drawing, I guess the common case will be 800x600.
>
> 3) no, no LCD, MCU to come out jpg, device ( PC/ Handset /..) to
> recevie jpg.
>
> so, this MCU ( or MCU + MEMORY ( should flash ? or EEPROM ? ) can save
> many pages of jpg, and then send to device.
>
> Best regards,
> Boki.
>

An ARM7 will not JPEG compress an 800 x 600 picture in 1 second.
IIRC someone tried running an ARM7 at 10 MIPS and it took ~40 seconds
to compress a 640 x 480 picture.

(40,000,000 us)/ 640 /480 => 130 uS / pixel at 10 MIPS or 1,3 ms/pixel at 1
MIPS.
At 1 MIPS you would need 1,3 ms * 800 * 600 = 624 seconds.
So you need 624 MIPS to do it in 1 second.

Maybe you can find a (significantly) better algorithm, but do not
underestimate
the need for performance.

A DSP is what you are looking for...

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB