Skip to content
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

Open
wants to merge 28 commits into
base: master
Choose a base branch
from

Conversation

beefdeadbeef
Copy link

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).

/*
* This file is part of the libopencm3 project.
*
* Copyright (C) 2009 Uwe Hermann <uwe@hermann-uwe.de>
Copy link
Member

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...

Copy link
Author

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.

#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) /*(^^)*/
Copy link
Member

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.

Copy link
Author

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 ?

Copy link
Member

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)

@beefdeadbeef
Copy link
Author

beefdeadbeef commented Nov 13, 2022

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>
Copy link
Member

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 &copy; @endhtmlonly 2012
Ken Sarkies <ksarkies@internode.on.net>
@author @htmlonly &copy; @endhtmlonly 2022
Sergey Bolshakov <beefdeadbeef@gmail.com>
Copy link
Member

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.

Copy link
Author

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.


/* Choose HSE as the RTC clock source. */
RCC_BDCR &= ~((1 << 8) | (1 << 9));
RCC_BDCR |= (1 << 9) | (1 << 8);
Copy link
Member

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 :|

Copy link
Author

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

@karlp
Copy link
Member

karlp commented Dec 5, 2022

I think this style looks a lot better personally!

@beefdeadbeef
Copy link
Author

I think this style looks a lot better personally!

thanks. next in my todo list are usb with clock recovery, maybe flash bits.
oh, and could you please pick [db9f4ed] alone ? i2c code here depends on it.

@karlp
Copy link
Member

karlp commented Dec 6, 2022

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)
Copy link
Member

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.

Copy link
Author

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 */
Copy link
Member

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.

Copy link
Author

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 ?

*/

void rcc_set_hsi_bypass(bool bypass)
void rcc_set_hsi_div(uint32_t hsidiv)
Copy link
Member

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

Copy link
Author

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.

@beefdeadbeef beefdeadbeef changed the title [RFC] Arterytek's AT32F4 support Arterytek's AT32F4 support Dec 26, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants