MS5611, BMP280 SPI update

[MJ666]

This is not ready for merge yet and work in progress. The goal is to create hybrid drivers wich are working for I2C and SPI. For sure this will add some complexity but finally only a single driver need to be maintained (AK8936 is already done like this but rely on some functions in the MPU9250 driver).

The F4 has three (other high pin versions even more SPI ports). With the latest experience with the MPU9250 I feel we need to connect more sensors via SPI. I plan to do this for more drivers in the future.

Feedback would be appreciated. Thanks.

Here is already an teaser:

# version
# RaceFlight 16.01.13a - 32KHz / ALIENFLIGHTF4 2.1.5 Jan 17 2016 / 02:48:07 (8ca579d)
# status
System Uptime: 29816 seconds, Voltage: 0 * 0.1V (3S battery - OK), System load: 4.22
CPU Clock=168MHz, GYRO=MPU9250, ACC=MPU9250, BARO=MS5611, MAG=AK8963
Cycle Time: 254, I2C Errors: 0, config size: 1872

# tasks
Task list:
0 - SYSTEM, max = 23 us, avg = 0 us, total = 645 ms
1 - GYRO/PID, max = 1244 us, avg = 155 us, total = 2708649 ms
2 - ACCEL, max = 37 us, avg = 6 us, total = 25087 ms
3 - SERIAL, max = 982 us, avg = 1 us, total = 9755 ms
4 - BEEPER, max = 24 us, avg = 0 us, total = 2314 ms
6 - RX, max = 86 us, avg = 55 us, total = 51185 ms
8 - COMPASS, max = 27474 us, avg = 8361 us, total = 1268126 ms
9 - BARO, max = 48 us, avg = 17 us, total = 39640 ms
10 - ALTITUDE, max = 35 us, avg = 4 us, total = 8957 ms

# 

[rs2k]

I like where this is heading. SPI is amazing compared to I2C. We can also probably take advantage of SS to connect multiple devices on one SPI port.

The STM32F411 has 5 SPI ports in a small package. Hopefully new MCUs continue following this route.

I need to go back over the MPU9250 driver. I split it off from the 6500 driver but made it in the 6000's image which means you need two separate drivers. The single driver method is probably the better route, but it was causing issues with gyro init at the time.

[MJ666]

I planning to connect Mag and Baro to an single SPI port for the AlienFlight F4 board (SPI1 MPU6500, SPI2 Flash or mSDCard, SPI3 Mag and Baro). Will see how this goes.

[rs2k]

That sounds like a great combo to put on SPI.

[MJ666]

Just added the BMP280 driver. I see here two different options.

The MS5611 driver is able to support I2C and SPI fur the sensor during runtime. This is adding some fancy pointer code and make the driver code a bit bigger.

For the BMP280 driver the I2C or SPI part will be selected at compile time and the final code will only support the selected bus protocol.

Usually an FC will not use the same sensor with I2C and SPI so the second solution should be fine in my view.

This would mean in case there is an new revision of an FC, were the sensor is moving from an I2C to an SPI connections, an new target will be required and the firmware will not be able to support both sensors.

Any feedback here is welcome.

[MJ666]

Still testing with this. The results with the SPI part are still strange. Sometimes the multibyte SPI reads are reading the same value multiple times. In example for the MS5611 reading calibration rom values work as expected but reading the pressure and temperature values is not correct. Have similar results with the other sensors. Also experimented with alternative SPI driver code without much success. May be I will try with and F3 target on my Discovery F3 development board and see if the drivers behave different there.
I have not sqashed the last changes yet to be able to still see the two different driver variant but move als of them to the smaller resulting code at runtime.

[blckmn]

We can simplify the SPI driver also to something similar to how the i2c has been done. i.e. as per the instance, but configuring the pins using the newer IO (rather than GPIO)

We can probably do away with the ENABLE / DISABLE of the devices (Mag, Mpu etc) in their respective files, and create a spiWrite, spiRead - pass in the SPI instance (enum as per i2c) and also pass in the IO_t of the CS pin, within the bus_spi.

e.g.
spiWrite(SPIDEV_1..3, cs_pin (IO_TAG), xx);
spiWriteBuffer(SPIDEV_1..3, cs_pin (IO_TAG), xx, length);

[blckmn]

#79 @MJ666 have started with moving to IO mapping on SPI.

[blckmn]

Hey @MJ666 this is looking good... I took your advice and consolidated the i2c driver for F1/F4 also did the same for led, and sound so I think combining is the way to go.

It doesn't look too complicated - easy to read and understand