• Announcements

    • bluehash

      Forum Upgrade   03/11/2017

      Hello Everyone, Thanks for being patient while the forums were being fixed and upgraded. Please see details and report issues in this thread. Thanks!

TDHofstetter

Members
  • Content count

    5
  • Joined

  • Last visited

About TDHofstetter

  • Rank
    Noob Class

Profile Information

  • Location
    Bradford, VT
  • Interests
    Boundless...
  1. Ah. Ok. I have one of your non-touch 2.2" displays (with ?SD & no onboard SRAM); it's nicely built & does the job very well. A little slow, but that's because it's serial (and we really can't afford parallel with most MSP430s, we just can't spare enough pins). If I could find a decent 2.2" resistive sensor overlay that I knew would fit my display, I'd add it to what I have & be done with it. BTW... good to meet you, Rob.
  2. I realize I'm a little late on the scene... whatever happened to this project? The 43oh says they're out of stock, and your Tindie store doesn't seem to list them. I'd like to have one, possibly several.
  3. Yep, definitely set to 16MHz (G2553); CCS recognizes the #define. EDIT: There's an improvement - I modified your clearScreen() a little, and got some better performance: void clearScreen(u_char blackWhite) { setArea(0, 0, getScreenWidth() - 1, getScreenHeight() - 1); setBackgroundColor(blackWhite ? 0x0000 : 0xFFFF); u_int w = getScreenWidth(); u_int h = getScreenHeight(); u_int Y = w; while (h != 0) { Y = w; while (Y != 0) { writeData(bgColorHighByte); writeData(bgColorLowByte); Y--; } h--; } } Note that I'm not calling getScreenWidth() on each h; instead, I'm using a single stored value. EDIT II: It's a very SLIGHT improvement - all it's doing is eliminating one call (which eliminates some stack activity), but it's an improvement. EDIT III: Got it. Your code is pretty tight, Rob... so I changed things a little by using only the upper 180 (of 240) pixel rows, wiping it with fillRect instead of clearScreen. Now I'm barely within my 150fpm (2.5fps) frame rate design limit. Now it's time to do the COOL stuff. 8) I can use the lower 60 rows for other stuff, like a once-per-frame textual display.
  4. Unfortunately, the shape data is random on every screen refresh, so I really need to wipe ahead of myself to eliminate any artifacts from the previous frame. Now... would it help to install the LaunchPad's 32KHz crystal? I've read (but can't verify) that doing so would bump up the MSP430's clock rate, which might get me into the ballpark I'm shooting for. Have you tried running one of these displays on a crystal-installed LaunchPad? If installing the crystal WOULD bump up the LaunchPad's execution rate, I'm all for it. After all, clearing (or washing with some color) the screen does involve pushing 153,600 bytes across the serial bus to the display - a pretty heavy workload. Thinking... Lessee if I can find speed up the library code, optimizing strictly for this application. Oh, and... lest I forget or neglect... thanks, Rob! These little displays are VERY NEAT. 8)
  5. Any chance of finding a faster display? I've optimized everything I can in code, and due to the blocking nature of the serial calls into the display's internal controller, the fastest I can repaint the display is twice per second. That's with a simple repaint, a clearScreen(1) followed by a single pixel paint per X (X is on the 320-pixel axis, Y is on the 240-pixel axis). -- Tim --