Updated TeensyDMX library for Teensy 4

[shawn]

I've updated the TeensyDMX library to support Teensy 4.

For now, please see the `teensy4` branch at: https://github.com/ssilverman/TeensyDMX/tree/teensy4
I'll be merging it into the master branch once it's settled. It's a little bit ahead of 4.0.0-alpha.2.

Note that it has some extra features and a few minor differences from the 3.x.x versions. Also note that this branch still supports all the Teensys 3 and later: 3.1, 3.2, 3.5, 3.6, LC, and 4.0.

Comments and suggestions welcome.

[shawn]

There's a good chance that the latest release, v4.0.0-alpha.6, is the last alpha release before I merge in the Teensy 4 support ("squashed", of course). I'm pretty happy with the new features and "workingness". Of course, now that I've said that, it's not going to work for some people...

Note that Teensy 4 support can be found in the `teensy4` branch. It's up to date with the `master` branch, just with Teensy 4 support.

After one alpha release with Teensy 4 support, I'll then move into beta, and then a final release. Lots has changed and improved. Check it out, all you DMX-loving makers out there. I'd love your comments.

The links:

• https://github.com/ssilverman/TeensyDMX
• https://github.com/ssilverman/TeensyDMX/tree/teensy4

[shawn]

I've released a beta version. Any questions, suggestions, and feedback welcome.

The link: https://github.com/ssilverman/TeensyDMX

[shawn]

I added Serial8 support for Teensy 4.1 in this branch: https://github.com/ssilverman/Teensy...ensy41-serial8

I'm going to let it marinate before committing to the main branch.

[shawn]

I just drafted a new release, v4.1.0-beta. It contains some major code changes where much of the #define-based code was replaced with code that's much more maintainable. If those that use the library feel like trying it out to see if I broke anything, that would be amazing, and would add more confidence to my theory of its correctness.

[Chendy]

Hello Shawn,

Thank you for your work on this library.

I was playing with your v4.1.0-beta trying to get Transmit and Receive to work simultaneously.
I want to 'intercept' DMX: receive some DMX, change some values, then send it back on its way.

I am using a Teensy 4.
To debug this issue, I'm directly connecting the Tx pin of the transmitter to the Rx pin of the receiver, on the Teensy 4.
- Tx: Serial2 so TX2 pin 8
- Rx: Serial1 so RX1 pin 0

I have wired these pins directly together, not via a pair of RS485 transceivers, to help debug.
I have also setup a logic analyser with DMX protocol decoder to monitor the signal.

#include <TeensyDMX.h>

namespace teensydmx = ::qindesign::teensydmx;

teensydmx::Receiver dmxRx{Serial1};
teensydmx::Sender dmxTx{Serial2};

// Example 1
// uint8_t lastValue = 0;

void setup() {
  dmxRx.begin();

  // DEBUGING
  Serial3.begin(115200);

  dmxTx.begin();
  for (uint8_t i=0; i<128;++i){
    dmxTx.set(i, 0);
  }
  dmxTx.set(1, 10);  
}

void loop() {
  
  // This will return zero for no data (and also for data that's zero)
  /*uint8_t v = dmxRx.get(1);
  if (v != lastValue) {
    lastValue = v;
    Serial3.println(v, DEC);
  }*/
}

The problem is, as is the Sender doesn't generate any DMX signal if the code is like above. Constant 0V output.
But if I comment out

 dmxRx.begin();

The DMX is correctly output.

Do you know of any working reference code that does can receive then send 'simultaneously'?

Thanks again

[shawn]

Hi, Chendy. Thanks for using the software. I was testing with a Teensy 4 today and it looks like receive is broken (well, at least for Serial3). I thought my latest change that altered the structure kept things the same (yes, I tested, not sure how I missed this), because TeensyDMX v4.0.0 seems to work fine. But something I did changed something, and I haven’t found what that is yet. It’s one of those “but it’s the same code and it should work the same” problems. I’m not sure when I’ll solve this, hopefully it’s soon.

[Chendy]

Hey Shawn,

Thanks for the response!

"TeensyDMX v4.0.0 seems to work fine"
So TeensyDMX v4.0.0 version should/might work with Teensy 4? If so, I'll get testing!

Cheers

[shawn]

I'm still working at it. I'm having some trouble figuring out what's different between v4.0.0 and v4.1.0-beta in terms of what gets executed in the serial IRQ. The only thing that I can see thus far is that I'm calling a virtual function inside the IRQ handler instead of just executing some code. The serial port gets initialized in the same way and the IRQ is processed in the same way.

[In Chrome, editing a post appears to delete it. That's weird. That's why multiple posts keep appearing. I want to edit, but instead it gets deleted. Trying Safari now.]

[defragster]

...
[In Chrome, editing a post appears to delete it. That's weird. That's why multiple posts keep appearing. I want to edit, but instead it gets deleted. Trying Safari now.]

Odd things happen at times - I've had doubled posts - but never deleted

That is also Odd because the New MSFT EDGE uses the chrome engine now and works fine - I've not ever used chrome itself though

[shawn]

I believe I've found the problem. @Chendy, would you mind trying out the new 4.1.0-beta.1 release?

The changes in this release:

1. Detection for packets that are too long
2. This fix
3. Some README updates:
   
   1. Added a table of contents
   2. New "Error statistics" section
   3. Details about too-long packets

I'll give the answer in a future post, but the following line was the problem. Can any LPUART aficionados spot the issue?

uint8_t status = port_->STAT;

[Chendy]

Hello Shawn,

You star!

BTW I tested the 4.0.0 and it seemed to work fine.
I'll test the 4.1.0-beta.1 release hopefully over the weekend, if not early next week.

Cheers

[shawn]

The answer to the challenge is that STAT is a 32-bit register. Changing to uint32_t fixed the problem.

[Chendy]

Great news Shawn. Ps I got super swamped with various work, but will test these amendments.

[shawn]

I’m also about to release a new version that’s more interoperable with those libraries that use IntervalTimer.

[shawn]

Released TeensyDMX v4.1.0-beta.2 with a few fixes: https://github.com/ssilverman/Teensy.../v4.1.0-beta.2

The changes:

• Fixed NativeEthernet interoperability by changing from a custom use of the PIT timers to use of the IntervalTimer API. This means that BREAK timing (when using a timer and not the serial parameters) will be a little less accurate. (For those curious, there's no way, using IntervalTimer, to call a function immediately before the timer starts; calling after a successful `begin` can lose up to a few microseconds. I'm now using emipirically-measured fudge factors; I was already doing this for the MAB.)
• Fixed setting the serial parameters when sending the BREAK/MAB times using serial parameters having a parity bit.
• Added a way to use serial parameters instead of a timer to generate BREAK/MAB timing. This is the new default.
• Added a new USBProWidget example. I'd love some feedback on this.

[shawn]

I just released TeensyDMX v4.1.0: https://github.com/ssilverman/Teensy...ses/tag/v4.1.0

Changes since v4.1.0-beta.2:

• 7- and 9-bit format support when using serial parameters to accomplish BREAK and MAB timings.
• USBProWidget example updates and fixes.
• A few other fixes and improvements.

[TexasHeat]

Thank you!!