Need recommend a MCU that is to creat jpg file.

[Boki]

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.

 

[Roger Hamlett]

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]

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]

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.

 

[martin griffith]

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,00.html


martin

 

[Tom Lucas]

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.

 

[Thad Smith]

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.

 

[linnix]

...

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.

 

[Nico Coesel]

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.

 

[Ulf Samuelsson]

The MCU will collect "RAW" data ( point[1] (x,y) = 10,10 ; point[2]

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