Discussion: Supporting the Arduino ecosystem

[beriberikix]

I’d like to start a discussion about how to support the Arduino ecosystem. The target audience are hobbyists who want access to different hardware than Arduino supports, room to grow with more capable APIs (ex. mixing Arduino methods with Zephyr) or need to access specific libraries that aren't easily implemented in baremetal (ex. BLE, OpenThread.) Arduino themselves have been going down this path by using Mbed OS as the base of their newer devices. Note that since Mbed OS is maintained by Arm, it is unlikely to support the variety of architectures supported by Zephyr.

@soburi developed a proof-of-concept trying to make it simple to import Zephyr as a library in the Arduino IDE. See https:/soburi/arduino-on-zephyr. It proved to create a lot of maintenance overhead (as currently implemented), but shows it is possible. We’ve been discussing possible alternative approaches here.

I’d love to get feedback from those interested in Arduino support / have ideas on how to approach the effort / interested in contributing.

[beriberikix]

To continue the discussion, I think there's a few areas to discuss:

• How to integrate the Arduino framework so that apps can use Arduino-compatible APIs and libraries (current ideas are external libraries and modules)
• What's the target environments? Arduino IDE, arduino-cli, Platformio, west
• Should it be a "monolithic" project, combining every target & environment or should it be split up?
• Where should this all be hosted and distributed.? The Arduino code is licensed under LGPL, making it incompatible with the Zephyr license.

[soburi]

Hi, @beriberikix, and all.

Thank you for introduce my project.
I got some insight from my experimental arduino package.
I think policy and strategy of my project are 'not so bad', but there may be better ways.
I write below about this problem, based on my experience.

1. API Implementation

From my point of view, there are no serious problem.
Mostly function are already provide from Zephyr, need only to go aheading implements and improvements of wrapper.
Fortunally, Arduino-API is stable and not so much codes.
However, I faced one problem. Describe below.

• [problem] Need GPIO configuration query function.

AVR has separate register that GPIO in/out configuration and intterupt setting (DDRx and EICRx).
pinMode() and attachIntterupt() are set in/out register and INT register by each, but Zephyr's GPIO API is one function to set both.
So we need to implement "read-modify-write" for a set of GPIO/INTERRUPT settings to emulate original Arduino behavior.
But no available GPIO setting query function on zephyr, thus can't implement the read part.
I think need gpio_pin_config_query function.

2. Building source

Arduino source is build by arduino-builder system. That is far from generally 'make' systems.
My package implement a tool to wrapping cmake and ninja commands. The tool gather command-lines that execute from arduino-builder, and analyse that to generate cmakefile and run.
The build process is a normal Zephyr's that.

My package is seem well worked, but need more effort to reduce maintain cost.

# The difference of build system between Arduino and Zephyr is based on their fundamental of design.
# Unfortunally, the dirty hack will remain until the end, I think.

# Most significant difference with commonly make system and 'arduino-builder' is searching include path by brute force.
#arduino-builder try compilation many times with combination of include paths to determine correct include paths.
# The behavior make allow that Arduino programmer don't need toconsider header file structure. I feel it is important difference between 'arduino' system and 'arduino-like' system.

3. Board Configuration

It is difficult problem. Config file is frequentry need to create in Zephyr development, But not considered in Arduino IDE.
Arduino prefer configure peripherals in a code. But Zephyr prefer config outside of a code like as prj.conf.
Kconfig reduce a complexity of system configuration. But it is still complex rather than 'old good days 8bit micom'. It is hard for newbies.

Provide GUI or Provide preset configuration are good help for this problem, but not perfect solution.

---

I think, it is two task is exists to provide Zephyr based Arduino environment.
The one is implement Arduino APIs on Zephyr environment.
The another one, make Arduino IDE (or other IDE) supports Zephyr.

Already I wrote, there is not so difficult problem to implementing APIs.

In my opinion, providing API implement as a Zephyr Module is prefered approach. Because it is naturally fit to Zephyr. We can use every tools such as west command and PlatformIO that already support Zephyr.
It also can support compile '.ino' file by implement CMake rule.
In this case, different with Arduino is only that need to contain 'CMakeLists.txt' and 'prj.conf'.

If Arduino APIs is implemented in Zephyr, to make Arduino IDE supports Zephyr is become a not complex (but not easy) problem. That is generate a configuration and just kick a Zephyr's build process.

# Even if Arduino IDE runs many things until kick a build process, that is different problem. And it is partially solved in my experimental project.

I guess "monolithic" project is prefere way.
Because Zephyr's API provide single abstraction of hardwares, (Ideally) It should be as single implementation.
# Even so said, not well abstracted hardware difference are exposed sometimes...

Some already existed Zephyr Module are contains proprietaly licence code. (Like a vendor specific HAL codes.)
I guess providing as module is also good by viewpoint of source license.

In my opinion, Firstly provide Arduino API as zephyr module and concurrently improve Arduino IDE support is good way to proceed this task.

[sslupsky]

It is unfortunate Arduino chose to go down the Mbed path.

IMO, Zephyr has done an excellent job of simplifying the build environment. It is as easy building an app in Zephyr as it is in the Arduino IDE. If you need to customize your Arduino build environment in any way, it gets very complicated quickly. The Arduino IDE is a great improvement on make. Perhaps Zephyr has evolved beyond the Arduino IDE.

I would recommend adding Microsoft's VSCode to the list of environments. I work in that environment when doing Arduino or Zephyr projects. If you haven't tried it yet, you probably should give it a whirl. There are a few quirks but overall it is pretty good.

[beriberikix]

Huge fan of VS Code, for just about every form of development (including via Platformio.) I'm really enjoying #21119! I use to be the product manager for Particle's Workbench and can attest to how much developers love VSC.

The reason I think it is valuable to have an Arduino API layer and Arduino IDE story is less about the people currently using Zephyr but to enable those who are not. That way, through the Arduino ecosystem, developers who are ready to take their skills to the next level, can do so through an incremental step rather than having to learn about the commandline, CMake, threads, etc. to start.

I believe it would only add to the Zephyr community and bring in more users. Once they start digging into the docs, learn about the tools, I'm sure they'll also want to "upgrade" to the more capable APIs, west, etc.

[sslupsky]

Agreed! I read an article by Limor Fried over on Adafruit's blog that said a similar thing ... it's all about getting more developers and doing that involves making the underlying technology invisible.

Zephyr is getting close to being a huge thing. I think it will have a profound impact in the embedded world. There are still a few rough edges but overall, it is quite impressive. When using VSCode with Zephyr, the development environment is like Arduino on steroids.

[beriberikix]

I recently discovered https:/arduino/ArduinoCore-mbed, which might be a good template for creating an adaptation layer for Arduino. Thoughts?

[sslupsky]

I am uncertain that helps much. Maybe as a template of what needs to be done. I think we need a new "core" ... ArduinoCore-zephyr

[beriberikix]

Agreed, but it could a similar pattern of adopting https:/arduino/ArduinoCore-API, implement the .h using Zephyr functions and build a generator for each specific board (which could be automated with Github Actions.)

[sslupsky]

Just has a look at the ArduinoCore API repo. That looks quite interesting, I was unaware they were doing that. Could be very helpful.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[beriberikix]

@jhedberg would it be possible to convert this issue to a Discussion topic? I recall seeing the feature in the launch but I don't know if it is available in the Beta. Otherwise I'd be happy to start a new discussion.

[jhedberg]

@jhedberg would it be possible to convert this issue to a Discussion topic?

Sure, no objections. FWIW, I don't have much personal stake or opinion here. IIRC I added then question label when I was release manager for 2.2 and we were triaging open issues.

[beriberikix]

Ah, sorry about that! I just saw you were the only maintainer on the thread :) I assume only members can migrate an issue into a discussion (if that's even possible!)

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[DhruvaG2000]

I completely understand the benefits to the community of this project, however I am still unclear on how exactly we should proceed with this.

Fundamental question I have is that zephyr is a contantly evolving RTOS Project. However after having a look at https:/arduino/ArduinoCore-nRF528x-mbedos they seem to have archived, which in my understanding means they have dropped further development. Means in future if there is any additions to mbed OS, they will not be reflected in the Arduino IDE framework?

I wonder if this will be counter productive if we were to do something similar for zephyr as zephyr is a very active project. Someone will have to constantly maintain this new "ArduinoCore-zephyr" which imo seems difficult for the life of this project. We should find a way to somehow have the entire zephyrproject as a sort of git submodule in the project such that a simple fetch from upstream should bring the latest zephyr features to the user. I however am not too sure if this is even possible as code refactoring or changing of function names/ APIs can break things entirely.

After going through arduino on zephyr perhaps if we could automate the steps mentioned there in the README, we could achieve something similar to an arduino IDE style code as it seems to have been done here: https:/soburi/zephyr/blob/arduino-api-example/samples/arduino-api/arduino_blinky/src/main.cpp

[per1234]

However after having a look at https:/arduino/ArduinoCore-nRF528x-mbedos they seem to have archived, which in my understanding means they have dropped further development. Means in future if there is any additions to mbed OS, they will not be reflected in the Arduino IDE framework?

That is incorrect. As is mentioned in the readme, it was archived in favor of another Mbed OS based Arduino core that has a broader scope. That project is very actively developed and maintained and continues to update to new versions of Mbed OS:

https:/arduino/ArduinoCore-mbed

[DhruvaG2000]

I guess I missed that. It does seem to be actively maintained, and we could definitely take some inspiration from their structure.