Add DSHOT support

[Linjieqiang]

Port from betaflight.

[oleost]

Any reason for closing this?

Dshot is more than just raw performance.
It gives to possibility in future to use motor as buzzers, etc etc.

Should be on the to do list for INAV.

[Linjieqiang]

But I see DE is besy to deal with other problems so I choosed to close it.But I love to see dShot will be implemented in INAV project

[fiam]

I'm moving this issue to 2.0, since there seems no interest in implementing DSHOT soon. PRs for it are welcome at any time though.

[Azuxul]

Dshot implementation is important for BLheli32, without dshot we need to change throttle value and i dosen't found how to calibrate esc after. So for using inav with BLheli32 esc dshot is important.

[Jeeper10A]

Is Dshot in the works? I have a Matek f7 board and decided on betaflight or Inav. INAV will be my first choice but only if Dshot is implemented,

[Azuxul]

Currently Dshot doesn't work.

[Blaster1920]

Any update on dshot1200 ?

[Jhinta]

+1 waiting for dshot

[strepto42]

+1 please, it's 2018 now. DSHOT is not only really useful, it's not even new tech now

[NeilGaede]

+1

[digitalentity]

I see a lot of requests to add DHOT. Anybody want to have a crack at it?

[turboworks]

You gave me all the servos, thank You very much, please+1 DSHOT me as well...https://youtu.be/koOqenMpvck

[avrahams]

+1 and also esc telemetry

[digitalentity]

Will look into DSHOT after we get 2.0 out of the door

[teckel12]

I wouldn't use DSHOT even it it was implemented, so I've got no motivation to add support. I feel there's too much potential risk with no gain over other more stable and tolerant protocols. But, there's a difference between a racing drone and a GPS navigation craft.

[digitalentity]

DSHOT support is more a marketing move than a real added value. For racing quads it might be worth it (although I doubt the real effect on flight performance would be different from effect of a placebo).

For bigger machines it will definitely do more harm than good since it's much more succeptible for poor wiring quality and EMI noise.

[strepto42]

I have to disagree. Dshot eliminates the need to calibrate escs and provides a much more fault tolerant protocol for control. Poor wiring and so on will actually affect non-dshot quads more. My long range rig suffers from motor twitch badly using one shot, but flies perfectly using Dshot (which is why I switched it back to betaflight). I have great respect for contributors to open source and this project in particular but seriously, get with the program guys. Digital > analogue

[owengrey]

On the wire DSHOT is analog. CRC checking masks issues by discarding corrupt packets and what is observed as "motor twitching" with OS125 with DSHOT will result in spontaneous stop of one motor at some point once too many packets are discarded.

This statement cant be true! you are mixing an analog answer mixed with a digital answer, It cant be both.... CRC checking cant be used with an analog signal.

When I get more time I will look into this as well.
I am a research and developement engineer and have been designing industrial embedded controllers for many years. All software can be improved and that goes for communications between items also.

[teckel12]

@owengrey On the wire it's analog, but it's converted to a digital signal on the ends, which then does the CRC check. This is a quite common "digital" communication technique.

[digitalentity]

We live in an analog world. There is no such thing as "digital signal", only "digital data" and "digital transmission" which means that binary data entering the transmitter is identical to binary data leaving the receiver. Even two logic elements connected by a simple wire operate voltage levels which they interpret as binary "1" and "0".

Same for DSHOT - it's a modulation technique to transmit a digital packet over analog wire. One largest drawback of digital transmission - it's usually all or nothing - communication works flawlessly even at very high levels of distortion. Beyond that it doesn't work at all.

[RCnator]

Pardon my lack of knowledge regarding IT etc but I hear about this timer and digitalentity wrote that he will "add a timer DMA framework after we release 2.0 (similar to what is there in Betaflight) - it will make adding dshot easier". What does that mean? Will we have dshot with 2.0.1 or will it be som kind of add on to 2.0?

[digitalentity]

@RCnator this means precisely what it means - another step of timer code refactoring in the development branch after release 2.0 goes public. It will make effort to add DSHOT easier but I have no idea when we'll have DSHOT implemented. Most likely next version, but no guarantees.

[digitalentity]

Ok, 2.0.0 almost out of the door. Time to start looking into DSHOT 😄

[teckel12]

@digitalentity Please reconsider. Imagine the users we'll have if INAV includes DSHOT. 😵

[digitalentity]

I'm ok with closing "motors stopped in air" issues if reporter is using DSHOT 😈

[teckel12]

Braces for DSHOT, the next SBUS disarm bug of 2018. Only difference is this time there's no fixing it.

[TwoToneEddy]

@digitalentity I'd love to look into this once the timer has been implemented. I'm literally moving house this weekend though so please don't wait for me if there's some urgency to get it in there for the next release. I know allot of pilots who will be thrilled at the addition of D-shot.

[digitalentity]

@TwoToneEddy I've started on TIM/DMA framework in #3833 (work in progress). Adding DSHOT on top of that should be fairly simple.

[digitalentity]

Also: I want DSHOT to be only available on targets where ALL motor outputs can support it. Otherwise firmware should automatically fallback to i.e. OS125. All DSHOT-related stuff should be guarded with define USE_DSHOT.

[digitalentity]

@teckel12 yes, we'll definitely see increase in bugreports. We'll figure out DSHOT policy once we have some statistics.

[davidngrc]

can't wait to test this, the next step will be esc telemetry, LOL

[wx4cb]

Any news on dshot support?

[teckel12]

@wx4cb TwoToneEddy said he was planning on adding this once the timing stuff was added, which it has been. I'd ask TTE of the status.

[TwoToneEddy]

I fully intend to look into this but I've just moved house and don't even have an internet connection. Happy to do it but it won't be for a few weeks.

[teckel12]

@TwoToneEddy You're doing it wrong. When I move, I get the Internet before anything. 😁

[TwoToneEddy]

@teckel12 Don't get me wrong, I fuming I don't have the internet yet, how am I supposed to make a cup of coffee

[turboworks]

dial-up?

[digitalentity]

No internet is really annoying. When I moved I got Internet even before the bed, table and microwave 😆

On topic: timer refactoring is in progress and I do it with DSHOT in mind - so adding DSHOT would be quite trivial.

Have a look at LEDSTRIP driver built on top of new timer framework https://github.com/iNavFlight/inav/blob/5ace4e6e59c3600bbe45dbd8ea9bf2ef1e17477a/src/main/drivers/light_ws2811strip.c - that's the complete driver, all low level hardware ops are done in timer code. DSHOT is very similar to LEDSTRIP protocol so implementation wouldn't be too different.

[digitalentity]

F7 implementation is clumsy and not tested yet. I kind of miss elegacy of ST's StdLib - HAL is true monstrosity. HAL_LL is much nicer, however amount of work to rewrite everything is huge (but eventually I might consider doing it anyway).

[teckel12]

These days, the Internet comes before food, clothing and shelter, because what's the point without the Internet?

[digitalentity]

Initial cut of DSHOT implementation - #3879

[digitalentity]

As I said - on new timer framework implementation is trivial

[TwoToneEddy]

So you've done it already! That was quick! Sorry I couldn't pull my finger out in time, once I'm up and running I really hope I can contribute.

[digitalentity]

@TwoToneEddy yep, new timer framework made it so trivial that I decided to go for it. Basically these ~140 lines of code are DSHOT protocol:

inav/src/main/drivers/pwm_output.c

Lines 196 to 299 in 51dff7c

	#ifdef USE_DSHOT
	uint32_t getDshotHz(motorPwmProtocolTypes_e pwmProtocolType)
	{
	switch (pwmProtocolType) {
	case(PWM_TYPE_DSHOT1200):
	return MOTOR_DSHOT1200_HZ;
	case(PWM_TYPE_DSHOT600):
	return MOTOR_DSHOT600_HZ;
	case(PWM_TYPE_DSHOT300):
	return MOTOR_DSHOT300_HZ;
	default:
	case(PWM_TYPE_DSHOT150):
	return MOTOR_DSHOT150_HZ;
	}
	}
	static pwmOutputPort_t * motorConfigDshot(const timerHardware_t * timerHardware, motorPwmProtocolTypes_e proto, uint16_t motorPwmRateHz, bool enableOutput)
	{
	// Try allocating new port
	pwmOutputPort_t * port = pwmOutConfigMotor(timerHardware, getDshotHz(proto), DSHOT_MOTOR_BITLENGTH, 0, enableOutput);
	if (!port) {
	return NULL;
	}
	// Keep track of motor update interval
	const timeUs_t motorIntervalUs = 1000000 / motorPwmRateHz;
	dshotMotorUpdateIntervalUs = MAX(dshotMotorUpdateIntervalUs, motorIntervalUs);
	// Configure timer DMA
	if (timerPWMConfigChannelDMA(port->tch, port->dmaBuffer, DSHOT_DMA_BUFFER_SIZE)) {
	// Only mark as DSHOT channel if DMA was set successfully
	port->configured = true;
	}
	return port;
	}
	static void pwmWriteDshot(uint8_t index, uint16_t value)
	{
	// DMA operation might still be running. Cache value for future use
	motors[index]->value = value;
	}
	static void loadDmaBufferDshot(uint32_t * dmaBuffer, uint16_t packet)
	{
	for (int i = 0; i < 16; i++) {
	dmaBuffer[i] = (packet & 0x8000) ? DSHOT_MOTOR_BIT_1 : DSHOT_MOTOR_BIT_0; // MSB first
	packet <<= 1;
	}
	}
	static uint16_t prepareDshotPacket(const uint16_t value, bool requestTelemetry)
	{
	uint16_t packet = (value << 1) | (requestTelemetry ? 1 : 0);
	// compute checksum
	int csum = 0;
	int csum_data = packet;
	for (int i = 0; i < 3; i++) {
	csum ^= csum_data; // xor data by nibbles
	csum_data >>= 4;
	}
	csum &= 0xf;
	// append checksum
	packet = (packet << 4) | csum;
	return packet;
	}
	void pwmCompleteDshotUpdate(uint8_t motorCount, timeUs_t currentTimeUs)
	{
	// Enforce motor update rate
	if (!isProtocolDshot || (dshotMotorUpdateIntervalUs == 0) || ((currentTimeUs - dshotMotorLastUpdateUs) <= dshotMotorUpdateIntervalUs)) {
	return;
	}
	dshotMotorLastUpdateUs = currentTimeUs;
	// Generate DMA buffers
	for (int index = 0; index < motorCount; index++) {
	if (motors[index] && motors[index]->configured) {
	// TODO: ESC telemetry
	uint16_t packet = prepareDshotPacket(motors[index]->value, false);
	loadDmaBufferDshot(motors[index]->dmaBuffer, packet);
	timerPWMPrepareDMA(motors[index]->tch, DSHOT_DMA_BUFFER_SIZE);
	}
	}
	// Start DMA on all timers
	for (int index = 0; index < motorCount; index++) {
	if (motors[index] && motors[index]->configured) {
	timerPWMStartDMA(motors[index]->tch);
	}
	}
	}
	bool isMotorProtocolDshot(void)
	{
	return isProtocolDshot;
	}
	#endif

and mixer output conversion to DSHOT scale:

inav/src/main/flight/mixer.c

Lines 187 to 218 in 51dff7c

	#ifdef USE_DSHOT
	// If we use DSHOT we need to convert motorValue to DSHOT ranges
	if (isMotorProtocolDshot()) {
	const float dshotMinThrottleOffset = (DSHOT_MAX_THROTTLE - DSHOT_MIN_THROTTLE) / 10000.0f * motorConfig()->digitalIdleOffsetValue;
	if (feature(FEATURE_3D)) {
	if (motor[i] >= motorConfig()->minthrottle && motor[i] <= flight3DConfig()->deadband3d_low) {
	motorValue = scaleRangef(motor[i], motorConfig()->minthrottle, flight3DConfig()->deadband3d_low, DSHOT_3D_DEADBAND_LOW, dshotMinThrottleOffset + DSHOT_MIN_THROTTLE);
	motorValue = constrain(motorValue, DSHOT_MIN_THROTTLE, DSHOT_3D_DEADBAND_LOW);
	}
	else if (motor[i] >= flight3DConfig()->deadband3d_high && motor[i] <= motorConfig()->maxthrottle) {
	motorValue = scaleRangef(motor[i], flight3DConfig()->deadband3d_high, motorConfig()->maxthrottle, dshotMinThrottleOffset + DSHOT_3D_DEADBAND_HIGH, DSHOT_MAX_THROTTLE);
	motorValue = constrain(motorValue, DSHOT_3D_DEADBAND_HIGH, DSHOT_MAX_THROTTLE);
	}
	else {
	motorValue = DSHOT_DISARM_COMMAND;
	}
	}
	else {
	if (motor[i] < motorConfig()->minthrottle) { // motor disarmed
	motorValue = DSHOT_DISARM_COMMAND;
	}
	else {
	motorValue = scaleRangef(motor[i], motorConfig()->minthrottle, motorConfig()->maxthrottle, (dshotMinThrottleOffset + DSHOT_MIN_THROTTLE), DSHOT_MAX_THROTTLE);
	motorValue = constrain(motorValue, (dshotMinThrottleOffset + DSHOT_MIN_THROTTLE), DSHOT_MAX_THROTTLE);
	}
	}
	}
	else {
	motorValue = motor[i];
	}
	#else

One thing that will make code easier to understand is mixer change to [-1;1] scale which I might go for next.

[DzikuVx]

I think we can close it as done in 2.1