Issues with simple Neopixel code

Toit

#Issues with simple Neopixel code

Thread channel in help

alex (he/him) 10/26/2025 07:52 PM

Using the following code, I get this when using jag monitor. Any ideas?

import gpio
import pixel_strip show PixelStrip

PIXELS ::= 1
main:
  pin := gpio.Pin 08
  pixels := PixelStrip.uart PIXELS --pin=pin

  r := ByteArray PIXELS
  g := ByteArray PIXELS
  b := ByteArray PIXELS

  r.fill 0x44
  g.fill 0x80
  b.fill 0xff

  pixels.output r g b

  sleep --ms=1

floitsch 10/26/2025 07:55 PM

Interesting.
10:1 is uart::create if I'm not wrong

floitsch 10/26/2025 07:55 PM

I don't see how and/or why that would take too long

floitsch 10/26/2025 07:55 PM

Is it reproducible?

floitsch 10/26/2025 07:57 PM

In the meantime, you can just use Pixelstrip.rmt. (for one pixel that should work perfectly fine)

floitsch 10/26/2025 08:08 PM

I can reproduce.

floitsch 10/26/2025 08:08 PM

And the rmt variant doesn't seem to work either.
Very strange.
I will debug.

alex (he/him) 10/26/2025 08:08 PM

rmt

puts it into deep-sleep

alex (he/him) 10/26/2025 08:09 PM

alexanderniebuhr@MacBookPro ~/D/P/c/toit [1]> jag monitor
✔ /dev/cu.usbmodem578E0248291
Starting serial monitor of port '/dev/cu.usbmodem578E0248291' ...
J�ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x9c
load:0x4086c110,len:0xb94
load:0x4086e610,len:0x2534
entry 0x4086c110
[toit] INFO: starting <v2.0.0-alpha.188>
[toit] DEBUG: clearing RTC memory: invalid checksum
[toit] INFO: running on ESP32C6 - revision 0.0
[toit] INFO: entering deep sleep without wakeup time

floitsch 10/26/2025 08:10 PM

How did you install the rmt version?

floitsch 10/26/2025 08:10 PM

For me it just doesn't do anything.

floitsch 10/26/2025 08:11 PM

could it be that the program finishes, and then nothing is left to do, and the system goes into deep-sleep?

alex (he/him) 10/26/2025 08:11 PM

Just installed it and then jag monitor

floitsch 10/26/2025 08:11 PM

installed it how?

alex (he/him) 10/26/2025 08:11 PM

Neopixel doesn't light up

alex (he/him) 10/26/2025 08:11 PM

/Users/alexanderniebuhr/.cache/jaguar/sdk/bin/toit compile --snapshot -o hello.snapshot hello.toit && /Users/alexanderniebuhr/.cache/jaguar/sdk/bin/toit tool firmware -e firmware.envelope container install -o hello.envelope hello hello.snapshot && /Users/alexanderniebuhr/.cache/jaguar/sdk/bin/toit tool firmware -e hello.envelope flash --port /dev/tty.usbmodem1401 --baud 921600

floitsch 10/26/2025 08:11 PM

Ok. That confirms my suspicion.

floitsch 10/26/2025 08:12 PM

Basically, your program finishes, and the system then decides that nothing is left to do and shuts down.

floitsch 10/26/2025 08:12 PM

If you increase the sleep, you will see that it doesn't go into deep sleep immediately.

floitsch 10/26/2025 08:12 PM

However, there is a bug with the rmt PixelStrip.rmt on the C6(edited)

alex (he/him) 10/26/2025 08:12 PM

Oh let me put a loop with logs, but I think that doesn't light up the pixel anyways

floitsch 10/26/2025 08:13 PM

You can work around it for now with the (deprecated) I2sPixelStrip:

import pixel_strip show I2sPixelStrip
...
main:
  ...
  pixels := I2sPixelStrip PIXELS --pin=pin

floitsch 10/26/2025 08:14 PM

I will debug the other ones.

alex (he/him) 10/26/2025 08:16 PM

I still don't get it to light up. But I'm using a strange waveshare dev board

floitsch 10/26/2025 08:17 PM

https://www.waveshare.com/esp32-c6-dev-kit-n8.htm
This one?

ESP32-C6 Microcontroller, WiFi 6 Development Board, 160MHz Single-c...

ESP32-C6 Microcontroller, WiFi 6 Development Board, 160MHz Single-core Processor, ESP32-C6-WROOM-1-NX Series Module, Supports USB And UART Development | ESP32-C6-DEV-KIT-N8

alex (he/him) 10/26/2025 08:18 PM

yeah

floitsch 10/26/2025 08:18 PM

pin 8 looks correct, and I manage to make mine light up. So that's a bit weird.

floitsch 10/26/2025 08:19 PM

So the I2sPixelStrip variant doesn't work for you?

alex (he/him) 10/26/2025 08:20 PM

No. But can be my board..

floitsch 10/26/2025 08:21 PM

Either way, the uart-deadlock is clearly a bug. And the RMT should also work.
I just tested on the normal ESP32 and there all three work.
Will now try with the s2, s3 and C3.

floitsch 10/26/2025 08:25 PM

S2 works.

floitsch 10/26/2025 08:30 PM

C3 only works with uart and I2s.

floitsch 10/26/2025 08:31 PM

I'm guessing RMT is currently broken on C3 and C6, and uart is broken on C6.

alex (he/him) 10/26/2025 08:42 PM

I'll get new prototype boards next week.. c3 & c6. But sounds like I have to switch to s3

floitsch 10/26/2025 08:44 PM

The c6 shouldn't be broken.
I'm already debugging the UART issue.

floitsch 10/26/2025 09:55 PM

I made a bit of progress, but no solution yet.
We are stuck in uart_ll_update, which waits for the peripheral to clear a bit.
I think the clock isn't active which is why we just keep looping there.
Will give up for today, but this is now a high priority.

z3ugma 11/04/2025 04:24 AM

I think I'm running into the same deadlock with UART on C6

z3ugma 11/04/2025 04:25 AM

z3ugma 11/04/2025 04:27 AM

I can reproduce it with a very simple:

import uart 
import gpio 

RX0 ::= gpio.Pin 14
TX0 ::= gpio.Pin 15

main:


  port1 := uart.Port
      --rx=RX0
      --tx= TX0
      --baud-rate=9600

z3ugma 11/04/2025 04:27 AM

[toit] INFO: starting <v2.0.0-alpha.189>
[toit] INFO: running on ESP32C6 - revision 0.1

z3ugma

I think I'm running into the same deadlock with UART on C6

floitsch 11/04/2025 03:20 PM

Yes. Any UART is currently broken on the C6.
It's still my top priority.

z3ugma 11/05/2025 12:43 AM

@floitsch

I want to try a serial console app over UART0, which today prints out log and print statements. will we be able to accept input from Uart0 Rx as program input

z3ugma

@floitsch I want to try a serial console app over UART0, which today prints out log and print statements. will we be able to accept input from Uart0 Rx as program i...

floitsch 11/05/2025 07:56 AM

At the moment there is no way to read from stdin on the esp.
However, you could change the sdkconfig do that the default console (with the prints and logs) goes to different pins and then use the original pins for your own UART (or any other use for that matter). You could even keep the tx the same (so that prints... still go to the same output if that's what you want).
Biggest downside:
- you need your own sdkconfig
- only works if you have a uart-usb chip on your board
- uses up a UART

z3ugma 11/05/2025 08:55 AM

I guess I could write my own logging module that sends to another UART pin though too, and just do it all natively in Toit?(edited)

floitsch 11/05/2025 08:56 AM

Also an option.

floitsch 11/05/2025 08:57 AM

But the stdin needs to be changed in the sdkconfig

floitsch 11/05/2025 08:58 AM

(there isn't any inherent problem with exposing the default stdin in Toit. It's just not implemented yet)

47 messages in total