STM32: Add F1 family support

[dahanzimin]

Hello, I hope you can support stm32f103rx, can you help me, or do you have relevant information, try to build it, but it is not successful

[tannewt]

Hi @dahanzimin, I think it'll be possible for some of that line. The smallest chip we support currently is the SAMD21 which has 256k flash and 32k ram. We don't support any smaller than that because it limits the modules we can include and the code that can be loaded.

It looks TinyUSB already supports the F1 so it shouldn't be too hard to get going. What is the compilation error that you get?

Our discord is a faster way to get help: https://adafru.it/discord

[dahanzimin]

@tannewt Thank you very much. We have tried to build F103 in stm32f405, and found the underlying St_ There are many drivers that don't correspond to each other, and there are too many modifications. I don't know the circuit Python architecture very well, and my ability is limited. Help me!

[hierophect]

@dahanzimin there are significant changes between the F4 and F1 families in ST's provided HAL APIs, even more so than between the F4 and F7/H7 in many cases.

While I understand the appeal of running Circuitpython on a chip as pervasive as the F103, I think you would ultimately find the experience to frustratingly limited - the number of lines of code you'd be able to support on 20k of RAM would be pretty small. You might have more success with Micropython, which does support the F103 and optimizes for size and speed a little more than we do.

If you do decide to forge ahead with adding F1 support to Circuitpython, Micropython would still be the ideal starting point as their code outlines many of the changes that need to occur between the STM32 chip families.

[dahanzimin]

@hierophect It should be the popularity and cost performance of STM32F103. At present, 103re is selected. It has 512k / 64K memory. It is worth trying circuit Python and trying to promote circuit Python in China. Thank you!

[hierophect]

@hierophect It should be the popularity and cost performance of STM32F103. At present, 103re is selected. It has 512k / 64K memory. It is worth trying circuit Python and trying to promote circuit Python in China. Thank you!

Ah, my mistake, I misread and thought you meant the F103x8 series used on the Bluepill type boards. Well, I can't say the Adafruit sponsored team will be able to pick up the project since we're focusing on new chip lines (i.MX series, ESP32S2) but I don't think there's any reason we'd turn away a PR adding support to a SoC with more memory than a SAMD21, if you're interested in contributing.

[dahanzimin]

I don't see that STM32F103's micropython is a good official or other supported project. Thank you. Can you recommend it? Thank you. I hope the circuit Python is better

[hierophect]

@dahanzimin You're right, on closer inspection they don't have direct support for a board using a F103. I had assumed they did because their drivers reference the F1 and account HAL differences for it. I'd have to dig around more to find out why they did that without any actual F1 boards on their support list.

If you or anyone else is interested in setting this up, this would be the general Todo List based on what it took to add the F7 and H7.

• [ ] Create a family category in mpconfigport.mk, setting all modules to 0 as per the porting docs.
• [ ] Create a board family and SoC folder in stm/peripherals/, with clock setup code brought in from CubeMX, and pin/peripheral/ definitions for the SoC. Pin and peripheral files can be created with the python scripts in tools/.
• [ ] Create a board folder for the first F103 development board (bluepill or otherwise) in boards/, along with replacing appropriate pins, settings and identification information.
• [ ] Create a linker file for the F103 memory addresses, modified as required to allow room for an internal filesystem.
• [ ] Import system_stm32f1xx.c from a CubeMX project and place in boards/.
• [ ] Create a reduced stm32f1xx_hal_conf.h file in hal_conf/ based off a CubeMX export, and add a CPY_STM32F1 flag.
• [ ] Modify the makefile to select the correct cortex settings (cortex M3), and double check that no FPU settings or other miscellaneous details need to be changed.
• [ ] Add flash settings to supervisor/internal_flash.h.
• [ ] Double check that the F4 packages in packages/ match the ones used in the F1, and add new package definition if not.
• [ ] Begin enabling modules in common-hal/ by deleting entries mpconfigport.mk, starting with the easiest ones. Microcontroller and DigitalIO should need essentially no changes other than maybe an include or two, but busio typically takes more work, and AnalogIO and Pulseio take the most.

Most drivers should be brought in automatically since we have the F1 included in st-driver/. This list probably seems like more work than it actually is, most of this is just copying existing family folders/files and replacing the certain parts as necessary with the correct data from the F103 datasheet. The hardest part is the final section, which is adding module support in common-hal, but even a board with just DigitalIO has some utility.

[dahanzimin]

@hierophect @tannewt Thank you very much for your help. Welcome to China. We are committed to promoting circuit python

[ladyada]

@dahanzimin please let us know if you have any more questions - we would love to add more STM support :)

[dahanzimin]

@ladyada Thank you very much. Yes, STM32F103 family, very good cost performance, more suitable for promotion and universal education, not much ability to modify St_ Drive, very distressed

[tannewt]

Hi @dahanzimin, please open new issues for new questions. Can you join Discord? That is the best place to get help getting going: https://adafru.it/discord

I believe that issue happens when the version of cmake is too old. Try 3.13 or newer (iirc)

[dahanzimin]

@dahanzimin You're right, on closer inspection they don't have direct support for a board using a F103. I had assumed they did because their drivers reference the F1 and account HAL differences for it. I'd have to dig around more to find out why they did that without any actual F1 boards on their support list.

If you or anyone else is interested in setting this up, this would be the general Todo List based on what it took to add the F7 and H7.

• [ ] Create a family category in mpconfigport.mk, setting all modules to 0 as per the porting docs.
• [ ] Create a board family and SoC folder in stm/peripherals/, with clock setup code brought in from CubeMX, and pin/peripheral/ definitions for the SoC. Pin and peripheral files can be created with the python scripts in tools/.
• [ ] Create a board folder for the first F103 development board (bluepill or otherwise) in boards/, along with replacing appropriate pins, settings and identification information.
• [ ] Create a linker file for the F103 memory addresses, modified as required to allow room for an internal filesystem.
• [ ] Import system_stm32f1xx.c from a CubeMX project and place in boards/.
• [ ] Create a reduced stm32f1xx_hal_conf.h file in hal_conf/ based off a CubeMX export, and add a CPY_STM32F1 flag.
• [ ] Modify the makefile to select the correct cortex settings (cortex M3), and double check that no FPU settings or other miscellaneous details need to be changed.
• [ ] Add flash settings to supervisor/internal_flash.h.
• [ ] Double check that the F4 packages in packages/ match the ones used in the F1, and add new package definition if not.
• [ ] Begin enabling modules in common-hal/ by deleting entries mpconfigport.mk, starting with the easiest ones. Microcontroller and DigitalIO should need essentially no changes other than maybe an include or two, but busio typically takes more work, and AnalogIO and Pulseio take the most.

Most drivers should be brought in automatically since we have the F1 included in st-driver/. This list probably seems like more work than it actually is, most of this is just copying existing family folders/files and replacing the certain parts as necessary with the correct data from the F103 datasheet. The hardest part is the final section, which is adding module support in common-hal, but even a board with just DigitalIO has some utility.

@hierophect How to use pin and periodic files can be created with the python scripts in tools /. Python scripts is very powerful, do you have a manual?

[hierophect]

@dahanzimin The two scripts in the tools directory do the following:

• parse_af_csv.py: This script generates boilerplate to fill the periph.c and pins.c files, based off a .csv file created from the "alternate function mapping" table of the chip datasheet. Many of these .csv files have been created already by micropython, and you can see an example of the format in the stm32f767_af.csv file. Use the syntax python parse_af_csf.py Filename.csv -pins-only to generate the pin tables, and python parse_af_csf.py Filename.csv -x to generate the peripheral boilerplate. Note that this boilerplate is not complete, and needs to have the peripheral instance arrays manually created. You also need to create the .h files yourself based on the size of the generated arrays - refer to the existing chip folders inperipherals/ for reference.
• parse_pins_csv.py: This script is more basic - it just generates the table of pins used in "boards//pins.c". It shouldn't need much modification once created. You need to create the pin table yourself based on the development board, but it should be pretty easy, see pins.csv for an example. I just type it out manually.

I'm sorry that these scripts are kind of crude, I created them mostly for my own use and haven't gotten around to reworking them to be more generally useful to everyone. Eventually I'd like them to simply generate the entire chip definition automatically. But for now they at least save a lot of time compared to manually creating the peripheral tables by looking at the datasheet.

Since micropython does not have F103 SOC .csv files, you will need to create them yourself. However, F103 devices do not have an alternate function mapping, so I'm not sure the best way to generate the file... probably just putting all of the peripherals for a given pin in the first altfunction slot, like so:

PortA,PA0,,WKUP/USART2_CTS/ADC123_IN0/TIM2_CH1_ETR/TIM5_CH1/TIM8_ETR
PortA,PA1,,USART2_RTS/ADC123_IN1/TIM5_CH2/TIM2_CH2

I'm not sure how much time this would save. It might be best to make incomplete, very simple versions of the peripheral files manually to start out with, and then we can expand and modify them later.

[hierophect]

@dahanzimin

typedef struct {
    uint8_t periph_index:4;     // Index of the peripheral instance
    uint8_t altfn_index:4;      // Index of the altfn for this pin (0 to 15)
    const mcu_pin_obj_t * pin;  // Pin Object
} mcu_periph_obj_t;

periph Index and alt What exactly does index mean? I didn't see the note at the end。

Periph index is the number of the peripheral. On the STM32F405, this is the number after the I2C Instance - I2C1 is index 1, I2C2 is index 2, etc. Altfn index is the altfunction number, which is used to link the GPIO pin to the peripheral during GPIO Init - as I mentioned before, I don't think F1 chips have alternate functions at all, so it makes the most sense to just list it as "1" for all peripherals.

[hierophect]

You can see for the F405 this is the altfunction table:

For F4 chips, each pin has many different functions so you select the one you want to use with this "altfunction index". But on the F1, the functionality of each pin is more limited, so I think the strategy is just to assume the other peripherals for that pin are not turned on?

[hierophect]

See: #3192 for closure reasons