search

MausTec / edge-o-matic-3000

Firmware for the Edge-o-Matic 3000
GNU General Public License v3.0
103 stars 29 forks source link

Setup CI using GitHub Actions #18

Closed fenbyfluid closed 3 years ago

fenbyfluid commented 3 years ago

There are two commits here, the first commit fixes building using only the PlatformIO tools on Linux with no separate Arduino SDK in the include path, and the 2nd using the PlatformIO CLI to build a firmware image. I've tested the build on Windows as well to make sure it's still good there, but it didn't seem worthwhile to include multiple in the CI run as it is cross-compilation anyway.

I haven't tested the firmware image on any hardware yet, as I've only got the one and wouldn't want to take any risks - as this build process (and the HAL lib linked) appears to be a very recent undertaking.

fenbyfluid commented 3 years ago

I have a couple of questions about contributing to firmware development further:

MauAbata commented 3 years ago

I've been meaning to address these things, I didn't actually think anyone was paying this much attention to the code. I'm open for discussion, and if you're in the Discord that'd be great. Some quick points:

1) Licensing: I need to hash out a few concerns I have. In this case, my biggest fear is two opposing forces: A license so narrow as to ruin the spirit and freedom afforded by open source software, or a license so broad so as to damage the success of the Edge-o-Matic in some way. Building and selling this hardware is a business I must continue to grow--I don't have a fallback job, this is it right now, this is my entire career. I don't have much of a network or resources to give me insight into how to handle these cases, so I might just be catastrophizing the situation in my head a bit. Your feedback on this is welcome.

2) eom-hal: This is a Hardware Abstraction Layer, intended to slowly replace all the low-level interactions with the physical hardware. Since there was a huge parts shortage across the world, I have a few revisions of the hardware which are going into production, and I wanted a way to protect the hardware from improper access, but also set a level groundwork for firmware development which didn't care how the hardware worked, only that it did, eventually, work. The HAL detects and handles hardware changes appropriately, and is an experiment in a split build system and linking. My original intent with keeping the base of the HAL closed source was to ensure the only visible connection to hardware is a safe interface. That said, there isn't too much damage that can be done by setting incorrect voltage levels on GPIO and whatnot, most of this is just protocol stuff. I don't think this should be closed source either, and I haven't decided whether or not it has to be (see 1).

The HAL also includes code I use for provisioning and shipping out new boards, which includes setting the serial number, hardware configuration, etc. This isn't a grand mystery of how it works, it is just information that, for the boards I am shipping out, I would require that it is never tampered. Aside from rendering the board nonfunctional, changing the serial number makes it irritatingly hard to track and adjust various production defects that may arise in the future.

3) Flashing: So you caught me in a transition period where I have temporarily removed hardware references as I'm sorting out changes to those necessitated by parts going on year long backorders and the like. I didn't want to have a document published that indicates, for example, the pressure is an analog value on this particular pin, when it is in fact a serial data value on some devices. For this reason, I made the HAL a linked module that can be replaced with various other abstractions to support your own hardware if need be. One abstraction planned is a virtual test endpoint which simulates the result of HAL calls, and another is back to the ESP32 dev module on a breadboard, but this time with an actual stable pinout that's not tied to production models of the Edge-o-Matic. I get very nervous publishing an interface contract that I know is changing. All of this is an ongoing effort.

That said, all code on the main branch is compatible with production Edge-o-Matic units shipped out. The boards that have hardware revisions have not yet shipped, but code changes for them will be available before they do ship. If you have a device in hand, the current main branch code is compatible. Until hardware access moves to the HAL, don't actually change any of the hardware setup and configuration, naturally. And again, the HAL probably doesn't have to remain closed-source (I did clever things and I want to show them off). I just need to soothe my fears, first. I've been having a lot of them.

Again, your feedback is greatly appreciated. These are conversations I haven't had, and what few times I've initiated them they ended up instilling more fear that amounted to me feeling like I should focus more on applying for jobs than trying to grow an electronics company and employ others. This is all, even a year later, still frightening, unstable, and new territory for me. Decisions I make are not permanent, and only made for what I feared was the safest thing to do at the time. I want to make electronics, I think it's neat. There is, as it would seem, a frightening amount of paperwork involved.

MauAbata commented 3 years ago

After reviewing my notes from the previous weeks spent trying to work out this notion, I've decided GPLv3 works best. PR here for additional comment specifically regarding licensing: https://github.com/MausTec/edge-o-matic-3000/pull/20

W/R/T EOM-HAL, further discussion here about that is alright.

fenbyfluid commented 3 years ago

Hey, thanks for the responses! I think GPLv3 is a great fit for this code, nice choice. As the user base increases and things move towards a slightly easier setup path I hope community contributions grow - which was definitely my aim with a PR like this, having pre-commit checks just makes it so much easier to know what's incoming is sane, and it gives a reference for people to know how to get started building things locally as well (and unlike instructions, generally stays updated!)

The idea of eom-hal is definitely brilliant and makes perfect sense, it certainly should make general firmware development easier and safer, but I definitely would like to see it open source albeit with big "here be dragons" warnings. My interest in seeing it open and available is that I've become very passionate about the Rust programming language over the last few years, coming from a background as a professional C++ developer it makes reasoning about data lifecycle absolutely trivial (at the expense of some more upfront cost teaching the compiler what the rules are going to be). While it's not quite there for the architecture of the EOM hardware yet (although hopefully soon, there is an active working group for it), Rust has made great strides in embedded development already and its focus on fearless concurrency is just perfect for things like interrupt driven environments. So while not a near term thing, I'm super interested in exploring the possibility of a Rust port of the firmware and how that would shape up, and that would make sense to start at the level of something like EOM-HAL.

I do have a device in hand thankfully (and what a great little bit of kit it is) so it's good to know that the current state of things all lines up. There's a particular feature I want to have a shot at building out some time soon (multiple configuration profiles), but that shouldn't be going anywhere near the hardware level so should be all happy days to test locally anyway. I'll look forward to seeing more about those other test interfaces when you get there :D

I'm not currently in the Discord but I'd love to be - as soon as I can figure out how to make distinct identities work sanely on Discord you'll see me there!