Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Teensy 4.0 Leading option for Smart LEDs with I2SWS2811??

  1. #1
    Senior Member crees's Avatar
    Join Date
    Dec 2016
    Location
    Utah
    Posts
    214

    Teensy 4.0 Leading option for Smart LEDs with I2SWS2811??

    Teensy 3.2 is where I started being serious with smart LEDS using the OCTOWS2811. This platform has been very rewarding and for me has advanced to a nice solution providing up to 43,520 Pixels of control creatively combining multiple chips in one ecosystem!

    With Teensy 4.0 at my doorstep I can't help but think this new platform should continue being a leader in LED control in DIY and professional projects. As I am aware the DMA to direct IO methods of octows2811 were not able to be ported to the new platform for justifiable reasons. Will Octows2811 ever be ported to teensy 4? I don't think so... (Flex IO anyone??) but is it worth it? The question should be is there a better way to drive numerous LEDs from Teensy 4 than to go down the octows2811 T4 rabbit hole? The WS2811 non blocking Serial method is certainty an option but for large scale projects it may not be up to the challenge. FastLED also has support for teensy 4 allowing multiple pins in parallel to be used and is also an option but does not take advantage of any DMA methods (for me it does matter). For most the FastLED and Non blocking Serial should be sufficient and satisfy the creators. But what if you want to push the teensy 4 to large scale LED installs with the possibility of efficient DMA and multiple pins in parallel?

    I am looking at building upon Yves-bazin FastLED approach by using one I2S to drive 8 parallel outputs using a shift register and a carefully clocked output. With Teensy 4 having the ability to provide 2 i2s this could potentially be 16 Pins of extremely efficient high FPS pixel output. Perhaps FlexIO could provide more I2S? The part that I am looking at is possibly driving this from DMA to help free up CPU for tasks like populating buffers and lookup tables by handle incoming LED data from sources such as W5500 (artnet, sACN) or a more developed Ethernet MAC. One challenge to our 3.2 platform is running W5500 in MacRaw mode. We found that If you want to utilize multicast then MACRAW is the only way to go. however it comes at a cost of CPU overhead and what better CPU to handle this than the Teensy 4 CPU!

    Currently Yves-bazin has done phenomenal work on I2S for driving high amounts of LED's. Some here are aware of Yves-bazin LED accomplishments in the FastLED group. I did come across another teensy user getting Yves method to work on I2S teensy but understandably it was affecting the audio in the project as well. So this solution may not be the best for all but should be a viable one. Just wanted reiterate (if this has been brought up already) this approach and get some feedback.

    Thoughts? Concerns?

    Perhaps this should be called I2SmartLED library??

    crees
    Last edited by crees; 12-31-2019 at 12:04 AM.

  2. #2
    Junior Member
    Join Date
    Feb 2016
    Posts
    5
    Hey Crees, I'm also super interested in using the T4 as a platform for driving large scale LED projects, especially with the prospect of getting fast USB Ethernet at 20+ Mbyte/sec going to shovel plenty of data to multiple arduinos. Have you looked more into it in the meantime?

  3. #3
    Senior Member crees's Avatar
    Join Date
    Dec 2016
    Location
    Utah
    Posts
    214
    Yes! another teensy veteran “ward” was able to manipulate the flex IO with pretty awesome results! Basically a similar approach using shift registers.

    https://forum.pjrc.com/threads/59023...FlexIO-and-DMA

    One interesting thing to consider is the need for higher bit resolution for the pixels that may be similar but different timings. With world semi having a history of slightly changing timings with every major release it may be worth looking at driving more bits to generate more precise clockless signals. The cost to this approach is dropping the pin count. Unless the flex IO can clock faster to accommodate the extra bits the only thing I can think of is to reduce the pins outputs from 32 to 16 and increase the bit resolution. Of course this is assumptions from my mind. I may be overlooking or thinking this approach.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •