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

Thread: Teensy 4.0 with OctoWS2811

  1. #1

    Teensy 4.0 with OctoWS2811

    I'm using Arduino 1.8.11 / Teensyduino 1.50 with the Teensy 4.0 / OctoWS2811 Adapter Board. When I run the BasicTest I get the following error:

    Code:
    /Applications/Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/OctoWS2811/OctoWS2811.cpp: In member function 'void OctoWS2811::begin()':
    /Applications/Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/OctoWS2811/OctoWS2811.cpp:94:2: error: 'GPIOD_PCOR' was not declared in this scope
      GPIOD_PCOR = 0xFF;
      ^
    /Applications/Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/OctoWS2811/OctoWS2811.cpp:177:19: error: 'GPIOD_PSOR' was not declared in this scope
      dma1.destination(GPIOD_PSOR);
                       ^
    /Applications/Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/OctoWS2811/OctoWS2811.cpp:184:19: error: 'GPIOD_PDOR' was not declared in this scope
      dma2.destination(GPIOD_PDOR);
                       ^
    Error compiling for board Teensy 4.0.
    It looks like the OctoWS2811 library isn't currently supported by Teensy 4.0, is there a known workaround or plan to support OctoWS2811 in the future?

  2. #2
    Junior Member
    Join Date
    Oct 2013
    Posts
    13
    Have the same issue myself. Did you figure anything out?

  3. #3
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,624
    I was curious, so I thought I would take a quick look,

    Looks like this one would be a bit of a challenge and it is not something I have or use... Actually I think I did buy one in my last PJRC purchase, but...

    Some of the challenges associated with this include:
    The board is setup to use pins: 2, 14, 7, 8, 6, 20, 21, 5 on the T3.x (and LC) which maps to Port pins D0-D7 on T3.6/3.5 (did not look at others, but assume on same Port pins 0-7)

    Problem(s) with T4: These pins are not on the same port nor are there any 8 pins that are consecutive bits on the same port, nor does the T4 have 8 bit access to IO ports (access is 32 bits).
    These 8 pins are spread out like4.4, 1.18, 2.17, 2.16, 2.10, 1.17, 1.16, 4.8)

    So I don't see any obvious way to translate the DMA operations used in this library over to something that would work on T4.
    My guess is it would take a sort of rethink... For example if one has 8 pins on the same IO buss, could this could be setup to do DMA not to the Data register but only use the SET/CLEAR registers... Or if 8 pins were all on the same FLEX IO controller, could we setup to do this.. Note: would probably need to be FLexIO 1 or 2 as 3 does not have DMA...

    So sorry, I don't think I am much help here, probably needs someone like Paul who set this up originally.

  4. #4
    It might not help you specifically since it isn't compatible with OctoWS2811, but Ward demonstrated a way to drive WS2811 strips using the FlexIO and some external shift registers:
    https://forum.pjrc.com/threads/59023...FlexIO-and-DMA

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,814
    I've committed code on github for OctoWS2811 on Teensy 4.0.

    https://github.com/PaulStoffregen/Oc...bf0a2d4c607f13

    This will be in Teensyduino 1.52, which will begin beta testing next week.

  6. #6
    Awesome! Can you share a little about your method to provide output on an arbitrary set of 8 pins?

    It looks like you set up DMA to transfer 32 bits to each of GPIO1, GPIO2, GPIO3, and GPIO4 in sequence (as opposed to the T3 code which transfered 8 bits to a single GPIO) - is that correct?

  7. #7
    Junior Member
    Join Date
    Sep 2015
    Posts
    19
    Thanks! I was waiting for this! Directly upgraded two of the LED walls you can see in the video which were using OctoWS2811 on a T3.6 to a T4.0 and the increase in performance makes the animation run way smoother! It went from varying around 40 fps to maxing out at 140 fps (the limit for the amount of leds/strip I'm using). Thank you so much!
    https://youtu.be/cdfFI6miXMU

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,814
    Thanks for sharing. Would it be ok to give this unlisted video a shout-out on social media?

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,814
    Quote Originally Posted by easone View Post
    It looks like you set up DMA to transfer 32 bits to each of GPIO1, GPIO2, GPIO3, and GPIO4 in sequence (as opposed to the T3 code which transfered 8 bits to a single GPIO) - is that correct?
    Yes, that's exactly how it works.

    Because the data expanded to 128 bits is so large, it's generated on-the-fly into a pair of buffers. DMA scatter-gather is used to seamlessly transition between using each buffer.

  10. #10
    Junior Member
    Join Date
    Sep 2015
    Posts
    19
    Quote Originally Posted by PaulStoffregen View Post
    Thanks for sharing. Would it be ok to give this unlisted video a shout-out on social media?
    Yes, please go ahead

  11. #11
    Junior Member
    Join Date
    Oct 2013
    Posts
    13
    Quote Originally Posted by PaulStoffregen View Post
    I've committed code on github for OctoWS2811 on Teensy 4.0.

    https://github.com/PaulStoffregen/Oc...bf0a2d4c607f13

    This will be in Teensyduino 1.52, which will begin beta testing next week.
    Im trying to use this with a bno080 over i2c but what happens is, the frame-rate drops for a while then the sensor doesn't return readings anymore. If I don't call leds.show(), the sensor works normally. Could this library interfere with i2c in some way?
    I also tried using bno055 on i2c and a different thing happens, works fine for a while then the frame-rate drops and doesn't recover. The sensor still returns values though.

    These are the pins I'm using: uint8_t pinList[] = {34, 36 , 28 , 38, 31, 39, 35, 37};

    Using bno080 on spi works ok but its not an option for us because of the distance to the sensor. We are making a dress covered in about 3200 leds, and the IMUs are supposed to be in the hands.

    Any ideas how I should debug this?

  12. #12
    Junior Member
    Join Date
    Oct 2013
    Posts
    13
    After looking a bit more this is what i found so far.

    Using the debug feature of the bno080 library I get:

    Received: Header: 12 00 05 64 Body: E3 22 0E 01 AC 00 A3 35 00 00 00 00 00 00 Length:18 Channel:Gyro-vector
    Received: Header: 12 00 05 66 Body: E3 22 0E 01 AC 00 A3 35 00 00 00 00 00 00 Length:18 Channel:Gyro-vector
    Received: Header: 12 00 05 68 Body: E3 22 0E 01 AC 00 A3 35 00 00 00 00 00 00 Length:18 Channel:Gyro-vecto
    Received: Header: 12 00 05 6A Body: FF FF FF FF FF FF FF FF FF FF FF FF FF FF Length:18 Channel:Gyro-vector <- this seems to be where the problem starts
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    Received: Header: 14 01 00 00 Body: 00 01 04 00 00 00 00 80 06 31 2E 30 2E 30 00 02 Length:276 Channel:Command <- still figuring out
    Received: Header: 14 00 02 00 Body: F1 00 84 00 00 00 01 00 00 00 00 00 00 00 00 00 Length:20 Channel:Control <- what these two mean
    Received: Header: 05 00 01 00 Body: 01 Length:5 Channel:Executable <- this means the sensor reset itself


    The library first reads four bytes to get the header and figure out how many bytes are coming then reads the rest in a separate read. In the packet where the problem starts this second read seems to fail for some reason.

  13. #13
    Junior Member
    Join Date
    Oct 2013
    Posts
    13
    I don't know how to really interpret this but it seems the library somehow borks i2c.

    Another debug trace:

    Received: Header: 12 00 05 BA Body: 4B 10 FF 02 D0 00 D0 3D 00 00 00 00 00 00 Length:18 Channel:Gyro-vector
    Received: Header: 12 00 05 BC Body: 4B 10 FF 02 FF FF FF FF FF FF FF FF FF FF Length:18 Channel:Gyro-vector <- sh*t hits the fan
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout
    I2C timeout everything below here just means the sensor reset itself and is sending another 'hello im here, this is who i am'
    Received: Header: 14 01 00 00 Body: 00 01 04 00 00 00 00 80 06 31 2E 30 2E 30 00 02 Length:276 Channel:Command
    Received: Header: 14 00 02 00 Body: F1 00 84 00 00 00 01 00 00 00 00 00 00 00 00 00 Length:20 Channel:Control
    Received: Header: 05 00 01 00 Body: 01 Length:5 Channel:Executable


    Click image for larger version. 

Name:	Screenshot 2020-05-20 at 14.37.51.jpg 
Views:	6 
Size:	23.4 KB 
ID:	20205

    The image shows a logic analyser trace at the point it all borks.

  14. #14
    Junior Member
    Join Date
    Oct 2013
    Posts
    13
    Tried using teensy4_i2c instead of Wire but it also fails and reports a timeout. :/

  15. #15
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,814
    Can you try it with all the LEDs disconnected, so Teensy does all the same things but no LEDs actually receive the data. The idea is to check whether their massive changes in power consumption are somehow interfering? Spending a lot of time on the software side would be a shame if the problem is due to power.

  16. #16
    Junior Member
    Join Date
    Oct 2013
    Posts
    13
    Hey Paul, yes I tried doing that early on. Actually as I'm trying to debug this I only have the control box and nothing but the IMU connected. The only thing that helps is not calling leds.show(). Without that call the IMU works for hours (left it over night), with the call, i2c freezes (teensy stops clocking) in less than 10 seconds. I pretty much tried everything I know to find out what is going on. Debugging OctoWS2811 is WAY over my head.

Posting Permissions

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