libjpeg + cortex m3

Hello Does anyone make cross compile libjpeg to cortex m3 core. I trying but have a question. arm-elf-gcc or arm-none-ebai-gcc haven't library libc.a. When I compile whit options export CC=arm-none-ebai-gcc I have comunicat that

" /Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':

readr.c:(.text+0x20): undefined reference to `_read'

"

and few similar like this. It's system's function, how add syscall.c to this project and compile.

Where I should search definition of syscalls function.

Mayby exist the other method to decompress jpeg in cortex m3.

Regards michwol

Reply to
michwolo
Loading thread data ...

"michwolo" skrev i meddelandet news:QcydncfiCdMPTH_VnZ2dnUVZ snipped-for-privacy@giganews.com...

/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o):

I compiled libjpeg for ARM and it resulted in a 1.2 MB file. Did not check if symbols were stripped.

Are you sure you have enough memory in Your Cortex-M3? Think you should check the size on ARM with stripped binaries.

It is going to be pretty slow anyway... Are you sure you should not use an ARM9 (or better AVR32 :-) which has much better capabilities for decompression

--
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
Reply to
Ulf Samuelsson

news:QcydncfiCdMPTH_VnZ2dnUVZ snipped-for-privacy@giganews.com...

/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o):

I don't know about libjpeg, but a good JPEG codec takes only a few KB of code. The problem is the RAM required for the image and temporary storage. It'll need an MCU with a lot of SRAM.

An ARM9 wouldn't be any faster, and neither would AVR32 be. For best results one would use an optimised JPEG codec with assembler for some of the core functions. However unless there is a lot of RAM to allow for high resolution images, performance is not really an issue.

Wilco

Reply to
Wilco Dijkstra

news:QcydncfiCdMPTH_VnZ2dnUVZ snipped-for-privacy@giganews.com...

but

libc.a.

comunicat

/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o):

to

Hello Guys again. What You propose I should to do. My intention is to display a few pictures. For this moment I send windows bmp to lcd 132 x 132. What is Your proposition. Stm32 is very cheap, hmmmm str9 is more expensive.

I want to test a powerfull of stm32, I want to give it some complicated calculations for examples decompress, but it may by impossible ?

Regards michwolo.

Reply to
michwolo

/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o):

Performance is not an issue. Flash size is a small issue. The Ram buffer (17K) is a big issue for many small uC. You need some external memory.

Reply to
linnix

"michwolo" skrev i meddelandet news:soydnYfsorJ6eX7VnZ2dnUVZ snipped-for-privacy@giganews.com...

/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.2.3/../../../../arm-none-eabi/lib/libc.a(lib_a-readr.o):

Yes, we all know that even a Core-2 Quad at 3.0 GHz would be slow, compared to the mighty Cortex-M3...

At 132 x 132 x 16 bits, your raw image would be 34 kB. You can store ~30 pictures/MByte. By connecting an AT45DB642 (8 MB), you will have 240 raw pictures.

On the other hand, and AT32UC3A has up to 64 kB SRAM and would have more than enough to store the complete picture internally. The new AT32UC3A3 has 128 kB of SRAM, if that is not enough.

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

Reply to
Ulf Samuelsson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.