AT32UC3A: Implement initial BSP support for SimpleMachines' Mizar32-B

[ramangopalan]

Dear RT-Thread Community, Greetings!

[

为什么提交这份PR (why to submit this PR)

This PR implements initial BSP infrastructure to get RT-Thread working
on SimpleMachines' Mizar32-B target.

你的解决方案是什么 (what is your solution)

The libcpu base is common across AVR32 targets. I did update the
exception file in a previous commit. I created a separate directory
for AT32UC3A within bsp/ and modified the essential parts - Kconfig,
SCons and importantly, I updated Microchip's ASF driver files.

在什么测试环境下测试通过 (what is the test environment)

I tested the BSP with the Mizar32-B target. The system boots into the
msh shell. The default application works as expected. I used the
Mizar32's VGA extension card. I can interact with the RT-Thread
session using a VGA monitor and a PS/2 keyboard.

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• 代码是高质量的 Code in this PR is of high quality
• 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification

[aozima]

Can merge
avr32uc3b0 and
avr32uc3a0

to

avr32 or
avr32uc3？

limit the repo size. :-)

[ramangopalan]

Dear @aozima, greetings!

Thank you very much for your feedback. I fully understand. I will
certainly try to merge uc3a and uc3b. Just a question: Can you please
point me in the direction of any other BSP within the codebase which
implements something similar? I can then adopt a similar style for
merging the two.

I did think of this earlier. But in my case, I have the following - at
least, for now:

• The original at32uc3b0256 (MCUZone AVR32DEV1) development kit.
• The Mizar32 (at32uc3a0128, at32uc3b0256 and at32uc3a0512) targets.

Are the compilation flags (as a function of desired target) passed to
SCons? OR is the user responsible for generating the configuration
using menuconfig?

The at32uc3b0256 target (in its current state within the codebase)
relies on the older device files from Microchip. I have updated the
device files for the Mizar32 target. I can get rid of the older driver
files and get the common RT-Thread drv files to use the newer HW
abstractions within a common directory.

Finally, how would the application file look? Would it use conditional
compilation based on arguments passed to SCons?

[ramangopalan]

files and get the common RT-Thread drv files to use the newer HW
abstractions within a common directory.

Just another question pertaining to the common driver files: The pin
configuration within the Mizar32 models A, B and C are the same. The
at32uc3b0256 target has a different pinout. Is the common driver file
(for example, drv_gpio) responsible for implementing the abstractions
as a function of the desired target CPU build?

An example/reference implementation will really help me. Many thanks!
:)

[supperthomas]

files and get the common RT-Thread drv files to use the newer HW
abstractions within a common directory.

Just another question pertaining to the common driver files: The pin configuration within the Mizar32 models A, B and C are the same. The at32uc3b0256 target has a different pinout. Is the common driver file (for example, drv_gpio) responsible for implementing the abstractions as a function of the desired target CPU build?

An example/reference implementation will really help me. Many thanks! :)

Do you know nordic ? https://github.com/RT-Thread/rt-thread/tree/master/bsp/nrf5x/nrf52840
or stm32 https://github.com/RT-Thread/rt-thread/tree/master/bsp/stm32
you can choice which one you can implement. Two type bsp is ok for your bsp.
We suggest the bsp path is /<board/mcutype>
like avr32/at32uc3b0256 .

[ramangopalan]

Dear @supperthomas, Greetings!

Many thanks for your input. Perfect. Thank you for the references. I
haven't seen the codebase to its entirety yet. I will get back to you
in a couple of days once I hack the structure. Many thanks again!

[ramangopalan]

Dear @supperthomas,

From [1], I just snipped.

    config RT_BSP_LED_PIN
        int
        default 13 if BSP_BOARD_PCA_10056
        default 16 if BSP_BOARD_ARDUINO_NANO_33_BLE
        depends on BSP_USING_GPIO

I fully understand. Thanks. :)

References:
[1]: https://github.com/RT-Thread/rt-thread/blob/master/bsp/nrf5x/nrf52840/board/Kconfig

[ramangopalan]

Dear @supperthomas, Dear @aozima, Greetings!

Sorry for the slight delay in response. Thank you for your
suggestions. I have moved the previous at32uc3b BSP files into the
common bsp/avr32. I skimmed through bsp/nrf52840 and bsp/stm32 to see
the general structure and Kconfig implementation.

Can you please check if these commits are OK? Please let me know if I
can help with anything else. Many thanks.