This is a work-in-progress version of my attempt at a pair of FlashStorage & EEPROM libraries.

FlashStorage is a lower-level library that abstracts away (most of) the burden of storing and retrieving user data from flash. It simply provides a read() and a write() method, that handle all the pageing, erasing and updating and whatnot behind the scenes, so the end user doesn't have to care about the low level details.

EEPROM builds on top of that, and provides an Arduino-esque EEPROMClass, with an API similar to the AVR EEPROM. It's more limited than that, because only the basic functionality required for Kaleidoscope is implemented at this point (no C+11 iterators or array access at this point).

There are a few things I need to work out still, namely:

• [x] Sane defaults. At the moment, I copied some defaults from 05_USBD_MSC_internal_flash. Ideally, we'd have those defaults come from boards.txt. The major things we need is the size of the storage, where it starts (or where it ends, which is more practical to store in boards.txt in our case), and the page size.
• [x] Make small operations more efficient. At the moment, all reads and writes require a full page read/write, even if we could do with less. In case of Kaleidoscope, we quite often do much smaller reads and writes.

For reads, we can be much more efficient, because we don't need any paging there. We just read N byes of data from an address, and done.

For writes, the most efficient way would be to copy the whole storage to RAM, and only write back on commit(). That'd make writes a lot more efficient, at the cost of ram. Another option would be to have a prepareWrite() function, that tells the library how much data we'll write, and where, so it'll prep that area in RAM, and write it all back in commit(). This, however, would require dynamic memory allocation. There's fmc_word_reprogram(), which should - judging by its comments - reprogram a word at an address without erase. We could use that for more efficient small writes, as we won't have to do full page erase + writes. However, any of these require more thought, and I'll postpone efficient writes 'till a follow-up PR instead. Lets get the very basic functionality working in this one first.

Meanwhile, I'm submitting this as a draft PR for comments, and perhaps ideas. The code has not been tested on hardware yet, I've only done compile tests with this iteration. Once I got to the "test on hardware" stage, I'll report back too.

Hey, I'm trying to use software serial with F130 but it is failing to compile in Arduino IDE with the following error.

SoftwareSerial.cpp:264:5: error: 'noInterrupts' was not declared in this scope 264 | noInterrupts(); SoftwareSerial.cpp:266:5: error: 'interrupts' was not declared in this scope 266 | interrupts();

Any help is really appreciated. Thanks in advance.

The code for the servo class and header are copied from the Arduino AVR source code but the copyright statements have been removed. Please ensure that all copyright material used in this repository include existing copyright statements

Dear Sir, first of all: Many thanks for your great work! My problem is that although there are lots of GD32XNNN micros supported in Plaformio, there are only around 5 in Arduino. As I tend to prefer to use the Eclipse based Sloeber IDE against the Platformio, I would greatly appreciate if I can program and debug GD32E230 micros there. Unfortunately, the Sloeber plugin only accepts Arduino-style .json file. I would geratly appreciate if you update the Arduino plugin in order to support more MCUs, namely the GD32E230K8T6, should it provided no major difficulty for you. Best regards, Tomáš Jíra

Hi All. Have started to develop with GigaDevice chips. I have followed the instructions to use the Arduino Ide and successfully compiled a the "Blink" example for the "GD32F30x MBed Series" The following "blink-build.txt" shows the debug output of a build command.

blink-build.txt

I would appreciate it if somebody could explain the use of "-isystem" include paths and where I can find information on it. I have never come across it before. Any help much appreciated I look forward to participating in the Community. Best regards Noel Diviney

When this code lived in the ‘core/gd32’ directory, all variants were being automatically compiled and linked in to the resulting ‘core.a’, which resulted in name collisions and symbols not resolving correctly for the target architecture unless you got lucky at link time.

Moving the startup code into ‘variants’ resolves this issue, as only the code matching the variant currently in use is compiled and linked in.

This covers more bases when the device is reset by hooking into the firmware library's reset hook.

I've also added a 5ms transmission timeout on flush so things don't hang indefinitely if the host is ignoring that endpoint.

Tested on macOS UEFI and the real OS, as well as Linux. I don't have access to windows right now, so I can't test that.

The underlying i2c implementation would always block infinitely on read events if it didn't get an answer from the i2c device.

This change adds the same timeout countdown we use elsewhere in the library.

This patch fixes a race condition present when calling ‘USBCore::pop’ in a tight loop, such as in ‘Stream::timedPeek’.

The issue occurs because, when the USB peripheral gets a packet from the host, it does the following two things, in order:

1. set a flag on the endpoint to return a NAK status to the host for subsequent OUT packets, and then
2. set the interrupt pending flag and associated registers indicating that new data is available.

This is not done atomically, and is handled by the peripheral concurrently with the CPU executing the firmware. As a result, there is a time between steps 1 and 2 where, after the peripheral has set the status flag to return a NAK, firmware code can overwrite that flag to specify that the endpoint is a valid state to receive more data, and then the interrupt is fired. Assuming no other changes are made to the peripheral's registers, after this point, an OUT data packet to the endpoint may come in immediately after current interrupt is serviced and, as a result, continue writing past the end of a full transaction buffer.

The previous version of ‘USBCore::pop’ blindly set the endpoint status to say that it was available for OUT packets, assuming that as long as its data buffer was empty, and that interrupts were disabled for the duration of its operation, it was in the correct state. However, if host data is coming in fast enough, and the calls to ‘pop’ are also fast enough, then it can trigger this race, because the USB peripheral can change the endpoint status outside of interrupt context and concurrently to firmware code.

This patch addresses that issue be only setting the endpoint status once, the first time more data is requested after the buffer is empty.

This gets us a lot of the boilerplate code moved off into a subdirectory maintained by Arduino.

It also gets us better infrastructure for adding features like PluggableHID.

It does mean that a couple features Max already implemented may need to be redone.

Right now this core is primarily built with PlatformIO (see https://github.com/maxgerhardt/gd32-pio-projects).

Original Arduino-IDE support was probably there as there is a platform.txt, board.txt and a package index at https://github.com/CommunityGD32Cores/GD32Core but it seems slightly incomplete to me (no download URLS?).

~~Since development and debugging is a thousand times easier and faster in PlatformIO, Arduino IDE is not a priority as of now.~~

EDIT: A package json was added with instructions at https://github.com/CommunityGD32Cores/GD32Core-New#using-this-core-with-the-arduino-ide, but uploading does not work yet due to missing uploader packages and logic.

I was trying to run the following code to test two serial ports and I was having this issue.

void setup() { Serial.begin(9600); Serial1.begin(9600); } void loop() { Serial.println("looping S1"); Serial1.println("looping S2"); delay(1000); }

The issue I'm having is I'm getting the output for both serial print lines on the first serial output.

Then I tried to run SPL example with changed parameters to check whether it is a issue with my PCB but after I made same changes, I was able to use UART1.

Then I tried to use only Serial1 with the following code and on the debug mode I noticed the following.

void setup() { Serial1.begin(9600); } void loop() { Serial1.println("looping S2"); delay(1000); }

It seems like it is still passing the same parameters for 1st serial port. Please can you help me to fix this ? Any help is really appreciated.

Thanks.

Many of the GD chips support two or even three can busses. Would be nice to have support for that peripheral. Should be as easy as taking the code from the STM core and moving it to the GD core.

Some recent versions of the BTT TFT Touchscreens (https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware) make use of the GD32F205VC MCU so this project should consider adding support for these boards. Even though they are not development boards, the number of peripherals they include make them an excellent choice for custom projects. As a matter of fact, we are currently making use of this code base for implementing a custom motor controller on one of these boards (https://www.biqu.equipment/collections/lcd/products/btt-tft35-e3-v3-0-display-touch-screen-two-working-modes). Here is the link to the Github repo for this project (https://github.com/vovan888/ArduinoCore-GD32).

https://www.arduino.cc/reference/en/language/functions/interrupts/nointerrupts/ says they're part of the standard API.

We don't implement them.

It looks like it they should be implemented as wrappers around __disableIrq and __enableIrq() per https://stm32f4-discovery.net/2015/06/how-to-properly-enabledisable-interrupts-in-arm-cortex-m/ and some grepping of the GD32 code.

Depends on https://github.com/CommunityGD32Cores/platform-gd32/issues/21.

The low-power GD32L23x series of chips should be supported here in ArduinoCore-GD32, with libraries such as LowPower or SleepyDog and friends to take care of the new functionality.