This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Interfacing Camera with TM4C129

Other Parts Discussed in Thread: CC3100

Hello Forum,

Besides forum and dedicated office activity, I do take some time to do DIY (out of my curiosity). My DIY uses a Camera to interface to DK-TM4C129. It is a pretty simple camera called uCAM-II which I interfaced over UART serial bus. The good thing about the camera is it allows for both RGB565 RAW and VGA JPEG.

KISS... I started off with RGB565 RAW and it took me some time to workaround few issues with the Camera (it has its oddities). At the end of it I was able to do a 1fps image with extrapolation of pixel from 160x120 to 320x240 panel on the DK-TM4C129. Added a feature like sd_card save to bmp format and negative images. I have a few more development activities planned

1. Increase the speed to the maximum of 3.6Mbps for a descent 9fps

2. Change format to JPEG and port over a JPEG decoder to TM4C129

3. Port the same over for TM4C123 LaunchPad

4. Use the CC3100 booster pack to send the data from TM4C123 to TM4C129 for viewing

5. Use the sd-card to store the image on "button" press.

(Try to take out a few hours to do the development, so response on this thread would be way too slow... Apologies in advance)... Anyone interested can of course post to this thread.

Regards

Amit

  • Blasphemy for sure - yet often review of other (similar) firm's efforts in your "area of interest" saves time/effort. Similar firm (one letter removed from yours) has a camera peripheral module embedded w/in their Cortex M4. (if not mistaken - it includes some form of JPEG acceptance - surely a crucial advantage)

    BMP files (as you know) "quickly eat every byte" of your storage medium. (that's why no commercial camera would save images in that (forsaken) format.)  And - that massive storage size drastically increases the transaction time - both in storing & then recalling your camera data - does it not?

    Friend has a nice "riding horse" - yet entering that horse in "Kentucky Derby" makes little sense.  There may be (superior) "races" for your DIY efforts - as well...

    Correct (i.e. best) Tool to Task warrants (further) consideration...

  • Hello cb1,

    Thanks for the feedback. And, Yes, TM4C does not have a native camera interface and BMP will eat a lot of RAM for temporary storage. However the intent is to go 1-5 on a TM4C to better understand imaging requirements keeping the vector of uC constant before changing the uC itself.

    Of course the other firm's effort is centered around an interface to handle the same, and I am yet to walk down that path,

    Regards
    Amit
  • Hi Amit,

    Understand and support your objective - you/I each know that each ARM vendor creates their own brew of, features/functions." 

    Suspect your brief review of the makeup & functionality of another's (already done) implementation will prove useful - save you time/effort.

    Yet another consideration - your 129 is not without functional advantages.  By steering your DIY project more into the 129's "sweet-spot" - don't you best match, "tool to task?" 

    Your proposed DIY attempt rings similar to "emplacing a hump upon a horse."   Horse may not (fully) appreciate his "upgrade" - and nearby camel may not find (that surgery) attractive...