A too high telemetry rate should not affect other things running, if the message/uart tx buffer is full, they will just be dropped.
However: My Lisa/M board also got completely stuck a few times (luckily only while bench testing).
Some JTAG debugging showed that it got stuck in a while loop:
seemingly after trying to recover from some i2c error on the bus with the mkk controllers:
* SPURIOUS_INTERRUPT called
* calls abort_and_reset(i2c1)
* which calls i2c_hard_reset(i2c1)
* inside i2c_hard_reset it got stuck in ```while (GPIO_ReadInputDataBit(GPIOB, p->scl_pin) == Bit_RESET);```
Having a while loop here without timeout is bad... but I don't quite understand why it got stuck there... and I can't reproduce it anymore... might have been a hardware problem in my case (since the SCL line never went high again)
But we really really need a new I2C driver!
Christophe already wrote a new one and it is mostly tested. But there are still some
issues with e.g. the aspirin driver (might not be a i2c driver problem per se, maybe initialization timing problem with the gyro?).
I have only had problems with the mkk controllers so far (but then that is what I mostly tested), and I get quite a few I2C acknowledge failures on the bus with the mkk controllers...
It could be that with more "traffic" on the uart and the accompanying higher load (interrupts) causes i2c errors to occur more often, but that is just a wild guess....
Cheers, Felix
On Tue, Feb 21, 2012 at 3:45 PM, Loic Drumettaz
<address@hidden> wrote:
Yes, i meant just check. I will add the sys_mon module to my configuration. Other than delay on the motor, I had also some bugs with my Lisa M board: the board freezes with all leds on, and the motor stops (happenned in flight only once!). This seems to happen more often when i set the telemetry message to "attitude". Is it possible that when the telemetry rate is too high, the board stops?
Hi Loic,
Thank you for updating the wiki. I had a strange behaviour using the int_cmpl_quat: there was some delay in the thrust command when reducing throttle. So I went back to int_cmpl_euler but I think i need to do more testing with int_cmpl_quat.
Commanded thrust has nothing to do with attitude estimation...(unless you run into lower/upper motor command limits with supervision).
Maybe this problem was related to the level of vibration I had before balancing motoprops...
About the running frequency of the algorithms: is it possible to make sure that the calculation is not too long compared to the sample time? Is it possible that the MCU gets overloaded?
You can't make sure that everything get's computed in time.. or if you meant to just check:
The sys_mon module gives you some information about the timing of the periodic tasks. It will give you a rough average (over 1 sec) cpu load, perdiodic time, periodic cycle time and min max of these. So your max should not be over the periodic time, otherwise in at least one cycle it took longer to calculate everything and the next one was slightly delayed...
Cheers, Felix
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel