Potential fix for detecting idle PIO?

[henrygab]

This may fix the early return from the prior version of the hwled_wait_idle() function?

Need testing / verification.

[DangerousPrototypes]

I am going to test this now.

[DangerousPrototypes]

This is the 1 wire LEDs, you can see the three frames (0xffffff 0x000000 0xaa55aa) are nicely packed to meet spec.

Here is the 2 wire LEDs with this pull request. The frames are spaced out a lot, same as before. This is much faster than the 1wire protocol, but 16uS between frames still seems like a lot to me.

Slowed it down from 5MHz to 800khz and we get the nice tightly packed frames of the 1wire protocol.

Still, sending 32bit frames at 5mhz with nothing but packing in frames seems off to me.

[DangerousPrototypes]

I merged the changes manually after testing.

[DangerousPrototypes]

I reworked the syntax processor to use arrays of functions and removed the switch statements. I thought it was probably one source of the delay between frames. However, look at this. After the start frame there is a sizable delay, but then everything else queues up nicely. This includes data and a stop frame.

Actually it doesn't seem to matter what is first, the first frame has a big delay after it.

None of these functions are using the wait_for_idle at all, that is done at the end of the syntax execution.

[henrygab]

I merged the changes manually after testing.

It sounds like you picked up the changes for the hwled_wait_idle(), so I could delete the branch. At the same time, it sounds like you found an unrelated issue?

Actually it doesn't seem to matter what is first, the first frame has a big delay after it.

If I'm understanding correctly:

1. WS281x (aka 1-wire LEDs, typically 800kHz) are working correctly.
2. APA102 (aka 2-wire LEDs, SK9822, Adafruit Dotstar, etc.) are outputting correct data.
3. However, APA102 has a 10µs-16µs delays after the first frame, where a frame is the single 32-bit value that the PIO program pulls, and which the PIO program then extracts the R/G/B values for. Moreover, it doesn't matter what is contained within that first frame ... the delay still occurs.

Is this approximately correct?

If so, then I will open a new issue referring to this thread, and close this PR.

My first thoughts are to investigate the PIO program, the in/out buffer configuration for the PIO program, etc.

[DangerousPrototypes]

Yes, I will go ahead and close this PR.

I think I may have misled you on a different issue, and then confused your solution with a separate matter in this thread.

I believe you are try to solve:

I added the wait idle before the 50uS delay, but it is not working in here. So maybe the wait idle isn’t working the way I think it is.

Had to increase the reset delay to 100us to get my string of LEDs to cooperate. WS2812 is working. Now to test APA102…

Which was two separate fixes

1. I put the wait for IDLE in the stop frame function instead of the start frame function. They are nearly identical in LED mode and I just updated the wrong function. That was the solution to the first part.
2. I did have to increase the reset delay, but because a precise 50uS delay wasn't enough for any of my LED test strings. >65uS worked on all of them. I put it at 100uS because it seemed safe for all manner cheapo LEDs that are out there.

Partially fixed, but I still don’t like how spaced out the frames are.

I thought your proposed solution was to this persistent issue. I tore apart and reworked the whole syntax compiler to hunt that one down. It was not something I had planned for the near future, but I'm very happy with the result. It didn't fix that between-frame bug. I did note the delay isn't there when pushing only data, it only happens between start frame ([) and whatever comes next. It is really weird.