3 ms·

This seems like way overcomplicated design - why do they need two CPUs? They claim "real time control", but this doesn't check out: their main CPU, esp8266, has

by theamk 7y ago

This seems like way overcomplicated design - why do they need two CPUs? They claim "real time control", but this doesn't check out: their main CPU, esp8266, has a DMA that can emit stable protocol timings. And the higher level effects don't care about millisecond or ten of jitter. I am running two such simple strips right now, and it works very well.

leggomylibro 7y ago
ESP8266s aren't very pleasant to work with, and in my experience it can be hard to accomplish much in program logic while keeping the WiFi stable. But the cottage industry around these addressable LED driver boards is getting pretty ridiculous. The PixelBlaze already does a great job of controlling them from an ESP8266. And the LEDs aren't that hard to use with generic hardware like Arduinos, even for people with zero prior experience. There's no doubt about it, this world caters to the hucksters and the unrealistically optimistic.
- jeffhuys 7y ago
  Regarding "in my experience it can be hard to accomplish much in program logic while keeping the WiFi stable". I've had the same; sorting a big list of numbers or doing any action that takes a few seconds can make the WiFi unstable, disconnect, or not respond. I'm curious though, there are some dual-core designs with ESP8266 compatibility out there, would that help?
  - fit2rule 7y ago
    I have no problem using coroutines to keep Wifi working fluidly on ESP8266. This just requires attention, its not too difficult to keep the ESP8266 pumping data.
- fit2rule 7y ago
  Genuinely curious what you find unpleasant about the ESP8266 to work with?
  - readmodifywrite 7y ago
    From my experience, and this is compared with AVR and most ARM parts I've worked with. 1) Generally poor documentation. Non-existent at the register level - you are entirely at the mercy of the SDK and what other people have reverse engineered. 2) Crashes on unaligned pointer access. This is something that ARM generally handles with ease (though there are exceptions). Porting code from ARM or 8 bit machines to the ESP8266 can take a fair amount of effort in tracking down all of the unaligned access exceptions that come up. It's extremely frustrating. 3) To that point, the SPI flash access is also beholden to 32 bit alignment. That really complicates things if you port code that relied on a typical SPI flash's ability to access at a 1 byte granularity. 4) Poor compiler support. I think the latest GCC they support is 5.something. It requires a custom backend so it is vendor maintained. Contrast with ARM support in GCC which is generally outstanding. 5) No hardware debug support. You can run GDB over a serial port, but that's no where near as powerful as having an actual JTAG/SWD port. 6) The program memory architecture is complex and difficult to use (poor documentation is part of the issue here). There's no on-chip flash - code streams from a SPI flash into a RAM cache. Some code has to run out of RAM and must be placed by the linker as such. All that being said - the chip works. The Wifi is excellent (I run dozens of these at a time, they are more reliable than my Unifi routers they connect to). For a $2 FCC certified module it's unbeatable. I have really come around to like this part in spite of its many flaws - it was built to do one thing very well at a price point no one else could touch - and by and large it succeeded.
    - fit2rule 7y ago
      I have run into a few of these, I do have to admit, but I don't find any of these to be show-stoppers, necessarily .. like you I like the ES-series, in spite of the flaws. It's comfortable, once you move in. One last question, platform.io? Pretty good ecosystem in general - and with the wide variety of assets to select from, a lot of your points become less painful ..
readmodifywrite 7y ago
Hi there! Project creator here. Hindsight is 20/20 - the dual CPU design did prove to be overly complex. It does in actuality work quite well, but it was extremely difficult to implement and it's a lot of extra parts for features that turned out to be less useful than anticipated. There's some major reasons why I designed it that way at the time though: 1) I already had an OS that ran on the AVR, and didn't want to spend the effort porting it entirely to the ESP8266. That being said, I've since mostly ported it over anyway. The ESP8266 is indeed wayyyy harder to use than an AVR. But, as it turns out, not harder than dealing with two extremely dissimilar CPUs. 2) The ESP8266 doesn't have great I/O. In particular, I wanted to run PWM LED strips and the AVR allowed me to do that (the LED driver circuit can run PWM or digital output on the same pins). However, I realized pretty quick after selling a few of them that nobody else cared about PWM and not long after that, neither did I. Only a handful of my projects still use the PWM circuit. 3) The AVR has a much, much better DMA than the ESP8266. There's a fast LED style dithering feature available for some LED strips, and the Xmega DMA is what made it possible to do that. Yet another feature than turned out to be less useful than I'd thought - most strips I use clock too slowly to dither anyway. 4) It also has more analog I/O, which I use in my own projects, but probably no one else does.
BoorishBears 7y ago
ESP32 has the RMT peripheral which is very well matched to manipulating LED strips: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/rmt.html https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...

by theamk 7y ago

leggomylibro 7y ago

ESP8266s aren't very pleasant to work with, and in my experience it can be hard to accomplish much in program logic while keeping the WiFi stable. But the cottage industry around these addressable LED driver boards is getting pretty ridiculous. The PixelBlaze already does a great job of controlling them from an ESP8266. And the LEDs aren't that hard to use with generic hardware like Arduinos, even for people with zero prior experience. There's no doubt about it, this world caters to the hucksters and the unrealistically optimistic.

jeffhuys 7y ago
Regarding "in my experience it can be hard to accomplish much in program logic while keeping the WiFi stable". I've had the same; sorting a big list of numbers or doing any action that takes a few seconds can make the WiFi unstable, disconnect, or not respond. I'm curious though, there are some dual-core designs with ESP8266 compatibility out there, would that help?
- fit2rule 7y ago
  I have no problem using coroutines to keep Wifi working fluidly on ESP8266. This just requires attention, its not too difficult to keep the ESP8266 pumping data.
fit2rule 7y ago
Genuinely curious what you find unpleasant about the ESP8266 to work with?
- readmodifywrite 7y ago
  From my experience, and this is compared with AVR and most ARM parts I've worked with. 1) Generally poor documentation. Non-existent at the register level - you are entirely at the mercy of the SDK and what other people have reverse engineered. 2) Crashes on unaligned pointer access. This is something that ARM generally handles with ease (though there are exceptions). Porting code from ARM or 8 bit machines to the ESP8266 can take a fair amount of effort in tracking down all of the unaligned access exceptions that come up. It's extremely frustrating. 3) To that point, the SPI flash access is also beholden to 32 bit alignment. That really complicates things if you port code that relied on a typical SPI flash's ability to access at a 1 byte granularity. 4) Poor compiler support. I think the latest GCC they support is 5.something. It requires a custom backend so it is vendor maintained. Contrast with ARM support in GCC which is generally outstanding. 5) No hardware debug support. You can run GDB over a serial port, but that's no where near as powerful as having an actual JTAG/SWD port. 6) The program memory architecture is complex and difficult to use (poor documentation is part of the issue here). There's no on-chip flash - code streams from a SPI flash into a RAM cache. Some code has to run out of RAM and must be placed by the linker as such. All that being said - the chip works. The Wifi is excellent (I run dozens of these at a time, they are more reliable than my Unifi routers they connect to). For a $2 FCC certified module it's unbeatable. I have really come around to like this part in spite of its many flaws - it was built to do one thing very well at a price point no one else could touch - and by and large it succeeded.
  - fit2rule 7y ago
    I have run into a few of these, I do have to admit, but I don't find any of these to be show-stoppers, necessarily .. like you I like the ES-series, in spite of the flaws. It's comfortable, once you move in. One last question, platform.io? Pretty good ecosystem in general - and with the wide variety of assets to select from, a lot of your points become less painful ..

readmodifywrite 7y ago

Hi there! Project creator here. Hindsight is 20/20 - the dual CPU design did prove to be overly complex. It does in actuality work quite well, but it was extremely difficult to implement and it's a lot of extra parts for features that turned out to be less useful than anticipated. There's some major reasons why I designed it that way at the time though: 1) I already had an OS that ran on the AVR, and didn't want to spend the effort porting it entirely to the ESP8266. That being said, I've since mostly ported it over anyway. The ESP8266 is indeed wayyyy harder to use than an AVR. But, as it turns out, not harder than dealing with two extremely dissimilar CPUs. 2) The ESP8266 doesn't have great I/O. In particular, I wanted to run PWM LED strips and the AVR allowed me to do that (the LED driver circuit can run PWM or digital output on the same pins). However, I realized pretty quick after selling a few of them that nobody else cared about PWM and not long after that, neither did I. Only a handful of my projects still use the PWM circuit. 3) The AVR has a much, much better DMA than the ESP8266. There's a fast LED style dithering feature available for some LED strips, and the Xmega DMA is what made it possible to do that. Yet another feature than turned out to be less useful than I'd thought - most strips I use clock too slowly to dither anyway. 4) It also has more analog I/O, which I use in my own projects, but probably no one else does.

BoorishBears 7y ago

ESP32 has the RMT peripheral which is very well matched to manipulating LED strips: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/rmt.html https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...