Butterfly alternate SDA/SCL

[profezzorn]

The Butterfly pinout indicates that PB8/9 can be used as alternate pins for I2C. It also seems like that is indeed supported by stm32l4_i2c.c, but I can't find a way to enable that in Wire.h/Wire.cpp (I need PB6/7 for touch sensing, which is why I want to use the alternate pins.)

[profezzorn]

While this might still be a handy feature for some, adding another variant makes more sense for my use case. Eventually I'll create a pull request for the new variant.

[kriswiner]

Well, D3 and D4 offer IWire1.

I am not sure how to invoke the alternate I2C on D6 and D7 for Butterfly.

We use this on Dragonfly:

Wire.begin(TWI_PINS_20_21); // set master mode

so I suppose something like

Wire.begin(TWI_PINS_7_6 ); would work?

On Sat, Apr 14, 2018 at 5:10 PM, profezzorn notifications@github.com wrote:

While this might still be a handy feature for some, adding another variant makes more sense for my use case. Eventually I'll create a pull request for the new variant.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/32#issuecomment-381369836, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qgEckOKRs6Zr_RQDMZHowdt3oJV0ks5too_egaJpZM4R2x91 .

[profezzorn]

I don't particularly like that API, but it could work. In my case I've actually re-done my board a bit, and SDA is now on PB9 (pin 7) and SCL is on PA9 (pin 30).

Maybe something like: Wire.begin(GPIO_PIN_PB9_I2C1_SDA, GPIO_PIN_PA9_I2C1_SCL); ?

or would that expose too much of the underlying stuff for your taste?

Another option would be something like: bool Wire::SetSDA(int pin); bool Wire::SetSCL(int pin); which would return false if the selected pin is not possible.

[kriswiner]

Well, the L4 Arduino APIs are set for the Butterfly (and other) boards that we produce and offer on Tindie. I don't expect we will offer custom variants nor modify the API for custom applications not our own. So I am afraid you will have to modify and maintain your own variant of the core for your own use. And, of course, in this case you can tailor the API to your liking.

On Sat, Apr 14, 2018 at 5:56 PM, profezzorn notifications@github.com wrote:

I don't particularly like that API, but it could work. In my case I've actually re-done my board a bit, and SDA is now on PB9 (pin 7) and SCL is on PA9 (pin 30).

Maybe something like: Wire.begin(GPIO_PIN_PB9_I2C1_SDA, GPIO_PIN_PA9_I2C1_SCL); ?

or would that expose too much of the underlying stuff for your taste?

Another option would be something like: bool Wire::SetSDA(int pin); bool Wire::SetSCL(int pin); which would return false if the selected pin is not possible.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/32#issuecomment-381372158, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qoOpBW4chqWshwoItKuc9KSiG8e-ks5topqvgaJpZM4R2x91 .

[profezzorn]

Being able to configure which pins do what is just a matter of flexibility, it makes the boards more useful for everybody.

I think it's a darn shame if I have to fork the repository just add my own variant, as I would much rather collaborate than play in my own sandbox.

[kriswiner]

Well, you will have to take this up with Thomas, who has to maintain all of this.

In general we welcome (your) collaboration, but it has to be consistent with our goals.

He and I have already discussed at length and come to some agreement on the philosophy behind these APIs. The idea is to make these boards, and the L4 MCUs in general, easy to use. This is the over-riding concern, not flexibility. To this end Thomas built the underlying system layer to be memory and power efficient, robust, and complete. The Arduino overlayer (the bit exposed to the intended user) is simple and easy to understand and use.

Mind you, we do not mean that we are targeting idiots as users (although we have our share ;>), merely that we are targeting users who quickly want to create an IoT device/application without getting bogged down in the details of embedded programming while still getting access to all of the sophistication and power these MCUs have to offer..

If flexibility is your priority, then there is likely no alternative but to maintain your own version, since this misses the point as far as we are concerned.

For maximum flexibility, you can always fall back to the ST HAL and STM32CubeMX (ha ha, Ha Ha, HA HA HA!)...sorry.

On Sat, Apr 14, 2018 at 6:16 PM, profezzorn notifications@github.com wrote:

Being able to configure which pins do what is just a matter of flexibility, it makes the boards more useful for everybody.

I think it's a darn shame if I have to fork the repository just add my own variant, as I would much rather collaborate than play in my own sandbox.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/32#issuecomment-381372826, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qh01pV9OgmIEtuS5euL6EmlYkZAEks5top9ZgaJpZM4R2x91 .

[profezzorn]

This isn't really the right venue for this, but I can't figure out how to start a private conversation... Would Tiera corp be interested in building and selling my design(s)? I don't mind if you guys keep the profit, and perhaps that way our goals could actually align pretty nicely.

More information about what I'm working on right now can be found here: http://therebelarmory.com/thread/9121/v4-sneak-peek

[profezzorn]

PS: simplicity and flexibility are generally not in conflict when designing APIs, as you can have as many APIs as you want.

[kriswiner]

You can e-mail me at tleracorp@gmail.com.

On Sat, Apr 14, 2018 at 7:05 PM, profezzorn notifications@github.com wrote:

This isn't really the right venue for this, but I can't figure out how to start a private conversation... Would Tiera corp be interested in building and selling my design(s)? I don't mind if you guys keep the profit, and perhaps that way our goals could actually align pretty nicely.

More information about what I'm working on right now can be found here: http://therebelarmory.com/thread/9121/v4-sneak-peek

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/32#issuecomment-381374617, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtbB0N6BtnwB7uYW3U0IJ4u9D2JNks5toqrPgaJpZM4R2x91 .

[kriswiner]

Cool project, can't wait to see how it turns out!

On Sat, Apr 14, 2018 at 7:05 PM, profezzorn notifications@github.com wrote:

This isn't really the right venue for this, but I can't figure out how to start a private conversation... Would Tiera corp be interested in building and selling my design(s)? I don't mind if you guys keep the profit, and perhaps that way our goals could actually align pretty nicely.

More information about what I'm working on right now can be found here: http://therebelarmory.com/thread/9121/v4-sneak-peek

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/32#issuecomment-381374617, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtbB0N6BtnwB7uYW3U0IJ4u9D2JNks5toqrPgaJpZM4R2x91 .

[GrumpyOldPizza]

There original Dragonfly had not enough I2C ports and there needed to be a way to switch dynamically between 2 mappings.

The SW approach was crummy and perhaps will be reworked.

The design philosophy behind the code is that you instantiate a static object with a fixed pin mapping. The whole board gets mapped via variant.h and variant.cpp. Any API that would assign pin mappings dynamically is out of the question. The code is not set up to do this, nor is it architecturally desirable.

You clearly have a board that has different mappings. That is not something bad. It's just that the right way to handle this it to create your own variant.

On Sat, Apr 14, 2018, 6:56 PM profezzorn notifications@github.com wrote:

I don't particularly like that API, but it could work. In my case I've actually re-done my board a bit, and SDA is now on PB9 (pin 7) and SCL is on PA9 (pin 30).

Maybe something like: Wire.begin(GPIO_PIN_PB9_I2C1_SDA, GPIO_PIN_PA9_I2C1_SCL); ?

or would that expose too much of the underlying stuff for your taste?

Another option would be something like: bool Wire::SetSDA(int pin); bool Wire::SetSCL(int pin); which would return false if the selected pin is not possible.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/32#issuecomment-381372158, or mute the thread https://github.com/notifications/unsubscribe-auth/AG4QfAFLZCWueDsujtERN0S9i0WKFOs9ks5topqvgaJpZM4R2x91 .

[profezzorn]

That's a fine design philosophy - until it isn't.

As you yourself discovered with the dragonfly, there are times when it is desirable to change the pins. I agree that in my case, using the variant abstraction is the right way to go, but if I had been working on an add-on board, the answer might be something different.

It's only a matter of time before someone else comes along with a similar feature request, when that happens, will you choose your principles or your customers?

[GrumpyOldPizza]

Dragonfly itself has a different problem, in that you need to concurrently map one logical I2C bus to 2 sets of predefined pins. More like adding an extra bit to the I2C address.

That is substantially different from the use case you are after where you really have a different variant with a different static pin mapping.

For the latter problem, a new variant is the appropriate solution.

On Sun, Apr 15, 2018 at 11:03 AM, profezzorn notifications@github.com wrote:

That's a fine design philosophy - until it isn't.

As you yourself discovered with the dragonfly, there are times when it is desirable to change the pins. I agree that in my case, using the variant abstraction is the right way to go, but if I had been working on an add-on board, the answer might be something different.

It's only a matter of time before someone else comes along with a similar feature request, when that happens, will you choose your principles or your customers?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/32#issuecomment-381421606, or mute the thread https://github.com/notifications/unsubscribe-auth/AG4QfPZXyZwgg1k9gnOgOBKi9iF4AudVks5to31_gaJpZM4R2x91 .