i2c thing

[BenG]

A friend and myself are currently testing some code we added to the latest ESC32 source to support I2C and extensions to the shell config system. Right now six ESC32 are running on my new hexacopter with a NG-UAVP HW0.24 flightcontroller and Foxtech 4428 690kV motors with Xoar 13x5" props. First tests are promising, it seems we didn't break anything else in the codebase...

[kinderkram]

Thx, Ben!

I read your posts at FPVC and they sound very promising.
One of the problems with the previous I2C code was that it spit out I2C errors when you armed the ESCs.
The other major one was a stalling motor when you quickly pumped up the throttle from 0 to 100%

You might want to test this on the bench. And then make the code available.

Thx in advance,

Norbert

[BenG]

We are currently updating the actors with 1kHz, 8-bit values and it seems from what I saw on the bus without issues so far, but I will have to do some flying test soon, the motors seem to follow the throttle nicely. We are also looking into using the DMA controller for the I2C transfers, but the alternate function pins where the I2C is currently mapped seem to be not supported to do that...

[Kisssys]

I would hope that you would have a 10 bit mode to realize more benefit from the ESC32. If you look at the normal range of hover with 8 bit I2C it's very narrow and not a lot of resolution.

[BenG]

[Kisssys]

I can't see any reason you need to be anywhere near 1000hz. I couldn't tell much difference from 200 to 400 hz

[BenG]

The 1kHz is a bit of a historic constant we initially set in 2007 as we started our project, I concur with you that 500Hz or even 250Hz may easily be enough if the sensor fusion and attitude estimation are good.

On another note, I did some more I2C testing today, no glitches on either side (flightcontroller/ESC32) so far...

I2C testing...

6 x Foxtech 4822-690kV with Xoar 13x5" at 16.5V

[sam]

Hi all,

I've been working with the I2C code posted above with Hyon - and I can see why it got left!

As mentioned the main problems seem to be around arming - communications are fine until the ESC32 arms and starts to go through the states. It looks like the I2C interrupt takes too long waiting on runNewInput() and doesn't catch I2C events occurring in the meantime.
I've modified the code a bit to catch certain interrupts, but otherwise it seems I've got two situations:
- With I2C clock stretching enabled (default), after arming the ESC32 appears to hold the SCL line low, stopping any other communications coming through.
- With it clock stretching disabled, the ESC32 appears to operate fine (going armed -> stopped -> starting -> running), but whenever a message or event is recognised to be missed, the ESC32 changes back to ESC_STATE_STOPPED and repeats.

Do any of these problems ring a bell with anyone? In particular, if there's a way to be calling runNewInput() without missing I2C events (or freezing the bus), I would be very happy to know!

Thanks in advance for any help,
Sam

[bn999]

The code was originally written around the ADC processing timing which is critical for good zero crossing detection. Most of the system's work is done in interrupts, so they can hold the processor's attention for periods of time. If there are more urgent timing requirements for I2C, then their interrupts must be given a higher priority and possibly the ability to pre-empt existing interrupts. But, it will be crucial that the minimum amount of work be performed in these new ISRs, perhaps postponing additional work for lower priority interrupts, like the run loop which is triggered each systick.

If this strategy does not work, then a fundamental reorganization of the code might be necessary, but I think this unlikely.

[M00nMan]

I'm also a fried of BenG. I ported the ESC32 code (branch 1.5) to GCC and adapted our I2C routines.
It seems that I2C, other communication and calibrations work fine.
During port I notices some things in the code which should be polished and others prevent working with both compilers (GCC and the original one). Maybe Bill contacts me to clarify these problems and improve the code.
I plan to evaluate the code a little more but I assume most 'll behave as BenG already wrote.
Additionally a move to the latest version 2.01xxx is process , for I2C with and without CAN support.