Layout and implementation about arduino_stm32 HOT 50 CLOSED

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

from arduino_stm32.

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.

from arduino_stm32.

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 [email protected]
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
#36 (comment)
.

from arduino_stm32.

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.

from arduino_stm32.

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 !

from arduino_stm32.

@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.

from arduino_stm32.

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 [email protected]
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
#36 (comment)
.

from arduino_stm32.

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 :-(

from arduino_stm32.

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

from arduino_stm32.

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.

from arduino_stm32.

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 [email protected]
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
#36 (comment)
.

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

from arduino_stm32.

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

from arduino_stm32.

Not currently practical with the amount of time I have available

from arduino_stm32.

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.

from arduino_stm32.

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

from arduino_stm32.

@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.

from arduino_stm32.

@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.

from arduino_stm32.

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.

from arduino_stm32.

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 ;-)

from arduino_stm32.

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!

from arduino_stm32.

Thanks Donald

from arduino_stm32.

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.

from arduino_stm32.

Andrew

Thanks.

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

from arduino_stm32.

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
micropython/micropython#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.

from arduino_stm32.

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.
  

from arduino_stm32.

Hi @WestfW

Can you send me a link to those files.

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

Thanks

Roger

from arduino_stm32.

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.)

from arduino_stm32.

@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.

from arduino_stm32.

@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.

from arduino_stm32.

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 |
| |
|   |

from arduino_stm32.

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 [email protected]
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
#36 (comment)
.

from arduino_stm32.

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.

from arduino_stm32.

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 [email protected] 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
#36 (comment)
.

from arduino_stm32.

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

from arduino_stm32.

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"... particle-iot-archived/core-common-lib@b0e32ee

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.)

from arduino_stm32.

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 ??

from arduino_stm32.

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

from arduino_stm32.

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.

from arduino_stm32.

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.

from arduino_stm32.

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?

from arduino_stm32.

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

from arduino_stm32.

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

from arduino_stm32.

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);

from arduino_stm32.

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.

from arduino_stm32.

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.

from arduino_stm32.

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

from arduino_stm32.

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!

from arduino_stm32.

Thanks bob

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

from arduino_stm32.

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 [email protected]
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
#36 (comment)

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

from arduino_stm32.

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

from arduino_stm32.