Hi all,
I am, possibly, going to port the Arduino platform to support the DA1469x.
But before I decide what abstraction layer I am going to choose I would like to know what maintaining a port requires for the Arduino platform.
Is there documentation on this subject or does anyone have experience with maintaining a port?
I am grateful for any information you could share with me. Please, do not hesitate to ask me any question.
A lot of work, potentially for a long time. Maybe Dialog will hire you, or at least pay you. (or maybe they'll stop making the chip. Or go out of business. Or be acquired by some other company.)
So let's say you do the port, and you think it's "finished." At a minimum, you still need to:
Watch for user complaints indicative of bugs in your code. Or features you didn't implement (maybe features you didn't plan to implement.) Some significant number of these are likely to be "stupid questions" not specific to your core or the dialog chip 
Watch for changes from Dialog in their presumably-semi-proprietary Radio code (assuming you already figured out how to include and support that in your Arduino core.) Or if their SDK changes. (Atmel/Microchip is on something like the 4th backward-incompatible iteration of their ARM SDK. SAM Arduinos (Due) uses Rev1. SAMD support (Zero, etc) is "bare metal", but is now using an "outdated" version of the CMSIS files.) Make fixes and changes as appropriate. Support new protocols as they come along and reach a certain market density. (IPv6? The latest encryption?)
Be prepared to need to add "variants" if the chip becomes popular enough for third parties to start building boards.
Keep an eye on your source code repository provider. Arduino used to be on "Google Code", but it went away. Github has been bought by Microsoft...
Watch for changes from Arduino in terms of what is included in their core and APIs, as well as how your cores is installed and updated. You can choose to ignore changes and hope your users are OK with "the old way", I guess. Or you can update aggressively and annoy the users who DID like the old way. This means watching whatever official Arduino core you are closest to as patches go in, and figuring out whether those patches are relevant to your core.
Watch for libraries that become popular that aren't immediately compatible with your core. If they're popular enough, port them. Have fun if they're fundamentally incompatible (WS2812 "neopixel" is a good example of something that is moderately difficult to port between cores.)
Maybe things go great, and you collect a bunch of other people "helping" to "add features" and "fix bugs." Be prepared to spend some time evaluating their contributions and saying "no" a lot (but "nicely"!)
You might also worry that Dialog decides that they really like having Arduino Support for their chips, and goes off and hires someone else to do it "better" than your core (or does it internally.) (I don't know exactly what happened with STM32 and Roger Clark, but it doesn't look much like I would have liked it to go.)
PS: I don't believe that Arduino has any special provisions for 3rd party developers, in terms o things like "early documentation of directions" or "warnings about future changes." Some of that happens on the mailing list (you know about the "Developers" Mailing list already, right?)
But given that folks like Adafruit and PJRC are "frequently" seen asking stuff like "can we please get our improved xxx into the standard core", they don't seem to have any "special standing."
(maybe that's not true. The IDE support for adding 3rd party boards and packages is pretty much phenomenally better than most other IDE vendors; especially ones with their own hardware products. I'd suspect that there was SOME behind-the-scenes discussion of how that was all going to work. But I don't know.)
Well, I think it is worth noting the way the most recent significant advancement in the Arduino development software, pluggable discovery and monitors, was handled: This system was based on a contribution to the classic Arduino IDE from Paul Stoffregen:
which then needed to be expanded and ported to Arduino CLI. An RFC was published for each component of the project:
and these were advertised on the mailing list. The pluggable discovery RFC had a ton of high quality input from the community, and there were some significant evolutions of the proposal in response (the community was not so interested in the pluggable monitor RFC, but it followed the template of pluggable discovery closely). This was followed by the implementation and documentation of those proposals in the public open source Arduino CLI repository, done via pull requests with plenty of time for reviews from the community.
So this was all done very much in a transparent manner that was open to input from interested parties. But I'm sure you could point out other cases where it went differently. Maybe it is a sign of improvement though? The same process is being used for the "build profiles" feature.
I also think the ArduinoCore-API project is a positive thing for 3rd party platform developers. But you would certainly be justified in arguing that Arduino is not so receptive to community contributions in this area. As you say, a big part of maintaining a popular open source project is turning down proposals. I think it is essential for Arduino to maintain direction and a specific vision when it comes to the Arduino API, and that is not compatible with accepting every thing anyone happens to throw at it, even if technically sound. But as you also say, the proper way to do that is by saying "no" nicely, not by ignoring the contributions.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.