Reconfigure interruptions?

[Peque]

Systick just activates sensors readings interruptions, which are faster; at the last reading we disable sensors readings interruptions and execute the control. This way sensor readings are closer to each other in time. Is the interruption switching (from main to sensors) faster than simply waiting in the systick and avoiding the sensor interruptions? (guess switching requires saving registers etc.)

[cua-cua]

To improve current implemented solution:

• Synchronization between the control and the distance sensors execution. The ideal situation is to read completely the sensors just before the control execution.
• The current sensors state machine has 4 states to read each sensor so 16 states triggered by interruption. The time between interruptions is too long and there are a lot of context changes. The reads could be closer.

To analyze:

• Possible active waiting:
  -- LEDs rise/fall time : 5-9 microseconds
  -- ADC read time: Sampling time cycles (1.5) + 12.5 cycles, with 14 MHz of ADC clock(max config) and 4 channels injected. Check ?
  -- How much free time do we have on systick?
  -- System clock possibilities
• Disadvantes-advantages of interruptions:
  -- Context change time: ?
• Sensors reads overlapping

[Peque]

I like the active wait approach. We could simply:

• Read all while emitters are turned off.
• Turn on emitter 1, wait a bit, read.
• Turn on emitter 2, turn off emitter 1, wait a bit, read.
• Turn on emitter 3, turn off emitter 2, wait a bit, read.
• Turn on emitter 4, turn off emitter 3, wait a bit, read.
• Turn off emitter 4.

Also, while we "wait a bit" we can do the raw-to-meters conversion. This way we might not even lose any time.

It also simplifies the interruptions and finally solves the problem of not having all readings as close as possible to the control execution.

[Peque]

Unable to make this work. Moving it to OSHWDem 2018 milestone...

Anyway it is now not so critical, as it seems we fixed the peaks in the sensors readings after the latest changes.

[Peque]

Moved to Portugal 2019 milestone. Added "on hold" label as this method results in less reliable readings. We probably need some hardware changes to improve that (i.e.: add capacitors next to the emitters to provide the required transient power).

[Peque]

We will try this approach with Meiga.

If it works well we could consider backporting it to Bulebule. In that case we could take the chance and update the PCB with other changes:

• Add an ADC reading for motor voltage
• Slimmer design (thinner tires)
• More weight to the front
• New motors/encoders (with 2-cell battery)
• Pyboard instead of Bluepill?

[cua-cua]

Could you change PCB changes on Bulebule to Bulebule repo?

[Peque]

@cua-cua Yeah, good idea! Bulebots/bulebule#411