Keep a structure similar to Arduino_Core_STM32

[bmourit]

If possible, imo it would be best to keep this repo as similar as possible to the STM32 version. There are a few reasons for this that I believe make it important.

1. No need to reinvent the wheel. Since many of these MCUs are compatible with a version of some STM32 MCU, we should reuse as much code as possible from them. This is the entire purpose of Open Source, and the STM32 repo has been tried and tested.

2. Most GD32 users are using the STM32 repo and our goal should be making it simple for them to switch. The less involved the process, the better. While exact replication isn't always going to be possible, we should at least keep the general structure relatively similar.

3. Common API
   While GD32 may or may not do this on their own, it would be neat to get a common API for these platforms. Eventually this will cause some diversion from STM32, but we can use macros and defines in a similar way they do to insure legacy MCUs still work.

I'm thinking particularly of the GPIO and pin code with Arduino. The documentation for both STM32 and GD32 is not very clear in the manuals. But we know a lot of chips are using the STM32 version. So let's take advantage of what is already done.

I've started some of this already. I've already separated out digitalpins and analogpins, and respective name files. For some reason the GD32 version was using a different bit packing structure and different functions to find and sort the pins and names. I say we dump that and adopt the exact functions Arduino_STM32 is using. They work, and we wont have to spend hours trying to figure out what is going on.

[obra]

Since the beginning, that has been a since the beginning, that has been an anti-goal of the project. When we started out, we made the decision to stick as close to the actual standard Arduino API as possible.  The STM32 Arduino Core made a bunch of decisions that make it different than the rest of Arduino. On Jan 20, 2024, at 1:06 PM, Boyd ***@***.***> wrote: If possible, imo it would be besst to keep this repo as similar as possible to the STM32 version. There are a few reasons so this that I berlieve make this important. No need to reinvent the wheel. Since many of these MCUs are compatible with a version of some STM32 MCU, we should reuse as much code as possible from them. This is the entire purpose of Open Source, and the STM32 repo has been tried and tested. Most GD32 users are using the STM32 repo and our goal should be making it simple for them to switch. The less involved the process, the better. While exact replication isn't always going to be possible, we should at least keep the general structure relatively similar. Common API While GD32 may or may not do this on their own, it would be neat to get a common API for these platforms. Eventually this will cause some diversion from STM32, but we can use macros and defines in a similar way they do to insure legacy mcus still work. I'm thinking particularly of the GPIO and pin code with Arduino. The documentation for both STM32 and GD32 is not very clear in the manuals. But we know a lot of chips are using the STM32 version. So let's take advantage of what is already done. I've started some of this already. I've already separated out digitalpins and analogpins, and respective name files. For some reason the GD32 version was using a different bit packing structure and different functions to find and sort the pins and names. I say we dump that and adopt the exact functions Arduino_STM32 is using. They work, and we wont have to spend hours trying to figure out what is going on. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[obra]

Note also that ST has predatory, restrictive licensing terms for much of the code that they release. This is something that changed a few years back specifically to disallow could they write from running on chips made by gigadevice and other competitors. unless you were doing a clean room implementation, there’s potential for legal trouble if if you are borrowing code from the STM32 Core. On Jan 20, 2024, at 1:38 PM, Jesse Vincent ***@***.***> wrote:Since the beginning, that has been a since the beginning, that has been an anti-goal of the project. When we started out, we made the decision to stick as close to the actual standard Arduino API as possible.  The STM32 Arduino Core made a bunch of decisions that make it different than the rest of Arduino. On Jan 20, 2024, at 1:06 PM, Boyd ***@***.***> wrote: If possible, imo it would be besst to keep this repo as similar as possible to the STM32 version. There are a few reasons so this that I berlieve make this important. No need to reinvent the wheel. Since many of these MCUs are compatible with a version of some STM32 MCU, we should reuse as much code as possible from them. This is the entire purpose of Open Source, and the STM32 repo has been tried and tested. Most GD32 users are using the STM32 repo and our goal should be making it simple for them to switch. The less involved the process, the better. While exact replication isn't always going to be possible, we should at least keep the general structure relatively similar. Common API While GD32 may or may not do this on their own, it would be neat to get a common API for these platforms. Eventually this will cause some diversion from STM32, but we can use macros and defines in a similar way they do to insure legacy mcus still work. I'm thinking particularly of the GPIO and pin code with Arduino. The documentation for both STM32 and GD32 is not very clear in the manuals. But we know a lot of chips are using the STM32 version. So let's take advantage of what is already done. I've started some of this already. I've already separated out digitalpins and analogpins, and respective name files. For some reason the GD32 version was using a different bit packing structure and different functions to find and sort the pins and names. I say we dump that and adopt the exact functions Arduino_STM32 is using. They work, and we wont have to spend hours trying to figure out what is going on. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bmourit]

In the USB libraries yes. I'm not referring to those. There is nothing in the STM32duino code (not done by STM) that would prevent what I am referring to. It was literally done by the Open Source community. One of the tenants of that community being code reuse.

A more "pure" Arduino core would still be feasible if so desired, and my suggestion wouldn't prevent that from happening.
But having a pure core that no one is using benefits no one.

Also, there is nothing predatory about STM's USB license, whatsoever. STM is very good to the open source world in general, so I feel those comments are misplaced.

Please also note, this project has seen almost no activity in nearly a year. So I am not sure why anyone would be against something that could make it usable to many projects, ie. Marlin Firmware. But if this is something unwanted, I will just do my own fork.