Large Display: x by y w/ 24 bpp Graphics buffer visualized with neopixel string in zig-zag layout #1289
Replies: 14 comments
-
Posted at 2019-02-04 by @allObjects Very interesting... just notice that it is color dependent... I draw a line with 0,0,8,3 in my 9 by 4 panel with each of these 4 colors:
Colors I'm looking for an explanation... There must be an easy answer. I will take a clip of the behavior... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @allObjects Here it is... regarding orientation: tilt your head to the right to see it landscape... sorry for that... since the shot was straight down, the phone (camera) could not figure out top... To take (most of) the glare away, I put a white card stock / heavy white paper on the leds. Btw, orange and red are the 'working colors 0 and 3. What you can observe is: with multiple colors, color sequence in the string is always the same: zag - odd row - sequence is reverse of zig - even row - sequence, and the middle pixels have the same color and the begin and end pixels have each a different color. This is a dump of the colors and the buffer - line by line - you can recognize the diagonal line: Tilde
Buffer dump w/ more details (byte index of RGB tuple begin for even row and end for odd row - and RGB values):
Same pattern for all the R G B colors:
Even if I messed up the interpretation of RGB or BGR or what ever, I would expect to show only one color... or max two - one for zig and one for zag... but not three with the inner pixels - if there are more than one as in row 2 - having the same color... To produce this, setup the neopixel string on B15 w/ a resistor of 330R Ohm between B15 and 5V and upload this code:
I also tried w/ no no zig-zag and the color effect is the same... also drawing single lines in horizontal and vertical and +-45 degrees show the same color issue... set pixel does it! Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by Spocki dithering/smoothing in the graphics buffer display routine? what if you take a "perfect" line exactly matching the dots, ie r1c3, r2c4, r3c5, r4c6 |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by Spocki or simply r1c5, r2c5, r3c5, r4c5 |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @allObjects Thought about this... but the colors are so absurd... and how can you smoothen out setting single pixel? ... it is random that left or right of the pixel a green one shows... just weird. Here the code to your suggestion - and thank you for jumping on this:
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @gfwilliams I'd be pretty sure that this was actually an electrical issue due to the neopixels missing one or two bits (so one pixel's colour 'bleeds' into the next). Are you sure the grounding is ok? And do you have an oscilloscope? Are the signals actually 5v? Out of interest, what happens if you just do:
Which is the 'old' style of doing neopixels. I'm just aware that there was this PR 8 months ago that changed the waveform pattern: espruino/Espruino#1459 There was obviously a lot of testing that went on but given it had been working fine for years beforehand, the phrase "if it ain't broke, don't fix it" could apply here. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @allObjects HW / wiring all just ok... it was reproducible... no electrical issue what so ev er... This means that the "neopixl" module has obviously some ick... as code below and clip proof... and kind of surprise is that the colors are quite different... YYYYYYUUUUUUUUUUUUPPPPP.... plain SPI use fixes it (your option is a bit off... but that's peanuts... and with B15, isn't it SPI2?) Thanks a lot, @gfwilliams.
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @gfwilliams Thanks - I've just revered that PR, so on the latest builds it should now be working again. I think I'll have to start manually testing every hardware-related change that comes in before merging - it just takes so much time to do though. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @allObjects ...becoming the Linus trap |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @gfwilliams Hopefully I won't start hurling abuse at contributors :) edit: I do really appreciate any contributions to Espruino. However, I do this full time and I'm aware that in a lot of cases (like with the Neopixels) I have a lot of hardware available here that I can test with - its not reasonable to expect others that are suggesting changes to have tested on all the same stuff, so at the end of the day it falls down to me to test things out before merging. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @allObjects
...did not want to go there and was not really my concern... was more thinking about your and your 'closes' sanity. Nothing wrong with working hard or more than average... but it still should sustain life and not the other way round. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-06 by @allObjects ...had some more neopixely color fun with this code... works like a charm... I mean @gfwilliams 's neopixel implementation... the old way... and in a bit - comes 2v02 - also the new way! Take a look at the clip showing poor man's video screen... display panel... call it what you want... (this version uses the 30 pixel per m... 60/m is available too and would make it better (and more power hungry. Going for 144/m will almost be 'blowing away'... also the power that goes with it. 144/m is the densest so far. Theoretically 200 is possible by the body of the pixel (<=5mm square), but unfortunately the 'legs' stick a bit out and are thus not that cooperative to reach that density.
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-06 by @gfwilliams Nice - and wow, that looks bright! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-09 by matencio It does look bright. This is turning out to be a great project resurrecting the past. Here's the artwork the lights will sit behind. An artist's representation (mine) but ten rows with the different colors as in the video of the board. The board is black with the horse cutouts diffused by a frosted clear plastic and the Neopixel lighting behind the horse. I think it will be really nice when completed.Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by @allObjects
On Espruino-WiFi w/ 2v01, I have a 9 by 4 graphics instance of Graphics with 24 bpp. The graphics is updated on external events. The events are detected by watched and polled pin changes and statuses. For the display panel I use a 5V off-initializing neopixel string in line-by-line zig-zag routing that presents like a dot matrix panel. Since I do not want to use the application driven .flip() of moving the display buffer into the display, I have a function on 250[ms] interval that does it. Because the setup, the .flip like logic is very simple:
On a very regular basis I get random green 'erranding' pixel before or after pixels I'm setting in the string direction . Moving my set pixel along the the string by setting current pixel w/ backround color (0) and next or previous pixel with a constant non-backround color (!0), the green 'erranding' pixel keeps leading or following the changing pixel... weird...
Reading the buffer with a JS function, I never see bleeding. All 3 pixel bytes have always left the old place and show all up at the new place.
Event rate is very low compared to neopixel refresh rate (graphics flip rate). Power supply is 3A. Grounds are connected at Espruino board. There are never more 12 pixels on, never all white. Pin mode is set to af_opendrain and data line is pulled to 5V w/ resistor. I varied the resistor between 1K and 330R w/ no different result.
What could cause that? Even with constant refreshing and no change in the graphics buffer, the green 'erranding' pixel stays put. The 'erranders' or really random... also in regard of the row.
Beta Was this translation helpful? Give feedback.
All reactions