Dive Computer Project Brick Wall

For other supported Arduino products from Adafruit: Shields, accessories, etc.

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
Vic320
 
Posts: 9
Joined: Thu Apr 25, 2013 12:59 pm

Dive Computer Project Brick Wall

Post by Vic320 »

Hi, I am working on an open source scuba diving computer project (http://www.diydivecomputer.com) and I have run into a major problem. I am using a 2.7" Sharp Memory display similar to Adafruit's product (http://www.adafruit.com/products/1393) only bigger - it's 400 x 240 pixels. After testing many displays, this is the perfect display for this project. I am using the Teensy 3.0 micro controller (http://www.adafruit.com/products/1044) which is an awesome little board. For some reason, I got it stuck in my head that this controller has 32K RAM but I realized yesterday that it actually only has 16K. The buffer for a 400 x 240 display, even at one bit depth is 12K or in other words it uses up most of the controller's RAM for the display buffer and leaving too little for the actual dive computer code. This would not be a big problem if you could individually address the pixels on the display - you can't, you need to send over the entire 400 pixel row at a time. So I am now searching for solutions and am looking for feedback.

1) Can someone recommend a similar display with individually addressable pixels? This would eliminate the need for a RAM buffer.

2) Can someone recommend a controller with a similar form factor (REALLY small) and processing power (32bit ARM) of the Teensy 3.0 but has at least 32K RAM and 128K Flash? Since this is an open source project I really liked that the Teensy uses the Arduino IDE which would make it much more accessible for people to work on so I would prefer a controller that also uses this IDE.

3) Can someone suggest a way of computing a single row's worth of pixels at a time? This would allow me to have only a 50 byte buffer, however the display will have several different UI elements on the screen at one time (see mockup image below) including a compass which will need to be updated frequently so coordinating all of those to get a row at a time would be very difficult I think.

4) I've considered using an external SPI connected RAM for the display buffer but that would add a lot of overhead. Each byte sent to the buffer would require four bytes sent over SPI (a command byte, two address bytes and one data byte) unless I can figure out a way to stream consecutive bytes but that's the same problem I have with the display. This is a problem when drawing to the buffer - when sending to the display, I can stream whole rows at a time which will be fairly low overhead. I am currently getting about 16 frames per second out of the display with the internal RAM buffer which is way more than I need so I have lots of processing power and bandwidth to play with but this is not a very elegant solution.
Attachments
image.jpg
image.jpg (57.57 KiB) Viewed 850 times

User avatar
adafruit_support_rick
 
Posts: 35092
Joined: Tue Mar 15, 2011 11:42 am

Re: Dive Computer Project Brick Wall

Post by adafruit_support_rick »

Offhand, I don't know of any other Teensy-sized ARM or similar platforms. Most things are going to more Uno-sized.

The row-buffer is not necessarily a difficult problem. The trick is that you need to make each display element an object, and you need an ordered list of these display objects along the z-axis. Pass your row buffer to the objects in back-to-front order, and have each object draw itself into the row buffer.

If it's too complicated to figure out how to draw a single row, an element can draw itself into a local temporary buffer, and then copy out the relevant row from the temp buffer to your row buffer.

Vic320
 
Posts: 9
Joined: Thu Apr 25, 2013 12:59 pm

Re: Dive Computer Project Brick Wall

Post by Vic320 »

Thanks for the reply. I had thought of that (making all UI elements into objects that returns lines) but the UI library I have already build relies heavily on Adafruit__GFX library which does not work that way. It assumes there is a buffer. I was hoping to continue to use it since the alternative would be to essentially rewrite it - a lot more work. I guess, I don't have much of a choice outside of making my own custom micro controller board that has more RAM which would be even more work. Thanks again...

User avatar
adafruit_support_rick
 
Posts: 35092
Joined: Tue Mar 15, 2011 11:42 am

Re: Dive Computer Project Brick Wall

Post by adafruit_support_rick »

You can still do it with objects. You've got 5 areas which are much smaller than the the entire screen. Let them draw to a temporary buffer. They can all share the same temp buffer. Looking at your picture, your largest area is around 200X120. So your temporary buffer would be 3K.

Vic320
 
Posts: 9
Joined: Thu Apr 25, 2013 12:59 pm

Re: Dive Computer Project Brick Wall

Post by Vic320 »

Rick, After thinking about your feedback and doing some experiments, I am now convinced that you are right. Doing each UI element as an object and having it calculate it's image one line at a time will work especially since most UI elements pull from bitmaps (fonts, images, ect.). I've done a some experiments and have gotten text on the screen with almost no memory use (one 50 byte buffer) and have even seen some improvement in performance to boot. Thanks again!

User avatar
adafruit_support_rick
 
Posts: 35092
Joined: Tue Mar 15, 2011 11:42 am

Re: Dive Computer Project Brick Wall

Post by adafruit_support_rick »

Cool! Good work.

One thing I've learned over (too) many years of working with limited space is that there's always some way to use less memory! :D

User avatar
adafruit_support_bill
 
Posts: 88097
Joined: Sat Feb 07, 2009 10:11 am

Re: Dive Computer Project Brick Wall

Post by adafruit_support_bill »

Offhand, I don't know of any other Teensy-sized ARM or similar platforms. Most things are going to more Uno-sized.
There is the mbed: http://www.adafruit.com/products/834

User avatar
solardude
 
Posts: 145
Joined: Fri Oct 18, 2013 12:47 am

Re: Dive Computer Project Brick Wall

Post by solardude »

Vic320 wrote:Hi, I am working on an open source scuba diving computer project (http://www.diydivecomputer.com) and I have run into a major problem. I am using a 2.7" Sharp Memory display similar to Adafruit's product (http://www.adafruit.com/products/1393) only bigger - it's 400 x 240 pixels. After testing many displays, this is the perfect display for this project. I am using the Teensy 3.0 micro controller (http://www.adafruit.com/products/1044) which is an awesome little board. For some reason, I got it stuck in my head that this controller has 32K RAM but I realized yesterday that it actually only has 16K. The buffer for a 400 x 240 display, even at one bit depth is 12K or in other words it uses up most of the controller's RAM for the display buffer and leaving too little for the actual dive computer code. This would not be a big problem if you could individually address the pixels on the display - you can't, you need to send over the entire 400 pixel row at a time. So I am now searching for solutions and am looking for feedback.

1) Can someone recommend a similar display with individually addressable pixels? This would eliminate the need for a RAM buffer.

2) Can someone recommend a controller with a similar form factor (REALLY small) and processing power (32bit ARM) of the Teensy 3.0 but has at least 32K RAM and 128K Flash? Since this is an open source project I really liked that the Teensy uses the Arduino IDE which would make it much more accessible for people to work on so I would prefer a controller that also uses this IDE.

3) Can someone suggest a way of computing a single row's worth of pixels at a time? This would allow me to have only a 50 byte buffer, however the display will have several different UI elements on the screen at one time (see mockup image below) including a compass which will need to be updated frequently so coordinating all of those to get a row at a time would be very difficult I think.

4) I've considered using an external SPI connected RAM for the display buffer but that would add a lot of overhead. Each byte sent to the buffer would require four bytes sent over SPI (a command byte, two address bytes and one data byte) unless I can figure out a way to stream consecutive bytes but that's the same problem I have with the display. This is a problem when drawing to the buffer - when sending to the display, I can stream whole rows at a time which will be fairly low overhead. I am currently getting about 16 frames per second out of the display with the internal RAM buffer which is way more than I need so I have lots of processing power and bandwidth to play with but this is not a very elegant solution.
I'm also trying to use the 2.7 Inch Sharp Memory LCD on the new Teensy 3.1 which has 64mb of SRAM. I just can't get the Adafruit Code Sharp Memory LCD library + GFX library working with the screen. Did you have to make any modifications to get the Sharp Memory LCD library working on the Teensy 3? If so could you share it with me please!

Your dive computer looks pretty cool BTW

Locked
Please be positive and constructive with your questions and comments.

Return to “Other Arduino products from Adafruit”