Logically invert the pin? #7667

espruino-discuss · 2025-02-12T19:24:52Z

espruino-discuss
Feb 12, 2025
Maintainer

Posted at 2018-10-31 by George

Hi, I am trying to make a backlight using WS2812b for my nixie clock project. Here is a screenshot:

I am controlling 5v Neopixel with 3.3v logic. As you can notice, when the microcontroller pin is high, LED's data pin is 0v, when the pin is low, LED's data pin is 5v. AFAIK Espruino's Neopixel lib is designed for non-inverted wiring only. Is there a workaround for my case? Maybe the pin itself can be inverted, so it outputs HIGH when being set to LOW and vice versa. The PCBs are already printed and I don't want to throw them away

espruino-discuss · 2025-02-12T19:24:55Z

espruino-discuss
Feb 12, 2025
Maintainer Author

Posted at 2018-10-31 by @allObjects

I assume you need the level shift... because your driving mc pin is not 5V safe... but you do not want the inversion, do you?

You need now to convert your inverting circuitry in a non-inverting level shifter... and with you PCB already done, you get out of this only with 'fix-wiring-in-the-air' and trace cutting... latter may be prevented...

Give these approaches a shot:

First is a bit a hack... The diode in the second is to make sure that the voltage on the input side is lowered, but has a negative inpact on the output, which raises the LOW... between 0.2V at lowest without Diode, and about 0.9 with Diode... To compensate for the first Diode, you may add one in the output as well in forward direction AND add a 33..68K resistor to ground... but that's a lot of stuff in the air...

Second is a typical MOSFET level shifter.

As a third, you may also use a 2-transistor - double inverter - after all you may just have all additional components at hand anyway ;-) - with:

no trace cutting
T1-Base on PCB (instead of T2-Base)
T2-Emitter and Collector on PCB (as originally)
R2-in-the air with one end on R3-+rail
R2-in-the air with non-rail, T1-Collector and T2-Base in the air
T1-Emitter somewhere on Ground / T2-Emitter

Attachments:

Posted at 2018-10-31 by George

Thanks for that, but before hacking and messing with the wiring I want to try to fix this issue on a software level. If not, well, then hacking is the only way

Posted at 2018-10-31 by @allObjects

Good luck... I was looking up whether it is possible to change the pin config to inverted logic as many devices allow... but did not find a thing (assuming you work w/ STM32F series of processors...). I hoped to find a possibility where you would poke some bit into some register and it magically happens... Since Neopixel is burned into the firmware, you may need a separate build...

You did not answer whether you need a level shifter...

Least messing is option 2.

Posted at 2018-10-31 by George

By the way, is your fix possible with the BC817 transistors I already have?

Posted at 2018-10-31 by George

Sorry, yes, a level shifter is exactly what I need here because I am controlling a 5v LED with 3.3v chip

Posted at 2018-10-31 by @allObjects

Sure... because they are just plain general purpose, and the loads you put on them are way within their limits...

For R3 you can keep your R82... and your R83 does not hurt... but it could be of higher resistance value, because you have now a double staged amplifier switch...

Posted at 2018-10-31 by George

Higher like 10k? I have a bunch of different resistors to pick from (1m, 10k, 5.6k, 4.7k, 3k) which one fits most? I came to Espruino from web development because of JS, and transistors are still kind of black magic to me)

Posted at 2018-10-31 by @allObjects

10K is fine... Power seems not to be an issue, since you run anyway much more demanding things than just this transistor circuitry... R3 Suggests 33k, but 10k - if this your highest value - does work too. With this low power, DC signal, switching applications, it is not that critical.

Posted at 2018-10-31 by @gfwilliams

What board are you running Espruino on? The Neopixel libs are all different.

I think you might be able to make it work on STM32 using the old school SPI.send4bit method with different bit patterns, and on NRF52 you may be able to use NRF52LL to create an inverter using PPI - but all the others would require a source code change and rebuild.

No guarantees though - SPI may change its state when idling which would break it.

It's been on my list to try and bring all the Neopixel code into one common codebase, and then to add exactly what you're suggesting - an option to toggle the polarity. Haven't had time yet though!

Posted at 2018-10-31 by George

I am running Espruino on my own nixie clock board with an STM32F100CB chip. How does SPI.send4bit method works? I mean WS2812b protocol requires 8khz rate, how can I match this with SPI?

Posted at 2018-11-01 by @gfwilliams

Check out https://www.espruino.com/Reference#l_SPI_send4bit

The old way of doing neopixels on STM32 was:

SPI1.setup({baud:3200000, mosi:B5});
SPI1.send4bit(leds, 0b0001, 0b0011); // send to the lights

and that's basically what still happens under the hood.

If you tried:

SPI1.send4bit(leds, 0b1110, 0b1100);

instead then it might invert everything for you.

Posted at 2018-11-01 by George

Thank you, I will try this tonight. By the way, if my signal is inverted, does this mean, that I should keep the pin HIGH all the time when I am not sending bits? And how can I achieve this?

Posted at 2018-11-01 by @gfwilliams

I forget what's needed - you'd have to look at the WS2812 datasheet.

It might be that the last bit of the data that is sent on SPI is enough to set the resting state of the line. However if it isn't then I'm afraid you're out of luck

Posted at 2018-11-02 by George

I tried this:

SPI1.setup({baud:3200000, mosi:B5});

// like so
SPI1.send4bit([1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1], 0b1110, 0b1100);

This should turn the first led white, but did nothing :(
Is this wrong?

I also found this guide showing how to control WS2812 with PWM and DMA. This is a very efficient way, as they say. This guide is far beyond my understanding. Is something like this available with Espruino?

When I started this project, I thought that the LED part would be easy and fun. Already wasted four days on this problem, lol)

Posted at 2018-11-04 by @gfwilliams

Try:

leds = new Uint8Array([255,255,255])
SPI1.send4bit(leds, 0b1110, 0b1100);

The bits are already split up for you.

DMA is used on nRF52 but not STM32 - however the code that's in there works great and has been in use for years without trouble, so I'm loathe to change it.

I'm not sure their PWM via DMA approach is better than the current SPI+DMA approach though.

That thing I mentioned about bringing all the code together would hopefully involve using DMA, but that's another can of worms since it has to be made to work on all platforms as well.

Posted at 2018-11-04 by Robin

Sun 2018.11.04

Hello @george,

'I thought that the LED part would be easy and fun'

Yes, if this were an LED. This is in fact a Neopixel. Much more fun! ;-)

'Already wasted four days on this problem'

Nothing about what you are in the process of learning is wasted. Imagine Thomas Edison, 'I've just found 10,000 ways that won't work!'

I re-read #1

You are in fact just re-discovering methods that prove the limitation of the circuit board data input inversion!

Note that I don't have access to a scope to verify the following . . . .

I re-checked the device data requirement:

https://cdn-shop.adafruit.com/datasheets/WS2812.pdf

The reset pulse required for the 5050 is a low state, greater than 50usec

Although @gfwilliams #16 suggestion leds = new Uint8Array([255,255,255]) will turn the first Neopixel in a strip white, this will only work when on a non-inverted circuit, as you already have discovered.

https://www.espruino.com/Reference#l_SPI_send4bit bit0 - The 4 bits to send for a 0 (MSB first)

So if SPI1.send4bit(leds, 0b1110, 0b1100); sends the correct reset pulse, your data will need to be inverted. As a suggestion, try the middle road leds = new Uint8Array([127,127,127]) on the first test. Better yet, leds = new Uint8Array([90,165,15]) e.g. 0x5A 0xA5 0x0F Alternate the bits, in case the inversion is changing the reset width too much. If the reset pulse is detected, some color of some sort may be seen.

Depending on the number of Neopixels there are, send more data. For the above circuit of three, send nine bytes or more. It's possible that some data might get detected as the reset.

In #10 above Gordon pointed out: > 'No guarantees though - SPI may change its state when idling which would break it.'

My guess is that this is in fact what is occurring that the data line is remaining in a high state, so a low reset pulse is never seen at
the correct place and at the correct time interval, in the data sequence.

As you discovered in #15 SPI1.send4bit([1,1,1,1,1,1, may work, if you are able to prove being able to send that reset pulse.

In your circuit, remember that data is inverted, so the above code is sending a continuous stream of set the output to black.

Although there hasn't been an indication of how many circuit boards, it seems from #1 'for my nixie clock project', only one or two perhaps?
Four days have been spent researching a software solution when I believe @allObjects had the best suggestion in #2 Just lift the base of the input data transistor and tack solder a matching flying transistor and input resistor. Should be able to tack solder on top of the existing one without having to remove it.

Here is yet another simple schematic showing the same - unless others disagree, two common 2n2222 should also work.

https://electronics.stackexchange.com/questions/110510/why-are-two-transistors-often-used-instead-of-one/110511

What case package is being used? TO-92 TO-236AB perhaps?

Posted at 2018-11-04 by Robin

Sun 2018.11.04 (after five hours of reading and thinking)

It appears I may have to retract a bit of what I just posted.

After doing a wee-bit of research, I had to re-learn how a data one and data zero are created.

https://learn.adafruit.com/adafruit-neopixel-uberguide?view=all

Under heading 'Writing Your Own Library' (Unable to paste as it is an image)

2nd pp "There’s a math goof in the datasheet’s timing values. Use these figures instead:"

As both a data one and a data zero start with a logic one at the leading edge, inverting the signal as in hardware #1 above, would mean that a leading edge could never be detected accurately. Data therefore could never be sync'd and decoded as sending the inverted data in software, would mean the duty cycle as seen by the 5050 would start with a leading zero, which doesn't mark the beginning of a valid data value. It might be that one could fake that using values near the middle of the range, say 0x0F by catching the declining pulse in an inverted data bit stream
as the leading edge, but then precise data could not be sent, meaning no color control and the zero state latch/reset value could not be sent correctly.

I now don't believe it is possible using software based on the above article and included datasheet.

The actual neopixel module source might be of some help in understanding:

https://github.com/espruino/Espruino/tree/master/libs/neopixel

Posted at 2018-11-04 by George

@robin, thanks for the encouragement) I have tried sending data as you offered with no effect. I feel that there is nothing left to try with the software part. Another reason why I was evading hardware fixes is that all my components are SMD, and transistors have the TO-236AB package. I have a soldering station with a hot air gun, so soldering these components on a factory-quality PCB is fairly easy. But I can hardly imagine how to make this "in-the-air" fix with SMD components. Resistors are SMD too, they are 0805. So here comes the tricky part.

By the way, I have two separate lines of Neopixels. One of them is on B5 and another one on B6 port. There is no SPI on B6. I have seen, that latest Espruino version can setup SPI on every pin, but does it have enough speed to control the Neopixels?

Here is how my whole project looks like. Just in case.

Posted at 2018-11-04 by Robin

I noticed this thread is posted under other boards, may I ask which board you are using, as the answer is, depends. I can provide more, knowing that based on my successes.

Also, did you catch #18 as I made a post at the same instant your #19 came through.

Posted at 2018-11-04 by George

Yep, I've seen it. I am using my own board and I made a custom build of Espruino for it. Nothing special, it is based on STM32Discovery with the package changed to LQFP48 and some more little tweaks. I also used pin_names_direct as @gfwilliams offered. I have posted a link to my board PCB layout and diagram in my previous post.

Posted at 2018-11-04 by Robin

Ahhh,

'I was evading hardware fixes is that all my components are SMD'

Had a hunch that might have been the reason. Did my prototyping with a breadboard, so made a false assumption there. Might have been what @allObjects was thinking in #2 above also re:TO-92. Now I look at my strip and the SMD stuff there and have to agree, not easy. If fact near impossible?

' I am using my own board'

So does this board then only use hardware SPI ? e.g. is it capable of software SPI ?

> ' I feel that there is nothing left to try with the software part'

Do you agree with my #18 assessment based on the article pp and datasheet data zero and data one diagram?

Posted at 2018-11-04 by George

Do you agree with my #18 assessment

Absolutely. Thinking on how to add one more transistor on each line there. There is enough room, but I want to minimize the mess.

So does this board then only use hardware SPI? e.g. is it capable of software SPI?

I have no idea. The datasheet says that there is an SPI on the B5 pin. I am using Espruino's SPI.setup function. When I use it on the B5 port it is ok. When I use it on B6 port there is an error "ERROR: Pin B6 is not capable of SPI1 MOSI". I don't know what characteristics a port should have to be capable of a software SPI. As I mentioned earlier, there is this line in Espruino's 2.0 update notes:

Software Serial Transmit and Receive on any pin

Isn't this an SPI? This looks very promising.

Posted at 2018-11-04 by @allObjects

...take a look at this conversation about Hardware OR Software I2C/SPI/USART/... and HOWTO do it. I hope it of some help to you.

Posted at 2018-11-05 by Robin

EDIT: Post #24 with link to post created around the same time, arrived simultaneously as I posted #25 Apparently answers what I mentioned below, I was unable to check.

EDIT2: (3 hours later) disregard edit apparent above - either a load of doc pages have to be fine tuned (which would have been completed before 2V0 press release) or my original hunch stands based on:

https://www.espruino.com/Reference#t_l_SPI_setup

'Some boards such as those based on nRF52 chips can have SPI on any pins'

'On STM32F1-based parts, you cannot mix AF and non-AF pins (SPI pins are usually grouped on the chip - and you can't mix pins from two groups)'

When I saw pin B5 I immediately thought, must be running on a Pico as one of the three hardware SPI pins is B5

Just checked: (is that the same as your project?)

https://www.espruino.com/ReferenceSTM32VLDISCOVERY

and that reference indicates 2 hdwr SPI pins, also B5 and B15 similarly to the Pico

https://www.espruino.com/Pico

Now if one checks the reference of

https://www.espruino.com/MDBT42Q

https://www.espruino.com/Pixl.js

ex: '32 x GPIO (capable of PWM, SPI, I2C, UART)'

Then I saw your error:

'ERROR: Pin B6 is not capable of SPI1 MOSI'

I thought I saw that error in the source, close but not exact,

https://github.com/espruino/Espruino/blob/master/libs/neopixel/jswrap_neopixel.c

but I did find this on Line 92

'* On some platforms like STM32, pins capable of hardware SPI MOSI are required.'

So, although I would verify this with @gfwilliams, as the older boards (that I am familiar with) required hardware SPI, I have made the assumption, without further checking, that the new 2V0 software SPI feature was available on the newer hardware, the Pixl and MDBT42Q

I'll agree that in the link you mentioned that this topic could be mis-understood.

Posted at 2018-11-05 by @allObjects

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.

Posted at 2018-11-07 by @gfwilliams

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.

Posted at 2018-11-15 by George

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?

Posted at 2018-11-15 by @gfwilliams

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

Posted at 2018-11-15 by George

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?

Posted at 2018-11-15 by @gfwilliams

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_neopixel_write

Posted at 2018-11-16 by Robin

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/stm32l496ag.html
from link
http://www.espruino.com/STM32L496GDISCOVERY

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 @gfwilliams #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 @MaBecker will catch this entry, @george are you there?, this evening to be able to add some insight before @gfwilliams will view this early Fri am.

Posted at 2018-11-16 by @allObjects

@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?

Posted at 2018-11-16 by @gfwilliams

We are (speaking for George here, I believe he'll agree) in agreement that the suggestion of inverting the output using @gfwilliams #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 :)

Posted at 2018-11-16 by @MaBecker

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

Posted at 2018-11-16 by @gfwilliams

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

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

Posted at 2018-11-16 by @allObjects

@MaBecker, nice!

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

Posted at 2018-11-16 by George

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

Posted at 2018-11-16 by @allObjects

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

Attachments:

Posted at 2018-11-16 by George

@allObjects, exactly

Posted at 2018-11-16 by @allObjects

@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, @MaBecker'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?

Posted at 2018-11-16 by George

@allObjects, yeah, the fix @MaBecker 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.

Posted at 2018-11-16 by George

@gfwilliams, 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...

Posted at 2018-11-17 by @gfwilliams

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?

Posted at 2018-11-17 by @allObjects

@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 @MaBecker 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.

Posted at 2018-11-17 by George

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.

Posted at 2018-11-17 by Robin

From last pic in #42

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

Posted at 2018-11-17 by George

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

Posted at 2018-11-17 by George

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.

@gfwilliams, 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.

Posted at 2018-11-18 by Robin

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/questions/32017/esp8266-nodemcu-first-ws2812-led-lights-up-green

Makuna/NeoPixelBus#11

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

Posted at 2018-11-18 by @allObjects

...just add one more neopixel in front of the chain and enclose it... sometimes 'the solution' is not really a solution but resolves the issue (@robin: ...even thoug I looked at the fix in Makuna's code...).

Posted at 2018-11-18 by Robin

Sun 2018.11.18

Was going to suggest that, trying to avoid more tedious soldering, but remember, then it's 'option base one' for the remaining viewable Neo's

Also, . . . . One could run a long data wire from the last of those beneath each Nixie to where B6 was to control the in-between Neo's

See note #27 where software SPI may not work
and

http://www.espruino.com/Reference#l_SPI_setup
'those based on nRF52 chips can have SPI on any pins'

Posted at 2018-11-18 by George

The LEDs are fine. I connected data line to Arduino and launched Adafruit's Neopixel demo sketch. Everything works beautifully.

I don't think SPI is the only way to run Neopixels with STM32. Basically, SPI is sending 4x more data at 4x more speed to mimic the LED's protocol. Does Espruino allow controlling a pin with a CPU directly with tiny timings, like: "set HIGH to the pin, wait for 450 nanoseconds, set LOW etc.." or it is a too low-level task?

Posted at 2018-11-18 by Robin

Sun 2018.11.18

'I don't think SPI is the only way to run Neopixels'

May I ask what the thought is, not using SPI? Are we still attempting to solve the why is the first Neo green here?

> ' or it is a too low-level task?'

@george, honestly I'm not sure. I thought I read a post on how to do just that many months ago, but I've not been able to re-locate it. Was hoping to read over and provide some insight.

Have confirmed that function digitalPulse(pin, value, time) is for millisecond pulses though.

I'm wondering if 'inlineC' could be used for the speed part, but I'm not familiar enough with the 'C' libs at GitHub. This might be a place to poke around and parent folders, while waiting for a reply.

https://github.com/espruino/Espruino/blob/master/libs/neopixel/jswrap_neopixel.c

'at 4x more speed'

Guessing here, would changing some of the SPI setup params solve the speed issue perhaps?

http://www.espruino.com/Reference#t_l_SPI_setup

Posted at 2018-11-20 by @gfwilliams

I mentioned right at the start of this thread that there was a software solution, but it's hard-coded to a certain clock speed on an F405, which won't be yours. You could possibly recompile and change things if needed.

Posted at 2018-12-09 by George

May I ask what the thought is, not using SPI? Are we still attempting to solve why is the first Neo green here?

Yes, I am trying to solve this issue and another one at the same time: the second line of Neopixels is connected to a pin with no hardware SPI on it. Running a data line from the end of one line of LEDs to the beginning of another one feels terrible. This is why I am trying to workaround hardware SPI usage.

What we've got now: The LEDs are not damaged, even the first one (which is always green when controlled by Espruino). When I poke a wire from Arduino to Neopixel's data line everything works perfectly. But Arduino is 5v.

@gfwilliams, could you please tell me where can I find the code for the F405? I couldn't find it in Espruino sources. Is it outside of Neopixel lib or even deprecated?

Posted at 2018-12-10 by @gfwilliams

Sure, yes - it's here:

So it's only compiled in for WIO_LTE at the moment. I guess a more thoughtful implementation could be included for all boards though (for instance it could benchmark itself to figure out how many iterations it has to idle for - in fact STM32's jshDelayMicroseconds already does that).

Posted at 2018-12-10 by @gfwilliams

I guess you're stuck as you have already made your board, however you could use optoisolators.

Because the optoisolator's input is basically a LED you could connect all the anodes to the SPI output, with all the cathodes to GPIOs. You could then control which optoisolator output was active by fiddling with the GPIOs.

Posted at 2018-12-18 by George

@allObjects, I finally managed to solder a second transistor as you offered. It looks terrible, but it works! Now the signal is not inverted. I also recompiled Espruino so that STM32 uses hardcoded timers and changed the timers from

\#define PATTERN_PULSE_T0H() for(uint32_t i = 0; i < 17; i++) {__NOP();}
\#define PATTERN_PULSE_T0L() for(uint32_t i = 0; i < 33; i++) {__NOP();}
\#define PATTERN_PULSE_T1H() for(uint32_t i = 0; i < 30; i++) {__NOP();}
\#define PATTERN_PULSE_T1L() for(uint32_t i = 0; i < 20; i++) {__NOP();}

to

\#define PATTERN_PULSE_T0H() for(uint32_t i = 0; i < 7; i++) {__NOP();}
\#define PATTERN_PULSE_T0L() for(uint32_t i = 0; i < 14; i++) {__NOP();}
\#define PATTERN_PULSE_T1H() for(uint32_t i = 0; i < 13; i++) {__NOP();}
\#define PATTERN_PULSE_T1L() for(uint32_t i = 0; i < 8; i++) {__NOP();}

But no matter what I send, the LED's are always white. My thought was if F405 is 168 MHz and F103 is 72 MHz I should just scale the delay values proportionally. @gfwilliams, what am I missing here?

Posted at 2018-12-18 by @allObjects

@george, thanks for the feedback... and sorry that the cool design now as a bit a sore spot... on the other hand, it is a reminder of all the effort that went it to push it thru, no matter what!

Posted at 2018-12-19 by @gfwilliams

I think you really need to stick an oscilloscope on it and check what's being output.

I believe the F4 chips actually execute more instructions per cycle than F1s in some cases (Cortex M4 vs M3) so that could be knocking your timings out.

Posted at 2018-12-19 by George

Unfortunately i don't have one...

I also found stm32's jshDelayMicroseconds function you were talking about earlier

void jshDelayMicroseconds(int microsec) {
    int iter = (int)(((long long)microsec * (long long)JSH_DELAY_MULTIPLIER) >> 10);
  //  iter -= JSH_DELAY_OVERHEAD;
  if (iter<0) iter=0;
  while (iter--) __NOP();
}

I see the logic of this function like this:

iter = microsec * (how_fast_mc_is / how_fast_it_should_be)

But i don't understand how to make this function work with nanoseconds.

Posted at 2018-12-19 by @gfwilliams

I'm afraid that without an oscilloscope or Logic Analyser you're going to find this pretty much impossible - you're just stabbing around in the dark. At £15 something like this would be well worth the investment: https://www.amazon.co.uk/Hobby-Components-24MHz-Analyser-1-1-16/dp/B00DAYAREW

Just get it, connect it and send the Neopixel signals - then see how long the signals actually are compared to what you want and divide the numbers accordingly.

To use jshDelayMicroseconds for smaller numbers you'd have to make your own function for sending that used JSH_DELAY_MULTIPLIER and precalculated the numbers to count from for PATTERN_PULSE_Txx - but again it's not guaranteed.

Posted at 2018-12-31 by @allObjects

@george,

I do not know if this

But there is an issue with the first LED. Its green part always turns on no matter what color I set it to.

is still an issue for you...

Because I just fooled around with the Neopixel LEDs I got as part of the PICO Kickstarter reward... and guess what: using my Espruino-Wifi, the string of 8 neopixels I connected to B15 showed the same green sickness... No matter what color I give, the last pixel (sent) just gets screw(ch)ed over.

First I thought it was some coding issue... but no... since I did not set any pinModes, I felt that the convenient - or glorious - automode could be the culprit: and it IS. Setting the pinMode() to output just fixed the issue (I did not look into the Neopixel write implementation... may be it can be fixed there for good... waiting a bit longer with going back to auto or what...).

Only a while after I fixed the issue it came back to me that you had a similar issue... ;-)

Anyway... I know that you use a different chip, but one never knows until tried. Give setMode(<pin>,"output") a shot.

Posted at 2018-12-31 by @MaBecker

Anyway... I know that you use a different chip, but one never knows until tried. Give setMode(,"output") a shot.

Good point @allObjects, this is what fixed first Neopixel issues on my side and if not just send twice.

Posted at 2019-12-05 by George

Almost year passed and I solved the issue today. Unfortunately I had to drop Espruino and stick to low level HAL STM32 library. The LED pin is controlled by timer's PWM and DMA. If you invert the timer polarity simply changing one register everything starts working. I want to say a HUGE thanks to everyone who helped me with this problem. You guys are awesome. OMG I can finally finish my clock now, I am so happy!

I will post the clock here as soon as I finish them.

Posted at 2019-12-05 by @allObjects

...glad and sad... glad that you got your project completed - I know the feeling that can drown every compromise take on the way to now - and sad that you had to go to low level libs and fiddle there. May be this is an option to be considered in Espruino's firmware to be able to choose polarity for output in general / have it configurable... since this is a standard function on every current micro controller...

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Espruino JavaScript

Logically invert the pin? #7667

{{title}}

Replies: 1 comment

{{title}}

Select a reply

Espruino JavaScript

Logically invert the pin? #7667

espruino-discuss Feb 12, 2025 Maintainer

Replies: 1 comment

espruino-discuss Feb 12, 2025 Maintainer Author

espruino-discuss
Feb 12, 2025
Maintainer

espruino-discuss
Feb 12, 2025
Maintainer Author