First pass at a BluePill Variant

The official STMicroelectronics Arduino core
User avatar
RogerClark
Posts: 6917
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: First pass at a BluePill Variant

Post by RogerClark » Sat Sep 24, 2016 12:17 pm


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

Re: First pass at a BluePill Variant

Post by RogerClark » Wed Sep 28, 2016 11:30 am

FYI

Info from Wi6Labs, They use these versions of "Firmware" in the Cube
1.4.0 STM32CubeF1 and the 1.4.0 STM32CubeL4.
So removed some older "firmware" versions from my cube and made sure I only had these.... As I sometimes need to export files e.g. USB etc from the Cube for use in this core

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

Re: First pass at a BluePill Variant

Post by danieleff » Tue Oct 11, 2016 7:37 am

danieleff wrote:What if you only put the periphery definition structs (g_analog_config, spi_init_info, g_uart_config, ...) to the variant file?
Here are all the peripheral specific variables extracted: http://pastebin.com/5DW8DNZY . (except a few enums (spi_instance_e...), and the clock setup is not there). Apart from these the code seems to be pretty generic (except gpio clock setup mentioned previously).

The size of the structs can be greatly reduced. The pin speed/pull/mode can be removed in SPI/I2C/UART, I dont think they change. The GPIO_CLKx_ENABLE can be removed by calling digital_io_init() instead of HAL_GPIO_Init().

Do these pin setups differ enough to varrant them to be put into the variant files? I know theoretically yes, but for example, is there an actual F1 board where someone wants to use different values?

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

Re: First pass at a BluePill Variant

Post by RogerClark » Tue Oct 11, 2016 8:39 am

Thanks

I'm not sure how much space would be saved my removing elements from the structs, I guess it depends on how much can be removed.

I recall looking at something similar in libmaple and it wasnt wasting that much space, but this is probably different

Re: Pin config between variants

I think libmaple inits all possible gpios even for the lowest variant. Perhaps not technically correct but it saves a lot of duplicated code and doesnt seem to do any harm if the device doesn't actually have that hardware

stevestrong
Posts: 1614
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: First pass at a BluePill Variant

Post by stevestrong » Tue Oct 11, 2016 9:07 am

danieleff wrote:The size of the structs can be greatly reduced. The pin speed/pull/mode can be removed in SPI/I2C/UART, I dont think they change. The GPIO_CLKx_ENABLE can be removed by calling digital_io_init() instead of HAL_GPIO_Init().
Do I see it correctly, will we have a nice mixture of HAL and old libmaple code?
What do we gain with it?

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

Re: First pass at a BluePill Variant

Post by danieleff » Tue Oct 11, 2016 9:26 am

stevestrong wrote:
danieleff wrote:The size of the structs can be greatly reduced. The pin speed/pull/mode can be removed in SPI/I2C/UART, I dont think they change. The GPIO_CLKx_ENABLE can be removed by calling digital_io_init() instead of HAL_GPIO_Init().
Do I see it correctly, will we have a nice mixture of HAL and old libmaple code?
What do we gain with it?
It already exists in this codebase: digital_io_init. It does clock setup too.

But then there is SPI uses HAL_GPIO_Init, and does clock init in as a struct field, line 261-263. (Which is actually wrong because spi_sck_clock_init = SPI1_SCK_GPIO_CLK_ENABLE, which sets up port B clock, but the sck pin is on port A)

Then there is ADC, also HAL_GPIO_Init, and it also uses its own if-s to start up the clock (scroll up a little).

Then there is the Interrupt one, which if I see correctly does not setup clock at all, so I guess it only works accidentally.
Etc...

I say, all these could just call the existing digital_io_init(), and leave clock setup there.

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

Re: First pass at a BluePill Variant

Post by danieleff » Sun Oct 23, 2016 6:56 pm

These structs can be automatically generated using the CubeMX data xml files. I wrote a python script that can extract SPI data into C code: http://pastebin.com/85JCVk9K , Usage:set the cubemx_dir variable, and run it as: python cubemx_data_export.py STM32F103C8
Examples of generated code: STM32F103C8, STM32L476RG, STM32F746BE

UART/I2C (or even gpio list in variant) can be easily done. ADC/DAC/PWM a maybe little harder. Timers ... I did not look into it.
It generates the default pins. There is a "remaps" at the bottom to help set up alternate pins.

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

Re: First pass at a BluePill Variant

Post by danieleff » Sun Nov 13, 2016 9:40 am

And here are some generated files for boards: https://github.com/danieleff/Arduino_Co ... n_examples
While the first SPI/I2C... pins are mostly the same, if you ever want to use alternate pins / multiple SPI-s etc... it will be easier to generate than configuring all of them by hand.
These are just examples but they are the structs used in this core.

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

Re: First pass at a BluePill Variant

Post by RogerClark » Sun Nov 13, 2016 9:51 am

Excellent...

Thanks

Ollie
Posts: 190
Joined: Thu Feb 25, 2016 7:27 pm

Re: First pass at a BluePill Variant

Post by Ollie » Sun Nov 13, 2016 5:15 pm

Daniel,

I had not visited your Github previously and now I have to say that I like your programming style a lot. The information you have at

https://github.com/danieleff/Arduino_Core_STM32F1

is very useful for all STM32 developers. There are so huge amount of details that I do wonder, what kind of quality assurance methods you have used to gain confidence that the information is correct.

Cheers, Ollie

Post Reply