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:
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
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:
Again, knowing all of the above are not required ... a big project can be broken down into bite sized pieces and learning grows.