Layout and implementation

[xxxajk]

The layout you suggest for installation is incorrect. It WAS correct for the older versions of Arduino. 1.6 and beyond lays things out in a much better way. Here is how I did the installation: under the hardware dir, made an 'ST' dir, and copied the STM* dirs under that. Made an 'ST' dir under the root examples directory, and copied the examples there. copied the Linux maple tools where they belong, under hardware/tools Adjustments still need to be made to the recipes for uploading in order to work still, but this is a start. If you like I can fork and re-arrange everything where it aught to go, and I also can include support for the STM32f429-discovery board as well. https://github.com/texane/stlink should be used on Linux for uploading via the stlink interface.

While I realize you are basing this off of the work done on maples, I'm a bit disappointed that you didn't just use CMSIS headers in order to define everything. Arduino does exactly this for the Atmel ARM chips. It would have made everything so much easier.

[rogerclarkmelbourne]

Hi xxxajk

There is another project that uses CMSIS headers etc see https://github.com/avikde/koduino

So that may suit your needs better

I'm afraid I'm just one person, with limited resources, making the most of what was available from leaflabs libmaple

Please feel free to clone the repo and or-organise it, but I can't guarantee that I will action a pull request to re-organise, as I have had numerous pull requests which I have action'ed, which have subsequentially broken something and I've then had to deal with tracking down the issue and then reverting the commit

[xxxajk]

Thanks for the link. I completely understand your situation, that is why moving to CMSIS would be beneficial to you. The idea is that it makes porting a lot smoother, since there are many components that can be easily shared because they are common to ARM chips of the same class. For example, NVIC on all CortexM-4 is identical, and the only change is the address. This means that using standard macros, you get to re-use NVIC code across all CortexM-4, no matter who supplies it. This only applies to ARM specific features, not any extras that a supplier adds, such as SPI, or UARTS, however you will know the addresses for each, and its type, and if it is a certain sub-family, and it can work across the entire chip line, without having to re-write everything for each variant. Arduino guys do this for the SAM family for this reason exactly -- quicker development of software for chips in the same line.

[avikde]

I feel like I should chime in (I'm the creator and so far sole maintainer of the Koduino repo https://github.com/avikde/koduino that Roger linked to). Just to give you a little more info...I am using the CMSIS and ST's standard peripheral libraries, which are not quite portable across their different series, but almost.

However, just like Roger, I have very limited time to work on it so the support for additional chips / families will be slow. :( The current support is for:

• F373 (close to F378): full support (I've been using this chip on several critical projects of my own for the past couple of years)
• F405 (close to an F40X or F41X chip, but not F411): just started, but digital, analog I/O, Serial work already...and I'm working on Wire, SPI, etc. now.
• F1?? possibly coming soon, but since for my own projects I like chips with hardware floating point this might not be the highest priority

I follow the Arduino 1.5+ hardware spec, and there is simultaneously a lightweight Makefile build system as well. I use the Makefiles more often myself, so the Arduino boards.txt may lag behind the cutting edge a bit.

Documentation is starting to appear here http://avikde.me/koduino/html/index.html. I mean to put up a document of "how to port to new series / chips" which (as you point out) is relatively easy (but still harder than it should be because ST's standard peripheral libraries aren't that portable).

Let me know if I can provide any other information / if you're interested in messing around with the code.

-Avik De

On Mon, Mar 16, 2015 at 8:43 PM Andrew Kroll notifications@github.com wrote:

Thanks for the link. I completely understand your situation, that is why moving to CMSIS would be beneficial to you. The idea is that it makes porting a lot smoother, since there are many components that can be easily shared because they are common to ARM chips of the same class. For example, NVIC on all CortexM-4 is identical, and the only change is the address. This means that using standard macros, you get to re-use NVIC code across all CortexM-4, no matter who supplies it. This only applies to ARM specific features, not any extras that a supplier adds, such as SPI, or UARTS, however you will know the addresses for each, and its type, and if it is a certain sub-family, and it can work across the entire chip line, without having to re-write everything for each variant. Arduino guys do this for the SAM family for this reason exactly -- quicker development of software for chips in the same line.

— Reply to this email directly or view it on GitHub https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/36#issuecomment-82006553 .

[xxxajk]

Well, of course, but across any one particular series, it will be, and you get defines of what is available to you. Some examples: Startup code from the supplier... Speed(s) of the MCU... if it has an FPU... UART/SPI/etc with kind and how many, and the addresses of each...

The list is too huge to mention, but it basically boils down to at least at a minimum knowing what you got, and where it is, even if you don't yet support that component.

[rogerclarkmelbourne]

Hi Avik

I've order a Nucleo F3,. so I may get chance to try your code sometime

Apart from that I'm working on interfacing the OV7670 camera to STM32

Currently the code is really clunky, as its based on the AVR stuff, but I'm starting to investigate whether its possible to use the DMA controller to read from a GPIO port. Well, I know its possible to read the data, but the issue is that the DMA controller on the F103 can't be triggered by external input - which is what I require as there is a pixel clock from the camera that indicate when data (a pixel) can be read.

But as I'm using a timer on the STM32 to generate the input clock to the camera, it may be possible to use a timer to generate the DMA request signals, which are in sync with the Pixel clock as ultimately the master clock is the STM32

Also, I've read that the Timers on the STM32 have something called input capture, which can be used to trigger a timer, and a timer can trigger a DMA transfer. So I may be able to run a very fast timer in order to generate a dma request from an external interrupt into the timer But is early days on that one.

I've only just managed to understand the libmaple dma functions, as they are not well documented and there is only one example, and the example doesn't seem to work ;-)

I also get the usual questions on the forum etc with people who have issues uploading via whatever method they have chosen etc etc etc. never a dull moment !

[xxxajk]

@avikde I have some work to complete here, but after that is done (day or two) I'll try adding support for my discovery board, in my own fork-branch, which you can review/pull from. My board is the STM32f429-discovery-- just reiterating so you know.

[avikde]

Great! I don't want to burden this thread too much (please feel free to open an issue in the koduino repo if/when you have problems!), but since I had a few minutes tonight I created a stub of the F429 variant in the repo

https://github.com/avikde/koduino/tree/master/stm32/variants/f429_439

A few things to note:

• I haven't had time to change the boards.txt, so I'd suggest the Makefile method http://avikde.me/koduino/html/md__setup_makefile.html initially. It's pretty straightforward to edit the boards.txt as well if you want to use the Arduino IDE.
• I don't have this board so won't be immediately able to test anything.
• I haven't implemented the hardware USB as a Serial interface yet... (mostly since I use USART1 for bootloading on all my boards, and it's connected to an FTDI chip). I successfully uploaded code I compiled to a F411 nucleo board recently by cp'ing over the generated .bin, I imagine you could do something similar to upload the code to your discovery board.

I also started writing very brief "instructions" on the steps that will be required to get basic led blinking, analog reading and PWM happening:

http://avikde.me/koduino/html/md__porting.html

Hope this helps get started! -Avik

On Mon, Mar 16, 2015 at 10:22 PM Andrew Kroll notifications@github.com wrote:

@avikde https://github.com/avikde I have some work to complete here, but after that is done (day or two) I'll try adding support for my discovery board, in my own fork-branch, which you can review/pull from. My board is the STM32f429-discovery-- just reiterating so you know.

— Reply to this email directly or view it on GitHub https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/36#issuecomment-82045214 .

[WestfW]

Wow. I hadn't realized that when LeafLabs rejected the idea of using the STM Standard Peripheral Library, that they had also stopped using the ST CMSIS and peripheral definitions. Writing and maintaining all that separately is a pretty awful idea :-(

[rogerclarkmelbourne]

Unfortunately its something we are stuck with if we want to use LibMaple

Edit.

Is the Standard Peripheral library open source ? from what I recall at least one set of sources from STM is not actually open source, in terms of redistribution.

If its the stuff I'm thinking of, you can use it free of charge for commercial or non commercial but but republish, which is possibly why Leaflabs went their own way.

As soon as Avik ports his stuff to F103 it will be a lot easier for everyone ;-) Oh and including the SerialUSB stuff would also be needed

And sorting out uploading via DFU, and Serial and STLink from multiple platforms

[WestfW]

Hmm. What I was thinking was that the CMSIS stuff direct from ST should be used, but probably NOT their Standard Peripheral Library. I thought it was the latter than Leaf had problems with, and from what I've seen of it, it's pretty awful code :-(

The CMSIS files (stm32f10x.h and similar) have this license: http://www.st.com/software_license_agreement_liberty_v2 which is confusing, since it states you can't distribute source, except as allowed by another part of the license, which I read as allowing you to do that.

[xxxajk]

The basic idea is to use just the headers, ld files, and startup asm .all the usual stuff from arm that pertains to the arm core in use afaik is free to copy around. preph drivers are ours to write, as usual.

Take a look at the arduino SAM dir, you'll see how it is done there. None of atmel's stuff is used, except for the standard macros, ld, and startup.

One thing I do note, is that ST's headers are almost complete too. The one bit I've not found, but defined in CMSIS is to know how many IRQ's you have... I could have missed it though, there are a lot of headers to look over.

On Wed, Mar 18, 2015 at 4:18 AM, Bill Westfield notifications@github.com wrote:

Hmm. What I was thinking was that the CMSIS stuff direct from ST should be used, but probably NOT their Standard Peripheral Library. I thought it was the latter than Leaf had problems with, and from what I've seen of it, it's pretty awful code :-(

The CMSIS files (stm32f10x.h and similar) have this license: http://www.st.com/software_license_agreement_liberty_v2 which is confusing, since it states you can't distribute source, except as allowed by another part of the license, which I read as allowing you to do that.

— Reply to this email directly or view it on GitHub https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/36#issuecomment-82813070 .

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[rogerclarkmelbourne]

Guys

I totally agree that it would be best if it was all re organised to be the same as the Arduino team did for the Due SAM architecture, however the original codebase pre-dates even Arduino 1.0, let alone 1.6 etc. And like you say, it doesn't use standard headers that are now freely available for the stm32 And there is also now a freely available peripheral interface code, which is what Avik uses.

However, I don't personally have the time to completely rebuild this codebase, and there are no other interested parties who want to work on doing this.

I get contribs for things like new libraries, and also for bug fixes to the current codebase, but that's all.

I know bob cousins made some attempts at splitting out the code so that the STM32 specific bits were in a library, like the SAM architecture, but there were a lot of issues with weak references, and bob didn't have time to do this, and no longer contributes to the project following an argument with a member of the forum about the use of FDTI devices

I honestly thought that the future route would probably be via Aviks code base, but I've not even had time to port the F103 devices to his code base, let alone looked at supporting the maple bootloader and USB serial stuff.

Perhaps when there are more active users of the STM32 platform, things will move foreward, either in this repo or Aviks or perhaps another one entirely

[rogerclarkmelbourne]

Not currently practical with the amount of time I have available

[feurig]

Have you engaged the leaflabs forums for active help on this project? I am really excited to see this work emerging and will reengage my efforts to make a usb_midi variant.

[rogerclarkmelbourne]

Matthias has cloned the repo and done a midi variant, check the arduino forum for links.

Re engaging the leaflabs forum

Last time I looked, only the moderator seemed active. Often questions don't get answered for weeks

I have contacted Matri who manages the main libmaple repo, but basically he is not very communicative, and just seems to only do the occasional bug fix as submitted to him, or changes to support whatever board he is currently looking at, rather than a root and branch change.

I suspect it may be less work to add maple specific features to aviks repo than to convert this repo to use CMSIS

But with an active user base on the arduino forum and on here, that you can count on the fingers of one hand, I'm not sure how the impetus to do a complete rework is going to happen in the foreseeable future

[rogerclarkmelbourne]

@WestfW

I looked at the license on a lot of the STM code and most of it has that license. I did post to STM's own forum, but no one there could give me an answer to the question about licensing.

Does anyone know where Em::BLocks gets their STM32 headers etc from? I'm not sure where Avik got his from either

I guess its a legal grey area, if we were to use headers that have been repackaged in breach of their original agreement (without our knowledge) I suspect we could get asked my STM to stop using them, and the whole project would then be stuffed

Someone could of course try posting the same issue to leaflabs libmaple and see if Marti responds. He normally just says that libmaple etc is no longer supported

PS. He also didn't reply to some other legal questions I asked him.

[madias123]

@rogerclarkmelbourne : feurig (donald) is one of the maker of usb_midi library. We should say a big "welcome on board!" to him! So maybe we can "reactivate" more of all the "good" members of the leafmaple community, those who have abandoned the maple project 1-2 years ago.

[feurig]

Matthias worked off of my midi repo. He has gone a long ways with it. I hope to get some of the sysex stuff I started years ago working there.

Cheers.

On Mar 31, 2015, at 1:31 PM, Roger Clark wrote:

Matthias has cloned the repo and done a midi variant, check the arduino forum for links.

Re engaging the leaflabs forum

Last time I looked, only the moderator seemed active. Often questions don't get answered for weeks

I have contacted Matri who manages the main libmaple repo, but basically he is not very communicative, and just seems to only do the occasional bug fix as submitted to him, or changes to support whatever board he is currently looking at, rather than a root and branch change.

I suspect it may be less work to add maple specific features to aviks repo than to convert this repo to use CMSIS

But with an active user base on the arduino forum and on here, that you can count on the fingers of one hand, I'm not sure how the impetus to do a complete rework is going to happen in the foreseeable future

— Reply to this email directly or view it on GitHub.

[rogerclarkmelbourne]

Hi Donald

Welcome and thanks for assisting Matthias.

Hopefully all these projects / repo's will breath some new life back into the Maple Mini etc.

I think it would be good in the long term if yours and Matthias' work for USB MIDI could be combined back into the main repo, but we are all "time poor" so I don't see any big problems with having 2 different repo's ;-)

[feurig]

Thanks Roger, I suspect Matthias was having some forest through the trees issues. I hope that work can be done at this level as well. USB_MIDI should be a variant.

I really prefer the separation of the usb core from the class pieces that was carried out of the libmaple (for an example of what a difference that makes check out the https://github.com/rkistner/arcore project).

I need to put some tools together to send sysex messages to reset the device, maybe send a sysex stream for a midi debugging console and reset to the boot loader like I was able to do with lufa on the stock leonardo midi.

Unless they start pulling functionality Arduino > 1.5.x provides the hooks to do this.

I will mess around with Matthias's fork and see if I can get anything that works well enough and then see how much work it is to make a variant of your core.

Cheers!

[rogerclarkmelbourne]

Thanks Donald

[xxxajk]

Great to see some activity on this issue. I'm currently neck deep in uC work for the next couple weeks, so I have not been able to do anything. After the flood of work is over, I should have lots of free time to dedicate to the effort, especially since I see there is indeed an interest.

[rogerclarkmelbourne]

Andrew

Thanks.

If you could look into this, it would be beneficial.

[rogerclarkmelbourne]

Guys

Just a note about the use of any of the CMSIS and hardware abstraction files from STM.

The license on STM files is actually very restrictive in terms of even the redistribution of the files.

I've noticed other repos have removed use of the files because of this e.g see https://github.com/micropython/micropython/issues/26

See

http://www.st.com/st-web-ui/static/active/en/resource/legal/legal_agreement/license_agreement/software_license_agreement_liberty_v2.pdf?sc=software_license_agreement_liberty_v2

IANAL but as far as I can see, the license is very clear, that it doesn't allow even copying of the files except for private use

"make copies, prepare derivative works of the object code versions of the Licensed Software for the sole purpose of designing, developing and manufacturing the Products"

So use of any of files under that license, would put this repo under the possibility of a takedown notice from STM.

There may be versions of the CMSIS and hardware specific files that can be sourced that don't carry this license , which would be fine.

[WestfW]

Are we talking about SPL code, or the CMSIS header files (stm32f1xx.h) The latter seems to have gotten a new license during the HAL transition. It now reads:

---

---

• @attention *

• © COPYRIGHT(c) 2014 STMicroelectronics

  *

• Redistribution and use in source and binary forms, with or without modification,
• are permitted provided that the following conditions are met:
• 1. Redistributions of source code must retain the above copyright notice,
• this list of conditions and the following disclaimer.

[rogerclarkmelbourne]

Hi @WestfW

Can you send me a link to those files.

As the ones Avik are using, contain the old / problematic license ;-(

Thanks

Roger

[WestfW]

Download the STM Cube SW for the chip http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031 Then the (big) relevant include file is in ...\stm32cubef1.zip\STM32Cube_FW_F1_V1.0.0\Drivers\CMSIS\Device\ST\STM32F1xx\Include

(Hmm. I notice that they've changed the layout a bit, going to the "per-device" include files like many other vendors, rather than a single file for the whole family.)

[rogerclarkmelbourne]

@WestfW

Thanks Bill.

Last time I downloaded STM Cube, I don't think it had any support for the F103 series, So I guess they must have updated it, or I wasnt looking very well ;-)

I'll take a look tomorrow when I should have some more free time.

[xxxajk]

@WestfW That's what I propose, using the headers only. The software end generally can be usually done better than what is supplied, and tailored to use cases that matter, while eliminating bloat.

[WestfW]

Last time I downloaded STM Cube, I don't think it had any support for the F103 series,

Yes, the F1 series was the last to get "Cube" support, and relatively recently: STMicroelectronics Completes STM32Cube™ Flexible Fast-Start Software Platform, Supporting All STM32 Microcontrollers in Volume Production

										STMicroelectronics Completes STM32Cube™ Flexible Fast...null
View on www.st.com	Preview by Yahoo

 

[avikde]

Thank you for doing some digging Roger. In the early stages of my repo I followed the popular spark project where they do use the ST standard peripheral libs, but now that I look again they seem to have a different license https://github.com/spark/core-common-lib/blob/master/STM32F10x_StdPeriph_Driver/inc/stm32f10x_adc.h

I am not totally sure how they got that but perhaps that means it's possible to redistribute that code (hopefully just a matter of finding the right download on ST's site with the "CC zero license")? I think I'd trust Spark to do have done this properly. -Avik

On Sun, Apr 5, 2015 at 5:11 AM Bill Westfield notifications@github.com wrote:

Last time I downloaded STM Cube, I don't think it had any support for the F103 series,

Yes, the F1 series was the last to get "Cube" support, and relatively recently: STMicroelectronics Completes STM32Cube™ Flexible Fast-Start Software Platform, Supporting All STM32 Microcontrollers in Volume Production

STMicroelectronics Completes STM32Cube™ Flexible Fast...null
View on www.st.com	Preview by Yahoo

— Reply to this email directly or view it on GitHub https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/36#issuecomment-89737919 .

[rogerclarkmelbourne]

Avik

Thanks for the tip on the Spark project files.

Looking at the file you referenced, its author is the MCD Application Team

So I found this

http://www.codeforge.com/s/0/MCD-Application-Team-stm32

But I have not really tracked down who they really are.

[avikde]

I assume they are some software team working with ST. It's the same on the SPL files I have https://github.com/avikde/koduino/blob/master/stm32/system/STM32F37x_StdPeriph_Driver/inc/stm32f37x_adc.h

On Sun, Apr 5, 2015 at 4:34 PM Roger Clark notifications@github.com wrote:

Avik

Thanks for the tip on the Spark project files.

Looking at the file you referenced, its author is the MCD Application Team

So I found this

http://www.codeforge.com/s/0/MCD-Application-Team-stm32

But I have not really tracked down who they really are.

— Reply to this email directly or view it on GitHub https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/36#issuecomment-89847768 .

[rogerclarkmelbourne]

Avik

Yes. Doing some more digging they appear to be part if STM.

However not all of ther files are under the same license

I will need to download the new version of STM Cube to get the F103 files, and look to see if they are also written by these guys

[WestfW]

https://github.com/spark/core-common-lib/blob/master/STM32F10x_StdPeriph_Driver/inc/stm32f10x_adc.h Um. Wow. It looks like the spark people just removed all the ST copyrights and threw in their own CC license. Check out the "changes"... https://github.com/spark/core-common-lib/commit/b0e32eeb28cc99a7390ba0ae12657fdafb23f783

I'm pretty sure that it is/should be fine to include in the .h files when you publish a build-related tool, but I wouldn't do THAT. That's just ... wrong. (I got really "careful" when I "derived" an assembler version: https://github.com/WestfW/Minimal-ARM/blob/master/inc/stm32f103c8.asmh)

I think: 1) It's OK to include unmodified ST CMSIS include files in compiler tools. 2) I think the old license allowed this, but it was pretty ambiguous. 3) The new license (from the HAL distributions) is clearer... 4) Modifying the ST files in any way should be avoided. 5) SPL and Cube/HAL should be avoided, except... They might get you easier portability to other ST chips. (which is not clear; I'm seeing lots of complaints about Cube, and there is a separate download and documentation for each chip family. Just figuring out whether the HAL apis are common across families is ... difficult.)

[rogerclarkmelbourne]

Bill,

OK.

Sounds like another can of worms :-(

I just downloaded the latest Cube and it then downloaded 100Mb worth of additional files, and poking around, in the headers etc, it looks like STM are doing a considerable amount of re-working at the moment. Dates listed in the headers I've looked at are either December 2014 or some time in 2015

If people are having issues with the latest version of the Cube it may be better waiting for the dust to settle before attempting to use any of the file ??

[rogerclarkmelbourne]

Guys,

I'm not sure if you are aware, but I setup a new forum for Arduino on STM32

http://www.stm32duino.com

We could move this discussion to a thread on there as its probably easier to manage, and leave this just as the issue

Note @madias123 also discussed a similar thing on the forum in terms of adding new functionality for I2S and possibly updating SPI to use the STM headers

Its something that is long overdue

[rogerclarkmelbourne]

Guys,

I'm not sure how far this will get but @sheepdoll has been looking at using the output of the STM CubeMX to generate HAL and Driver files that can be used with converted / ported files from the Arduino SAM core.

I've taken that work and for the NucleoF401 and started to look at the STM32F103CB

These files are now in https://github.com/rogerclarkmelbourne/HALMX_Arduino_STM32

Note. These files have been committed just so that they can be shared, there really is no functionality yet, unless you make calls to the HAL e.g.

void setup() {
  // put your setup code here, to run once:
}

void loop() {
   HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);
    HAL_Delay(200);/* Insert delay 200 ms */
}

But the code above does compile and flash the LED on pin 13 of my board.

@sheepdoll has only copied over a subset of the SAM core files, and only Arduino.h has been updated to load the relevant HAL core for the 2 boards we are looking at.

Next work is to build a PIN MAP array, and then re-import all the SAM core files and either remove or comment out all code to make all functions into stubs.

The stubs can then have HAL code added to perform the necessary functions

Note. At the moment its unclear if the HAL for the different processors is identical. e.g. whether the HAL for the F1 has exactly the same API as the HAL for the F4.

The F4 HAL doc can be found here http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf

The F1 HAL doc can be found here http://www.st.com/st-web-ui/static/active/cn/resource/technical/document/user_manual/DM00154093.pdf

It could be that this approach simply won't work, so this is really just some R&D about what will or won;t work, and may go nowhere, but is worth investigating.

Note. The only file we are aware of that has licensing issues is the linker file, and I suspect this is an oversight by STM (rather than something intentional)

However I have found what appears to be a replacement file, (from sourceforge), which I have put in the MXSTM32F103CB/ld folder Its probably not perfect but it appears to work, and may be usable as a basis for a linker file that doesn't have any licensing issues.

[bobc]

Old thread, but just a note about ST's "liberty license". It is deliberately not Open Source :

Product: means Your and Your’s end-users’ product or system, and all the related documentation, that includes or incorporates the Licensed Software and provided further that such Licensed Software or derivative works of the Licensed Software execute solely and exclusively on microcontroller devices manufactured by or for ST.

I asked ST about this, and they explained it is to prevent their software being used on clones. At the time I hadn't heard of GD32, so was a bit skeptical, but it seems the clones are real...

I am sure if you publish software designed to run purely on ST devices, ST would not come after you. But if you have explicit mentions of clone devices, i.e. GD32, then it's possible that ST would issue a takedown.

[RickKimball]

Seems like that strategy didn't work. The GD32 has an API that looks exactly like the SPL. Also how does the gnu arm eclipse plugin use the SPL without fear?

[rogerclarkmelbourne]

I thought GD had their own SPL.

The GD32 is not identical to the STM32, and it would be fairly easy for STM to prevent the Cube output working correctly on the GD32 by changing the value of some of the Reserved bits in various regs, as GD use these for additional features

[RickKimball]

I thought I looked at it before and it appeared to be a complete rip off. I could be wrong.

[RickKimball]

Here is a typical diff between the GD32 firmware lib and SPL 3.5

---
> void ADC_DeInit(ADC_TypeDef* ADCx, ADC_InitPara* ADC_InitParaStruct)
181,183d127
<   /* Check the parameters */
<   assert_param(IS_ADC_ALL_PERIPH(ADCx));
<   
187c131
<     RCC_APB2PeriphResetCmd(RCC_APB2Periph_ADC1, ENABLE);
---
>         RCC_APB2PeriphReset_Enable(RCC_APB2PERIPH_ADC1RST, ENABLE);
189c133
<     RCC_APB2PeriphResetCmd(RCC_APB2Periph_ADC1, DISABLE);
---
>         RCC_APB2PeriphReset_Enable(RCC_APB2PERIPH_ADC1RST, DISABLE);
194c138
<     RCC_APB2PeriphResetCmd(RCC_APB2Periph_ADC2, ENABLE);
---
>         RCC_APB2PeriphReset_Enable(RCC_APB2PERIPH_ADC2RST, ENABLE);
196c140
<     RCC_APB2PeriphResetCmd(RCC_APB2Periph_ADC2, DISABLE);
---
>         RCC_APB2PeriphReset_Enable(RCC_APB2PERIPH_ADC2RST, DISABLE);
203c147
<       RCC_APB2PeriphResetCmd(RCC_APB2Periph_ADC3, ENABLE);
---
>             RCC_APB2PeriphReset_Enable(RCC_APB2PERIPH_ADC3RST, ENABLE);
205c149
<       RCC_APB2PeriphResetCmd(RCC_APB2Periph_ADC3, DISABLE);
---
>             RCC_APB2PeriphReset_Enable(RCC_APB2PERIPH_ADC3RST, DISABLE);

[bobc]

Seems like that strategy didn't work.

I know it's kinda nuts, since when did the Chinese care about copyright? But that is the way lawyers think, and they are paid to write words even if they are ineffective. At least it might scare off some customers from GD32, or provide some leverage for a lawsuit. Of course, lawyers win again in that case. Good luck suing GD in China!

Business customers of ST or GD probably aren't affected, it makes it awkward for OSS people but they are not a commercial concern. I can see why many OSS projects start with a blank sheet to avoid any problems down the line.

[rogerclarkmelbourne]

I dont think this is an issue for the libmaple based repo, is it ?

I thought that Leaflabs had written most of the code to avoid the old ST license, or are there bits of the repo that still use remants of the ST code (I know there are bits and pieces all over the place but I'd not looked closely at the license in the header as its all inherited from libmaple)

Its more of an issue for the HALMX core, but I don't think we can support GD32 using the cube, its high lightly to have technical issues and supportability issues.

[rogerclarkmelbourne]

Edit I'm not sure if the Liberty License is the old one (pre Cube)

But that license was useless for Open Source as it forbids redistribution.

Hence why Leaflabs wrote a lot of stuff from scratch

I though the new license on the Cube was more open, and allows redistribution, but may only allow use with STM products

[bobc]

AFAIK all the original Leaflabs code is clean and written from scratch. The license I just looked at is from the Cube F1 page : http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef1.html under section "Legal", "SLA0048: Mix Liberty + OSS + 3rd- party V1 - SOFTWARE LICENSE AGREEMENT 2.1". I didn't check for their other code, it's probably similar.

Redistribution should be ok, it is the "ST only" that might cause trouble. It's a judgement call, but I would always start with something fully open, I hate doing things twice!

[rogerclarkmelbourne]

Thanks bob

I will mention this to @sheepdoll and @Serasidis who have been writing the code with the cube

[xxxajk]

Just do like many in the Linux community (yours truly inclded) has done.

WRITE CLEAN-ROOM CODE .

Don't look at other examples, etc, just use the datasheet and do what seems correct, bugs ort not, and correct bugs as they appear.

This approach is guaranteed to zap any copyright infringement, even if it does take extra work. Usually this sort of code, since it is thought from the ground up, ends up faster and better than canned stuff from the chip makers-- who are interested in selling IC's, not code.

Just my 2 cents....

On Sat, May 21, 2016 at 11:46 AM, Roger Clark notifications@github.com wrote:

Thanks bob

I will mention this to @sheepdoll https://github.com/sheepdoll and @Serasidis https://github.com/Serasidis who have been writing the code with the cube

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/36#issuecomment-220784810

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[rogerclarkmelbourne]

STM now released their own Arduino Core see github.com/stm32duino

Development work will probably still continue on this repo as I think it generates smaller binaries and has not license issues