Roadmap March 2021: Cooking with fire

[jwkblades]

As you have likely noticed by now, we are getting stdmicro to be a bit closer to something usable. It still has a long ways to go before I would view it as a drop-in project starter or a library capable of being the "go to" for embedded C++ applications, but it is moving. In the coming weeks, I plan on adding the following:

• stdmicro::Function (I already have the majority of the code worked out, but am having issues getting instance methods stored without also segfaulting when called (I may move this forward with that portion of the functionality omitted for the time being, as it is still useful)). I envision this being the primary interface for things, like IRQs, going forward with stdmicro. It will be a bit more spare required (we are looking at somewhere around 32 bytes instead of a standard function pointer - on a 64-bit Linux system), but the freedom and modern feel that it has is really useful in comparison to using a c-style function callback.
• stdmicro::MemoryPool A nice memory pool, which you can use to allocate objects against instead of new/deleting them yourself. This will, as we move into data structures and strings, offer you a nice way to limit the amount of RAM stdmicro will even attempt to allocate against - allowing you to segment off a portion of your available resources for stdmicro and not have to worry about the library eating everything your system has to offer.
• stdmicro::Allocator Primarily the same concept as std::allocator; the default one will almost certainly make use of stdmicro::MemoryPool.
• Enhanced font drawing capabilities! While font outlines are enough to get things moving, they aren't exactly production-worthy. Also, ~5 seconds to draw out a 800x480 display with 8pt font size is way too slow. It is worth noting that I am NOT going down the route of saying bitmap fonts are acceptable. In 2021, we want to use vector fonts everywhere. It is also worth noting that the fonts are currently the vast majority of the firmware size. Without a font being compiled in, the firmware is somewhere in the ballpark of 45KB (a bit of a guess due to recent additions in the e-ink example). The raw SVG font file itself is 31KB, so we are using about 3x the program space we should be at the moment.
• Getting an airlift. The ESP32 are nice little microprocessors, but not quite as low-power or simple to use as the Pico, so instead of adding a separate processor that we support when we are so early in development, I figured we could add a WiFi (and Bluetooth: Low Energy) co-processor to the mix. This will allow us to get online and start running some more interesting applications (over the air firmware updates, anyone?).
• Decoupling from pico-sdk. Don't get me wrong, I love what they have done and how easy they have made it to get started. I just want to get a bit further along the process of having Pico (and eventually other micro controllers) development feel more like a first-class citizen on Linux. What I mean here is that you should be able to go to a project directory, run make and have a firmware file pop out. The Pico methods currently require that you, as a developer and user, have a lot more knowledge of how to set up your project than I feel is reasonable. This process will also be cutting out cmake as a requirement in favor of using standard Makefiles.
• "Mock" processor! Great for allowing us to unit test non-processor hardware interactions on your development box and ensure that things are working as intended before you attempt to put them on real hardware. Of course, when you are unit testing hardware interactions, you don't have certainty that the code will work until you have actually tried it out, but once you get it working, having unit tests to verify your expectations remain true into the future can seriously help out when future-you fixes a bug and breaks an expectation in the process. Unit tests will be invaluable when dealing with non-hardware-related code changes, which will hopefully become more common as the foundations are built up.
• Tutorials! It is great to have code and examples, but that only goes so far. Tutorials and literature that people can use to quickly jump into the project, set up their local micros and hardware, and get comfortable feeling that they can contribute as well (or at least learn) is important for the future. I am all about knowledge, gaining it, sharing it, making it easier for the next person, and hoping that someone will someday create something amazing with it; it just requires that people put forth the effort to share what they know and have learned with others. I am not sure what these will take the form of at this point, possibly discussions, possible a wiki, or maybe a tutorial directory hierarchy within the project itself.
• Examples. At the moment, the example implementation is living in the root directory, this will eventually be split out with multiple directories, each of which are minimal implementations of a specific thing instead of a catch-all.
• Experimental. At the moment, this is really where things like the font drawing should live, but it is just jumbled in with the example in the root directory. Experimental functionality should, of course, be viewed as something that may drastically change at any moment, but is also fun for those looking to play around.
• Additional hardware support. That's kind of a given, considering the project you are looking at, but I felt it would be worth spelling out some of it:
  • NeoPixel RGB/RGBW RGB and RGBW LEDs that are individually addressable.
  • 7.8in 16-Greyscale E-ink Display Who doesn't want a 300DPI display that supports 4-bit greyscale? It is sure to be a nicer looking device than the GD7965 ;)
  • Micro SD card support, so you can persist data across power cycles. This may also wind up having a filesystem implementation being written up.

As far as priorities go, I really don't have much idea. Obviously, there are some things that I think will be released before others (such as stdmicro::MemoryPool before stdmicro::Allocator, which will be before stdmicro::String, etc.), bit I don't have a great sense of what people want. If you have input, feel free to post it here! I can't guarantee that I will follow the input given, but I will at least take it under consideration.

[marshall-mcmullen]

I'm really exciting to see this coming together @jwkblades . I applaud your initiative and your vision around this project. Looking very forward to it.