Logically invert the pin?

Gordon keeps Espruino backward compatible on his original, genuine Espruino boards. This was 100% true up to and including 1v99. For 2v00+, CC3000 wifi module is dropped (from builds for new boards), because TI ushers new development to new CC3100MOD on CC3000 site. But with the advent of software implementation of SPI/I2C/UART(Serial), boards in the past that did not have this support, have it now as well.

Just to add to this - to use send4bit for neopixels, you need hardware SPI. Software won't cut it even though it is available.

There is a software implementation that is used on the WioLTE, but it's pretty rough, gets thrown off by IRQs, and uses hard-coded timing that only runs at that device's clock speed - so isn't included in normal builds.

I tried to squeeze one more transistor into my PCB and failed. SMD components are too tiny for "in the air" fixes. I talked to a guy who helped me to make the PCB recently and he said that I can just remove the transistor and connect the pin directly to Neopixel's data keeping the connection with 5v. Then the pin can be used to pull the 5v line to ground. Is there any other option then send4bit? ` Can I control the pin's state directly with the correct timing with Espruino?

You're on STM32? as long as the pin is 5v tolerant then yes, you can do that

But, how should I do that?

I need to set pin high or low for nanoseconds. How is this possible with javascript? Could you please post an example?

Just use the normal neopixel library - see the notes in the reference on it about using the af_opendrain mode: http://www.espruino.com/Reference#l_neop­ixel_write

Thr 2018.11.15

Two topics have resulted:

Topic 1

'You're on STM32?'

In #21

'my own board ... custom build ... Nothing special, ... based on STM32Discovery'

Is it reasonable to infer that there are 5v tolerant pins? (are these the correct docs?)

"Up to 136 fast I/Os, most 5 V-tolerant"
from bullet list
https://www.st.com/en/microcontrollers/s­tm32l496ag.html
from link
http://www.espruino.com/STM32L496GDISCOV­ERY

Topic 2

Thank you @George for cut-n-paste-n-post of the image #30. (From #17 link WS2812)

I'm going out on a limb here, but I owe it to George as I may have mis-led on our lengthy exchange (#17-#25) we had two weeks ago on Sun Nov 04 as we may be in near adjacent time zones. (I'm in CST six hours behind Gordon GMT, allObjects PST - how about George?)

Out on the branch,

I jumped (#17) into this thread after a several day exchange head start and without a scope to confirm some hunches. George has done exhaustive testing and made many trial attempts at a software resolution. I had a hunch from flicker I had seen using the Neopixel during a separate code project I was working on. I made (wrongly) a suggestion, which George coded and attempted, while I patiently waited his reply.

Further out,

After many hours of re-reading the data sheets and re-thinking on the porcelain goddess, I believe I uncovered the why as to why inverting the bit stream most likely wont work. We are (speaking for George here, I believe he'll agree) in agreement that the suggestion of inverting the output using @Gordon #31 suggestion af_opendrain will (and does) invert the data at the pin.

Further out and the limb is really bending here,

But inverting the data isn't the issue. Please re-read my #18 explanation as I believe George agrees from his #21 & #23 response, that I discovered the real issue is with the (polarity and when) of the latch pulse needed by the 5050, as described by the learn.adafruit article from #18.

Really out there,

Unless one has a much faster clock rate and a whole bunch of code to create a false latch pulse leading edge, (which I'm not entirely convinced,
would allow for a sync'd pattern within the data) then simulate equivalent widths of inverted data, after the 50usec delay, inverting the data wont solve the demand of the 5050 hardware.

Ready to take a bullet,

Maybe @allObjects or @MaBe will catch this entry, @George are you there?, this evening to be able to add some insight before @Gordon will view this early Fri am.

@George, since you picked the mc (as mentioned in #21, check stm's datasheet for that chip in regard of pins being 5V tolerant. Btw, what stm chip is it exactly?

We are (speaking for George here, I believe he'll agree) in agreement that the suggestion of inverting the output using @Gordon #31 suggestion af_opendrain will (and does) invert the data at the pin.

It doesn't - just follow what the docs say and try it. You get a 5v, non-inverted output from the STM32.

I'm afraid that's my last post on this thread though - I've spent way too long already.

If you want something to 'just work' then buy an official Espruino board - it's also easier for me to justify spending lots of time helping with issues :)

@George maybe you look at this https://hackaday.com/2017/01/20/cheating­-at-5v-ws2812-control-to-use-a-3-3v-data­-line/

I did say last post but @MaBe that is a fantastic piece of advise.

Very easy, and APA106 come in through-hole so would be very easy to use.

@MaBe, nice!

I though think it should not be that difficult to do some air wiring. @George, could you pub a pic of you PCB?

@allObjects, there is a link to my project in #19. It has my PCB layout, just change the tab.

@George, I guess that's the area of interest, as attached in pic.

2 Attachments

@allObjects, exactly

@George, I did some more adjustments... and added details. Yes, it is quite a finicky thing... but when you solder R83 and R2X upright with only at one end onto the pads of R83, T1 also upright with Collector and Emitter straddling Q1's Basis and Emitter, and finally connect with a thin strand from a stranded wire what has to be connected, it could work... but as said: it is really finicky. Since you have not a free chain of RGB LEDs, you unfortunately cannot sacrifice one... otherwise, @MaBe's cool suggestion could be the 'perfect' solution (...ah fix...(:/...

Btw, where did you get the nixie thing from, and what tubes are you using?

@allObjects, yeah, the fix @MaBe posted is really interesting, but not suitable in my case.

I am using IN-18 tubes made in USSR. I was lucky enough to find them on some weird site (like craigslist but Russian). They are not that common, but still possible to find. They were sold for 25$ each, so I bought all the lamps that guy had! My treasure. This box was sealed in 1981.

@Gordon, could you please clarify one moment for me? Espruino Neopixel API reference says the following:

If I remove my transistor, connect STM32's pin directly to Neopixels's data and add a pull-up resistor to 5V there, then set this pin to af_opendrain mode and run
require("neopixel").write(B5, [255, 255, 255]);
It should work, right?

I have tried this and it didn't work. I begin to suspect that I accidentally burned the LEDs...

Yes, you should at least get something. .write is more reliable with Uint8Arrays but it should at least make things go random colours the way you have it.

Also if you just lower the voltage you use to 4v then even without the resistor and pullup it should work.

Given this is a custom board, if you had the clock settings set up wrong then possibly USB would still work even if all the peripheral timing was wrong?

@George, amazing... about 6 months ago I looked thru options to try a nixie clock - driven with an Espruino and port expander / shift register (and of course, 'high'-voltage drivers) ... but these original nixies as well as the red bubble LED displays are disappearing like extinct species... About the bubble displays I have posted and someone else actually is building this watch w/ a bank of four of these red bubble displays.

On the Web I found a site about a place that produces new nixie tubes of the type you got... and not just nixies, but also regular ones... just not affordable for people like me. Getting a good stash yourself was a smart move...

Looking forward to see your project come to completion...

...the fix @MaBe posted is really interesting, but not suitable in my case.

May be it could be: just get an additional RGB LED and place it 'in front' of the one you have to have working (I see one under and between each of the nixies).

Thank you for the great pictures.

How can I check the clock settings?

Looks like I damaged one pin on my STM32 which was responsible for the Neopixel control. Now I'm left with the B6 pin, which is still alive but does not have SPI. Can I implement Neopixels protocol without the lib, using only CPU and hardcoded timings? I know that vanilla STM32 can do it. Is it possible on Espruino?

I ordered new STM32's and I just want to localize the problem while they are being delivered.

From last pic in #42

Is the 'real' purpose of that nixie to reveal the number of shots remaining in that bottle of Jagermeister? ;-)

It indicates the number of shots done. That's why I'm making 10-digit nixie display :D

Yay! We are getting somewhere, guys!)

But there is an issue with the first LED. Its green part always turns on no matter what color I set it to. When I reset the board all LEDs turn off, but when I turn them off manually by sending zeros, first always stays green. In the picture, I made a red to green gradient, you can see that first color is wrong.

@Gordon, the clock is fine, the problem was with the Neopixels soldered upside down. There was a misleading dot in the corner of every LED's footprint. I matched it with the notch of each LED but turned out that dot indicated power pin. When I replaced all the LEDs (they all burnt), the af_opendrain method worked. I just need to figure out the first LED's issue.

Sat 2018.11.17

Wow! That is really cool!!

Ahhh, . . . . was it the additional nine shots that helped?

'but when I turn them off manually by sending zeros, first always stays green'

Would it be possible to jumper over the suspect Neopixel's data line, sending the data entry to the second in the series?

Haven't tried that, but don't see that it would cause an issue.

As you are about to guess, if the second Neo lights red, my guess would be the first Neo is bad. If it's green even more puzzling, and more thinking to do. . . .

Another thought, is it possible the array of data has become corrupt? What about setting element zero to black, and see if the remaining data illuminates the rest. Should that be successful, try just sending data to element zero only, three separate attempts, to see if each individual RGB can be set programmatically.

WS2812 is GRB
G require("neopixel").write(B5, [255,0,0]);
R require("neopixel").write(B5, [0,255,0]);
B require("neopixel").write(B5, [0,0,255]);

EDIT: Google is your friend:

https://arduino.stackexchange.com/questi­ons/32017/esp8266-nodemcu-first-ws2812-l­ed-lights-up-green

https://github.com/Makuna/NeoPixelBus/is­sues/11

Apparently, other boards and other software have had a similar issue. Not a consistent fix though.