I want to make a program that will display color pictures (eventually video with sound too) on a small color lcd screen, I want to use an atmega 328 chip with an sd card to store the images. Any help that would point me in the right direction would be greatly appreciated.
\$\begingroup\$ \$\endgroup\$
2 
- 1\$\begingroup\$ You need to tell us what part you are having problems with. Do you have an LCD selected? Have you figured out how to use an SD card? This question is far too broad to be a good fit here. Questions should generally be about a specific electronics design problem. \$\endgroup\$Kellenjb– Kellenjb2012-02-12 20:22:25 +00:00Commented Feb 12, 2012 at 20:22
- \$\begingroup\$ I agree - these sorts of 'point me in the right direction' posts are usually absurdly vague and frequently impossible or unreasonable. Is there any way to muster the same level of general ire over these as there is over shopping questions? \$\endgroup\$AngryEE– AngryEE2012-02-13 19:23:43 +00:00Commented Feb 13, 2012 at 19:23
Add a comment |
2 Answers
\$\begingroup\$ \$\endgroup\$
4 Without more details it's impossible to give a specific answer, so here's some general stuff:
If you are wanting to display colour video (e.g. ~24 frames or more per second) then you will need a little more processing power than most 8-bit uCs can provide.
To give an example, say you have a small 240 x 320 colour TFT display with up to 18-bit colour. 18-bit colour gives 2^18 = 262144 possible colours.
You will need at least one screens worth of RAM for the display memory.
To display one full screen will take 240 x 320 x 18 = 1382400 bits (1.38Mbit or 172.8KByte) of RAM.
If you have a frame rate of say, 25 frames per second then you have a data throughput of 1.38Mbit x 25 = 34.56Mbit or 4.32MB per second.
Of course you don't have to use the full 18-bits of colour info, so you can get down to e.g. 240 x 320 x 8 = 614400 bits per frame with 256 colours (~15.3 Mbit for 25 fps)
For black and white you only need 1 bit per pixel, so then you get 240 x 320 x 1 = 76800 bits or 9.6KB per frame. Throughput at 25 fps would be 240 x 320 x 25 = 240KB per second.
So unless you only want static (or slowly changing) images, I would advise looking at a 32-bit uC like a PIC32, or an ARM of some sort. The display controller ICs that drive the displays (i.e the thing your uC talks to) usually have at least a frames worth of memory, sometimes more, so you can work with limited RAM if you shuffle things about a bit but generally the idea is you make your changes in uC RAM then update the whole screen at once at your specified frame rate.
Microchip have a few TFT dev boards and a Graphics stack to help with development, although I wouldn't go for anything less than the higher end PIC32s for driving them.
Depending on your resolution/colour/sound requirements, a more capable ARM might be better, they range from speeds of 40MHz up to GHz, so plenty of choice - the development options are generally not quite as budget friendly though.
One excellent chip is the STM32F4, check out the STM32F4 Discovery board, it has everything you need to start using it for £10 (yes, really) For this you get a 168MHz uC with 1MB Flash, 192KB of RAM and more peripherals than you can shake a stick at. Plus on the board there is a MEMS accelerometer and microphone, codec and headphone socket and STLINK2 programmer (can be used to program other ST chips) included.
On the down side, the development is not as friendly as e.g. Microchip or Atmel - they don't provide an IDE and the documentation leaves quite a lot to be desired.
Random video of STM32F1 playing QVGA
- \$\begingroup\$ I have some uncertainty about the color-depth and bit count - possibly there is a mistake in the number of colors count and I think it could be good to separate in RGB and BW images, just for clarity. Anyway +1 :) \$\endgroup\$clabacchio– clabacchio2012-02-13 12:27:59 +00:00Commented Feb 13, 2012 at 12:27
- \$\begingroup\$ @clabacchio - I mistakenly put 2^28, I fixed it to 2^18 which it should have been. Also added some calculations for BW image. \$\endgroup\$Oli Glaser– Oli Glaser2012-02-13 13:10:31 +00:00Commented Feb 13, 2012 at 13:10
- \$\begingroup\$ Seen :) But with 18-bit depth, you mean 18 gray levels or 6x3? I'm not so much into image compression and display driving, but maybe colormapping could be helpful? \$\endgroup\$clabacchio– clabacchio2012-02-13 13:13:32 +00:00Commented Feb 13, 2012 at 13:13
- \$\begingroup\$ With 18-bit depth, I mean RGB 6-6-6, for 262K colours. So yes 6x3. Other options would be stuff like RGB 5-6-5, RGB 4-4-4, etc. You can use a colour LUT to convert from different formats, the display driver ICs usually have one built in. \$\endgroup\$Oli Glaser– Oli Glaser2012-02-13 21:31:04 +00:00Commented Feb 13, 2012 at 21:31
\$\begingroup\$ \$\endgroup\$
2 Sounds to me like you should think hard about developing your application on an Arduino as a start, since it's built on the ATMega328.
There are a number of libraries and tutorials out there for driving Graphic LCDs. Similarly, the core Arduino libraries include SD card drivers. And once you're ready for it, there are Shields and drivers for generating audio as well.
Once you have prototyped with Arduino and shields, you can get the compiled artifacts (e.g. hex / elf files) from the Arduino build and use them in your own integrated design.
Under the covers Arduino software is just C++ built with avr-libc / avr-gcc.
- \$\begingroup\$ could you point me in the direction of how to do this without the arduino. I already have a programmer and chip and breadboard. \$\endgroup\$Cjueden– Cjueden2012-02-12 18:26:39 +00:00Commented Feb 12, 2012 at 18:26
- \$\begingroup\$ @Cjueden you can use the Arduino IDE to develop your software then target your ATMega328 as you normally would (e.g. with an ISP programmer) with the Intel HEX file generated by the avr-gcc toolchain... or alternatively you could just use the C++ source from the respective libraries for inclusion in your own project. \$\endgroup\$vicatcu– vicatcu2012-02-13 02:58:13 +00:00Commented Feb 13, 2012 at 2:58