Should submitted libraries be in the Libraries folder ?

Guys,

Just a quick straw poll.

Should submitted libraries go in the libraries folder, or would you prefer if they were in a contributions folder?

Having them in the Libraries folder means that unless you already have a library with the same name in your main libraries folder, that you don’t need to mess around copying STM32 specific libs from a contribs folder to your libraries folder.

However I realise this isnt the “Arduino” way to do things, i.e The hardware / library folder only normally contains the core libs

But there are merits in both approaches and its for the community to decide which way you decide is best

MY vote goes for keeping in libraries any library that is ported specifically for the STM32F1 mcus, so it would not compile or work with a different MCU. I.e FreeRTOS and CoOS, they depend on setting a callback in the libmaple systick ISR routine. So the ported ones will not work on any board that doesn’t use libmaple as a base.

For libraries that work on different platforms, like the ILI_due, that works on AVR, DUE, Teensy & STM32F1, then it may be wise to put them on a different folder, and users can move it around if they want to use it, but I still think it is kind of convenient that when you download the repo, you are getting the libraries that have been ported to work with this MCUs. They are not readily available anywhere else, so is convenient to download something and be able to compile without having to dig what libraries support this MCU and what not.

If we take the long-term approach, likely the <user>/arduino/libraries would be more appropriate, but my personal preference – understanding that contributions are likely hacked by other than the author – is to stick them into /hardware/STM32/STM32F103/libraries (or whatever… F2, F3, F4 if not generic) … but there is the “rub” … a generic STM32 library would need to be in 4 places: STM32F1 … STM32F4 unless the newer GUI scans /hardware/STM32/libraries too… before dropping back to <…>/arduino/libraries.

Ray

I don’t think there should be any libraries in the Arduino_STM32 except for the Arduino core ones, SPI, WIRE .. etc.

I think if we post working/ported libraries to http://www.stm32duino.com/viewforum.php?f=13 the core code will become more stable and have less changes. Problems with libraries can be documented directly on the forum thread where it was announced. The forums seems like a better place to have a conversation about problems and how it works than the issues section of github. Code library maintainers/developers will put less pressure on Roger to make updates to their libraries in github and he can focus on the core platform support. This will result in a more stable Arduino_STM32 code and the ability of library maintainers to respond to problems changes and new version without bothering Roger.

-rick

Code library maintainers/developers will put less pressure on Roger to make updates to their libraries in github

That does sound like excellent reasoning to me.

Ray

Actioning pull requests into individual libraries inst much of an issue for me as its low risk.

ie if someone stuffs up, they only stuff up a single library.

Its a bit different for SPI and I2C, but for things like individual display libs, I have no issue with it.

Adding a topic for supported / ported libs requires people to host stuff either on github or somewhere else, and not everyone wants to do this.

So in some cases, I think stuff will need to be put in the repo somewhere even if its not in the libraries folder

@ray.

Re: F4 and libs

Yes. If the F1 and F4 code was merged this would be a serious issue, as most of the libs would need to be modified, as they can no longer do direct hardware access, and would need to make calls into some sort of thin HAL, which may be too slow (though I think in most cases would be OK)

I ported Dean Camera’s atomic.h lib from AVR to Cortex M3 a few years ago (originally for Maple, actually), and since it’s been donated it to Paul S.’s Teensy distro. He puts it in the library search tree so it can be accessed by

#include<util/atomic.h>

which is the same as in the AVR distro.

I’m happy to contribute this lib for this project as well, if you decide there’s an appropriate location for it. If you wanted it under util for source compatibility with AVR and Teensy3.x, one place that would work is

hardware/Arduino_STM32-master/STM32F1/system/libmaple/stm32f1/include/util/atomic.h

but maybe you’d have a better place in mind.

Hi pico

I’m not sure what atomic.h does , but if its good enough for Teensy its definitely good enough for us

Can you elaborate on how to use it, are there any examples ?

Ps. It doesn’t sound like a typical library, it sounds like a system enhancement if its in a util folder

The atomic.h lib provides a set of macros that are used in creating interrupt guarded blocks of code for critical sections.

For example, if writing a buffer handling routine where several pointers need to changed either all together or not at all in order to have the buffer in a sane state, and there is a chance an interrupt might occur midway through the section that updates the pointers, and the interrupt handler uses the buffer handler, then for safety, the interrupts need to be disabled for that section of code.

Disabling/re-enabling interrupts is not difficult, but the atomic macros make it all a bit neater and easier to keep track of where things are up to.

For example, if you wanted to protect this critical section:

ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
// critical section
if (!buffer_full) {
++ptr1;
buffer_full = (ptr1 == ptr2);
}
}


Thanks @pico

Do you need to do something specific to port this to STM32 , or do you think the Teensy or Due version would be OK

Can you send a link to the file on github etc

Thanks

Roger

RogerClark wrote:Thanks @pico
Do you need to do something specific to port this to STM32 , or do you think the Teensy or Due version would be OK?

@pico

I have a few more pull requests I need to look at today, but I’ll try to incorporate this in the next day or two

Thanks

Roger