Updates on the Software - Waging war with interrupt priorities

Much has been done now and after a few long days I have finally got interrupt driven measurements from the sensors to work. Because I want the abstract level of the code to be high there was a lot to fix to get it to work and be "invisible" to the user, but now it works very well.

This is how it is done/implemented:

1. First the sensor sends out an "Data Ready" signal, however this is not on the I2C-bus (MPU6050 or HMC5883L, the barometer does not have an data ready pin).
2. The interrupt is generated and an Binary Semaphore (in FreeRTOS) is set so the task that reads can be unblocked.
3. The task will try to take the I2C-bus by checking the I2C-mutex, if the bus is occupied it will wait, else it will tell the I2C to get the data requested using interrupt driven transfers. When it is done the I2C will execute an Callback-function that will set the I2C-mutex as free again and tell the OS to start using the data.
4. Now the task will wait for the next "Data Ready" interrupt.
   

This guarantees that there will be no collisions on the buss and it is easy to add mote functionality depending on where you want things to happen. 

    The biggest problem when trying to do this was when FreeRTOS always got stuck on a function called "vListInsert", this was tracked down to be a problem in the priority of my interrupts. The interrupts must have a lower logical interrupt priority (higher numerical value) than a define in FreeRTOS, else the thread safe API functions could not be called safely. The USB was given a priority of 5 and the I2C was given a priority of 6 (higher value is lower priority), but then the I2C stopped working. I then found out that the ISR (Interrupt Service Routine) of the USB was taking to long to execute and therefore "breaking" I2C packages when preempting it, this was as simple as swapping their priority. Now all other interrupts must have a priority of 7 - 15 for not to interfere with the I2C and the USB and FreeRTOS has 0-4.