This is a great start, thank you!

@dahanzimin you will need to git pull to get the RTC fixes.

@dahanzimin you will need to git pull to get the RTC fixes.

@hierophect thank you for your support, I will continue to cheer.

@dahanzimin have you worked at all on the F1 flash implementation? If not, I will work on that this week.

@dahanzimin checking in on this, are you still moving forward with an F1 for your project?

I am finding that a fairly serious roadblock for this port is the lack of dev boards for the more powerful F1 chips. The highest F1 that ST releases a dev board for is the F103RB, which is only 128kb of flash, too small for Circuitpython. It seems that virtually all community chips are for the F103C8, which is even smaller.

[EDIT: turned off math too]

@hierophect asked me about whether it would be possible to fit any subset of CircuitPython in 128kB. The answer is no. For example, leaving only the most basic modules in place for Gemma M0 still takes ~163kB:

INTERNAL_FLASH_FILESYSTEM = 1
LONGINT_IMPL = NONE
CIRCUITPY_FULL_BUILD = 0

SUPEROPT_GC = 0
SUPEROPT_VM = 0
CIRCUITPY_RTC = 0
CIRCUITPY_ANALOGIO = 0
CIRCUITPY_PULSEIO = 0
CIRCUITPY_RANDOM = 0
CIRCUITPY_ROTARYIO = 0
CIRCUITPY_USB_HID = 0
CIRCUITPY_USB_MIDI = 0
CIRCUITPY_MATH = 0
CFLAGS_INLINE_LIMIT = 35

There is really not much left. We can't turn off floating-point, because we use it everywhere.

I've made some additions to this port, including adding in support for F1/F0 style page-based filesystems, and fixing some issues with the clock and USB setup phases which also caused compilation errors. I'm now able to compile this for the STM32F103ZE, and I can confirm that it reaches main and at least tries to turn on TinyUSB. However, shortly after startup, I find that it crashes to the WWDG_IRQHandler, in a non-deterministic way (it happens in different places every reset cycle). I think this is very close, but I could use help in debugging that final hurdle.

@k0d are you able to push your USB changes to this PR?

@hathach could you take a quick peek at this? I've been trying different ways to get USB to connect to my F103 board, but so far I've had no luck. My current version is just lifting the clock, pin and IRQ settings from the F103 BSP in TinyUSB but it's still not working. Backtrace shows it seems to be stuck checking return tud_cdc_n_get_line_state(0); and return _cdcd_itf[itf].line_state;

@hierophect hihi, which board you are testing with ? the only f103 I have is bluepill. It did runs tinyusb stock example, so hopefully it is only setup issue.

@hathach I have an APMF103ZE, which is a clone of a larger F103.

At this point, though, I think it's time to just close this PR. I don't know from my testing whether the current issue is actually on our end or whether it's some issue with the knockoff, and I don't have a better board to recommend because there are essentially no F103 dev units meeting CPy's minimum size requirements outside of China. Most users will find that the F4 and F1 lines have almost identical costs at this stat range, unless they are deliberately targeting knockoffs, so using an F401 instead of an F1 is almost always a better choice except for some very limited cases (CAN).

We can revisit this if someone comes up with a piece of hardware that makes decent use of it - until then I'd say we should simply wait for the larger STM32G0s for budget STM32 support.

The F103 issue I had was running TinyUSB with freertos, and the same issue was on CPY. It was fixed by making the USB interrupts lower (15 if I remember) than the RTOS interrupts.

My opinion is F103Cx is very attractive due to it's low cost, but that specific IC hasn't the flash for CPY, and when you go to higher boards...it's not so price effective.

I've got a board with L432CE, which Micropython already supports, so I think it'd be a good target chip...not due to price, but it's low-power features. Otherwise...I agree with you on the G0 series for a budget STM32 port.

@k0d I did try your fix (thanks again for trying it), and I didn't find that it made any impact, at least in my case. If you have an F103 board that is capable of running Circuitpython and would like to pick up this port, I'd be happy to reopen it - I just can't justify spending any more of my time on it. But as you said, the cost appeal of the F103 is mostly for the bluepill type C8 and CB, which are too small for Circuitpython. Once you get up into the R and Z series the price is essentially no different from the F401, which is faster and has better processor features.

I'd enthusiastically review any efforts in the L series direction. Adafruit isn't pursuing anything with that series but with the new sleep API coming along the ultra-low power boards would be interesting additions to the ecosystem. You could probably lift parts of the flash code in this PR for that purpose, as I think the L series have more in common with the F1 pages than they do with the F4 sector system.

@hierophect yeah, the F1 flash & ram is typically too small to run circuitpython. I am sure it is only clock, pin set-up thing etc since I got my F103 bluepill running in the tinyusb repo. Therefore we could come back to this later on if needed.