Thea's work is immaculate, and always an interesting read. Her synthesizer modules use FR4 PCBs as the front panels as well, a technique that's pretty popular but executed so well it's beautiful. [1] Even her documentation is made with care; when I have more disposable to spend I'm definitely buying a module.
Great point on embedded dependencies - In theory they can be a time saver, but in Rust land, they're often too.. abstract, and full of missing features and bugs. Easier to open the datasheets, and send a few bytes down the SPI/I2C etc lines. I haven't been able to use any deps without forking. In Rust, popular abstractions tend to get in the way too, ie if a rust peripheral struct is trying to own a shared bus.
Another good point, re HALs. She skipped the official HAL after finding it to be too much trouble. I've found that a good peripheral access library generated from SVD files is all you need, and is easier to work with than a HAL that's not carefully made. Ie an API that provides named register blocks, registers, and fields, and knows how many bits go in each, which you can read from etc. (Is this what the CMSIS lib she mentioned is?)
Related to the last point: "I write very small, usually project-specific, abstractions over that" - If you decide a popular or official HAL isn't helping you, you end up writing your own HAL!
> I've chosen to avoid using the Node.js ecosystem in favor of just plain JavaScript
Something is weirdly rotten in the Rust embedded ecosystem. The overarching experience is best described as akin to C++ template metaprogramming. The final result is that setting a GPIO output somehow requires unwrapping an option, as if we didn't just set a single bit in some register and there were actual meaningful errors with that operation the uC could detect.
Typestates and reliance on `embedded-hal` traits are a particular pain. I think we're in a weird spot, where the language itself, and some of the build tools (Like those by the Knurling team) are outstanding, but the most popular libraries have made questionable design decisions, and have flaws that show almost immediately.
I'm curious how many teams are developing new projects using Rust, but staying away from the open source ecosystem.
It’s not just crates.io. I have a minimal, no Libc, no runtime dependencies Windows project for fun that compiles to a tiny executable of only a few kilobytes. If you’re going down this minimalist/better C route, you increasingly have to avoid large parts of the Core library as well, which is becoming more bloated by the minute. The culture seems to move in the direction of “avoid unsafe at all costs” (even where that makes the API so complicated that it hurts correctness in practice) and “avoid dynamic dispatch at all costs” (even where that hurts performance).
Your comment made me wonder if crates.io is starting to show some of the same issues that npm has. Lots of small packages, not always consistent, focussed on one use case that make other use cases non-optimal.
The recent posts about Rust in Android shows a side of this. They are avoiding Cargo in favor of plugging in their own build system. Use the language for its benefits and avoid the ecosystem (partly).
I think the case with embedded code on crates.io is more along the opposite: they're trying to make the experience as consistent as possible by defining common interfaces for embedded drivers so code can run consistently with different hardware or libraries. The problem is it's really hard to design such abstractions, especially safely, when you can't make many assumptions about the hardware it'll be abstracting over and efficiency is paramount.
To address unwrapping the GPIO set: this is caused by a (popular) misuse of embedded-hal traits. The traits are fallible to be general, but HALs use this as their primary API, and make it always pass. So unwrap is effectively clutter, and misdirection. The answer is to provide a primary API that's decoupled from the traits, and bolt on the traits to support generic drivers.
Very inspiring. I'm myself starting a similar journey with my first hardware product (https://getgumball.com) and it's really reassuring that it is possible to do something like this in "solo" mode. We hear a tone of people doing it in the SaaS work, but not so much in hardware - if anybody here knows other similar examples, I'd love to hear about it!
Feels good to follow through from a hobby project to an actual shipping product. Its been fun re-igniting all the things learnt during electronic engineering classes back in university.
What is an interesting contrast is that by day i'm a web/ios software engineer where memory and disk is largely plentiful, but by night i work on cramming TCP/IP + USB stacks and real-time audio decoding threads into less than 80KiB of RAM on a Cortex-M4 MCU.
Currently busy ramping up production of a small batch of units and adding checkout to the website.
> it's really reassuring that it is possible to do something like this in "solo" mode
I'm very new to the hardware world but sometimes it feels like you need a big team to do it.
Great product!
> We hear a tone of people doing it in the SaaS work, but not so much in hardware - if anybody here knows other similar examples, I'd love to hear about it!
Oh thanks! Yes, this website is still very much a work in progress I do it the "#buildinbuplic" way, so some content on the website still needs to be created / improved.
The biggest thing that I notice, is the extremely practical approach she takes.
Decisions based on reality, limits, and resources. Despite all that, she's a remarkably capable person that makes it all work; regularly, and repeatably.
I've had to make those types of decisions all my adult life. It's how we ship.
> A one-woman company requires a far different approach than any sort of company with more than one engineer.
An insight I feel many software projects could learn from, even in small to medium teams.
Every tool has overheads in learning, maintenance, edge cases, and interoperability. The more abstracted the less agency you have over the tool, and time savers become roadblocks. Keep it simple, fewest dependencies, and close to where you have the most agency.
Without knowing much about the hardware scene, this was incredibly easy to follow, informative, and generally really interesting. This is a cool overview.
Also very impressive. What an undertaking. I can see why someone like this would succeed - she seems exceptionally organized, knowledgeable, and competent.
I have dreams of getting into hardware sometimes, then people like this really temper that thought. I don’t have anywhere near the chops and brain power to pull something like this off.
So it looks like the Winterbloom module is taking a "pitch CV" input in the range of 0-6V... what would typically generate this input in this type of setup? And what do all those other modules on the rack do?
Normally you'd use a sequencing module to send CV to the oscillator. I suspect that's where the orange patch cable is coming from.
The rest of the modules do a number of things. In the actual patch (so, in use) you can see a Quadrax working as an envelope generator, a VCA, a pan mixer, a filter (in this case Mutable Instruments' Blades). It'd be hard to explain modular in a HN comment, but if this interesting to you and you don't want to spend a lot of money (modular is expensive), give VCVrack a look.
I am a bit confused about the writing. Sometime it is "I", sometimes it is "we".
Does it means there are other people involved? Contractors maybe.
Edit:
Answered my own question. Design is indeed a one-woman job, but helped by one other woman (and two cats) for production.
And looking at the downvotes, it looks I was the only one confused. I was wondering about it for the repository aspect. Working alone is an entirely different experience compared to having even a single other person on the same codebase.
As a (mostly) solo dev of a project, I do switch between I and we sometimes confusingly, at least on Twitter. "I" focuses on my work (which the project mostly is) but "we" sounds more like there is a community (which there is, and others have helped me). So I'm not always sure which one to use for things like "I am / we are planning this feature".
haha thanks. i collect it for my paid community #shamelessplug https://codingcareer.circle.so/c/creators-mastermind a small group of fellow creators and indiehackers here. i started with an infoproduct myself (made $120k so far, def recommend it to everyone before tackling your own SaaS), looking to work my way up to saas someday but am being patient with it.
If you have a personal project in Arduino that you really like, I'd suggest trying to get that running on a bare metal dev environment, As opposed to trying with a brand-new project.
In a previous job, we used Arduino (environment+boards) to quickly spin up prototypes and testing new peripherals, then moved them over to bare metal (avr-gcc+Makefiles, custom PCB) for our production.
And if it's not too demanding a project, give this a go with AVR first, it's much simpler to move to bare metal than with ARM. Feel free to email with any questions.
I love Lunchmoney but it pains me that roll over budgeting is not supported yet. It feels like the perfect personal budgeting tool for me only missing one very critical feature.
Hats off to this lady for running a one-person tech company. Doing all the tech stuff would be easy, but handling bookkeeping, taxes, supplies, logistics, vendor relationships, sales, customer relations, everything... I'd actually die. Loads of energy!
> I initially started with Makefiles, but it quickly became hard to work with. Makefiles are wonderful, but at a certain level of complexity it makes more sense to move to an actual turing-complete language.
Small nit, Makefiles are Turing complete. This of course does not negate the stated reasons for moving to Ninja -- despite being Turing complete Makefiles are frustrating at a certain level.
Not really, C is pretty deeply entrenched in the embedded world. Unless you want to bitbang something like a USB host, you’ll be relying on vender libraries, and those libraries are overwhelmingly developed in C. Same is true for pretty much the entire build chain, debug tools, etc.
C and C++ still seem to be prevalent. At least in my experience, rust on a microcontroller is still mostly theoretical. There's plenty of obscure languages, though, both compiled and interpreted / virtual machine based.
For "embedded" linux grade CPUs, rust is starting to gain some practical traction. A few years ago the idea of writing application level glue code in it was still a bit silly, but these days it's starting to actually get linked into production systems. It all seems to be done in a way that's interoperable with existing C/C++ codebases, though.
Explaining my experience - I haven't done any hardware or firmware programming besides messing around with Ardunios. I have written a low amount of C (tiny VM for toy language) and a moderate amount of Rust (a couple thousand lines for various projects, mostly console apps that needed to run fast).
It sounds like you have some experience in this and I have been curious for a long time why Rust can't or doesn't run on almost every micro-controller? Is it based on the compiler? I thought that because Rust has no runtime/produces a binary which does not require a runtime that as long as the Rust compiler emits the right backend instructions it should just work?
Adding to my confusing, I think rustc uses LLVM which is a way of separating a language's frontend from the backend code emitted, so I thought any micro-controller supported by LLVM would work for Rust.
My day job is writing Rust code for microcontrollers.
What you're saying isn't wrong, it's just that... embedded development is incredibly diverse. LLVM doesn't support as many platforms as GCC does, and even once LLVM gets support for something, we need to do some work in Rust to get things working; support isn't automatic.
If you get to pick what your hardware is, Rust is fantastic. If you don't get to pick... it's a roll of the dice.
I'm only about a third of the way through the rust manual myself, so I can't say with confidence, but I suspect that rust's safe memory abstractions don't necessarily scale down to the lowest end of MCUs. The machine code instructions that make the code efficient simply may not exist on an 8-bit segmented memory CPU. That also touches on the gaps in LLVM support. I'll bet it's perfectly viable these days on any cortex-m MCU, though.
Also, a lot of embedded code consists of peripheral drivers, and in rust that likely means "unsafe" code. At that point, it's a bit of a wash which language you work in. That's especially true since rust can interoperate with the C ABI.
I haven't familiarized myself with all of rust's built-in data structures yet, and I'm not sure how much stuff necessitates allocating on a heap under the hood. That would be a compelling reason to carefully consider its use in some embedded systems. That's analogous to C++, where it's typical to avoid most of the STL data structures.
Most of Rust's memory safety comes from compile-time checks, not runtime code.
You do need some unsafe, but not as much as you may assume at first.
Rust doesn't really have any complex built-in data structures, and doesn't require a heap at all. That's a standard library thing, which you wouldn't be using in this context.
Rust on a micro is more than theoretical. You could start a commercial firmware project on it today. However it is an extremely slow-moving segment of the industry so I wouldn't expect to see much of it for a while.
Definitely still mostly C. Although currently tossing up whether we use some very limited C++ for a new project: some templated types to handle memory safety, and some strict encapsulation.
I'm quite intrigued by Zig and am hoping to get in and play with it, since it aims to be a "better C" (not C++) so it remains a small language. See this recent post which triggered my curiosity: https://kevinlynagh.com/rust-zig/
(edit: more thoughts on Zig) I am intrigued because I want out of a new embedded programming language aligns perfectly with their approach. comptime instead of the C preprocessor, generics, any allocation is explicit (any memory allocation is at initialisation time), etc.
Kind of. Rust seems to be becoming quite popular. It has features that allow low-level programming while maintaining as much type safety as possible. There's even talk of using it in the Linux kernel.
EDIT: I'm not sure why you ask that here though. Rust doesn't appear to be mentioned in this post.
> I write our firmware using C. While some might gasp at using such an "old" language, it turns out that the combination of my familiarity with C, the maturity of its resources and tooling, and the low-level nature of writing firmware means that C happens to be a joyful language for me to write firmware in.
Which has the flavor of defending the choice of C as if it weren't the standard choice.
Realistically for most micro controllers it's the only choice other than machine code. Basically because it's the only one offered by the manufacturers.
C/C++ is the most common IME, but Rust is coming along nicely.
I'm working on a commercial firmware for ATSAMD21 using Rust, and have been finding it quite a nice experience. The tooling is great, PACs and HALs are at least as good as the last time I used the Atmel-provided ones, it's really nice being able to just add a line to Cargo.toml to bring in a library rather than cribbing from a prior project or writing my own.
That said, the Rust HAL for SAMD21 is certainly not complete; I'm working from a forked version of it, and have issued a few PRs to extend/fix it and other libraries. There are a few areas, DMA in particular, where the community hasn't quite decided on the right approach.
C is still by far the most dominant: even convincing embedded developers to use C++ can be a challenge. A subset of the rust community is focusing on it for embedded work, and it's very interesting for that in a few ways (relatively little technical reasons not to use it now: basically if it's an architecture LLVM can target you can write rust for it), but it's basically not even on the radar of most firmware designers (who as a group are fairly conservative and not likely to be looking for new languages anyway).
It’s similar to academic writing in single author papers. Generally you’d use “we” but specify “I” in cases where you’re emphasizing a personal choice. Also, “we” is often broad enough to include the reader, too.
As someone who's been thrust into the embedded world for the last couple years, I have to say that her posts are a breath of fresh air. Her other articles are well worth the time if you're interested in the topic.
I was wondering about this. Is it a company of, like, two people, where she's the engineer and there's someone else doing other stuff like marketing? Or is she alone, and if yes, why the plural?
Are there good beginner resources on working with kicad out there? I haven't really found much but maybe I'm just failing at my search terms because I'm not as familiar with the field as I should be.
Esp. really beginner "baby's first circuit board design" and also "making minor modifications to someone else's board".
I really enjoyed getting to know Thea and her work on an episode of the Embedded Podcast [1]. She has an infectiously positive outlook on open-source development.
I just this week shared my Open-Source DIY Eurorack Module [1] with the world, so I can fully relate to the article.
It is a TON of work to pull off what Thea is doing here, and then to execute it all with such exquisit marketing on top. I'm impressed and wish her all the best in this fun (but crowded) market.
I find it interesting that Thea always uses "Our" with respect to "our products", "our firmware". It's super interesting that even though it could be "my", she thinks of it as a product of a team.
I also don't see anything that is specific to a "one-woman" company vs "one-person". Not that there's anything wrong with that; the title is accurate. Just wanted to point out this is applicable to everyone regardless of gender.
Eurorack is full of small sideproject companies like this. You can get your product in front of a good chunk of the market just by posting in a few forums (where also blogs etc pick it up). + some social media and maybe loaning out a few review units.
Thea's sharing the preferred parts list is particularly generous. There's a ton of work summed up in there. It's interesting that 0.100" headers and Eurorack hardware are coming direct from China but tact switches aren't.
I find her use of the words "me" and "our" refreshing. I've created a bunch of mostly unsuccessful businesses(1) and haven't really resolved this language for myself. Here are a couple quotes from the first paragraph...
> exactly one engineer - me
followed by
> our current tech stack
This is something I struggle with when I'm writing about my own business or product. Sometimes "our" feels like the right thing to say but I know it's really just "me". She seems to have resolved this herself and uses "our" when speaking about the company, the technology, company philosophy, etc. It's kind of refreshing and she might have just helped me decide it's okay to say "our" as a solo maker.
The royal we serves an excellent purpose. A rule of thumb could be: imagine you hired an employee. What would stay "we" and what would stay "me"? In the former case, the fact that you are solo is an implementation detail and should be abstracted from your audience.
Although she is the only engineer, I'm assuming she is not the only person in the company, so the use of "our" might be a reference to the tech stack "used by the company" in that context.
It's not. There is a C specification that requires quotes to be escaped within strings; there is no such specification for English. One can write English sentences that require arbitrarily distant pieces of context to be parsed correctly (much like perl, where one can write lines which may or may not be comments based on the state of some other part of the program), and such sentences may be unwise, but are by no means incorrect.
> As written, it sounds like the production assistant is separate from the person.
Of course you are the best judge of what English usage is ambiguous to you, but your suggestion of introducing a comma there is at odds with the convention that you can tell whether a noun following a conjunction is a subject (i e., starting a new independent clause) or an object (ie. the conjunction is bringing together two objects into one collection) by whether it follows a comma. I think your proposed cure is worse than the disease; personally I didn't find lvh's sentence at all difficult to parse.
>>As written, it sounds like the production assistant is separate from the person.
Interesting, when I first read it I did understand that the production assistant was the person he was talking about. But yes, I can see why it could be confusing.
This is how I think about it as well. Though I make the decisions, I do that for a corporation. That corporation is not the same as “me”, though it may have only one owner at the moment.
Our is the two together : Speaker/Writer + Reader/Audience. When I am writing something with the mindset of explaining it to others, even code comments, ours feels more natural to me. Imaging a person sitting across the table, and we are demonstrating something. So instead of saying, "Now I am going to turn this nob", it feels more natural to me to say "Now We are going to turn this nob".
Yeah it's been interesting for me too when running a one-man SaaS side project. I want to break the mold of obviously being one person pretending to be many. When I used a boilerplate privacy policy as a starting point for my app, I had to go through and edit all the "we" and "our" language to either use first person, passive voice, or the name of the app.
As I said in a downvoted post, I disagree. The post is a technical writing with an emphasis on setting up an environment for a single person.
For a technical writing, I would treat it like code, use the most accurate word possible, and here it is "me".
Even more confusing since by looking at the company website, there is more than one person involved. For example "When we use a third-party library, we pull its source directly into the firmware's source tree" implies that someone else has access to the repository when it doesn't seem to be the case.
It's not a court hearing where things have to be accurate or you're lying.
We generally is understood to be - me + project/company because the person and the project are not the same thing. Code bases do not get updated to reflect me/we grammer as people come in and leave.
Also technically a company is an artificial person, even a single person project can be we.
I appreciate your sentiment, but "only" is not accurate. Most comments have been remarkably positive; the rest come with the territory of a large, public internet forum. The community has acquitted itself well in terms of downvoting and flagging those.
You seem to be saying that Thea isn't a "real" woman. That's insulting, gross, and incredibly inappropriate. It's not "controversy"; it's insults and hate hidden under this plausibly-deniable veneer of "conversation". It's bigotry and bullshit. I'm glad those comments are dead, and hope yours follows.
Yeah Thea is as real of a woman as any cisgendered woman. It's upsetting that the commenter couldn't realize that there are legitimate claims about cisgendered women lack of representation in tech, but to come out with hateful language derails any useful discussion. They are literally creating a flame war while decrying that HN can't talk about certain topics. Also I am not sure this comment section is the place to talk about it.
> a self-identified gender that in this case differs from the writer's apparent sex
Sorry, but this is pretty tone deaf itself. How are you, or I, or anyone but the author suited to judge their stated gender? Shouldn't we leave that distinction up to them and just move on?
The point of this discussion is the tech she is working on, and I think that's a really valuable conversation in and of itself.
All this makes sense, except that programming microcontrollers without C++ leaves you in a world of pain. Most of what one uses C++ for, in that environment, happens at compile time, automating stuff that is bound to go wrong if you keep trying to do it by hand.
So, no virtual functions, no memory allocations, no smart pointers, probably no exceptions. But, templates that earn their keep. The normal experience with C++ done well is no need for debugging. Debugging microcontroller code is a royal pain, so preventing whole orders of possible bugs is worth a lot.
I guess it depends on who is doing it. If that's not your experience yet, it could be. Lean in on the type system, and make it work for you. The fewer bugs you leave room for, the fewer you get.
Why can't the word "man" be used to apply to both sexes when it is clear that it is being used in the sense of "person", ie "The tools and tech I used to run a one-person hardware company."
The title somehow implies that some of the choices are a consequence of the author's gender when they are in all likelihood purely technical.
Women should use "man" to refer to themselves in such instances. If it starts bothering "men" aka males, then the need to switch to "person" becomes more obvious.
A point to note, there are many languages where the term to express "one man" is gender neutral. Perhaps languages like English should rethink their usage of such language.
> The title somehow implies that some of the choices are a consequence of the author's gender when they are in all likelihood purely technical.
This implication reads as pure projection in your part. There is absolutely nothing else in the title or article to substantiate it. The author as a woman more likely just used the term as she is a woman and indeed the sole founder/worker of the company.
The simple fact that is in English language "man" is often used to apply to both sexes, the most common one being "Man"kind, another example being "Chairmanship".
A company being run by a single person is understood to be a "one-man" company even if it is run by a woman, because the emphasis is on the fact of being run by a single person rather than a single person of a particular sex.
PS. Have HN users become a downvote happy bunch in recent years, or is it just my imagination?
Hi Thea. I run a one-person OSHW business too. [1]
Assuming your volume is greater than a dozen pcs/month, you're doing both yourself and your international customers a massive disservice by not outsourcing fulfillment and logistics (at least for international buyers).
I went to order a single nut from your store, and the shipping to Australia was $35. Of course, this makes small purchases prohibitively expensive. But more than that, it shows that you don't care about your buyers from outside of the US, and conversely shouldn't expect them to care about you.
This especially matters if/when your products become cloned. Piracy is a service problem, and any markets you are not serving properly will be serviced by the copycats.
I make a small electronic gadget in the US, and international shipping is a nightmare. I'm also a build-to-order business with a low sales volume. My recourse has been to simply limit myself to domestic sales while sharing my design. I am guessing that some of my products "leak" out of the US by people ordering through a forwarding company.
There is some kind of insane massive asymmetry in international shipping costs that really does make it prohibitive to ship anything out of the US.
However, if you've figured out how to do this well, I'd love to read more about it. Maybe another blog is in order. ;-) There are some things that are mysteries to me, such as what kind of inventory level is necessary to make everything run smoothly but without losing your shirt.
Yeah, I do have a tendency to shit on other people's ideas without offering a constructive alternative. I should probably stop doing that...
Anyway, I don't know how applicable 3PL is for products that are built to order, but for something mass produced it really is as simple as putting barcode stickers on them (I use a $50 desktop label printer for this) and then sending a box of them to a Chinese 3PL company (ChinaDivision etc.).
This can and should be done from day 1 (again, probably not for bespoke items unless volume is high!), and will cover basically every country on Earth except Iran and North Korea with cheap and reliable logistics.
Loudly trumpet that shipping is free (or fixed cost) no matter the buyer's location, and you'll get a lot of goodwill from buyers in underserviced markets.
The next step from there is to set up an Amazon FBA presence in various markets worldwide. Even if you don't sell much inventory through their site, you can take advantage of Multi-Channel Fulfillment to send stock cheaply from a local warehouse.
I pay something like US$50 a month to be a part of their logistics network, plus around US$5 per package for fulfillment and logistics regardless of location.
Regarding inventory levels, if possible I'd recommend always holding enough stock to cover 6 months' worth of baseline sales at all times. If your product relies on word of mouth for discovery, a feature on a site like Hackaday (and the ripple effect that causes) could easily cause 3-6 months' worth of sales in a week. I learned this the hard way last year.
Best of luck with your business, and if you want to have a chat about logistics feel free email admin at espotek dot com. It's something I really care about and it kills me to see so many people do it wrong.
So do I. My answer is to just pass the cost on and swallow the value of my time. So if an order comes in from, say, the UK I just tell the buyer that the price includes US shipping but shipping to their country will cost $$ extra. I invoice them that amount and once they send it, I package it up, fill out the Customs forms and send it.
I don't think I've ever had someone complain about the extra shipping cost: I think they're used to it.
I manufacturer my OSHW in Shenzhen and ship from there, shipping was far cheaper but thanks to Covid that's becoming less and less true, largely because the really cheap shipping was essentially people filling empty space in air-mail containers - and there's so fewer planes flying there just isn't that space. I'm now charging my customers a surcharge (but eating half the extra cost) - it still costs half of what I'd pay if I were shipping from here in NZ.
FWIW, with music gear it is more common that you buy the product from local stores carrying it. Only a few production runs in is a bit early to have good international coverage for that (especially if most of the batch is sold out in preorder anyway, which is what I'd guess at), but from the website that's clearly in the works.
[1] - https://twitter.com/micktwomey/status/1383527521744867338/ph...