Update ESP32 RMT driver and managed code to latest API version

[AdrianSoundy]

Description

Currently the RMT code uses the legacy RMT API which is deprecated. This should be updated to the latest APi and include the new features.

• Stop warning error on ESP32 boot for RMT (legacy)
• Add the sync manager feature to synchronize the starting of multiple channels.
• Expose symbol encoder which can be used to speed up C# code or encoder can be called as part of rmt transmit.
• Update managed API to simplify the setting of RMT frequency (no need to know target RMT clock source/rate)
• Other manager API changes if required but try to keep backwards compatibility.

How to solve the problem

Update native and managed RMT code to use latest API.

Describe alternatives you've considered

No response

Aditional context

No response

[AdrianSoundy]

The new API has a number of underlying concept differences that will make C# code not backward compatible.

• The concept of channels has been removed and you now just create a new channel against gpio and it will internally give next available channel.

WIP

[eeegs]

The code that converts the mark to space ratio is very slow, on one board we have, setting the colour of 4 leds (we were using the RMT driver directly not the led library), we could see the led colour changes being applied with about a 1/2 second delay. Investigations found the SerializeCommands to be slow. We changed our code so that as we wrote colours the correct serialised data was being written to memory immediately, so SendData(byte[] data, bool waitTxDone) could be called.

We suspect the use of math '/', '%' (and the branching) and not bit manipulation is the main problem. SerializeCommands could look something like this:

private byte[] SerializeCommands()
{
	int index = 0;
	byte[] array = new byte[_commands.Count * 4];
	for (int i = 0; i < _commands.Count; i++)
	{
		RmtCommand command = _commands[i];

		byte highByte1 = (byte)(command.Duration0 >> 8);
		byte lowByte1 = (byte)(command.Duration0 & 0xFF);
		byte highByte2 = (byte)(command.Duration1 >> 8);
		byte lowByte2 = (byte)(command.Duration1 & 0xFF);
		byte level1 = (byte)(command.Level0 ? 0x80 : 0);
		byte level2 = (byte)(command.Level1 ? 0x80 : 0);

		array[index++] = lowByte1;
		array[index++] = (byte)(highByte1 | level1);
		array[index++] = lowByte2;
		array[index++] = (byte)(highByte2 | level2);
	}
	return array;
}

All the variable assignment is redundant, but the compiler should optimise the code nicely.

[CoryCharlton]

The code that converts the mark to space ratio is very slow, on one board we have, setting the colour of 4 leds (we were using the RMT driver directly not the led library), we could see the led colour changes being applied with about a 1/2 second delay. Investigations found the SerializeCommands to be slow. We changed our code so that as we wrote colours the correct serialised data was being written to memory immediately, so SendData(byte[] data, bool waitTxDone) could be called.

If you're just looking for faster LED control you might want to check out my CCSWE.nanoFramework.NeoPixel library.

It's been a while since I implemented it but I believe there was a reason I didn't backport any of the serialization improvements into the main library. That being said pull requests are always welcome if you have an improvement.

[CoryCharlton]

@eeegs just following up on this that I implemented your change to the RMT library and it's now 50% faster.

[AdrianSoundy]

The next version speeds the serialization even further by putting it into native code.

[CoryCharlton]

The next version speeds the serialization even further by putting it into native code.

Awesome!

I'm assuming TransmitterChannel will still continue to expose SendData(byte[] data, bool waitTxDone)?