Lessons learned by a software guy venturing into hardware(sidecart.xyz)
sidecart.xyz
Lessons learned by a software guy venturing into hardware
https://sidecart.xyz/blog/2023/11/01/lessons-learned-by-software-guy-venturing-into-hardware/
57 comments
As the author of the blog post, it’s disappointing to hear that you didn’t enjoy it. My article was never about claiming to be a hardware expert, but rather about sharing my personal experience as a newcomer for those interested.
What I find concerning is the unwelcoming attitude towards newcomers like myself, prevalent in some hardware and electronics communities. My critique in the article is directed at this exclusionary mindset. It’s important to remember that every expert started as a beginner, and a dismissive approach does not benefit the community. We all have unique contributions to make, and diminishing the experiences of newcomers isn’t constructive. Let’s focus on fostering a community where learning and growth are encouraged for everyone.
What I find concerning is the unwelcoming attitude towards newcomers like myself, prevalent in some hardware and electronics communities. My critique in the article is directed at this exclusionary mindset. It’s important to remember that every expert started as a beginner, and a dismissive approach does not benefit the community. We all have unique contributions to make, and diminishing the experiences of newcomers isn’t constructive. Let’s focus on fostering a community where learning and growth are encouraged for everyone.
I think several of the slightly negative responses are because the article is about "creating a side project for a specific user segment...in a tiny market," plus discussion of business considerations, and the headline suggests something much broader.
The HN audience has folks from all aspects of hardware design, from architecture, to RTL coding, to physical design, or hobbyists programming FPGAs, etc., Saying "hardware was an entirely new world for me. I found it to be an unforgiving, harsh, complex terrain," just sounds wrong to them, like you're drawing conclusions about a huge field based on a narrow hobby project.
You seem to have set out to write an opinionated piece with a particular point of view, and said in your intro that you were going to be controversial, so you must have expected not everyone would agree with everything you said.
The HN audience has folks from all aspects of hardware design, from architecture, to RTL coding, to physical design, or hobbyists programming FPGAs, etc., Saying "hardware was an entirely new world for me. I found it to be an unforgiving, harsh, complex terrain," just sounds wrong to them, like you're drawing conclusions about a huge field based on a narrow hobby project.
You seem to have set out to write an opinionated piece with a particular point of view, and said in your intro that you were going to be controversial, so you must have expected not everyone would agree with everything you said.
> Manufacturing Isn’t That Difficult
That’s literally one of your headings. You can’t hide behind the arrogance of the EE community when you say stuff like that, especially if you’re just ordering a four layer board from JLPCB. No offense but you didn’t manufacture anything - you did the equivalent of spinning up an EC2 instance via the web interface, installed nginx on it, and blogged about it as if you were a cloud architect. That tone permeates the post, despite the titular admission.
I would approach any professional community with much more humility. Especially when you’re still learning stuff like ”When assembling parts, you may face delays if some are unavailable.”
That’s literally one of your headings. You can’t hide behind the arrogance of the EE community when you say stuff like that, especially if you’re just ordering a four layer board from JLPCB. No offense but you didn’t manufacture anything - you did the equivalent of spinning up an EC2 instance via the web interface, installed nginx on it, and blogged about it as if you were a cloud architect. That tone permeates the post, despite the titular admission.
I would approach any professional community with much more humility. Especially when you’re still learning stuff like ”When assembling parts, you may face delays if some are unavailable.”
> I felt like using Amazon Web Services for the first time in 2006!
Literally I say that manufacturing is like using AWS in 2006…
Literally I say that manufacturing is like using AWS in 2006…
As an EE/firmware engineer working in the field, don't listen to the naysayers. Just because it's not some 10 layer RF board doesn't mean it's not a rewarding project and a worthwhile product. For the record, the products we design and assemble in-house are only 4 layer boards, and our business is doing just fine.There's too much elitism in engineering. I think the article is awesome; you found out a lot of pain points that I deal with regularly. The only nitpick I have is that I wish more people were on the side of open source hardware than patents.
> I think the article is awesome; you found out a lot of pain points that I deal with regularly.
Imho the most valueable part of the article is between the lines: showing how many aspects are in play, how long the route from first experiments to shippable product can be.
The devil is in the details. And those details can differ a lot depending on project, expertise or suppliers. For example one pcb manufacturer may have very different capabilities, pricing structure or quality control than another. Picking suitable components is almost an art in itself. Etc etc.
Imho the most valueable part of the article is between the lines: showing how many aspects are in play, how long the route from first experiments to shippable product can be.
The devil is in the details. And those details can differ a lot depending on project, expertise or suppliers. For example one pcb manufacturer may have very different capabilities, pricing structure or quality control than another. Picking suitable components is almost an art in itself. Etc etc.
I personally don't see a problem. Writing shouldn't be limited to experts, as long as person clearly identifies what it is and what it isn't. Both in the title and introduction of article it clearly says that it is experience of person who is new to field. Which to me implies that whatever they are saying should be taken with grain of salt and that they might not have exhaustive or fully accurate knowledge. It doesn't claim to be "ultimate reference book for everything hardware". That doesn't change the fact that that's experience they got as beginner. It's up to you decide whether reading beginners experience is useful to you.
On the other hand it also means that the problems person encountered are likely nothing extraordinary. And that it's something other beginners should watch out and further research, as they are likely to encounter similar challenges. Beginner articles can also be useful for those who have no idea where to start as means to gather keywords for further reading.
Having beginners share their experience might not be useful for most experts. But it can be helpful to highlight common pain points and areas of potential improvements for educators and people making tools.
On the other hand it also means that the problems person encountered are likely nothing extraordinary. And that it's something other beginners should watch out and further research, as they are likely to encounter similar challenges. Beginner articles can also be useful for those who have no idea where to start as means to gather keywords for further reading.
Having beginners share their experience might not be useful for most experts. But it can be helpful to highlight common pain points and areas of potential improvements for educators and people making tools.
Yeah, I think it's fine, and even very positive, to be sharing their view. However, I do agree with the sentiment that "hardware" used as a generalization is confusing. There are lots of different kinds of hardware and the article does not clarify it anywhere, although you can derive what they mean through the later descriptions. I had to re-read the intro once I had figured out what "hardware" meant.
Personally, I'm also a software engineer who ventured into hardware, and even am now professionally doing hardware design. I find that perspective worthwhile. But I am an ASIC engineer, which is a very different kind of hardware than PCB design or integrating ICs on a breadboard. The lessons and realities of each are different. So I would find it helpful if the post (and title) clarified what specific field was being discussed.
Personally, I'm also a software engineer who ventured into hardware, and even am now professionally doing hardware design. I find that perspective worthwhile. But I am an ASIC engineer, which is a very different kind of hardware than PCB design or integrating ICs on a breadboard. The lessons and realities of each are different. So I would find it helpful if the post (and title) clarified what specific field was being discussed.
>> Asking an expert and getting explained is invaluable, but what I found particularly disheartening is the treatment of ‘noobs’ in amateur electronics forums. Being insulted when asking questions is not pleasant. I thought ego issues were unique to software development communities, but they were not. If you need to ask questions on the forums and you’re learning, you better have tough skin.
> So it is with hardware, and personally it frustrates me when software people think they can generalize about the "hardware" space because they printed a 4 layer with JLCPCB and now they know the "hardware" world and its ins and outs.
You appear to be who he is complaining about. I'm an embedded dev, and what he wrote isn't far off the mark - I see more inaccurate posts of about from software-only devs.
> So it is with hardware, and personally it frustrates me when software people think they can generalize about the "hardware" space because they printed a 4 layer with JLCPCB and now they know the "hardware" world and its ins and outs.
You appear to be who he is complaining about. I'm an embedded dev, and what he wrote isn't far off the mark - I see more inaccurate posts of about from software-only devs.
The Author stated that they had experienced hostility when asking questions. While I'm not sure to what level their experience was, I can share the many times I've tried to answer a hardware question in many forums , I found the the individual who was asking was just looking for a quick working solution to their design idea (mostly a school project) and not really willing to take input on how to figure the solution out themselves. Many became hostile when I would not provide the schematic (with calculations) for them. That got old fast and convinced me to not try to help out any more. It's unfortunate that I can't share my 30 years of hard earned design experience with someone who truly wants to learn but I don't have the time to determine who is genuine and who is not. I'm just not going to deal with the hassle anymore. I get plenty of that at my day job....and they pay me to tolerate it.
All I can do is point someone in the right direction and give a few things to read. But nobody wants to read.
Unfortunately, doing hardware is hard without reading. Lots of it. Choosing a part requires reading datasheets by the dozen or hundreds, so you get fast at skimming them but when you pick one and design its circuit, you need to read every damn page of that PDF. And then go and dig up the errata if it exists too.
Lots of knowledge about hardware exists either as institutional knowledge in people's heads or in books. But, electrons and physics still work the same way they did 30 years ago, so there's no reason you can't read an EE book from that long ago to get foundational concepts.
Coders (myself included) try to Google our way to the fastest solution to each problem. Why read API documentation if someone has a solution on stack overflow? Unfortunately papering over knowledge gaps will often explode in your face because there inevitably will be mistakes, and now you have to wait 4 weeks to respin and assemble a new board.
Long turn times and physical costs require a bit more level and less yolo in hardware. So there is no reason to become allergic to reading if you want to be in hardware.
Unfortunately, doing hardware is hard without reading. Lots of it. Choosing a part requires reading datasheets by the dozen or hundreds, so you get fast at skimming them but when you pick one and design its circuit, you need to read every damn page of that PDF. And then go and dig up the errata if it exists too.
Lots of knowledge about hardware exists either as institutional knowledge in people's heads or in books. But, electrons and physics still work the same way they did 30 years ago, so there's no reason you can't read an EE book from that long ago to get foundational concepts.
Coders (myself included) try to Google our way to the fastest solution to each problem. Why read API documentation if someone has a solution on stack overflow? Unfortunately papering over knowledge gaps will often explode in your face because there inevitably will be mistakes, and now you have to wait 4 weeks to respin and assemble a new board.
Long turn times and physical costs require a bit more level and less yolo in hardware. So there is no reason to become allergic to reading if you want to be in hardware.
I try to handle this by not being too invested. If the poster hasn't mentioned anything other than "help me," then I point them at resources to learn with a suggestion of where to start.
If they say "I did X Y and Z but I have problem W" then I try to provide more directed, actionable assistance, or at least explain how to debug the problem.
That at least keeps me feeling like I'm being helpful, but not wasting my time.
If they say "I did X Y and Z but I have problem W" then I try to provide more directed, actionable assistance, or at least explain how to debug the problem.
That at least keeps me feeling like I'm being helpful, but not wasting my time.
This article initially upset me because it muddied my hardware honeymoon memories and attacked my perceived future. However, I’m glad I read the whole thing because I the author actually did the thing and built something and wrote about it. It is one of those rare blog posts where things don’t go perfectly well and the author is not some sort of flawless god. Experience is gold and this article lays it out raw, I love it.
I’m newish to embedded software and hardware and I find it difficult but oh so rewarding. Highly recommended.
I’m newish to embedded software and hardware and I find it difficult but oh so rewarding. Highly recommended.
There's a reason why it's called "Hardware" and not "Easyware".
The very same reason why it's called "Software" rather than "Dependaware".
The very same reason why it's called "Software" rather than "Dependaware".
I'm on a similar adventure right now, an ex-software person building a motorized iPhone stand that is Bluetooth controlled.
It's been fun to see how with Fusion 360, a 3D printer, and JCLPCB you can build all kinds of devices. YouTube and GPT-4 are excellent tutors for hobbyists entering the hardware space.
The 2 week wait for custom parts from China makes you realize the advantage they have over there when it comes to the rapid prototyping stage of product development.
It's been fun to see how with Fusion 360, a 3D printer, and JCLPCB you can build all kinds of devices. YouTube and GPT-4 are excellent tutors for hobbyists entering the hardware space.
The 2 week wait for custom parts from China makes you realize the advantage they have over there when it comes to the rapid prototyping stage of product development.
The two week wait just tells me you don't value your time during the rapid prototyping stage. Why exactly do you need a manufacturing process during prototyping that is exactly the same as your manufacturing process? Ok the domestic manufacturer charges 50€ more for the same PCB (price at 10 units) but they offer rapid turnaround including shipping in three or even less days.
As far as spinning boards goes, you can get bare pcbs back from China in a couple weeks. If you pay extra, that can be 10 days. I use a Korean quickturn when I need the PCB shipped within 3 days, but it costs a pretty penny.
Producing PCBs domestically in the US is a sad joke. There are only 3 types of fabs here:
1. Stuck in the 80s and can't do much more than 2 layers and 10/10mil
2. Super high-end govt contractor ITAR jobs programs. Great quality but thousands for a run
3. Other shops that claim to produce pcbs but actually just farm them out to a partner in China and reship.
So even for protos China pretty much always wins.
As a price comparison, let's take an 8layer board I quoted through Screaming Circuits in the US. $4k. PCBway can do the same board for a bit over $300.
Producing PCBs domestically in the US is a sad joke. There are only 3 types of fabs here:
1. Stuck in the 80s and can't do much more than 2 layers and 10/10mil
2. Super high-end govt contractor ITAR jobs programs. Great quality but thousands for a run
3. Other shops that claim to produce pcbs but actually just farm them out to a partner in China and reship.
So even for protos China pretty much always wins.
As a price comparison, let's take an 8layer board I quoted through Screaming Circuits in the US. $4k. PCBway can do the same board for a bit over $300.
Would you mind providing a reference to the Korean quick term service do you use?
U&I
quickturnpcb.co.kr
It's not just the fab.
Have you found domestic assembly services that will take a hobbyist prototype order, charge less than $2k and turn in under 2 weeks (US or Euro)?
For ~100 SKUs and 200-400 placements.
Have you found domestic assembly services that will take a hobbyist prototype order, charge less than $2k and turn in under 2 weeks (US or Euro)?
For ~100 SKUs and 200-400 placements.
I think he's implying he buys his ICs and components from China instead of Amazon or somewhere local with fast shipping
What is the cost of your project? Could you share more information? I was looking to do something similar.
The individual builds will be pretty cheap: sub $75 with an Arduino, NEMA stepper motor, PCB, a few other parts, and some plastic enclosures.
There's definitely some bootstrapping costs to acquiring tools (3d printer, soldering set up, adjustable power supply, Fusion 360 license). That's around $1k-1500 for a nice hobbyist setup by the time you get everything.
The real cost is when you decide to quit your software job to work on a hardware project :)
There's definitely some bootstrapping costs to acquiring tools (3d printer, soldering set up, adjustable power supply, Fusion 360 license). That's around $1k-1500 for a nice hobbyist setup by the time you get everything.
The real cost is when you decide to quit your software job to work on a hardware project :)
That strikes me as being a much higher unit cost than I would have anticipated. Are you way overprovisioned on the arduino and the steppers or is there something else fancy going on that's driving costs up?
It could certainly be much cheaper than $75, that's just the ceiling. Arduino Nano BLE is $30 and one stepper on Amazon is $15. Plus other small hardware, plastic and assembly.
>First and Most Important Lesson: If You’re Here for the Money, You’re in the Wrong Place
It's worth reiterating this for college students, etc. considering going down the hardware path. While I got a tremendous amount more intellectual satisfaction by going for an electrical engineering degree instead of a CS or even CompEng one, that was because I realized CS was the kind of thing I would end up in anyway and would gladly study on my own terms. Numerical methods in differential equations, not so much.
If you do decide to do EE in 2023, I strongly recommend you break the mold of sparkies being atrocious coders. The skills are natural complements, even if for some reason most people like to pretend otherwise. But one is much more lucrative on average.
It's worth reiterating this for college students, etc. considering going down the hardware path. While I got a tremendous amount more intellectual satisfaction by going for an electrical engineering degree instead of a CS or even CompEng one, that was because I realized CS was the kind of thing I would end up in anyway and would gladly study on my own terms. Numerical methods in differential equations, not so much.
If you do decide to do EE in 2023, I strongly recommend you break the mold of sparkies being atrocious coders. The skills are natural complements, even if for some reason most people like to pretend otherwise. But one is much more lucrative on average.
> While I got a tremendous amount more intellectual satisfaction by going for an electrical engineering degree instead of a CS
I find this interesting. Did you end up getting a CS degree and then compare the intellectual satisfaction?
I found CS fascinating. Of course you get to choose your own path through CS and could possibly avoid most of the major breakthroughs, but to do it in earnest is revelatory. There is Godel’s Incompleteness restated/rediscovered through computation; the church-Turing thesis, Curry-Howard correspondence, graph theory, etc. I never did EE, but I did some math in my past and CS felt closer to pure math than anything else I’ve studied.
I find this interesting. Did you end up getting a CS degree and then compare the intellectual satisfaction?
I found CS fascinating. Of course you get to choose your own path through CS and could possibly avoid most of the major breakthroughs, but to do it in earnest is revelatory. There is Godel’s Incompleteness restated/rediscovered through computation; the church-Turing thesis, Curry-Howard correspondence, graph theory, etc. I never did EE, but I did some math in my past and CS felt closer to pure math than anything else I’ve studied.
>Did you end up getting a CS degree and then compare the intellectual satisfaction?
No, but we could always flip the question since we know you didn't do EE. ;) I did however slap on a math minor and find out I'm way better at abstract algebra than I have any reason to be.
I'll sum it up as "I'm just more of a frog than a bird", but I don't really think that's it. I think relevancy selection is just an inherently hard philosophical problem and it's really hard to actually grok the internal or aesthetic kicks smart people get at different things.
Dynamical systems tickle my fancy, so do group actions and finite fields and generating functions, the incompleteness theorems don't, go figure - at least not present day me, a depressed teenager me looking for philosophical solutions in all the wrong places ate that stuff up.
No, but we could always flip the question since we know you didn't do EE. ;) I did however slap on a math minor and find out I'm way better at abstract algebra than I have any reason to be.
I'll sum it up as "I'm just more of a frog than a bird", but I don't really think that's it. I think relevancy selection is just an inherently hard philosophical problem and it's really hard to actually grok the internal or aesthetic kicks smart people get at different things.
Dynamical systems tickle my fancy, so do group actions and finite fields and generating functions, the incompleteness theorems don't, go figure - at least not present day me, a depressed teenager me looking for philosophical solutions in all the wrong places ate that stuff up.
If you choose a field and career simply for the money, you are bound for rather sad life. There should be at least some personal interest behind that choice.
Anyone suggest some great book recommendations to better understand modern computing hardware?
I have these three on my shortlist: (i) The Art of Electronics (3rd edition), written by Horowitz and Hill; (ii) Digital Design and Computer Architecture: ARM Edition; and (iii) The Elements of Computing Systems: Building a Modern Computer from First Principles, by Nisan & Schoken
But keen for more.
I have these three on my shortlist: (i) The Art of Electronics (3rd edition), written by Horowitz and Hill; (ii) Digital Design and Computer Architecture: ARM Edition; and (iii) The Elements of Computing Systems: Building a Modern Computer from First Principles, by Nisan & Schoken
But keen for more.
IMHO there is no way to understand _modern_ computer hardware without knowing the old, retro one. Start with basics od digital electronics, then analyze some old computers (Altair, Apple 1, PC XT)then, slowly move on.
This is great advice. The concepts haven't changed much - electricity and physics don't change at all - we just have new techniques and the scale is way larger than before.
Electricity and physics change immensely with scale. The kinds of slop you could get away with at very slow speed and relatively low powers on old hardware are not allowed for with modern high-speed technologies.
In the context of PCB design, even something as simple as decap sizing and placement becomes tricky as clock rate increases. EE students regularly suffer through voltage drops and ground bounce from poorly managing the size and placement of decaps. These are problems that either did not exist or had simpler solutions in the old days.
In the context of PCB design, even something as simple as decap sizing and placement becomes tricky as clock rate increases. EE students regularly suffer through voltage drops and ground bounce from poorly managing the size and placement of decaps. These are problems that either did not exist or had simpler solutions in the old days.
I didn't mean that, I just meant that the laws of physics don't evolve as the industry evolves - they're constant.
"The laws of the universe are constant" is not useful advice for learning anything.
Which subset of said laws is applicable for electrical engineering has changed immensely over the years, and studying old hardware will not prepare the student for modern design.
Which subset of said laws is applicable for electrical engineering has changed immensely over the years, and studying old hardware will not prepare the student for modern design.
[deleted]
I had a 1040ST back in the day and it was great for the time. I learned me some C with the Mark Williams C, played around with bbs's and whatnot, but I'd be hard-pressed to find a reason to go back.
Of course we're all different, but I'd assume the real driver would be the ability to run specific beloved apps of yore.
Of course we're all different, but I'd assume the real driver would be the ability to run specific beloved apps of yore.
Spend the extra to gold flash your edge connectors unless you want a painful chemistry lesson.
+1. Been there, done that. Bottom line: for projects like this goldplated fingers are worth it. Eat the cost & be happy.
What about advertising your product? I've heard that that is exceptionally difficult these days.
One approach is to write a blog posting about how you created your product and get it on the front page of Hacker News
... which is not particularly useful if your target user does not intersect with the HN demographic.
Indeed, advertising suffers from a severe signal-to-noise problem.
Like the OP, I make a hobby related product as a side hustle. There are some sources of word-of-mouth advertising through web forums for enthusiasts. Usually you have to give something before you can get something back, and respect the forum rules. I never mention my product unless someone specifically asks.
Also, I was an established member of a forum before I ever even dreamt up my product. I made a couple to give away, and another forum member wrote up a review. The rest is history. ;-)
Like the OP, I make a hobby related product as a side hustle. There are some sources of word-of-mouth advertising through web forums for enthusiasts. Usually you have to give something before you can get something back, and respect the forum rules. I never mention my product unless someone specifically asks.
Also, I was an established member of a forum before I ever even dreamt up my product. I made a couple to give away, and another forum member wrote up a review. The rest is history. ;-)
What’s the name of your product? Do you have a page with pictures of it and descriptions of what it does?
I just would like to celebrate this sentence for one second:
> If It Can Be Done with Code, Don’t Do It with Hardware
We all complain about why my washing machine needs a connection to Wifi and why my brakes don’t work while I’m tuning the heating on the display (joking to emphasize the craziness of plugging the infotainment on the CAN bus), but our hardware is now so reliable that it’s more reliable to do something in software and reuse existing HW bricks, than to design a specific circuit for a dedicated function.
> If It Can Be Done with Code, Don’t Do It with Hardware
We all complain about why my washing machine needs a connection to Wifi and why my brakes don’t work while I’m tuning the heating on the display (joking to emphasize the craziness of plugging the infotainment on the CAN bus), but our hardware is now so reliable that it’s more reliable to do something in software and reuse existing HW bricks, than to design a specific circuit for a dedicated function.
It's always better to have as much functionality mutable via firmware update. Even if it's a day 1 factory update and it never gets updated again. You have an extra couple months to test and harden the design and prevent showstoppers.
However, anything safety critical or that could potentially hurt the device always needs hardware dedicated to it. As an example, using a couple I2C-adjusted buck regulators. Very convenient, until your i2c gets wedged or you get bit flips due to noise on the bus or a i2ç peripheral glitch with some other device on the bus. Now your 1.2v rail has 4 volts on it. You can't fix that with software.
However, anything safety critical or that could potentially hurt the device always needs hardware dedicated to it. As an example, using a couple I2C-adjusted buck regulators. Very convenient, until your i2c gets wedged or you get bit flips due to noise on the bus or a i2ç peripheral glitch with some other device on the bus. Now your 1.2v rail has 4 volts on it. You can't fix that with software.
> Be Prepared to Lose All Your Money
In Taipei we have Fablab which has a CNC machine, laser cutter, multiple 3d printers, oscilloscope, and soldering irons, among a thousand other little bits and bobs. I'm guessing most cities have similar, and I've heard of phenomenal libraries with tools like this. It could be worth looking into this! Universities often have all the equipment you need as well.
In Taipei we have Fablab which has a CNC machine, laser cutter, multiple 3d printers, oscilloscope, and soldering irons, among a thousand other little bits and bobs. I'm guessing most cities have similar, and I've heard of phenomenal libraries with tools like this. It could be worth looking into this! Universities often have all the equipment you need as well.
Having also taken this journey, the one thing I wish I'd understood much earlier is how important familiarity with CAD tools was going to be. Not just PCB layouts but everything from enclosure design to product mock-ups. You need to get comfortable with at least the basics of both additive (3D printing) and subtractive (CNC milling) processes.
One note on "If It Can Be Done with Code, Don’t Do It with Hardware" - there are times where locking things down in hardware is worth it. Things like safety and compliance for example - it is much easier to prove a hardware design is "safe" and fault tolerant than software.
The point about "not doing something in hardware if can be done in software", is although mostly true, is less so when one takes FPGA into consideration, where the difference between hard in soft is blurred.
Eh, not really. FPGA folks will tell you the exact same thing. Digital design and verification is much harder and more time consuming than SW. The suggestion has always been to start your implementation in SW and if you just can't make it work (ex. no reasonable uC can keep up) only then do you reach for an FPGA.
My point is that VHDL/Verilog is both hardware and software. OTOH I find FPGA "programming" with VHDL considerably easier than actual embedded programming. No need to fight for CPU clocks, no indeterminism is execution time etc.
Yes, and when doing it in software makes no sense. We have GPUs for a reason, for example. (Yes I'm aware graphics can be done on the CPU but there's a reason GPUs are faster)
There is no such as an affordable GPU in the cloud. You won't stop me from software decoding and software rendering and software encoding everything.
[deleted]
You wouldn't expect someone writing about the opportunities and lessons from the JavaScript/CSS frontend world to have a huge amount of insight into the work and opportunities of firmware developers.
So it is with hardware, and personally it frustrates me when software people think they can generalize about the "hardware" space because they printed a 4 layer with JLCPCB and now they know the "hardware" world and its ins and outs.
This post is about PCB design and fabrication. The equivalent would be if a hardware person spent a day banging their head against Azure Continuous Integration workflows and wrote a post entitled, "Lessons learned by a hardware guy venturing into software".