Closed Suspect-byte closed 2 years ago
I have a couple of the Pico's.
To be honest, for LED's, ESP's are best to use as they have built in Wifi and are same price there abouts. For a pico to have wifi you need to hook it up to a Raspberry Pi, or a wifi board, but the speed is slow.
Picos are a micro controller over a development board.
Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED!
Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED!
Closing for now since I don't think support is feasible without built-in WiFi. To add wifi, it is proposed to add an ESP which is rather ironic: https://www.tomshardware.com/how-to/get-wi-fi-internet-on-raspberry-pi-pico
Raspberry Pi has released the Pico W, with built-in wifi: https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-platform/ 🥳
Raspberry Pi has released the Pico W, with built-in wifi: https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-platform/ 🥳
You would need to port all of the libraries.
This should now be reopened? Are 2 mbytes of flash going to be enough with the WIFI code presumably taking up some of that?
Have you ported all of the libraries? 😲
may I suggest to split the code in to 2 layers? for example firmware on flash, the rest (such as effects) on an SD card?
may I suggest to split the code in to 2 layers? for example firmware on flash, the rest (such as effects) on an SD card?
An interesting idea. Can you show us how, please?
This should now be reopened?
I think its still not feasible. WLED is strongly depending on libraries from espressif, which do not exist on RP2040.
in #2704 there was mention of the existence of some replacement libraries that can do the same tasks as the esp32 ones:
@Cryptophunk :
ESPAsyncWebServer ESPAsyncTCP ESPAsyncUDP IRRemoteESP8266 LittleFS
These wouldn't be required as these are hardware specific libraries that have alternatives for RPI.
There's going to reach a point where you can only fit so much on an ESP32.
not sure what they are though.
@jmerc77 The library you are probably looking for to port WLED to rpi would be FastLED as this is the library to send data to the lights. I also believe that the server is built with NPM then minified after so it can fit on the ESP. I haven't looked into the sound reactive stuff much so I'm not sure if there are seperate libraries for that or if it is already supported in FastLED.
The first library I mentioned in the quote is to enable web server capabilities for ESP. The second and third are for UDP and TCP sync and the fourth is to allow saving onto an ESP chip. These libraries you can completely ignore when porting to rpi.
Unfortunately none of that is true. WLED uses NeoPixelBus, not FastLED. ESPAsyncWebServer is crucial for WLED as it defines what it is. LittleFS would need a replacement FS driver in Arduino architecture. If you do not want external connectivity then you can ignore ESPAsyncTCP and ESPAsyncUDP.
What I meant to say is LedFX not FastLed. Not sure if you would need to replace FS if you're not building it on an Arduino architecture. It's also kind of obvious that WLED runs on a webserver which would be much more easy to expand upon on rpi than an ESP device. There's not just one way to rebuild this for another architecture.
What is LedFX? A separate unrelated program. Yes it can output data WLED will understand. FS access is mandatory for storing configuration and presets. Using Arduino platform wrapper. An finally WLED was written using Arduino platform in PIO, RPi uses it's own platform which is incompatible with Arduino. Of course you can always write from scratch.
@jmerc77 The library you are probably looking for to port WLED to rpi would be FastLED as this is the library to send data to the lights. I also believe that the server is built with NPM then minified after so it can fit on the ESP. I haven't looked into the sound reactive stuff much so I'm not sure if there are seperate libraries for that or if it is already supported in FastLED.
There are more libraries that we need, and that you cannot simply replace with other stuff:
The complete list of what you'll need, in addition to espressif core libraries, is shown when you build WLED:
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (3.5.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
PACKAGES:
- framework-arduinoespressif32 @ 0.0.0+sha.4b0c087
- tool-esptoolpy @ 1.30100.210531 (3.1.0)
- toolchain-xtensa32 @ 2.50200.97 (5.2.0)
Scanning dependencies...
Dependency Graph
|-- FastLED @ 3.5.0
| |-- SPI @ 1.0
|-- IRremoteESP8266 @ 2.8.2
|-- ESPAsyncWebServerAircoookie @ 2.0.7+sha.b9349dc
| |-- AsyncTCP @ 1.2.0+sha.38b8475
| |-- FS @ 1.0
| |-- WiFi @ 1.0
| |-- LittleFS_esp32 @ 1.0.6+sha.820c01e
| | |-- FS @ 1.0
|-- LittleFS_esp32 @ 1.0.6+sha.820c01e
| |-- FS @ 1.0
|-- NeoPixelBus @ 2.6.9
| |-- SPI @ 1.0
|-- AsyncTCP @ 1.2.0+sha.38b8475
|-- Wire @ 1.0.1
|-- SD(esp32) @ 1.0.5
| |-- FS @ 1.0
| |-- SPI @ 1.0
|-- SD_MMC @ 1.0
| |-- FS @ 1.0
|-- SPI @ 1.0
|-- EEPROM @ 1.0.3
|-- ArduinoOTA @ 1.0
| |-- Update @ 1.0
| |-- WiFi @ 1.0
| |-- ESPmDNS @ 1.0
| | |-- WiFi @ 1.0
|-- DNSServer @ 1.1.0
| |-- WiFi @ 1.0
|-- ESPmDNS @ 1.0
| |-- WiFi @ 1.0
|-- WiFi @ 1.0
|-- ESP32 Async UDP @ 1.0.0
|-- WebServer @ 1.0
| |-- WiFi @ 1.0
| |-- FS @ 1.0
Honestly I like your enthusiasm and "sense of wonder" for embedded devices.
You could always start your own fork of WLED, and see how far you get on the device you like most. But as a member of the WLED core team, I can only tell you that this will be a long journey, and the odds for being successful (in reasonable time) are not so great. It might help to first study our source code, and then start shooting ideas ...
The RP2040 has PIO, which supports buffered clocked bitbanging, and easily implements the WS2811 protocol. The SDK contains a WS2811 driver as an example.
The RP2040 has PIO, which supports buffered clocked bitbanging, and easily implements the WS2811 protocol. The SDK contains a WS2811 driver as an example.
We'll be most grateful when you port all libraries to RPI. Perhaps read all of the posts above.
The RP2040 has PIO, which supports buffered clocked bitbanging, and easily implements the WS2811 protocol. The SDK contains a WS2811 driver as an example.
We'll be most grateful when you port all libraries to RPI. Perhaps read all of the posts above.
8 hardware peripherals for WS2811 on a cheap chip is quite attractive, but not for my small installations. I'm using the Pico as a WS2811 test driver, and thinking about making it a USB device so I can run it from Python. We all have our priorities.
FYI ESP32 can theoretically do 2x 24 outputs using I2S + 8 outputs RMT, I've tested 1x 16 outputs with I2S + 8 outputs RMT. HW assisted. On the cheap.
FYI ESP32 can theoretically do 2x 24 outputs using I2S + 8 outputs RMT, I've tested 1x 16 outputs with I2S + 8 outputs RMT. HW assisted. On the cheap.
I tried using someone's FTDI library, which used a synchronous mode to drive WS2812B. It might have worked, but I verified with a scope that the clocking took the timing out of spec. I see no reason to expect I2C would be any better. I'm not interested in the variables added by a kludgy solution. No such problem with the Pico's PIO, because it's bitbanging by HW coprocessor. I'm thinking I could even emulate a WS2811 entirely, which would allow a Pico module to do some very interesting things without additional hardware.
Ok, I'm done geeking out. Ciao.
Hey, will there be support for the Raspberry Pi Pico? Thanks in advance for answering.