Working: Adafruit Unified BMP085/BMP180 Driver

Hello everyone,

Adafruit Unified BMP085/BMP180 Driver works.

Thanks for posting

The only thing I had to do when I wired up the BMP180 was to modify Wire.h from

#define SDA 19
#define SCL 20

to:

#define SDA 23
#define SCL 22

for a “blue” STM32F103C8T6 using the I2C port at PB6+PB7. Was then able to run the i2c_scanner sketch. Returned I2C address 0x77. From there, went for all the marbles with the Adafruit sample sketch. Got Temp/Press/Altitude in the serial monitor

i’m a bit baffled; which blue pill board is it? a link if possible.

not tackled SDA SCL but perhaps #undef SDA #define SDA etc

let someone ask why’ve undef’d them? rather than to work you need to modify rather low level files?

stephen

It’s the same board I think most all of us are using:

http://www.ebay.com/itm/321569700934

Modifying Wire.h was appropriate because it is where SDA and SCL are defined. Other files will derive the values for SDA/SCL from Wire.h. The two pins they were defined to be, are not I2C at least on this board.

That is very strange. I have the same type of Blue Pill board, and mine works without any changes to Wire.h

@tiger762

pinout wise red pill == blue pill; scl/sda are 16,15 according to my pinouts and schematic.
differences are physical, caps size, usb socket and 3v3 regulator capacity

physically from topside board swd pins end, on the right are 3v3, gnd, 3v3, pb9, pb8(32), pb7 sda(15), pb6 scl(16)

where did you find those pin numbers 19, 20 (on pill these are pb3 & pa15) & also 22, 23( on pill these are not allocated)?

i very strongly doubt that an i2c interface would have its pins split on to different ports.

stephen

tiger762 wrote:
<…>
Modifying Wire.h was appropriate because it is where SDA and SCL are defined. Other files will derive the values for SDA/SCL from Wire.h. The two pins they were defined to be, are not I2C at least on this board.

I recall someone mentioning the defines for SCL and Sda a while ago, but I cant remember precisely what the issue was.

I think it was just that the defines were not used in the global constructor for Wire, but I’d have to double check.

The reason we use the 2 pins in question, is because they are the hardware I2C pins, even though the default Wire class uses software I2C.
So that anyone with existing hardware, could try hardware I2C and not have to rewire.

Actually, now hardware I2C is working, perhaps it should be the default Wire class, but changing it could cause a lot of problems for people, so I suspect it too late to change it now.

Unfortunately with the Arduino language, the Wire ( and SPI etc) libs create global instances of a default object. Which was fine on the limited AVR hardware, but has become constructing on the STM32 and other more powerful and flexible MCUs.
Hence our workaround in SPI to change the channel of the default class.

I guess we would need to implement the same sort of functionality as an addition to Wire, to change which pins the global instance used.

please feel free to write this new functionality and send a pull request .

something somewhere is wrong!
debian jessie 32bit up to date as of midnight with Arduino 1.6.5r5 linux 32bit and Arduino_STM32-310116-1345

if i count correctly you’re plugged into pb10, pb11 – that’s i2c2

for i2c1 its a 180 rotate of the pill and an extra pin along

my blue pill and resets

PA0: 0 PB0: 16
PA1: 1 PB1: 17
PA2: 2 PB2: 18
PA3: 3 PB3: 19
PA4: 4 PB4: 20
PA5: 5 PB5: 21
PA6: 6 PB6: 22
PA7: 7 PB7: 23
PA9: 9 PB9: 25
PA10: 10 PB10: 26
PA11: 11 PB11: 27
PA12: 12 PB12: 28
PA13: 13 PB13: 29
PA14: 14 PB14: 30
PA15: 15 PB15: 31

Couple of things. The previous post was displaying the values of PB6 and PB7 is hexadecimal. PB6 is 22 in decimal and PB7 is 23. Also, the BMP180 is in the lower right and is plugged into I2C1 which is in the upper left. I looked at the picture and can see how it is confusing because my GPS module is plugged into the USART#3 which shares pins with I2C2. I also used blue/purple for I2C1 (BMP180) and USART3 (NEO-6M)

Hope that clears up any confusion.

I guess we could implement setModule(int i2cChannel) for Wire in the same way that it was done for SPI

However as the default Wire class actually is SW not HW I2C, it may be better to add a function called setPins(int scl,int sda)

Actually, the class exposes properties for both the scl and sda pins,

class TwoWire : public WireBase {
public:
uint8 i2c_delay;
uint8 scl_pin;
uint8 sda_pin;

RogerClark wrote:
ie Wire.scl_pin and Wire.sda_pin

So if someone wanted to use different pins the easiest thing is just to write some code to set these in setup()