-
Notifications
You must be signed in to change notification settings - Fork 1.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
[PORT] Add GD32VF103 support and Sipeed Longan Nano Board support #959
Merged
Merged
Changes from all commits
Commits
Show all changes
27 commits
Select commit
Hold shift + click to select a range
2657560
Add hacky GD32VF103 support
KarlK90 19b971c
Add board support for gd32vf103 longan nano
KarlK90 ddb8378
Disable -Werror for now
KarlK90 771bbe8
Use https github as submodule
KarlK90 3db2089
Minor clean ups
KarlK90 23e3b16
Use JTAG for jlink flashing
KarlK90 790d90b
Set FreeRTOS to RISC-V (doesn't compile)
KarlK90 e5bd6bd
Update nuclei-sdk with __riscv_flen fix
KarlK90 ab1979e
Revert "Disable -Werror for now"
KarlK90 3eb54d8
Add stm32 license header
KarlK90 c6d495d
Remove dependencies to external libraries for the dcd driver
KarlK90 7682829
Add correct endpoint count for GD32VF103
KarlK90 b473923
Remove redundant linker files
KarlK90 6e287a7
Cleanup include paths and use linker files from nuclei-sdk
KarlK90 733a362
Use nuclei-sdk functions for init code
KarlK90 1d2a57a
Remove unsuitable clock configurations from init code
KarlK90 60d0311
Correctly initialize and handle the system tick
KarlK90 66d566f
Use functions provided by the nuclei-sdk hal
KarlK90 0399996
Code style changes
KarlK90 4cebde6
Remove unnecessary define guard
KarlK90 8b78067
Use linear buffer for GD32VF103
KarlK90 27f147f
Minor style changes
KarlK90 1b6540a
Update systick reload value
KarlK90 09e4348
move gd32vf103 to its own family
hathach 37d9f94
add gd32vf103 to riscv ci
hathach 73f8fae
change toolchain to riscv-none-embed-gcc-xpack for ci
hathach c4a6a5c
skip freertos example for gd32vf103
hathach File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Empty file.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Empty file.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
#ifndef _NUCLEI_SDK_HAL_H | ||
#define _NUCLEI_SDK_HAL_H | ||
|
||
#include "gd32vf103c_longan_nano.h" | ||
|
||
// 4 bits for interrupt level, 0 for priority. | ||
// level 0 = lowest priority, level 15 = highest priority. | ||
#define __ECLIC_INTCTLBITS 4 | ||
|
||
#define __SYSTEM_CLOCK 72000000 | ||
#define HXTAL_VALUE ((uint32_t)8000000) | ||
|
||
#define SOC_DEBUG_UART GD32_COM0 | ||
|
||
#define DBG_KEY_UNLOCK 0x4B5A6978 | ||
#define DBG_CMD_RESET 0x1 | ||
#define DBG_KEY REG32(DBG + 0x0C) | ||
#define DBG_CMD REG32(DBG + 0x08) | ||
|
||
#endif |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
LONGAN_NANO_SDK_BSP = $(GD32VF103_SDK_SOC)/Board/gd32vf103c_longan_nano | ||
LINKER_SCRIPTS = $(LONGAN_NANO_SDK_BSP)/Source/GCC | ||
|
||
# All source paths should be relative to the top level. | ||
LD_FILE = $(LINKER_SCRIPTS)/gcc_gd32vf103xb_flashxip.ld # Longan Nano 128k ROM 32k RAM | ||
#LD_FILE = $(LINKER_SCRIPTS)/gcc_gd32vf103x8_flashxip.ld # Longan Nano Lite 64k ROM 20k RAM | ||
|
||
SRC_C += $(LONGAN_NANO_SDK_BSP)/Source/gd32vf103c_longan_nano.c | ||
INC += $(TOP)/$(LONGAN_NANO_SDK_BSP)/Include | ||
|
||
# Longan Nano 128k ROM 32k RAM | ||
JLINK_DEVICE = gd32vf103cbt6 | ||
#JLINK_DEVICE = gd32vf103c8t6 # Longan Nano Lite 64k ROM 20k RAM |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,197 @@ | ||
/* | ||
* The MIT License (MIT) | ||
* | ||
* Copyright (c) 2019 Ha Thach (tinyusb.org) | ||
* | ||
* Permission is hereby granted, free of charge, to any person obtaining a copy | ||
* of this software and associated documentation files (the "Software"), to deal | ||
* in the Software without restriction, including without limitation the rights | ||
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | ||
* copies of the Software, and to permit persons to whom the Software is | ||
* furnished to do so, subject to the following conditions: | ||
* | ||
* The above copyright notice and this permission notice shall be included in | ||
* all copies or substantial portions of the Software. | ||
* | ||
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE | ||
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, | ||
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN | ||
* THE SOFTWARE. | ||
* | ||
* This file is part of the TinyUSB stack. | ||
*/ | ||
|
||
#include "board.h" | ||
#include "drv_usb_hw.h" | ||
#include "drv_usb_dev.h" | ||
|
||
#include "../board.h" | ||
|
||
//--------------------------------------------------------------------+ | ||
// Forward USB interrupt events to TinyUSB IRQ Handler | ||
//--------------------------------------------------------------------+ | ||
|
||
void USBFS_IRQHandler(void) { tud_int_handler(0); } | ||
|
||
//--------------------------------------------------------------------+ | ||
// MACRO TYPEDEF CONSTANT ENUM | ||
//--------------------------------------------------------------------+ | ||
|
||
#define USB_NO_VBUS_PIN | ||
|
||
// According to GD32VF103 user manual clock tree: | ||
// Systick clock = AHB clock / 4. | ||
#define TIMER_TICKS ((SystemCoreClock / 4) / 1000) | ||
|
||
#define BUTTON_PORT GPIOA | ||
#define BUTTON_PIN GPIO_PIN_0 | ||
#define BUTTON_STATE_ACTIVE 1 | ||
|
||
#define UART_DEV SOC_DEBUG_UART | ||
|
||
#define LED_PIN LED_R | ||
|
||
void board_init(void) { | ||
/* Disable interrupts during init */ | ||
__disable_irq(); | ||
|
||
#if CFG_TUSB_OS == OPT_OS_NONE | ||
SysTick_Config(TIMER_TICKS); | ||
#endif | ||
|
||
rcu_periph_clock_enable(RCU_GPIOA); | ||
rcu_periph_clock_enable(RCU_GPIOB); | ||
rcu_periph_clock_enable(RCU_GPIOC); | ||
rcu_periph_clock_enable(RCU_GPIOD); | ||
rcu_periph_clock_enable(RCU_AF); | ||
|
||
#ifdef BUTTON_PIN | ||
gpio_init(BUTTON_PORT, GPIO_MODE_IN_FLOATING, GPIO_OSPEED_50MHZ, BUTTON_PIN); | ||
#endif | ||
|
||
#ifdef LED_PIN | ||
gd_led_init(LED_PIN); | ||
#endif | ||
|
||
#if defined(UART_DEV) | ||
gd_com_init(UART_DEV); | ||
#endif | ||
|
||
/* USB D+ and D- pins don't need to be configured. */ | ||
/* Configure VBUS Pin */ | ||
#ifndef USB_NO_VBUS_PIN | ||
gpio_init(GPIOA, GPIO_MODE_IN_FLOATING, GPIO_OSPEED_50MHZ, GPIO_PIN_9); | ||
#endif | ||
|
||
/* This for ID line debug */ | ||
// gpio_init(GPIOA, GPIO_MODE_AF_OD, GPIO_OSPEED_50MHZ, GPIO_PIN_10); | ||
|
||
/* Enable USB OTG clock */ | ||
usb_rcu_config(); | ||
|
||
/* Reset USB OTG peripheral */ | ||
rcu_periph_reset_enable(RCU_USBFSRST); | ||
rcu_periph_reset_disable(RCU_USBFSRST); | ||
|
||
/* Configure USBFS IRQ */ | ||
ECLIC_Register_IRQ(USBFS_IRQn, ECLIC_NON_VECTOR_INTERRUPT, | ||
ECLIC_POSTIVE_EDGE_TRIGGER, 3, 0, NULL); | ||
|
||
/* Retrieve otg core registers */ | ||
usb_gr* otg_core_regs = (usb_gr*)(USBFS_REG_BASE + USB_REG_OFFSET_CORE); | ||
|
||
#ifdef USB_NO_VBUS_PIN | ||
/* Disable VBUS sense*/ | ||
otg_core_regs->GCCFG |= GCCFG_VBUSIG | GCCFG_PWRON | GCCFG_VBUSBCEN; | ||
#else | ||
/* Enable VBUS sense via pin PA9 */ | ||
otg_core_regs->GCCFG |= GCCFG_VBUSIG | GCCFG_PWRON | GCCFG_VBUSBCEN; | ||
otg_core_regs->GCCFG &= ~GCCFG_VBUSIG; | ||
#endif | ||
|
||
/* Enable interrupts globaly */ | ||
__enable_irq(); | ||
} | ||
|
||
void gd32vf103_reset(void) { | ||
/* The MTIMER unit of the GD32VF103 doesn't have the MSFRST | ||
* register to generate a software reset request. | ||
* BUT instead two undocumented registers in the debug peripheral | ||
* that allow issueing a software reset. | ||
* https://github.com/esmil/gd32vf103inator/blob/master/include/gd32vf103/dbg.h | ||
*/ | ||
DBG_KEY = DBG_KEY_UNLOCK; | ||
DBG_CMD = DBG_CMD_RESET; | ||
} | ||
|
||
//--------------------------------------------------------------------+ | ||
// Board porting API | ||
//--------------------------------------------------------------------+ | ||
|
||
void board_led_write(bool state) { | ||
state ? gd_led_on(LED_PIN) : gd_led_off(LED_PIN); | ||
} | ||
|
||
uint32_t board_button_read(void) { | ||
return BUTTON_STATE_ACTIVE == gpio_input_bit_get(BUTTON_PORT, BUTTON_PIN); | ||
} | ||
|
||
int board_uart_read(uint8_t* buf, int len) { | ||
#if defined(UART_DEV) | ||
int rxsize = len; | ||
while (rxsize--) { | ||
*(uint8_t*)buf = usart_read(UART_DEV); | ||
buf++; | ||
} | ||
return len; | ||
#else | ||
(void)buf; | ||
(void)len; | ||
return 0; | ||
#endif | ||
} | ||
|
||
int board_uart_write(void const* buf, int len) { | ||
#if defined(UART_DEV) | ||
int txsize = len; | ||
while (txsize--) { | ||
usart_write(UART_DEV, *(uint8_t*)buf); | ||
buf++; | ||
} | ||
return len; | ||
#else | ||
(void)buf; | ||
(void)len; | ||
return 0; | ||
#endif | ||
} | ||
|
||
#if CFG_TUSB_OS == OPT_OS_NONE | ||
volatile uint32_t system_ticks = 0; | ||
void eclic_mtip_handler(void) { | ||
system_ticks++; | ||
SysTick_Reload(TIMER_TICKS); | ||
} | ||
uint32_t board_millis(void) { return system_ticks; } | ||
#endif | ||
|
||
#ifdef USE_FULL_ASSERT | ||
/** | ||
* @brief Reports the name of the source file and the source line number | ||
* where the assert_param error has occurred. | ||
* @param file: pointer to the source file name | ||
* @param line: assert_param error line source number | ||
* @retval None | ||
*/ | ||
void assert_failed(char* file, uint32_t line) { | ||
/* USER CODE BEGIN 6 */ | ||
/* User can add his own implementation to report the file name and line | ||
number, | ||
tex: printf("Wrong parameters value: file %s on line %d\r\n", file, line) | ||
*/ | ||
/* USER CODE END 6 */ | ||
} | ||
#endif /* USE_FULL_ASSERT */ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
# https://www.embecosm.com/resources/tool-chain-downloads/#riscv-stable | ||
#CROSS_COMPILE ?= riscv32-unknown-elf- | ||
|
||
# Toolchain from https://nucleisys.com/download.php | ||
#CROSS_COMPILE ?= riscv-nuclei-elf- | ||
|
||
# Toolchain from https://github.com/xpack-dev-tools/riscv-none-embed-gcc-xpack | ||
CROSS_COMPILE ?= riscv-none-embed- | ||
|
||
# Submodules | ||
NUCLEI_SDK = hw/mcu/gd/nuclei-sdk | ||
DEPS_SUBMODULES += $(NUCLEI_SDK) | ||
|
||
# Nuclei-SDK paths | ||
GD32VF103_SDK_SOC = $(NUCLEI_SDK)/SoC/gd32vf103 | ||
GD32VF103_SDK_DRIVER = $(GD32VF103_SDK_SOC)/Common/Source/Drivers | ||
LIBC_STUBS = $(GD32VF103_SDK_SOC)/Common/Source/Stubs | ||
STARTUP_ASM = $(GD32VF103_SDK_SOC)/Common/Source/GCC | ||
|
||
include $(TOP)/$(BOARD_PATH)/board.mk | ||
|
||
SKIP_NANOLIB = 1 | ||
|
||
CFLAGS += \ | ||
-march=rv32imac \ | ||
-mabi=ilp32 \ | ||
-mcmodel=medlow \ | ||
-mstrict-align \ | ||
-nostdlib -nostartfiles \ | ||
-DCFG_TUSB_MCU=OPT_MCU_GD32VF103 \ | ||
-DDOWNLOAD_MODE=DOWNLOAD_MODE_FLASHXIP \ | ||
-DGD32VF103 | ||
|
||
# mcu driver cause following warnings | ||
CFLAGS += -Wno-error=unused-parameter | ||
|
||
SRC_C += \ | ||
src/portable/st/synopsys/dcd_synopsys.c \ | ||
$(GD32VF103_SDK_DRIVER)/gd32vf103_rcu.c \ | ||
$(GD32VF103_SDK_DRIVER)/gd32vf103_gpio.c \ | ||
$(GD32VF103_SDK_DRIVER)/Usb/gd32vf103_usb_hw.c \ | ||
$(GD32VF103_SDK_DRIVER)/gd32vf103_usart.c \ | ||
$(LIBC_STUBS)/sbrk.c \ | ||
$(LIBC_STUBS)/close.c \ | ||
$(LIBC_STUBS)/isatty.c \ | ||
$(LIBC_STUBS)/fstat.c \ | ||
$(LIBC_STUBS)/lseek.c \ | ||
$(LIBC_STUBS)/read.c | ||
|
||
SRC_S += \ | ||
$(STARTUP_ASM)/startup_gd32vf103.S \ | ||
$(STARTUP_ASM)/intexc_gd32vf103.S | ||
|
||
INC += \ | ||
$(TOP)/$(BOARD_PATH) \ | ||
$(TOP)/$(NUCLEI_SDK)/NMSIS/Core/Include \ | ||
$(TOP)/$(GD32VF103_SDK_SOC)/Common/Include \ | ||
$(TOP)/$(GD32VF103_SDK_SOC)/Common/Include/Usb | ||
|
||
# For freeRTOS port source | ||
FREERTOS_PORT = RISC-V | ||
|
||
# For flash-jlink target | ||
JLINK_IF = jtag | ||
|
||
# flash target ROM bootloader | ||
flash: $(BUILD)/$(PROJECT).bin | ||
dfu-util -R -a 0 --dfuse-address 0x08000000 -D $< |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
nuclei-sdk
is too overkill as submodule for just low level mcu driver. Furthermore, TinyUSB shouldn't reply on other project to provide hal layer. It is best to just use the mcu driver from the vendor, I think https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library would be a much better sub-module, since we only need a basic one.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 completely agree that the nuclei-sdk is overkill for this port, but I had chosen it over the multiple other repositories of the GD32VF firmware on github because their repository is the most up to date one and actively maintained by nucleisys which provided the RV32 core IP. Furthermore there is a bug in the GD32VF startup code in all libaries that throws an compilation error if
-Wundef
and-Werror
is used with GCC, for which I had opened a PR. Therefore I would vote to keep this despite being more then necessary, what do you think?The other repositories:
https://github.com/riscv-mcu/GD32VF103_Firmware_Library (Semi-official, contains a note to use nuclei-sdk, last activity in October 2020)
https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library (Is this official?, last real activity in November 2020)
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 pull the nuclei and did a quick check, the https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library is more updated in term of the mcu driver. The last activities you said in 2020 is update the mcu lib to v1.1. while nuclei still uses the v1.0 version. nuclei is more maintained by it is mostly for their platform, tinyusb is only interested in low level mcu driver (clock, register def). Therefore I think it make more sense to move to the said repo.
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 a bit confused the latest firmware library from GigaDevice is 1.1.2 from June 2021 but can only be found on http://www.gd32mcu.com/en/download/0?kw=GD32VF1 so all the repos are outdated. Judging from the activity in repositories all but nuclei-sdk seem to be unmaintained, as no pull request are merged or answered.
I hope that I don't bother you with this discussion, but I think that nuclei-sdk is the better choice from a maintenance perspective and I would happily open a PR to update the supplied firmware in nuclei-sdk. If that is not an option at all, I'll switch to the suggested https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library repository.
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 am not bothered at all, I have looked a bit more closer. To be honest, at first I thought Nuclei is a 3rd party, but look like they are IP creator similar to ARM. And Giga put Nuclei's N200 risc-v core into their silicon. Furthermore, Nuclei seems to spend much more effort on the software/firmware side than Giga does. And I could see why you prefer to go with their sdk. Feel free to correct me if I get it wrong.
https://github.com/Nuclei-Software/NMSIS is indeed a really great repo which is set to do what CMSIS does for ARM. I think we could actually depend on this nmsis. However, I still don't want to force any other users to use nuclei sdk just to run the usb stack. They may already be on another platform/framework, that could cause an conflict. Unless there is something that we would really need from sdk that we couldn't write it ourself.
To sum up, do you think it is good enough to just add 2 submodules
This is actually very similar to stm32 with an cmisis and driver combo, https://github.com/hathach/tinyusb/blob/master/hw/bsp/stm32f103bluepill/board.mk#L2
Note: when integrating tinyusb to an application, you can freely use nuclei, and have your own board setup, just changes the include path to the corresponding. The idea is if we use an smaller set of files (mcu lib), it would be more portable.
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.
That is good to hear!
You are totally right about Nuclei, they provided the N200/BumbleBee Core for the GD32VF103 to GigaDevice and kind of co-developed the firmware library. I'm not sure why GigaDevice doesn't show a bit more effort with their firmware, it is a bit frustrating.
I'm totally with you that we don't want conflicts in other projects. I think you are referring to namespace conflicts, like multiple definitions of the same symbol, but correct me here? My point is that the parts that we include and actively use in the compilation of tinyusb from
nuclei-sdk
is really just the NMSIS library and the gd32vf103 firmware library with modifications from nuclei to play along nicely with NMSIS (see below). The other header and source files related to different socs are not included in the build, it is just the bare minimum. So the conflicts should not increase by usingnuclei-sdk
and should be the same as using the separate NMSIS and GD32VF103 firmware repositories.On the other hand I had started to change the current port to use the two independent repositories as suggested and ran into trouble. The NMSIS library wants specific defines that describe the capabilities of the GD32VF103. Unfortunately we can't just use this file because the GD32VF103 doesn't have a FPU and has other IRQs defined. So we would have to provide this block ourselfs in a separate header file before including nmsis_core.h in the dcd driver.
But by doing so we have a board specific header-file in a rather generic driver, which is not good. The
nuclei-sdk
provides these defines in gd32vf103.h which is different from the gd32vf103.h that is supplied with the firmware library. And they actually modified the firmware library in other parts to play a long nicely with NMSIS framework. The GD32VF103 firmware library is really just meant to be used on its own. There maybe even more conflicts that but I haven't explored that way further.Given the above reasons and addressing your concerns about the conflicts could a dependency on just
nuclei-sdk
be the better option? What do you think?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.
You know this much better than me, there is obvious reason why you prefer the nuclei sdk
Yeah, I figured it out, Giga doesn't spend much effort like ST do with their stm32
My ultimate goal is not having usb stack to depend on nuclei-sdk to run. User should just compile it with any GD32VF103_Firmware_Library variant, especially one downloaded from the Giga site since that is what user will do. With that in mind, in the fact the nuclei has to modify the library to get it work with nmsis, I think we actually have to change the approach a bit.
src
folder, i.e thedcd_synopsys.c
. The reason is it will force user to use the modified firmware lib from nuclei and not be able to use official lib downloaded from Giga website. Even it is not well maintained, it is still what most user would use (unfortunately).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.
That sounds good to me! I'll change the implementation to meet these constraints, maybe the core code in src can even be implemented without any reliance on any gd32vf103 firmawre library or nmsis/nuclei-sdk.
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.
Thanks for patiently following my suggestion, yeah, the example bsp is mostly for demonstrating/testing and maintaining. If nuclei-sdk make it easier for us, no problem at all, I wasn't sure before and kind of worry it will become an dependency due to the nmsis. If we could get it dcd_synopsys neutral then that would be no problem.
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.
Perfect! I have cleaned up and fixed a bug with the systick timer not beeing reloaded. I decided to go with
nuclei-sdk
inside bsp for obvious reasons ;-). Let me know what you think!