Updated STM F1 core to support BluePill including USB Serial

Information on the latest releases
User avatar
RogerClark
Posts: 6726
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Post by RogerClark » Fri Dec 09, 2016 9:16 pm

danieleff wrote:I2C is currently hardcoded to the alternate pins PB8/BP9. On maple mini, PB9 is connected to USB as a reenumeration pin, so using I2C will accidentally disconnect USB.

You can set the default pins if you change `.sda_pin = GPIO_PIN_9` to `GPIO_PIN_7`, `.scl_pin = GPIO_PIN_8` to `GPIO_PIN_6`, and __HAL_AFIO_REMAP_I2C1_ENABLE() to __HAL_AFIO_REMAP_I2C1_DISABLE(). This also corresponds to pin 15/16 written on the board.

This part of the code will need to be changed so pins can be set in variants. This will be a bit of work...
Hi Daniel,

I didn't realise that STM had put I2C on non-standard pins on the Nucleo (and therefore we have inherited this mapping). i.e a Remap version of the pins


Looking in the global pin description there is

Code: Select all

  { PB9,   GPIO_PIN_9,  GPIOB, GPIO_PIN_IO|GPIO_PIN_I2C_SDA,                 false }
But I'm not sure that the GPIO_PIN_I2C_SDA value is actually used anywhere

However in twi.c it looks like the i2c is hard coded onto the alternate

https://github.com/stm32duino/Arduino_C ... twi.c#L146

https://github.com/stm32duino/Arduino_C ... twi.c#L161

https://github.com/stm32duino/Arduino_C ... twi.c#L245

They also hard code the I2C pins


https://github.com/stm32duino/Arduino_C ... #L162-L171

This is not good

We'll need to modify it to make it flexible

Perhaps the simplest solution is to move the whole struct

https://github.com/stm32duino/Arduino_C ... #L148-L176

to variant.cpp

User avatar
RogerClark
Posts: 6726
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Post by RogerClark » Fri Dec 09, 2016 9:42 pm

Update...

I just tried moving the struct to variant.cpp but its deeply entangled with twi.c because of the dependency on struct i2c_init_info_t

So it would require moving code from twi.c to twi.h, which is probably not practical

danieleff
Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Post by danieleff » Sat Dec 10, 2016 5:51 am

RogerClark wrote:Update...

I just tried moving the struct to variant.cpp but its deeply entangled with twi.c because of the dependency on struct i2c_init_info_t

So it would require moving code from twi.c to twi.h, which is probably not practical
I did this in my experimental branch a while ago, the relevant commit is this.
However I highly recommend not to blindly copy/paste like this to variants.

Currently I would do it like this:
  • Reduce the size of the structs. There are a lot of unneeded fields. *_clock_init, *_reset, *_mode, *_pull, *_speed all can be removed.
  • Move the `i2c_instance_e` enum to the variant, and NOT `g_i2c_init_info` ! This way variants can tell how many I2C ports they have.
  • Make the `g_i2c_init_info` `extern` instead of `static`. In twi.c only declare it, dont fill it out, so all g_i2c_init_info fields will be zero.
  • In variant, in initialization method, fill out g_i2c_init_info[].i2c_instance, ...i2c_alternate, ...sda_port, ...sda_pin, ...scl_port, ...scl_pin.
This way not the whole huge structs will be in varian, only the port and pin.

Basically I think optimizing those structs before moving only part of it to variant is the way to go. Otherwise it creates unnecessary repetition.

Also, do the same for SPI, UART.

If you agree, I can start sending optimizations. Its just I see you are pretty busy.

User avatar
RogerClark
Posts: 6726
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Post by RogerClark » Sat Dec 10, 2016 6:09 am

Hi Daniel

I agree, there are lots off things in that struct which don't need to be there.

BUt at the moment, I'm not sure whether ST would be happy with major changes to the structure.

But perhaps if I just create a branch called "unofficial" (rather than using the WIP "Work in Progress") as the branch for anyone who is not using a Nucleo board.
Then we can make whatever changes we want and it will have no effect on the master branch.

We can still make a boards manager package later, of the unofficial version, but it may be a different from the "official" boards manager package.

Post Reply