Jump to content
43oh

RWB

Members
  • Content Count

    13
  • Joined

  • Last visited

  1. So could a simple CMOS 555 timer chip be able to generate a square wave at .5Hz pulse to keep the Sharp Display refreshed? The Teensy 3.1 can not stay and deep sleep and provide the pulsed refresh, it has to come out of deep sleep every second which would bring the power consumption to about .250mA . But if I use a CMOS 555 timer chip to generate the Vcom pulse it only takes about 110-140 uA which is much better for a battery powered setup. Should something like this work just fine? I just plan to refresh the LCD screen data every 24 hours when in deep sleep stand by mode. Are t
  2. Yea your right. They suggested using the Low Power Timer on the Teensy 3.1 while the Micro is in Deep Sleep Mode to trigger the Vcom pin every second. So is it just a quick pulse to the VCOM pin or is it a more complicated signal? Does the screen do anything special when it receives a pulse on the VCOM line? I'm just trying to understand what exactly is happening. Also does the static image need to be changed or something if I plan on displaying the same basic info for 24 hours when in deep sleep? Or is a VCOM plus enough to keep pixels from supposedly sticking?
  3. About the VCOM and refreshing of these displays I have a question you might be able to help out with. I ended up using the 2.7 inch Sharp Displays with a Teensy 3.1 board because it had enough memory to run the screen + hold tons of sprite and bitmap data + it was alot easier for me to program using Arduino than Code Composer Studio. I'm wanting to keep the Sharp Memory LCD on and displaying the status info via a Static image that the Teensy 3.1 will generate every 24 hours while in deep sleep mode. I'm wondering what the easiest and most efficient way is to keep refreshing the
  4. Yes, it works! Thanks to Pabigot
  5. So how would I fix that? I'm clueless with my minimal knowledge base. I can't change the pixel dimensions or the screen will not display properly right? Is there a way to change the display buffer size so it works? There is enough FRAM to do this right? I can see how 96x96 divides evenly into 512, and the same goes for 128x128 pixels. I tried 400 x 256 since it divides into 512 by a even 200 but that gives me this error on building: error #10324-D: BOUND section ".TI.bound:DisplayBuffer" spans the boundary of an existing memory range FRAM <Linking> >> Com
  6. I figured it out. I had to use Code Composer Studio and load the MSP-EXP430FR5969 with Graphics Library from the MSP430ware database. Then I had to go to the HAL_MSP-EXP430FR5969_Sharp96x96.h file and change the pixel size of the display to 128x128 and then build the file and it worked. So the they are using Frame Buffer for in the example code in MSP430ware which should also allow me to use the 400x240 pixel Sharp Memory Display but when I try to use 400 horizontal x 240 vertical pixels and then built it I get over size errors like this: error #10324-D: BOUND section ".TI.b
  7. Hey everybody! I have the FR5969 Launchpad up running with Energia. I have a 128x128 pixel Sharp Memory LCD and a 400x240 pixel Sharp LCD that I'm trying to get running on the FR5969. I tried loading the Sharp Memory LCD Example code in Energia and changed the max pixel dimensions in the .h file from 96 x 96 to 128 x 128 but that causes a memory error when I try to compile. It says the ram is over by 24 bytes. So I'm assuming its trying to make room for the memory the LCD requires in SRAM which is too small by 24 bytes. If I change the max pixel size in .h file back to 96x9
  8. I received my FR5969 demo board with Sharp LCD yesterday! Its amazing how long the processor and display can run the clock app off just the capacitor. Its been showing time for 17 hours straight now. I loaded the MSP-EXP430FR5969 with Graphics Library from MSP430ware in Code Composer Studio. I then found the HAL_MSP-EXP430FR5969_Sharp96x96.h file and changed the Pixel x Pixel data to 128 x 128 pixels. Next I'll try the 400 x 240 pixels for the 2.7 inch screen. Looks like they are using a frame buffer in the demo code above. So the they are using Frame Buffer for in
  9. Thanks for the info. I have the 1.28 inch 128x128 pixel TFT & 2.7 Inch memory displays coming so I'll be needing to get both of them up and running soon. Sounds like the TI library is perfect as long as the 10kb file size doesn't take up memory needed to run my applications. It sounds like FrameBuffer is just bytes of memory that gets refreshed any time the screen changes. I learned that FRAM has a max speed of 8 MHz. I will be needing to generate or converter bitmaps I have already made to work on the Digole LCD displays so knowing they already have PC software to
  10. Thanks for the feedback. So based on your response it sounds like it should be pretty easy for somebody with the right skill to adapt the BQ27510 library for the Bq34z100. I'm willing to pay somebody for a working library for the Bq34z100, just let me know what its going to take if your up for the task. The Bq34z100 is really the only battery fuel gauge chip that will work for my needs so I'm kinda stuck using it.
  11. Hi everybody. I would like to use the MSP430FR5969 to read my battery status information from Texas Instruments Bq34Z100 fuel gauge that communicates via I2C. I know there is a Booster Pack for a different fuel gauge from TI that works with the Launch Pad and also communicates via I2C http://www.ti.com/tool/boostxl-battpack This has me wondering if it would be easy to use this existing library to read the data from the slightly different chip I'm evaluation now the Bq34z100 http://www.ti.com/lit/ds/symlink/bq34z100.pdf I asked the tech support guys on TI's forum if there w
  12. How does your code size compare with the ~10kb for TI's library? If I want to run the 2.7 inch screen with the MSP430FR5969 will I be forced to use the Frame Buffer option considering there is not enough SRAM on the board to store the 12,000 bytes required to display a full 2.7" sharp memory lcd screen? Also you said "As long as your running < 8MHz FRAM" You used the less than sign. Does that mean I have to run the FRAM at 8mhz or less to use it to frame buffer? Or is 8 Mhz the minimum speed? What would you say your Sharp Memory LCD library is lacking compared to TI's Sharp
  13. I have been playing around with these Sharp Memory LCD's also. I like how sharp the 128x128 pixel & 2.7 Inch TFT versions have the black pixel color instead of the mirror silver finish which I don't like. The ultra low power consumption is awesome. They require lots of SRAM so its taken me as a newbie to all this a long time to find some solutions that have enough memory to actually run the 128x128 pixel 1.28 inch screen and especially the 2.7 Inch 400x240 pixel screen that takes 12,000 bytes of memory. Looking at the ultra low power consumption of this screen + FRAM + the ne
×
×
  • Create New...