No announcement yet.

uOLED driver for nanoX!

  • Filter
  • Time
  • Show
Clear All
new posts

  • uOLED driver for nanoX!

    Hi All,
    I have made a driver for the uOLED-160-GDM1 to work with nanoX (aka microwindows) for linux. It works quite well, except you will have to disable the mouse driver as the pointer refresh is too slow. readme file is included.


    Attached files (11.7 KB)

  • #2


    This is interesting, I've tried myself to connect various modules to linux and wrote some drivers but I never thought about using directly the window manager to communicate with the screen over the serial port.

    The best approach (as I thought) was to wire directly the LCD (w/o the 4D module) on the LCD port of my gumstix and using the Intel PXA270 built-in LCD driver. But this was tedious, and my framebuffer driver was somewhat limited

    Can you comment on how well it works ? There are some troubles compiling qtopia/nanoX and cie on the Gumstix platform so I'd like your feedback before trying anything.
    Can you run a console on it ? Does it acts exactly as a framebuffer ??



    • #3

      Hi Julien,
      Nano-X has an api similar to the uOLED's command set, so my code is an interface between nano-x and the uOLED, for example the nano-x display driver has a draw line command, so i call oled line commad.. it work's good and bad. no framebuffer action is possible really, i had toyed the idea of using a framebuffer driver and the drawimage command, but no code yet..

      It works well with things like drawing windows and the clock and loadmon as they draw with line commands and rectangles, font's are a bit slower as they are pixel by pixel. Im hooking it up on my wgt634U netgear mips wireless router to display stats from the linux lighting architecture.

      console.. possible but i had drama's releating to my linux distro, it could not find pty0 and stuff, and couldn't get bash to work, but i could get "xterm ls".

      partial (weak) blit is implemented, but not many nanox programs use it.

      framebufffer: sorry but no, it just as fast as allways.


      • #4

        Oh ok, lol I admit I had high expectation since nanoX is one of the major (along with qtopia) window manager for embedded platform.

        I guess if there is a way of transfering the command a bit faster it would make things easier no ? I'm thinking about the SPI capabilities of the 4D modules. When they'll release 4DGL I think that would be possible.

        I think I'll give it a try, and start to rework this partial driver I made now that I've 1 weak break

        Thanks for the driver