You are reading a single comment by @Kolban and its replies. Click here to read the full conversation.
  • I would suggest the following ... this is going to be a long post ... sorry for that ...

    I'd like the project to be 110% open with no private repositories and complete and open communication between us all. We bring different skills, experiences and interests to the table. Whether one is a kernel C programmer, a JavaScript tinkerer, a hardware designer or just a consumer of the eventual Espruino on ESP32 ... we all get to play. There will be opportunities for folks to write tests, play with builds, write up notes, guides etc etc. So no-one should feel left out. In addition, if one is merely "interested" in an area, we can make time to chat, discuss or write it up. There need be no hidden knowledge and the more we share, the more eyes on the project ... the better.

    The project is a game in two halves. We start with the excellent code and architecture which is Espruino today. This code base has excellent support for alternate platforms (ESP32 is considered a platform here) and allows us to create "code" that is platform specific while the majority of the Espruino iceberg is platform independent and hopefully needs not be touched for an ESP32 port.

    The second half of the story is the new ESP32 platform. As I study this device, I find that the documentation is still being baked. As such, there is going to be much to learn in this area and there are no experts we can lean upon at this early time. Much of what was learned from the ESP8266 port can be leveraged ... but also ... much is new. It is appearing unlikely that Espruino for ESP8266 will "just compile" on ESP32. The underlying framework has changed to a real time operating system (FreeRTOS) and the networking APIs changed to be the "sockets" API.

    The runtime libraries and compilation procedures have also all changed.

    Then there is the elephant in the room ... availability of ESP32s. We don't know how quickly they are being produced nor their prices. They will eventually come down to a few dollars each (guess) but availability and price may not reflect this in the short term. Thankfully, I have an instance and we can "share it" over the network when needed.

    What this says, is that the project can be broken down into a wide variety of factors and tasks. Does anyone have any opinions or recommendations on how we manage and track these? The source code control system will be a branch in Espruino Github. That way the source changes and issues we raise will be recorded in history for the project ... but what should we use for discussions and design plans? Maybe a Wiki page at Espruino Github? Maybe gitter chat? Maybe there is some other distributed project tracking mechanism available to us that one of us might recommend.

    As for desirable skills and reading ... some of the following would be ideal:

    • C language programming - Espruino is written in C
    • ESP32 APIs and architecture - the ESP32 IDF , the ESP32 tech docs.
    • Espruino from a user's perspective
    • Espruino internals (as found on Github)
    • The Espruino build system
    • Using Github
    • Using Doxygen
    • Project guidelines, standards and overall conformance
    • BSD Sockets API
    • FreeRTOS API

    Again, knowing all of the above are not required ... a big project can be broken down into bite sized pieces and learning grows.

About

Avatar for Kolban @Kolban started