Hi, thanks for the offeer
I can help with the task of review and integrating the code in NuttX if you push it to github Best regards Alin On Mon, 5 Dec 2022, 05:44 Alan C. Assis, <acas...@gmail.com> wrote: > Hi Fotis, > > I think all the software you listed are interesting and are useful to > the NuttX community. > > As suggestion I think you could put it available on github and help > people to help clean it up and then submit a PR to NuttX. > > BR, > > Alan > > On 12/4/22, Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > > Hello everyone! > > > > Christmas arrived a bit earlier for NuttX as I would like to donate some > of > > my personal code to the community! > > > > A bit of context. > > Over the years that I am working on embedded systems, I have developed > lots > > of software that I use in my projects. > > Some of it is quite general-purpose, or useful for other applications, > and > > I have found my self reusing it > > quite often. In fact, there are some things that I use in practically all > > firmwares that I have developed over > > the last years. > > > > I always wanted to open-source this software so other people can benefit > > from it. > > But I never managed to do so. Open-sourcing needs some effort, the > software > > needs maintenance, documentation > > and support, and most importantly in most cases a "porting layer" needs > to > > be developed. > > Last but not least, every project needs a bit of "marketing" and > > "advertising" so others can learn about > > your work and use it. > > > > For the last couple of years I have been using NuttX a lot, and I have > > ported most of the aforementioned software > > to NuttX. I believe that NuttX and its community are perfect for me to > > publish my code, instead of creating > > a ton of small repos, of questionable usefulness and increasing my > workload > > considerably. > > > > It is very important that I can get immediate feedback from the > community, > > learn what people are actually > > interested in (instead of investing on software that no one needs), and > > provide actual and *working* > > samples of the code (as NuttX already supports a ton of different boards > > and arches). > > > > Using POSIX as the porting layer is also awesome. > > > > That being said, my free time is still exceptionally limited and I cannot > > do this myself. > > I still need the help of the community, and most importantly I need to > see > > interest in a piece of > > software before putting any work on it. > > > > So, what I offer: > > * I offer various codes, fully featured, production ready and tested. > > * All code will be offered for free (of course) and under Apache > licensing. > > * I will provide support to those working on these codes, to my best > > ability. > > * I will contribute to testing everything integrated to NuttX, as > hardware > > availability allows me. > > * I will do some licensing check, to ensure code is 100% original and > mine, > > or state the licenses of the projects I borrowed code from. > > > > What I ask for: > > I need people that are interested in each of these codes to integrate > them > > into NuttX apps. > > You just have to pick what it is interesting to you, contact me to > provide > > you with the code, > > and integrate it to NuttX. You will need to: > > * Add the code into the NuttX apps repo, and ensure Kconfig and the build > > system use the code properly (should be trivial). > > * Adapt the file format and the coding style to the NuttX one (this may > > need some work, but it can also be automated). > > * Provide an example app, something that someone can run to use or demo > the > > new code. > > * Test and verify the example app on actual hardware (I may be able to > > cross-check it on my hardware too). > > > > The code that I offer (for the moment): > > > > > > *** Lua v5.2.4 *** > > I know that there is already a Lua app for NuttX. > > But for anyone using it, it may be beneficial to use my work. > > > > First and foremost, I have ported the eLua LTR patch to Lua 5.2. This > patch > > dramatically reduces the memory usage of Lua. > > In fact, I found out that it is crucial to have this patch enabled for > any > > actual real-life usage of Lua on any "normal" MCU. > > > > I have created a Kconfig for all Lua configurations, so it can integrate > > with NuttX better. > > > > I have also made some other minor changes to the code that might be > > interesting for you. > > For example there is a simplistic sandboxing option. > > > > > > *** MQTT Broker *** > > Yes, a full-blown, spec-compliant MQTT Broker! > > To my knowledge there is no other open-source and portable MQTT broker > for > > embedded systems. > > > > It follows the MQTT v3.1.1 specification as closely as possible. I think > > there is only one violation, needed due to its embedded nature, > > but in all practical cases you may consider it fully compliant. > > > > It has been tested with dozens of devices, and it performs greatly. > > There are a couple of things that may need to be improved, but are > trivial, > > and will not affect the normal use of the software. > > > > I know that such a broker may not be your best option for a proper and > > large installation of IoT devices, but it is exceptionally useful > > for at least the following cases: > > * You have only a few devices, isolated (no internet), that you need to > > connect, and you want to avoid the cost (and maintenance) of a proper > > broker (e.g. Raspberry Pi). > > * You need to directly communicate with a device that only supports MQTT. > > Instead of going through an external server, you run the server locally, > > and communicate with the device directly. > > > > > > *** MQTT Client *** > > A production-tested, robust and quite flexible MQTT client. > > > > I know that there are plenty of such clients available out there, but > here > > is another one. > > > > Back in the day I tried to use the Eclipse Paho library. I found it to > be a > > horrible piece of software. Crashes, buffer overflows, spec violations, > > missing functionality and more. > > I don't know whether it has improved now, but back then I rolled-out my > own > > implementation. There were not many other alternatives available, and > Paho > > did not worth contributing to it. > > It needed so much work, that starting from scratch was much easier. > > > > Then, when I started using NuttX, I saw support for MQTT-C. Well, I tried > > it and I wasn't greatly satisfied (I don't remember the reasons). > > So I decided to keep using my own (and well tested) implementation. > > > > So NuttX, instead of relying on an external project, now can have its own > > client. > > > > > > *** Settings Storage *** > > This is probably my favorite. > > A key-value pairs storage for non-volatile settings or configurations. > > Very needed when you need to adjust the system's operation in run-time, > > download parameters etc. > > > > It acts in two layers: the settings API and the actual storages used. > > > > The settings can store or retrieve key-value pairs. > > Type casts are supported and are performed automatically. For example you > > can store the string "true" and then read it as the int 1 etc. > > There is support for caching writes (minimizing overhead and reducing > wear > > on the actual storage medium). > > There are signal notifications when a setting value is changed. > > > > The bottom layer, the storages, is responsible for actually reading and > > writing the settings map to the physical mediums. > > Every storage can also format the data according to its type. > > For the moment there are only ASCII and binary storages, but it would be > > very easy to expand this to JSON, XML, YAML and more. > > There is support for multiple storages used simultaneously, and > > synchronization between them (for example I usually use both the MCU's > > Flash and the SD card). > > > > > > *** FTP Client *** > > This is a client that I had developed before I learned about NuttX. > > I also tried NuttX FTPc, but I experienced may failures that I never got > > the time to troubleshoot. I just went back to the tried solution. > > One thing that I didn't really like in NuttX ftpc, it was that it is very > > taciturn. When something went wrong, you couldn't understand what the > issue > > is. > > The error information of this library is a bit better. > > > > If an alternative ftpc implementation is of interest to anyone, the code > is > > available. > > > > > > *** JSON Parser *** > > This is a very minimal parse-only JSON implementation. > > > > The motivation behind developing this was memory consumption. > > This parser can open an arbitrarily large JSON file (even MBs), using > only > > a few bytes of RAM! > > (If I recall correctly only 20 bytes!) > > > > Although there are other options there for you, if you need the smallest > > possible memory footprint, this is your parser. > > > > > > *** XML Parser *** > > Exactly as above with JSON. > > A minimal parser, that can open any file using just a few bytes of RAM. > > > > If you need something simple or you have memory constraints, use this. > > > > > > *** XTEA *** > > Simple XTEA encryption and decryption. > > Very useful when you need a quite fast way to encrypt (or obscure) some > > data. > > (Need to check licensing!) > > > > > > *** Sun Calculations *** > > A small library that can do astronomical calculations for the sun. > > That is sunrise time, sunset, day duration and more. > > > > > > *** Geolocation *** > > I used the ipgeolocation.io API and NuttX wget to get geolocation > > information about the device. > > Nothing special, but it may serve as a working example, or even > inspiration > > for others... > > > > > > If everyone is interested in any of the above please contact me. > > > > *PLEASE be responsible, and respectful.* (I am sure you will! :D ) > > If you request for a piece of software* you will have to help to get this > > into NuttX, and not only use it for your own personal gain*. > > >
