This was originally in response to a "NECRO POST": PLEASE HELP - Class Project: Backup Camera and Display on wheelchair. - Project Guidance - Arduino Forum
I am leaving this up in hopes the original poster finds a helpful solution. I also edited the now standalone post to have a more reasonable description of the project content (see video).
I know this is an old thread, but I came across it recently and thought we can surely do better. The current advice is okay, sure you can change to a different MCU, or change to a different architecture, or change to a different design spec.
Wouldn't it be cool if we could come up with a way to solve this weekend project without breaking the design constraints? Nifty.
I do not have the exact same setup as you, but quite similar. I also do not want to take the magic out of the class project, so here is some advice:
- Watch a <5 minute video on "how CRT monitor works"
- Review the example code for your display library:
- How to fill a rectangle with a given color?
- How to set a single pixel with a given color?
- Review the example code for your aducam:
- How to capture a BMP frame to the arducam FIFIO?
- How to read a given (X, Y) pixel from FIFO?
- How to interpret a given pixel value (RGB565)?
- Review 8 bit vs 16 bit integers
- Review bit shifting to combine two 8 bit values in to a single 16 bit value
- Putting it together: Scanning display
- Capture BMP frame in camera FIFO
- Read (x=0, y=0) from FIFO
- Write (x=0, y=0) on display to same value as camera pixel
- Increment until FIFO is empty, ignoring pixels outside the range of your display width and height
- Start again
- Future work:
- How to set more than one pixel in a single call?
- How many bytes and bits are required to store a single RGB565 pixel?
- How many pixels can you buffer at once on an arduino mega 2560?
- Why does buffering make refresh rate faster?
- Why is it desirable to have external ram (in this context)?
My findings are:
- The lowest the driver lets my sensor go is 160x120 pixels
- Capturing takes ~120ms (8 point moving average)
- My screen is a SPI 128x128 OLED
- I am reserving the top 15 pixels for debug text
- I am buffering 2 rows of display, or 128*2, or 256 pixels
- Did not dig too deep in to this, but seems to not matter much as long as you have a full line
- Basically same performance with 2 rows, 4, 8, 12
- Seems like power issues get more noticable at 12... does ram take more power, or does screen get weird with out of bounds draw calls (drawing a buffer with 12 rows, when only 4 rows left on screen)?
- Drawing a full frame takes ~240ms (8 point moving average)
- Best I got by end of night was ~2 fps (debug text, other overhead)
- Future work:
- Is 120ms the theoretical fastest rate at which a mega 2560 can pull data from the FIFO? Possibly. Intuition tells me the arducam takes ~120ms to write the FIFO, the mega takes ~120ms to read FIFO to RAM, the mega takes ~120ms to move the RAM to display
- Figure out why sometimes the feed gets misaligned and almost static like. In particular when a pair of bright yellow batman shorts are near the edge of frame... May be power, the arduino starts humming when this happens, sounds like voltage regulator
- Figure out why auto white balance made the feed super green unless there was something in near proximity to the sensor
- According to the OV2640 datasheet, the PCLK goes up to 36MHz, and the ADC runs at 20MHz. Is it possible to usefully drive the camera faster than the 16MHz mega?
Happy hacking!
