-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arterytek's AT32F4 support #1445
base: master
Are you sure you want to change the base?
Conversation
/* | ||
* This file is part of the libopencm3 project. | ||
* | ||
* Copyright (C) 2009 Uwe Hermann <uwe@hermann-uwe.de> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you want a more favourable beginning, don't do things like this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh sorry about that. Hadn't better idea how to attribute almost copypaste.
include/libopencm3/stm32/f1/rcc.h
Outdated
#define RCC_CFGR3 MMIO32(RCC_BASE + 0x30) /*(^^)*/ | ||
#define RCC_CFGR4 MMIO32(RCC_BASE + 0x50) /*(^^)*/ | ||
#define RCC_CFGR5 MMIO32(RCC_BASE + 0x54) /*(^^)*/ | ||
#define RCC_CFGR6 MMIO32(RCC_BASE + 0x5c) /*(^^)*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, so, I'm not going personally merge anything that adds f1 registers for a different target and a different family. There's got to be a better way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ifdef'ing those counts for (slightly) better way ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure honestly, the two approaches people have tried to take so far have largely been "copy paste the entire f1 tree" which is a maintenance nightmare, and "ifdef f1 code to be a trashfire supporting everything in the world" I imagine breaking it all into much smaller pieces so it can be composed more freely is likely the path forwards, but I've not tried (and it's not remotely on my own personal roadmap)
So, another attempt. This time i've decided to let stm32f1 rcc code alone, let's see how this helps me. |
/* | ||
* This file is part of the libopencm3 project. | ||
* | ||
* Copyright (C) 2009 Uwe Hermann <uwe@hermann-uwe.de> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not convinced Uwe has any copyright on this file. it's just header definitions from the datasheet. it's not "copying" when there's no other way? I'd go as far as saying there's not really any plausible copyright at all on this, as per oracle vs sco, but IANAL.
@author @htmlonly © @endhtmlonly 2012 | ||
Ken Sarkies <ksarkies@internode.on.net> | ||
@author @htmlonly © @endhtmlonly 2022 | ||
Sergey Bolshakov <beefdeadbeef@gmail.com> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copyrights here don't match what you've got lower down, and isn't this all your own work? pretty sure there's nothing left of the 2009 code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's slightly modified (from f1 variant) gpio_set_mode(), unmodified gpio_set_eventout() and new gpio_set_mux().
git blame shows few lines exactly from 2009 by Uwe. But honestly all this copyright stuff isn't my idea of fun,
i'll gladly agree with what you see appropriate here.
lib/at32/f40x/rcc.c
Outdated
|
||
/* Choose HSE as the RTC clock source. */ | ||
RCC_BDCR &= ~((1 << 8) | (1 << 9)); | ||
RCC_BDCR |= (1 << 9) | (1 << 8); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using different orders here was confusing and made me think you had a bug here :|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it survived that way from original submission in 2014, it seems. another wtf moment
I think this style looks a lot better personally! |
thanks. next in my todo list are usb with clock recovery, maybe flash bits. |
Ify ou want standalone commits reviewed, make them a standalone PR please. |
#define USART7_BASE (PERIPH_BASE_APB2 + 0x6400) | ||
#define USART8_BASE (PERIPH_BASE_APB2 + 0x6800) | ||
#define I2S2_EXT_BASE (PERIPH_BASE_APB2 + 0x6c00) | ||
#define I2S3_EXT_BASE (PERIPH_BASE_APB2 + 0x7000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be really nice not to have fixup commits in the same stack please. It makes splitting and bisection on a long set like this awful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm planning to squash this commit with first in series anyway -- if that's okay.
@@ -59,7 +59,7 @@ | |||
#define RCC_CFGR3 MMIO32(RCC_BASE + 0x30) /* CRM_MISC1 */ | |||
#define RCC_CFGR4 MMIO32(RCC_BASE + 0x50) /* CRM_MISC2 */ | |||
#define RCC_CFGR5 MMIO32(RCC_BASE + 0x54) /* CRM_MISC3 */ | |||
#define RCC_INTMAP MMIO32(RCC_BASE + 0x5c) /* CRM_INTMAP */ | |||
#define RCC_CFGR6 MMIO32(RCC_BASE + 0x5c) /* CRM_INTMAP */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this defines to be compatible with stm32, but with comments (that no-one will ever see) showing what the actual vendor names are? I'm inclined to say you want them both defined in that case honestly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, that's about two dosens registers, which do not exist in stm32f1 -- making them just as they are in at32 docs
feels sometimes really meh. This particular diff just fixes difference in register naming with register value define for this register below.
And by the way comments like these are wisible in doxygen, no ?
lib/at32/f40x/rcc.c
Outdated
*/ | ||
|
||
void rcc_set_hsi_bypass(bool bypass) | ||
void rcc_set_hsi_div(uint32_t hsidiv) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was this just copypasta before? This sort of fixup is exactly what you don't want in unrelated changesets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, that's was newly added. later i've decided that function naming doesn't follow existing pattern.
as i said, i'd like to squash this with initial commit later.
AT32F4 is a family of Cortex-M4/M4F MCUs made by Artery Technology. Their *Main Stream* series, which can be described as pumped STM32F1, includes AT32F40X/AT32F45X chips and features M4F core up to 240MHz, richer periheral set, shadowed flash with zero wait states and more, while tries to be compatible with original at register level. For now, add most basic things: * devices data * interrupt vectors * memory map
RCC on AT32F40x is similar with STM32F1x series, notable differences are (among others): * HSE clock in range 4-25 MHz * PLL multiplier up to 64x * HSI clock 48 MHz, which can be fed to USB * MCO output divider, down to /512
In addition to STM32F1 series AT32F40x features extra CAN2, SPI1/I2S, SPI4, SDIO2, I2C3, U(S)ART[6-8] etc, thus requiring more flexible pin muxer; in particular, eight MAPRx registers. Other notable difference, MAPR SWJ bits are just usual rw ones. On top of that, GPIO_MODE_OUTPUT_50_MHZ needs extra register poking. So, another piece of unique (sigh) API.
Timers on AT32F40x are mostly just as usual STM32 ones, with one notable addition: TIM[2-5] can be switched to 32-bit mode, namely TIMx_CNT, TIMx_ARR and TIMx_CCR[1-4] registers.
In addition to STM32F1 DMA controllers fuctionality, AT32F4x has so-called flexible request mapping mode, resembling channel remapping feature found on F0 MCUs, although implemented differently. Add support for it.
Add support for ADC, DAC, CAN, EXTI, I2C, IWDG, PWR, RTC, SPI and USART by reusing corresponding STM32F1 code.
in preparation for usbfs support, add * usbfs alternate packet memory selector * usbfs alternate interrupt vector selector. while not exactly reset and clock controls, they reside in RCC register space.
In addition to STM32F1 USBFS, AT32F40x has extra packet buffer, up to 1280 bytes in size, which can be selected instead of standard 512 bytes' one.
AT32F40x contains auto clock calibration block, which uses USB SOF signal as reference for HSI oscillator calibration. Add support for it by reusing CRS API.
AT32F4 is a family of Cortex-M4/M4F MCUs made by Artery Technology. Their *Value Line* series includes, among others, AT32F421/425 chips. Add basic support for those.
Add support for ADC, CRS, EXTI, I2C, IWDG, PWR, RTC, SPI TIM and USART by reusing corresponding STM32 code.
OTG_FS controller on AT32F425 is similar with one found in STM32, although it needs modified initialization procedure, in particular, device mode should be forced before powering up phy. Also, in contrary with documentation [RM_AT32F425_EN_V2.02], actual chips have OTG_FS_CID 0x2000, thus requiring PR#1261 [libopencm3#1261].
V2.04 and earlier of Artery's AT403A/407 Reference Manual sect 7.4.9 specifies b'0001' value for CH1/PB4 CH2/PB5 CH3/PB0 CH4/PB1 TIM3 pinmux. Actual hardware tests shows b'0010' should be used instead.
Hi. I'm currently amusing myself with at32f403a based blackpill board --
you probably heard of those, stm32f10x frankenclone with m4f core, richer peripheral set,
flash shadowed by SRAM (no wait states!) and overally more of it.
Problem is, it's frankenclone in denial -- they renamed any and every register and bit name
in their docs, although maintaining very close compatibility at register level.
So, i'm curious, if is this approach with hijacking stm32f1 code base is acceptable at all (thus RFC) ?
Currently i have only basic things like rcc & flash, gpio and timers, enough for blinky with systick and timer (at 240Mhz wow).