Wire library has SCL and SDA definitions but then doesn't use them. about arduino_stm32 HOT 12 CLOSED

Sorry

Can you explain in more detail.

from arduino_stm32.

It's been a while since I looked at your project. IIRC,....

At I Needed to change the SDA and SCL pins of the Wire (I2C) module. So I changed the SDA and SCL definitions near the top of the file. Then near the bottom the "Wire" is instantiated but then doesn't use the SDA and SCL definitions.

here: https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/libraries/Wire/Wire.h#L124
you see the TwoWire module get instantiated using the SCL and SDA definitions that were defined earlier in the file. Good! Apparenlty in August I found an instantiation (of the version I was using) where this was not the case.

from arduino_stm32.

Here is the offending code:
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/libraries/Wire/Wire.cpp#L192
(Look at wire.h to deterimine which pins are going to be used and then.... no reaction. Turns out the "Wire" object is instantiated with PB6 and PB7.

from arduino_stm32.

OK

What really needs to happen is that in Wire.h those definitions are changed to PB6 and PB7 as the pin numbers only apply to Maple mini boards, and they are not the only board that is now supported.

Then yes, I could change it back at the bottom of Wire.cpp

Also as it looks like the constructor defaults it to the same settings as in the bottom of wire.cpp, I suspect it can be written as

TwoWire Wire()

BTW. Normally if someone wants Wire on nonstandard pins they declare their own instance of

TwoWire myWire(MY_SCL_PIN, MY_SDA_PIN, MY_SPEED);

in the sketch

But I know this is slightly wasteful of memory as the instance of Wire declared in the library still exists and takes memory

from arduino_stm32.

Well the inconsistency caught me out. I know nothing of "customary" pins, so I went to the source, and found a neat definition of where the signals were going to be. Then I took my SCL and SDA wires and plugged them onto my board at those positions. Nothing!

I specifically did not WANT to run at other pins, I just wanted to use the default pins to get into the least amount of trouble. (I've switched to "use the default when possible". Too much: "Oh oops, we hadn't tested that". e.g. related to microcontrollers, choosing a pin for yourself on a Microchip PIC you might chose the one that happens to be the one and only open drain output. That pin can't "pull high". OK, that's ideal for I2C, but if say you chose to put your led there, you can spend tons of time trying to figure out why it doesn't drive high. Of course, once you know the opendrain thingy it's easy to find it in the datasheet, but figuring it out can take a lot of time if you start out looking in the wrong directions. If others use , I'll use that to prevent stupid problems. )

As far as I know, this is a software implementation. This has the advantage of being able to run on any pin you like. That sometimes overrules the disadvantages of a software implementation (e.g. more CPU load).

from arduino_stm32.

Wire defaults to using a software implementation, but on the same pins that the hardware implementation has to use.
i.e with the software implementation, like you said.... it can be on any GPIO pin thats not being used for something else.

I dont know why the default is to use software I2C, its a legacy thing.

Recently someone ( sorry I forget who did this, as there are nearly 300 people on the forum), fixed the Hardware I2C.

However I'm not going to change the default to Hardware until its been used by many more project, as soft I2C has served us well so far.

BTW. I noticed that I2C slave functionality is missing. I found some code for this last week, but have not had time to manually merge file files and test etc.

Re: Open drain etc

AFIK all pins on the STM32 are created equal, apart from a few are 5V tolerant. But overall, I know what you mean.

Anyway. I will make the changes tomorrow, as its getting too late here in Oz to do them tonight

from arduino_stm32.

Sorry

Swamped with other urgent PR's for bug fixes.

I'll need to leave this on the To Do list a bit longer

from arduino_stm32.

Trying to help by simply creating a patch. Things are slightly more complicated:
A comment in wire.h says: "On the Maple, let the default pins be in the same location as the Arduino pins"
Good idea....

On the other hand, having the pins where the hardware module lives is also a good idea.

These two approaches are however incompatible. Leaflabs documents the analog pins A1 - A5.

My personal preference would be to follow the first strategy: put them where the arduino has them. This is possible as long as you use the software implementation. Then people who want to use the hardware i2c will have to make the proper arrangements with their hardware.

Anyway. Two (untested: I don't have the hardware up-and-running) patches. You choose. (I can't attach diffs. I can't attach them as .txt, so I have to put them up on the web myself).

http://prive.bitwizard.nl/strat1.diff

http://prive.bitwizard.nl/strat2.diff

P.S. The "wire.h" in GD32 subdirectory is exactly the same. I would suggest that the GD32 implementation simply defines "GD32" and then includes the STM32 version. Apparently this requires no changes for the STM32 wire.h, as the GD32 version is identical. The current situation means double work to maintain patches as these....

from arduino_stm32.

Hi
Don't worry about the GD32 stuff, I can copy the fix across and AFIK only 2 people even have a GD32, (me and one other)

Re: Pins

I think its best to go with the STM32 HW pins for I2C so that people can switch to hardware if they want to, without needing to change pins

Judging by the number of postings on stm32duino.com, I think more people are using various "no name" / generic STM32 boards than are using the Maple mini.

So its best to ignore the pin mapping on the Maple mini and stick to the core STM32 pin names

Anyway, I'll checkout the diffs.

PS.
Sorry if I seem pedantic, but I find that a lot of the Push requests have bugs, (I had to knock back two PR's this afternoon, as they would not compile)

So I always have to download and test the proposed code changes to see if at least they compile, and then for SPI or I2C I have to get out my test rig and try running an I2C or SPI device with the changes and prove my existing test program works
(Which as you can appreciate, takes quite a lot of time)

But I'd rather people pointed out bugs, and I do generally, eventually get around to fixing them, depending on urgency and my workload.

from arduino_stm32.

Well, your "prodding" me: "still didn't get around to this", got my attention long enough to write the two patches. Maybe next time I can actually test them if you keep prodding me occasionally. :-)

from arduino_stm32.

Sorry. I've not had time either.

I will try to remember to do it this weekend,,,, but no promises ;-)

from arduino_stm32.

Yesterday i spend hours of debugging because i2c on my generic F103 board did not work until i found out, that the constructur uses fixed definitions instead of the ones defined in wire.h. Not sure why you did it like that, but if you really need those fixed pins why not just put them in wire.h where there are definitions for SDA and SCL?
I just uncommented the SDA and SCL constructor in the line above, commented the constructor with the fixed definitions and replaced SDA and SCL in wire.h with my own pins, now it works fine.

I made a pull request #197

BTW Hardware Pins are PB10 and PB11, so i personally use

#define SDA PB11
#define SCL PB10

from arduino_stm32.