Newhaven Displays OLED 4x20

avsa242avsa242 Posts: 116
edited January 8 in Propeller 1 Vote Up0Vote Down
Hi Parallaxians!

I've written a SPIN object to drive these displays (based on the US2066 controller). They can be interfaced with using I2C (which I've written this for), SPI, as well as a couple different flavors of parallel interface.
They're super thin (pic attached next to the FLiP I drove it with), have a great response (they don't have that motion blur/ghosting look that character LCD panels do) and great contrast.

In case any one has one of these and needs/wants to drive it with a Prop, or has looked at them online, I've put the code (MIT) at https://github.com/avsa242/nhd-0420

It uses one extra cog (for the PASM I2C object - thanks to JonnyMac), although I plan to try a version using a SPIN I2C object so that no extra cogs are used. EDIT: Done - this is up in the repository. Only catch with the SPIN version is that the I2C clock rate can't be specified.
It also uses a few objects from the spin-standard-library, also at github (though I've uploaded a zip containing the project as well, so it includes all dependencies).

Here is a video (unfortunately the 60fps didn't get preserved during the upload): Never mind - imported it incorrectly the first time. The current upload is 60fps.


Cheers,
Jesse
4048 x 3036 - 2M

Comments

  • 6 Comments sorted by Date Added Votes
  • Looks great!

    Is this the display you are using? http://www.newhavendisplay.com/nhd0420cway3-p-7829.html

    How many pins are you using?
  • Ron,

    Yes that's the one (just a side note that most of the photos I've seen of the display, that one included, don't very closely represent the font/typeface that's actually stored in the ROM. The one in the video I made shows the embedded font).

    Interfacing over I2C, it just uses five pins: Vcc, Vss, SCL, SDA (two pins are tied together to form SDA), and RES.

    When using I2C or SPI, most of the unused pins are to be grounded (hence all of the green jumpers from the module to the ground rail on my breadboard :) )
    I think I remember seeing a Google image search result of what looked like a small breakout/adapter board someone made, that once connected, only brought out the necessary pins for I2C or SPI - might have to dig that one up.
  • Yup... knew I saw it - Here it is: https://goo.gl/images/AqP3HW
  • Wow, that is an awesomely thin display compared to the regular #27977 LCD panel I have been using on the Stingray! Thanks for sharing your code.
  • avsa242 wrote: »
    Ron,

    Yes that's the one (just a side note that most of the photos I've seen of the display, that one included, don't very closely represent the font/typeface that's actually stored in the ROM. The one in the video I made shows the embedded font).

    Interfacing over I2C, it just uses five pins: Vcc, Vss, SCL, SDA (two pins are tied together to form SDA), and RES.

    When using I2C or SPI, most of the unused pins are to be grounded (hence all of the green jumpers from the module to the ground rail on my breadboard :) )
    I think I remember seeing a Google image search result of what looked like a small breakout/adapter board someone made, that once connected, only brought out the necessary pins for I2C or SPI - might have to dig that one up.

    Thanks! Good job!

  • Updated this over the past few weeks - changes incorporated in a new 'testing' branch:

    - Completely rewritten (*** API change): Separate functionality out into separate methods (e.g., SetDisplayCursorBlink(x, y, z) has been broken out into EnableDisplay(x), SetCursor(y) ). I wrote it the way I did originally as it was a 1:1 representation of how the functionality is combined in the instruction/register set of the display controller. At the time, it seemed certain to me that it had to be rewritten like this. In retrospect, I don't feel so strongly about it. ;) A disadvantage is that the register states are now stored as variables on the Prop - something I'm not too keen on, in principle. It's just a bit of a strange chip - you can't read register states back...
    - Reformatted to comply with the spin-standard-library guidelines
    - Added support for inverting the display
    - Added support for display shifting/horizontal scrolling (only the scroll by a full character cell is implemented so far. The display controller also features a 1-48 pixels "smooth scroll," but I haven't been able to figure this out, yet)
    - Renamed some methods to be more user friendly (e.g., SetBiDirection(com, seg) becomes MirrorH(boolean) and MirrorV(boolean)
    - WIP: Try to make it also API-compatible with Parallax's Serial_Lcd.spin object so migrating a project to OLED would be a bit less of a headache
    - TODO: Custom character map support, SPI version, optimization
Sign In or Register to comment.