[stevestrong – Tue Mar 27, 2018 9:32 pm] –
I don’t know what is the situation for STM32DUINO and GENERIC cores, but for libmaple F4 my repo seems to be most developed, so it would make sense to add it there.
I could make it, i put it on my TODO list.
I will most probably do it after I solve the current issue with DCMI…
I ask because I have spent a considerable amount of time over the past few weeks welcoming new members, answering general questions, and attempting to direct members to resources. I have been warning newbies to select from Roger’s core or STM’s core if they expected forum support, but several alternate members cores seem to be mentioned and sometimes in a manner that conflict with Roger’s libmaple F1/F4 versions.
For libmaple, I think there should be only one recommendation that we all should suggest; I do not care how many cores get listed with associated pro/con, but I feel strongly that only one (1) should be recommended by other members as the primary one… both for F1 and F4.
Ray
Steve has done a good job with the F4 core, but I think his version has no diverged so that its hard to make a PR to bring mine up to date.
Also, even Steve’s F4 core is never going to be as up to date as my F1 core, as neither Steve nor I have time to keep things updated.
So I agree, for the most stable core people should probably use STM’s official core, or potentially STM32_GENERIC. (but from what I can see on the forum, there is very little traffic associated with STM32_GENERIC, so either it works perfectly or less people are using it… I suspect the latter.
Although I have some F4 boards, I have never used them in a real project. The F103Cx provides plenty of performance for the sorts of jobs I need a microcontoller for.
Thats not to say that the F4 is not suitable for some things, I just don’t personally have a need to for that much speed etc
[RogerClark – Wed Mar 28, 2018 12:47 am] –
RaySteve has done a good job with the F4 core, but I think his version has no diverged so that its hard to make a PR to bring mine up to date.
Also, even Steve’s F4 core is never going to be as up to date as my F1 core, as neither Steve nor I have time to keep things updated.
So I agree, for the most stable core people should probably use STM’s official core, or potentially STM32_GENERIC. (but from what I can see on the forum, there is very little traffic associated with STM32_GENERIC, so either it works perfectly or less people are using it… I suspect the latter.
…
Roger,
Yes.
… the F103 core is behind with PRs, the F4 core in your git is behind Steve’s core and you both Steve and you have too little time to work on priorities. Worst, the forum is growing nearly daily.
Therefore, the only prudent recommendation is to abandon all cores based on libmaple and only recommend the STM Official core as it is evolving quickly will be Officially supported for a long time in the future… from what I can observe Frederic Pillon and his back-end team at STM is doing a superb job. To recommend to this forum any other course of action would make me derelect as an engineer and IT architect.
I believe that my service to this forum is of no further value … I am therefore leaving as a member and I wish the very best to you, Steve, and the forum at large. It has been a fun ride for the past many years. The ESP32 is calling… I am behind in authoring projects on Haster.io.
Bye all,
Ray
On the F1 although there are 33 PR’s showing, in quite a few of them I’ve asked the author to clarify something but they not replied
I guess I should probably close those which are older than 1 month and are awaiting a reply
As you know, the problem with the PR’s is all the testing to confirm they are not going to break anything, so if no one but me and the author are involved in the conversation, then perhaps the PR is not really worth the risk, as it does not have relevance to most people
I had fully expected STMs official core to take over from LibMaple over a year ago, but for whatever reasons; probably lack of Maple mini and BluePill support and lack of support for bootloader uploads, most people chose to stick with LibMaple as it does 99% of what they want.
please don’t totally leave.
keep popping up from time to time, couple of times a week just to keep a weather eye on things.
stephen
ps. an automated response to a first post would have saved you a h*** of a lot of typing and repetition, maybe it devolved to a cut and paste 
please come back a.s.a.p after you “finished” your ESP32.
Me, and I think all other members, I really appreciate your devotement here in forum.
It is nice to read your valuable comments.
Me personally, I still want to keep with libmaple, because I find it slim, transparent and I know it better than I know HAL.
Regarding the F4 core, I am currently dealing with it on daily basis, so I will do my best to keep further PRs/requests issued to my repo for the generic F4 boards I own and on which I can perform tests.
Personally, I keep a maple mini connected to an sdcard and an lcd in 2 different ports, with DMA, FreeRTOS, PWM, Timer DMA, just as a test rig mainly for SPI, running a sketch that uses most SPI and SPI DMA functions, in 8 and 16bit mode, with callbacks. When I have made any change to the SPI library, I have tested it first in that one.
Perhaps if we decide on a few tests suites that different members have, and document them, we can set those as the standard test.
The pigoscope for example could be is a good test for ADC DMA.
I really hope Ray is not completely leaving the forum, but just leaving as actively day to day, his comments and advice are unvaluable, but I understand he has other priorities that he needs to attend.
I’ll get my coat 
I looked around for Arduno unit test software ages ago, but didn’t find anything.
I agree things could be test compiled, but I suspect that’s only 50% useful, as most code that gets submitted compiles in the onfiguration the author is using.
But I think it would be very time consuming to build a compatibility matrix for even the board selection and specific code uint tests.
Then there is the inter library compatibility and finally the internal and external hardware compatibility
Etc
Even with lots of people using the core(s) and libs, fairly fundamental problems can take months to be noticed, because there are so many combinations
E.g.
the SPI LCB library 16 bit default, took 3 months to surface
The bug in Hardware I2C for devices using addresses starting with 0x7-something took months to be noticed
Even google etc use their user base as testers, I don’t think we have any choice but to do basically the same.
E.g.
Perhaps if 2 independent users think a PR works for them, I better merge the PR, in the knowledge there is a 10% chance there will be problems
Actually, I view PRs that just add new functionality as fairly safe, especially if it’s completely new files.
New functions in existing files, I need to check nothing else changed.
Case in point yesterday, I had to do a visual compare on code to add RTC calibration and spotted a change to an existing function.
So I had to contact the author of the PR and ask what that new line of code did, and they replied saying that the line of code should not be there, as it was redundant or a mistake.
In this case the code changed one of the RTC registers, so it rang alarm bells with me even though I have no idea what the register settings did.
Apareantky the code would run with or without that line.
And now the PR in question will not automatically merge..
So I am forced to spend time manually merging it.
Hence you can see why there are around 30 un merged PRs for the F1, as each PR can take hours of work before it’s vaguely safe to merge.
As I have Nucleos and discoveries, The lib maple core was never much use to me personally. I abandon my own HAL based core when Generic and the STM cores came out.
Since I installed the System Workbench for testing my core, I have not had much reason to use the Arduino IDE either. Or for the most part any of the Arduino libs, as I can code in HAL directly. Then my interests have gone back to AVR ASM for direct control of things, If I have a project that need C then there is not a lot of reason to use a micro controller when Raspberry Pi exists.
I still check these forums every day or even up to 5 times a day. Waiting to see if someone comes up with a light weight dedicated MIDI USB library like what exists on the Leonardo. Problem is that there is too much HID and Serial boot loaders to wade through, to sit down actually do something.
I did get out one of my STM32L053 discovery boards, as I wanted to check out the e paper display. I also keep reading the bare metal ASM tutorials, For some reason I find that I like ASM programming, or else programming in the printer language Postscript. Lately I have been using postscript to write translators between ASM mnemonic sets. 68K,8080 and AVR. I also have the scripts that can parse the HAL libraries and the STM Cube settings for drilling down and distilling out the parts I need.
[zmemw16 – Wed Mar 28, 2018 8:30 am] –
@Ray
please don’t totally leave.
keep popping up from time to time, couple of times a week just to keep a weather eye on things.
stephenps. an automated response to a first post would have saved you a h*** of a lot of typing and repetition, maybe it devolved to a cut and paste
I agree to the two sentences!
As many “old” members know, I’d a “baby break” for 2-3 years, only looking rudimental into this forum.
As a came back last month I was totally confused by the mass of different cores available. I cannot say which core is better and why and why not. I use the libmaple core only, because of backward compatibility reasons with my older projects. Ok, there are also historical reasons, thinking back of the pioneer days fighting through the totally weird structure leaflabs has left behind.
One the other side: Most of the code examples and libraries tips & hints are for the leaflabs core, furthermore it was really good documented by leaflabs –> http://docs.leaflabs.com/static.leaflab … dex-2.html for getting some low level stuff working.
While most of us were using F1 boards only with stm32duino new cheap F4 boards came up in the past 2 years…
Pointing to the things above, this reflect the current forum situation:
3-4 different cores
multiplied with F1-F4 MCU’s for all cores above
multiplied with sub repositories from users
So who in our world can tame such a monster?
So Ray did his best in the past to welcome new users, I was really impressed how he answered every new “newbie” post. So here comes a big “Thank you!” to Ray.
with stm32 integrating bluetooth LE STM32WB
viewtopic.php?f=3&t=3274
things are bound to get more interesting (now there may be a ‘real’ alternative on top of nrf51822 and TI’s CC 2640
in the arena of bluetooth LE enabled mcus
i think what we are seeing is an ‘explosive’ growth of stm32 (duino) as a viable mcu platform for the mainstream arduino and such projects
stm32 (duino) is ‘going places’
with its cortex m3 / m4 core and arm gcc compiler those ‘simple’ projects here are reaching ‘industrial strength’ & ‘IOT’ calibre
i think before maple / stm32 (duino) a do-all-you-want usb accessory is pretty much a pipe dream, today with stm32duino/maple & all the (cheap) blue pills / maple mini made all these real, the blue pill/maple mini usb assessory role can simply be redefined simply uploading a sketch putting do all you wish usb in the end user’s hands, this has ‘never happened’ prior, a lot of mcus is still pretty much usb-serial + mcu
and with stm32 integrating bluetooth, things would likely get more interesting
i think we are moving from a stage of amber hot towards a white hot future just as linux has evolved since the embryonic days.
that throw away statement from Linus Torvads “I’d like to say that I knew this would happen, that it’s all part of the plan for world domination.”
is pretty much a reality these days with it being embedded in every android core and runs just about every super computers on earth
https://readwrite.com/2014/07/01/linux- … mmunities/
it seemed quite possible that stm32 (duino) is part of an extension, evolution of that megatrend
as to the cores, i think the plural of cores is merely a natural coincidence of this evolution, i’m still sticking with libmaple for stm32f103 as it ‘just works’ and i’m familiar with its codes and features (at least for those sketches that i’ve tried). we can continue to attempt to make the features more consistent across the cores, but divergence if it happens is only natural and not always a bad thing.
this is despite the fact that bluetooth le is insecure
that 6 digit pin for ‘just works’ can be easily be brute forced and cracked within seconds (only 1 mil permutations) if the pairing transactions is captured
https://github.com/mikeryan/crackle
https://www.blackhat.com/docs/us-16/mat … y-Tool.pdf
[sheepdoll – Wed Mar 28, 2018 10:41 pm] – Waiting to see if someone comes up with a light weight dedicated MIDI USB library
There is: https://github.com/arpruss/USBMIDI_stm32f1
But it’s deprecated in favor of a more general USB library that has a MIDI component: https://github.com/arpruss/USBHID_stm32f1
[RogerClark – Wed Mar 28, 2018 8:54 pm] –
Apareantky the code would run with or without that line.And now the PR in question will not automatically merge..
So I am forced to spend time manually merging it.
I think in all cases such as this the PR’s should dimply be rejected and the onus put back on the originator to resolve with a new PR.
Although whether this then incurs a greater burden on your original testing time for the subsequent PR is another question.
Perhaps some stricter guidelines on PR submission need enforcing and you just need to be way more brutal?
Tough one.
[stevestrong – Thu Oct 25, 2018 8:07 am] –
Generic (black) F4 and the mini (small blue) version are supported by libample core: http://stm32duino.com/viewtopic.php?f=39&t=1976
Yikes! This branch is 185 commits ahead of rogerclarkmelbourne:master.
Steve,
The issue for years has been “which core to use”; Roger has been the “master” github by default and the one I pointed new users, but by his own admission, STM32DUINO has not been his first priority. Additionally, Roger has on more than one occasion needed to back-out merges that had negative consequences; therefore, he is ever cautious to test the changes – so, all of this takes time. Thus, Roger’s hosted core is always a bit behind in pull requests.
We have discussed the issues caused by STM32GENERIC and the many forks. Essentially, the “use at your own risk (and self-support) has been the label used. I recognize that you are likely the most active senior member in the forum and certainly one of the most knowledgable, but how should I position your core when discussing recommended cores? Should it be primary to Roger’s or should it be secondary (“… use Roger’s core first and if you have an issue, then try Steve’s core before posting in the forum.) To my thinking, why not recommend Steve’s core as the primary download?
As you are aware, Noobies are troublesome because they often have little experience and often have inflated expectations. It was simpler when I could state there was 2 cores, an Official one for Nucleo & Discovery boards and a monolithic one inherited from Leaflabs by abandonment and updated & enhanced by numerous forum members and hosted by Roger. How do I fit your core into this recommendation as Roger has F4 support, too. And both you & Roger have F1 support. Maybe Roger should drop F4 and you drop F1?
Ray
I allowed myself to move your post here, as I find this a better place to discuss the topic. Hope you don’t mind.
I intend to keep to support the libmaple F4 core in my repo, however only for the generic boards: black F4 and the mini version, as I only have these boards.
In the future I may add support for Arch Max as well, but not for other official ST boards, for which I would also suggest newbies to use the official ST core.
I will also keep my F1 version, I made some tweaks compared to Roger’s core, and will do some more tweaks.
However, I won’t recommend my F1 core for anyone else, as it might not work for all variants, I work mostly on the blue pill variant, and the others may suffer under the tweaks. I actually intend to remove many other variants and to rework the file structure to simplify the build process.
So yes, you may recommend my F4 libmaple-based core but only for generic F4 boards.
And please do recommend further on Roger’s core if related to F1 boards.
[stevestrong – Fri Oct 26, 2018 8:53 am] –
…
So yes, you may recommend my F4 libmaple-based core but only for generic F4 boards.
And please do recommend further on Roger’s core if related to F1 boards.
Moving the topic was smart as I had already forgotten this earlier thread.
Your clarification is most helpful in understanding how to position your efforts to benefit the forum members that fall in the stated niche – such things are not obvious by reading the github discription.
Thank you for the explanation.
Ray
First thanks for all the work many contributors donate to this project.
This discussion is very very similar to the discussion on Micro-Python that has the same problem that the beast has taken on its own life with being forked in to many ports making for problems with compatibility and helping noobs.
Users have a couple of options with Micro-Python 1. use a older more stable version that is well supported or 2. use the lasted build of a fork that has more features but likely to have bugs not yet worked out and also to be much less support.
As for debugging of the newer more featured ports this is sort of done by the users. If u make the decision to use a bleeding edge port with new features then you have to expect it is new and less tested and may have some bugs. If you find a bug you report it and you face if you just report it without narrowing it down it maybe a long time before it is fixed, if you narrow down under what exact circumstances the bug arises it makes it easier for someone to fix and it may get fixed quicker.
My 2 cents is let the beast run wild and see what it grows into. Advise noobs about choosing a less featured more stable ports or bleeding edge ports and all user need to understand they r using free open source software, none of the contributors r getting paid but instead r volunteers.
As someone new to programming (just coming on 2 years now) I have really enjoyed the concept of open source community supported software.
[flyboy74 – Sat Oct 27, 2018 7:13 am] –
…
My 2 cents is let the beast run wild and see what it grows into. Advise noobs about choosing a less featured more stable ports or bleeding edge ports and all user need to understand they r using free open source software, none of the contributors r getting paid but instead r volunteers.As someone new to programming (just coming on 2 years now) I have really enjoyed the concept of open source community supported software.
I have been programming 44 years… back to COBOL. I was formally trained in Fortran 66 and found I was rather good at it. I went through the 6502 machines, assembler, BASIC, C, IBM PC, UNIX, and more OOP crap than I can remember … I saw the original open-source effort with ShareWare. I still remember my CompuServe ID. Wikipedia has a good history of Open Source Software.
All the above proves is that I am old.
Your 2 cents worth is rather descriptive of how things go: whether one wants it to or not. Proprietary software gets reversed engineered, old software gets refreshed, people ignore licensing and distribute, edit, redistribute and the cycle never stops. Github is a great facilitator for the process.
The software problem is that like biology, code reproduction can provide positive evolutionary traits and it can often mutate with negative consequences, like cancer. Unfortunately, unlike bilogy, code mutation does not just die off leaving the fittest, it just goes stale and hangs around in github and forums for years to come: the good, the bad, and the ugly.
To get back to your 2 cents, the forking of the MicroPython and associated changes can be good or can be bad… someone must manage the grading process. Here with the stm32duino forum, Roger manages the pull requests and the forum validates the changes. It is a necessary QA process and Roger has backed out changes due to negative consequences.
Ray
i’m for the plurality of multiple F4 cores including having the libmaple, stm’s own, and stm generic cores.
i’m of an opinion that they have evolved to serve different needs.
libmaple for one could be thought of as ‘hand coded’ and in particular the boards we work with are the likes of the STM32F103 BP/MM and F407VET6 black boards etc
libmaple core may in a way be deemed the ‘leaner’ core even if it is less feature rich compared to the HAL cores
while stm’s own core have somewhat different features and a slant with stm’s nucleos and discovery boards which is a good thing
while stm generic has been a good effort similar to stm’s core as it is based on HAL, but again the motivations are different and this aims to keep a similar code base for different stm32 mcus to some extent mirror stm’s own core
the different motivations along the development would bring us cores with different feature sets and this is actually a good thing
as after all mcus has limited resources and this is one way that libmaple shines as it seem to be a ‘leaner’ core to run on bp/mm
i like the same libmaple approach on F4 as well as it is ‘targetted’ towwards the F407VET6 mcus and boards
there are other F4 series like the F429 which perhaps could be covered by stm’s core or daniels stm generic core as those are HAL based.
while libmaple could be taylored around F40{5,7}{R,V,Z}{E,G}T6 and hence that’d lead to a leaner core
if i remember correctly, libmaple core is one of them that have the FPU ‘switched on’ on fhe F4, that’s after some wild benchmarks tests (competitions experiments) which pito and myself tried
the learning curve for newbies is unfortunately a problem we can’t really resolve, even in the plain old maple mini (and clones) there are all sorts of ‘tricks’ around pressing the ‘user’ button which is actually the boot0 button to trigger the ‘perpetual bootloader mode’. new users (happened to me once) stumble all over that button as if you press and hold boot0 while pressing reset it simply drops into STM’s own uart upload bootloader mode. in a similar way new users simply need to take their time to learn the ropes around stm32 (duinos).
ps. my guess about maple mini using the boot0 button as the ‘user’ button is an intentional design, this is so that the maple/stm32duino bootloader can be flashed from the uart using that same button after pressing reset, the designers pack 2 different boot functions in the same button / pin never mind if you are a newbie / noob or otherwise
But, I would like everyone that can to embrace STM’s corporate core for longterm support.
The libmaple F1 and F4 are at End Of Life, in my opinion.
Ray
Although the LibMaple F1 core is relatively stable, there is virtually no maintenance or development work being undertaken on it, because its good enough for my own personal use, and I no longer have any spare time to devote to it. (and virtually no one else is doing an updated to this core)
I’d recommend that new users try STM’s own Core, as this has official / funded backing from ST.
[RogerClark – Wed Nov 28, 2018 10:29 pm] –
…
I’d recommend that new users try STM’s own Core, as this has official / funded backing from ST.
… and to extend the benefits, Frederic and team are improving non-STM hardware compatibility. If something is missing today, it may be in a future edition.
Ray
stm’s core and stm32 generic are based on HAL and those would benefit users wanting to run the same apps/sketches on different stm32 mcus.
but that said i think HAL is 10s of megabytes to >100 megs? large. even if the core itself may be rather small
[ag123 – Thu Nov 29, 2018 2:17 am] –
…
but that said i think HAL is 10s of megabytes to >100 megs? large. even if the core itself may be rather small
I regret that your statement makes no sense to me – why would the codebase size matter? Wikipedia is huge but I do not plan on reading it all at one time.
libmaple will likely live forever but STM32duino is heading for mothballing soon. Others have already forked Roger’s source tree and it is getting updates outside the forum to support individual’s needs. Roger’s goal was to support the Arduino metaphor and to minimize divergence.
For members that like libmaple, download the ZIP or clone the git… no one is taking that away from you. But I do not recommend newbies to go the libmaple route. STM’s official core is the recommended path. What intermediate and advanced users do is their own business and my recommendations are not targeted to them.
Ray
