User i2c bus access support

[tinwhisker]

A user can now spam the i2c bus.

[Gadgetoid]

Thanks!

Alas -I've got a set of changes to how the internal i2c devices are handled that will trample all over this - see: 34a4c7f - but the two should be able to co-exist with some modifications.

I'm just now sure how User I2C should interact with the battery/tilt state-machine, there are a few options:

1. Explicitly have the user disable system i2c, run their blocking transactions and enable it again after (ugly and weird)
2. Somehow integrate user i2c access into the system i2c state-machine using a callback system (potentially convoluted, but feels like the right approach)
3. Squeeze user i2c transactions into the 16ms wait period somehow
4. Leave it as it is, because it'll probably work fine anyway

Some experimentation might be required due to the... possibility of weirdness. Becuase the system i2c will split up transactions into their transmit and receive phases I'm not totally sure what happens if the user comes along and does a transaction in the midst of that. Bad things, probably.

I'm thinking no 2 might be the sensible choice but it would be nice if the user didn't have to care about any of this. At the moment (per your PR) their i2c access will be "blocking" and thus doing something like blasting out a series of LED registers, or reading a device with a large memory (lots of sensor information, or a little camera) could hang up their update loop.

Maybe this isn't a problem? User i2c will be a "we don't support that, but by all means have fun!" kind of addition to the Blit anyway.

On the upside-

Right now your code could run with very few modifications- the only thing the user would need to do (I think) is check that the (currently not user-facing) i2c_state flag is either STOPPED or DELAY. If those conditions are satisfied then they're free to go ahead and do all the blocking transactions they like during the course of their update. This would require one new function: can_i_do_i2c_pls() and an additional guard around the user i2c functions to make them exit immediately with a failure if the user tries to call them while the system is in a busy state.

That said, I'm still mindful of no 4- I don't know how HAL_I2C_Master_Transmit_IT and HAL_I2C_Master_Transmit co-exist, perhaps everything will just work fine as is with no special accomodations.

Whew... that's a long post!

[Gadgetoid]

Ah having read the code, it looks like HAL_I2C_Master_Transmit will just return HAL_BUSY if a HAL_I2C_Master_Transmit_IT has been called that is currently keeping the I2C bus busy. Any examples of user-mode I2C would have to take this into account and act accordingly.

[Gadgetoid]

Closing for now, since it's hopelessly conflicted and stale but there might be good cause to append this to the API when things have settled somewhat. I think it could work.