Shop OBEX P1 Docs P2 Docs Learn Events
P8X32A and Pervasive Display 2.7" 264 x 176 (117 dpi) - code samples? — Parallax Forums

P8X32A and Pervasive Display 2.7" 264 x 176 (117 dpi) - code samples?

Ken GraceyKen Gracey Posts: 7,392
edited 2014-11-29 12:43 in Propeller 1
Hey there!

I've got a display and development kit for this product http://www.pervasivedisplays.com/products/27. I'm looking at it for possible inclusion on a future badge or business card, or maybe for Parallax's product line.

Has anybody coded for this display in Spin? A quick search on our forums didn't find anything, so I know the search tool leaves much to be desired.

Any input on what I might expect in terms of coding complexity, or at least a starting point?

Thanks,

Ken Gracey

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-13 17:20
    Ken Gracey wrote: »
    Hey there!

    I've got a display and development kit for this product http://www.pervasivedisplays.com/products/27. I'm looking at it for possible inclusion on a future badge or business card, or maybe for Parallax's product line.

    Has anybody coded for this display in Spin? A quick search on our forums didn't find anything, so I know the search tool leaves much to be desired.

    Any input on what I might expect in terms of coding complexity, or at least a starting point?

    Thanks,

    Ken Gracey
    Looks like an interesting display. Controlled over a SPI interface with a few other control pins as well. And their internal controller chip is called a COG (Chip On Glass)! If you don't find anyone who already has a driver for this, I wouldn't mind writing one.
  • Ken GraceyKen Gracey Posts: 7,392
    edited 2014-11-13 21:12
    OK, that would be great - but I'm looking for Spin in this case. Would you like to code a Spin driver for this display?

    If so, I'll get you one of their evaluation kits. Their kits are quite nice - simple breakouts for breadboard connections to Propeller.

    Ken Gracey
  • Don MDon M Posts: 1,652
    edited 2014-11-14 02:46
    Are these E-Paper displays?
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-14 03:21
    Ken Gracey wrote: »
    OK, that would be great - but I'm looking for Spin in this case. Would you like to code a Spin driver for this display?

    If so, I'll get you one of their evaluation kits. Their kits are quite nice - simple breakouts for breadboard connections to Propeller.

    Ken Gracey
    Spin is okay. Much of this will probably be PASM anyway.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-14 03:24
    Don M wrote: »
    Are these E-Paper displays?
    Yes, according to the data sheet they are "Electrophoretic Display (e-Paper Display)". Is there an existing e-Paper display driver?
  • RaymanRayman Posts: 14,653
    edited 2014-11-14 15:11
    It's an interesting display. Fairly affordable for e-ink. Doesn't appear to have a backlight, which would limit it to well lit applications.
    Should be perfect for badges though as should be very low power...
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-14 18:03
    Ken Gracey wrote: »
    Hey there!

    I've got a display and development kit for this product http://www.pervasivedisplays.com/products/27. I'm looking at it for possible inclusion on a future badge or business card, or maybe for Parallax's product line.

    Has anybody coded for this display in Spin? A quick search on our forums didn't find anything, so I know the search tool leaves much to be desired.

    Any input on what I might expect in terms of coding complexity, or at least a starting point?

    Thanks,

    Ken Gracey
    Which of the products on this page did you buy? I assume that you bought the product on the page you linked but did you also purchase the shield? Just trying to figure out what kind of development platform is required for this project.

    Edit: Actually, I guess the only question I have is which of these are you talking about? They seem to have different manuals and maybe are programmed differently.

    Aurora Ma (V230)

    Vizplex (V110)
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-17 04:34
    It looks like this unit uses similar programming to the one you mention in the top post of this thread. There is C code available to drive it that would probably be pretty easy to convert to Spin.

    https://www.adafruit.com/products/1346
  • RaymanRayman Posts: 14,653
    edited 2014-11-17 09:39
    Would be nice if spin2cpp could work backwards... I think maybe Rokicki had a perl script to do it...

    I'm translating some other C code to Spin at the moment. There are some pitfalls to be avoided.
    One is that I have a lot of "if (!someFunctionWithBooleanReturnValue()) {}" which often won't work with direct translation.
    Problem is that C is looking for non-zero to be true whereas Spin only recognizes all ones as true...

    Ignore above comment, seems I was wrong
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-17 10:46
    Rayman wrote: »
    Would be nice if spin2cpp could work backwards... I think maybe Rokicki had a perl script to do it...

    I'm translating some other C code to Spin at the moment. There are some pitfalls to be avoided.
    One is that I have a lot of "if (!someFunctionWithBooleanReturnValue()) {}" which often won't work with direct translation.
    Problem is that C is looking for non-zero to be true whereas Spin only recognizes all ones as true...
    I'm not that big a fan of automatically translated code. I think I'd rather do a hand translation. It shouldn't be too hard. Also, Dave Hein *does* have a C to Spin translator. I suppose I could try that.
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-17 11:05
    Rayman wrote: »
    I'm translating some other C code to Spin at the moment. There are some pitfalls to be avoided.
    One is that I have a lot of "if (!someFunctionWithBooleanReturnValue()) {}" which often won't work with direct translation.
    Problem is that C is looking for non-zero to be true whereas Spin only recognizes all ones as true...
    @Rayman, the example you mentioned should translate to Spin without any problems. Both Spin and C treat non-zero values as not being FALSE. However, there are other cases where the difference in the logical TRUE value will cause problems, such as when a logical value is used in an arithmetic expression. Problems can also occur when translating && and || to AND and OR since C does conditional expression evaluation and Spin doesn't.

    @David, do you have a link for the C driver code. I could look at it to see if cspin can convert it.

    EDIT: I looked at the driver in epd.cpp and epd.h, which is C++. So cspin would not be able to handle it directly. I think the code could be convert to C without too much effort, and cspin should be able to handle it. The enums would need to be converted to #defines, and there may be a few other issue that would need to be handled manually. I could look into further if you want.
  • RaymanRayman Posts: 14,653
    edited 2014-11-17 11:25
    Hmm... Guess I need to retract my earlier comment... Thought I had trouble, but maybe it was something else doing it...
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-17 11:35
    Dave Hein wrote: »
    @Rayman, the example you mentioned should translate to Spin without any problems. Both Spin and C treat non-zero values as not being FALSE. However, there are other cases where the difference in the logical TRUE value will cause problems, such as when a logical value is used in an arithmetic expression. Problems can also occur when translating && and || to AND and OR since C does conditional expression evaluation and Spin doesn't.

    @David, do you have a link for the C driver code. I could look at it to see if cspin can convert it.

    EDIT: I looked at the driver in epd.cpp and epd.h, which is C++. So cspin would not be able to handle it directly. I think the code could be convert to C without too much effort, and cspin should be able to handle it. The enums would need to be converted to #defines, and there may be a few other issue that would need to be handled manually. I could look into further if you want.
    Well, Ken Gracey asked for help with this. It's his project, not mine. I just offered to help. I would still prefer to see a manual translation myself but Ken may be okay with an automatic translation. Maybe he'll comment here since it's his thread.
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-17 11:58
    It seems like the quickest approach would be to port the C++ driver and demos to PropGCC with minimal changes. Once that is tested and working it could be converted to C, and then to Spin if needed.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-17 12:02
    Dave Hein wrote: »
    It seems like the quickest approach would be to port the C++ driver and demos to PropGCC with minimal changes. Once that is tested and working it could be converted to C, and then to Spin if needed.
    Ken specifically asked for Spin. I don't know if he's also interested in C or C++. Are you suggesting to port the C++, then convert to C, then use cspin to to translate the C to Spin? Again, we'd have to confirm that Ken is willing to have automatically generated Spin code.
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-17 12:14
    David Betz wrote: »
    Ken specifically asked for Spin. I don't know if he's also interested in C or C++. Are you suggesting to port the C++, then convert to C, then use cspin to to translate the C to Spin? Again, we'd have to confirm that Ken is willing to have automatically generated Spin code.
    Yes, I am suggesting porting the code in the 3 steps you mentioned. cspin does a fairly good job of retaining variable names and comments, and the generated Spin code looks similar to the original C code. cspin will modify names when required so that they don't conflict with case-insensitive Spin name, and also to prevent using reserved Spin names. It appends _0, _1, _2 and so on to create unique names. cspin will also used the CLIB object to provide standard C library functions. This could all be hand-edited to clean up the variable names and use other Spin methods.
  • RaymanRayman Posts: 14,653
    edited 2014-11-17 12:23
    Just as an aside, I also found that Spin has a 30 character limit on variable names that C doesn't...

    Be nice actually, if there were a list of tips on converting Spin to C by hand.
    I think there was something about <= or something like that to look out for...
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-17 12:43
    Rayman wrote: »
    Just as an aside, I also found that Spin has a 30 character limit on variable names that C doesn't...

    Be nice actually, if there were a list of tips on converting Spin to C by hand.
    I think there was something about <= or something like that to look out for...
    Yup, you need to use =< in Spin where you'd use <= in C because <= is an assignment operator in Spin.
  • RaymanRayman Posts: 14,653
    edited 2014-11-17 14:26
    I think my earlier problem may be really due to ! being bitwise not in Spin and Logical not in C...

    What I should have used is "if not" instead of "if !"
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-17 14:47
    You should use "if not". Here are the operators that I translate in cspin. cstr[] is the list of C operatiors, and sstr[] is the corresponding list of Spin operators. 
    static char *cstr[] = {"=",  "!=", ">=", "<=", "&&",  "||", "!", "break", "while", "if", "switch", "%", "~",  0};
static char *sstr[] = {":=", "<>", "=>", "=<", "and", "or", "not", "quit", "repeat while", "if", "case", "//", "!",  0};
  • tomcrawfordtomcrawford Posts: 1,126
    edited 2014-11-17 17:01
    Ken, if you still have one of these eval kits, I would be happy to take shot at a driver. Dave suggested it might be mostly PASM, which is what I mostly like. Send me a pm if interested.
  • RaymanRayman Posts: 14,653
    edited 2014-11-22 06:50
    I just took a closer look at these displays... Looked at the electrical interface before and that looks easy.
    Today, I found the programming document. What a mess!

    What's got me interested is that it has the same connector as the Newhaven displays. So, I could maybe use my existing solder paste stencils to make a little adapter, similar to NH4.

    BTW: What's the difference between Aurora Ma and Vizplex? Is Aurora Ma just a newer version? Don't see any difference except the date...
    Update: Ok, I think I see the Aurora is newer the only one available on Digikey, so maybe a moot point.
    Google found me something saying the new Aurora works in refrigerators.
    Also, it doesn't appear to require a PWM input like Vizplex does.

    Update2: Looking some more at this, I see Pervasive has their 2.7" Aurora plus adapter board for just $37 on Digikey. The display is $25, so the adapter board is just $12 extra.
    This makes me unmotivated to make my own adapter board. Good part, is that you can get this thing working for just $37.
  • RaymanRayman Posts: 14,653
    edited 2014-11-22 14:18
    The drivers for this display are about 10X more complicated that I would have imagined...

    You can't just set a pixel to a new value, like you can with a regular LCD.
    First, you have to inverse the original value.
    Then, you have to shake the pixel up (appears to be two different ways to do this)
    Finally, you can set the new value.
    The Pervasive document recommends a 4-stage process, but the Arduino example (based on TI example), uses a different, 3-stage process (maybe you could call it 4 stages, but it's different anyway).
    All this is about preventing ghosting (seeing part of the old image in the new image).
    I think I see now why the Kindle flashes black and white when you turn the page...

    So, one memory complication is that you have to keep two images in memory, the previous one and the new one.
    If you keep them in HUB RAM, you need about 12 kB, which is OK for Propeller. Looks like Arduino has to store pictures in external flash memory.

    You update the display one line at a time, like you might expect.
    But, you first send odd numbered pixels, then you tell it what line you're on, then you send even numbered pixels (very strange).

    There's also a setting that depends on the temperature, which is why the board has a temperature sensor.
    But, I think we can ignore that for now and assume 25 C.
  • RaymanRayman Posts: 14,653
    edited 2014-11-29 12:43
    I spent a few hours today and yesterday coming up with a driver for this display (I'm so dull :) )
    Wrote the code from scratch instead of translating the other codes so that I could put an MIT license on it.
    Also, it was a fun exercise.

    This example is a 3 image slideshow. Input files are Windows Bitmaps. I think this makes it easier to work with...

    AuroraTest1 - Archive [Date 2014.11.29 Time 15.38].zip

    Here's a photo of my setup:
    EinkWorking2.JPG
    zip
    zip
    AuroraTest1 - Archive [Date 2014.11.29 Time 15.38].zip
    20K
    EinkWorking2.JPG
    1024 x 768 - 181K
Sign In or Register to comment.