Dev/mcu driver

[jo-bru]

New features introduced in the Dev/mcu-driver branch are:

The mcu_driver:

• to handle specific MCU tasks (such as version control, RAM usage, soft reset, etc.).
• I have not changed the parts discussed in issue #13 as this depends on the higher design structure which has yet to be defined.

• I would suggest to adapt the firmware structure as we implement the gateway design.

  The step_motor driver:

• A driver for the stepper motors (conveyor belt and slider).
• I used the step_lowlevel files from the provenance-discovery project.
• This low-level implementation uses an ISR, therefore the event handling for the step_motors is done differently. Maybe we can use this approach for other drivers to optimize event handling.
• As discussed, this driver needs yet to be tested with the hardware components.

[iomz]

I have not changed the parts discussed in issue #13 as this depends on the higher design structure which has yet to be defined. I would suggest to adapt the firmware structure as we implement the gateway design.

Yes. I agree for both.

low-level implementation uses an ISR

It's a pseudo interruption and not really the clock interruption with something like crystals – so less precise and susceptible to the MCU load from the subroutines for different peripherals, but it should work with a dynamic latency up to a couple of seconds...