Arduino Library Manager Inclusion

[NicholasTracy]

I've noticed that this repository hasn't been updated in over a year. I also noticed it is not in the library manager list for install and updates yet the repository has the 1.5 folder layout.

Can we get this library updated to work with the new Arduino library manager? Possibly along with ChiRTOS? Or is there something in the library that doesn't follow the new standards?

[per1234]

The library is compliant with the requirements of the Arduino Library Manager index. Here's what would need to be done to add this library to the Arduino Library Manager index:

1. Create a Git tag or GitHub release that matches the version value in library.properties.
2. Open an issue in the arduino/Arduino repository with a link to this repository requesting it be added to the Library Manager index.

[NicholasTracy]

If that is all that is needed then I don't see why a release tag couldn't be created so we can submit it.

The version number in the properties file shows 2018.8.2. That doesn't appear to follow the standard I doubt there have been 2,018 major versions 8 minors and 2 patches.

[greiman]

I am reluctant to add ChNil to the library manager. I will not be supporting this library in the future.

The last mod was in August 2017, not 2018.

It's just not practical to support real-time OSes as Arduino libraries. ChNil is now integrated with ChibiOS/RT and has many features that can't be ported to Arduino.

I now use systems like ChibiOS standalone. You loose to many features of the new versions of ChibiOS if you port to Arduino.

Porting becomes more difficult since ChibiOS assumes it has total control of the hardware.

[NicholasTracy]

That very well may be but there are plenty of us who would still prefer to have RTOS as a library for convenience. Moving over to another environment when you use so many different libraries and cores makes it difficult to want to switch. I do have ChibiOS installed but I haven't bothered diving in to it, I use MCUdude's mightycore for the 1284 at 20mhz in a few of my projects as well as the tiny core for 84/85s. If ChibiOS had some way to easily include many of the third party libraries I use as well as the cores for the AVR chips I use I would switch. Until then, having a library port of an RTOS is a godsend even if there are features missing. Frankly, FreeRTOS is already available in the library manager but I don't like the syntax and naming convention used. I do appreciate all the effort put in to porting this over though, thank you for that.

The last mod was in August 2017, not 2018.

I didn't say that, I was pointing out that the library.properties file had 2018.8.2 as the version number which didn't seem to be correct following the major-minor-patch format.

[greiman]

I understand the value of third party libraries, that's why I ported FreeRTOS to Arduino many years ago. I like ChibiOS better so I stopped updating my port of FreeRTOS and ported ChibiOS.

Fortunately FreeRTOS is easy to port so versions are being maintained by others and available in the library manager.

ChibiOS has a huge advantage because of it's HAL architecture. You only need to write small low level driver stubs.

Instead of porting ChibiOS to Arduino, I have considered writing an Arduino API translation layer for ChibiOS. Perhaps third party Arduino libraries could be used on native ChibiOS.

I did a prototype and used it with my SdFat library. It worked fairly well but it would be difficult to use unmodified Arduino libraries on native ChibiOS. Arduino libraries are not close to thread safe.

The upside was incredible performance gains. I logged ADC data to an SD at two million samples per second with almost no time jitter or lost samples on a STM32.

One idea is to have several cooperating Arduino sketches with each having its own thread.

By the way, look again at library.properties again it has 2017. I just stuck the mod date there instead of a valid version number.

name=ChNil
version=2017.8.2

[daitangio]

By the way I used ChNil with success for a couple of project: it is easy to understand and if I remembef only one interrupt is used so it easy to integratw with other arduino libraries

Please excuse typs as Sent from my iPhone

Il giorno 02 set 2018, alle ore 01:08, Bill Greiman notifications@github.com ha scritto:

I understand the value of third party libraries, that's why I ported FreeRTOS to Arduino many years ago. I like ChibiOS better so I stopped updating my port of FreeRTOS and ported ChibiOS.

Fortunately FreeRTOS is easy to port so versions are being maintained by others and available in the library manager.

ChibiOS has a huge advantage because of it's HAL architecture. You only need to write small low level driver stubs.

Instead of porting ChibiOS to Arduino, I have considered writing an Arduino API translation layer for ChibiOS. Perhaps third party Arduino libraries could be used on native ChibiOS.

I did a prototype and used it with my SdFat library. It worked fairly well but it would be difficult to use unmodified Arduino libraries on native ChibiOS.

The upside was incredible performance gains. I logged ADC data to an SD at two million samples per second with almost no time jitter or lost samples on a STM32.

One idea is to have several cooperating Arduino sketches with each having its own thread.

By the way, look again at library.properties again it has 2017. I just stuck the mod date there instead of a valid version number. I planed to

name=ChNil version=2017.8.2 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[greiman]

The ported version of Nil appears to work with most libraries but there are problems. Libraries are not thread safe so a library may fail if called from two threads.

Calls to delay() in libraries waste CPU time since since delay just spins in a loop. Delay calls should be replace by sleep.

Context switches can cause libraries to fail due to unexpected timeouts.

My Arduino port is better than nothing but native ChibiOS with HAL drivers is vastly superior.

I know it would be possible to provide a better performing Arduino API on top of native ChibiOS.

Particle WiFi and Cellular boards have the Arduino API and many Arduino libraries run on Particle boards. Internally there is FreeRTOS and the user programs run as a thread.

Here is a threaded particle program with three threads.

#include "application.h"

// LED Param, defines pin and delay between blinks
typedef struct {
    int pin;
    int delay;
} LED_PARAM;

// LED pins
int led1 = D5;
int led2 = D3;
int led3 = D1;

// Defines thread parameters
LED_PARAM ledParams[3] = {
    {led1, 500},
    {led2, 1000},
    {led3, 2000}
};

Thread* led1Thread;
Thread* led2Thread;
Thread* led3Thread;

os_thread_return_t ledBlink(void* param){
    LED_PARAM *p = (LED_PARAM*)param;

    // Start never ending loop
    for(;;) {
        Serial.print("Thread Parameters: ");
        Serial.print(p->pin);
        Serial.print(", ");
        Serial.println(p->delay);

        // Blink led
        digitalWrite(p->pin, HIGH);
        delay(p->delay);
        digitalWrite(p->pin, LOW);
        delay(p->delay);
    }
}

void setup() {
    Serial.begin(115200);

    // Set pin mode
    pinMode(led1, OUTPUT);
    pinMode(led2, OUTPUT);
    pinMode(led3, OUTPUT);

    // Start new threads
    led1Thread = new Thread("sample", ledBlink, &ledParams[0]);
    led2Thread = new Thread("sample", ledBlink, &ledParams[1]);
    led3Thread = new Thread("sample", ledBlink, &ledParams[2]);
}

void loop() {
    // Nothing here.
}

[daitangio]

So we must suggest to use ChbiOS port for arduino? I’d like to write a blog post in this subject...

Please excuse typs as Sent from my iPhone

Il giorno 02 set 2018, alle ore 14:41, Bill Greiman notifications@github.com ha scritto:

The ported version of Nil appears to work with most libraries but there are problems. Libraries are not thread safe so a library may fail if called from two threads.

Calls to delay() in libraries waste CPU time since since delay just spins in a loop. Delay calls should be replace by sleep.

My Arduino port is better than nothing but ChibiOS with HAL drivers is vastly superior.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[greiman]

Here are a few more reasons to build an Arduino API on a RTOS rather than port a RTOS as a library.

An RTOS and Arduino classes like String need dynamic memory. The Arduino malloc/free fail in threads.

delay() should do a context switch and sleep.

Wire, analogRead, and other API calls should sleep waiting for interrupts to wake. I wrote work-alikes for some of these but it does not fix libraries.

[NicholasTracy]

I must have misread that version numbering some how.

I do agree with you, a lot of libraries are not thread safe. quite a few libraries are actually written pretty poorly and don't use best practices. I tend to avoid those and write my own when I need to.

I'm all for the HAL and a driver for AVR chips. last i checked on the ChibiOS website there was only drivers for ARM chips. I would be happy to write my own but I won't claim to know the first thing about writing a HAL driver. I'm just now starting to get in to RTOS kernels and working with threads. I'm used to working bare metal so this higher level stuff is new to me. Having a legit abstraction layer would make porting my projects over to other architectures much easier and from what I understand it could speed things up too.

I still like the convenience of installing a core through the board manager, selecting the chip, selecting what clock frequency you want, selecting BOD fuses, selecting you programmer and being done with it. No lengthy tool chains or cli to mess with, no moving hex files around. makes prototyping a lot faster and convenient. I just wish other, more professional development environments would take some of those features and adapt them. ChibiOS could be one of them.

[NicholasTracy]

So here is my final question on the subject. Even though the core version of the port won't be updated, is there any reason not to still use it on Arduino for the rest of us not moving to ChibiOS yet? If the current version is stable enough and works why not just make it available on the library manager so that it is easy for those of us still using it in its current state to install? If nothing else it would just be an archival version and you could put something in the description stating it is not the most up to date kernel.