[Rant] Learning hardware has made me hate software - Page 1
Forum section: electronics / general

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: April 16, 2025, 08:16:28 am
content: I come from a mostly software background, I have a story quite similar to most of you (started programming in my teens, made random stuff, got introduced to embedded late in my teens). Then I got into univ, studied IT but liked embedded more so I got a job as an embedded dev. I started out at a small company which hired me under the impression that I was going to design their hardware AND write their firmware (they thought it was the same skillset). Well I didn't want to disappoint so I learned hardware design on the job (it was just a basic MCU based project, definitely not too hard) and delivered a successful product. That started my hardware journeyI have thought a bit about it, and I think the reason is mostly that I find software restrictive, compared to hardware design. Often when you ask why something cannot be done or has to be done a certain way in the hardware world, the reasoning behind it is a lot more clear. Its either because of cost reasons, design constraints, or well, plain old physics works that way (what are you going to do? Argue?)But in the software world, a lot of stuff is arbitrary. Its because some dev before you took a certain design decision. Now you need to follow it to completion. You have to learn the API syntax to do X, even though X could be done with 3 register writes. Why the overhead? Just so that you can avoid having to read the register map?Hardware is definitely harder, but the problems feel a lot real, and not just "well the API is a female dog to work with, it just is". Software issues feel like make believe problems, shotgun foot et al, just stuff that feels self inflicted.

author: NE666
author_rank: Frequent Contributor
timestamp: April 16, 2025, 01:09:42 pm
content: Quote from: BadeBhaiya on April 16, 2025, 08:16:28 amYou're rather assuming there though, that your imaginary predecessor's decision was itself arbitrary. Maybe it was; just a case of personal preference. But it's much more likely to have been the result of possibly undocumented but real at the time constraints, constraints they may now have been lifted or rendered irrelevant by time and/or changing circumstances. Even the classic 'a' language/framework/library/platform over 'b' choice is a directed decision if it is made because the individual or team simply has more experience with 'a' as compared to 'b'. That is a perfectly acceptable basis for a design/implementation choice, as it has real world consequences for productivity and maybe quality. Few things, if any, should be (nor likely are) arbitrary.To take your example, another very valid basis for choosing one design/implementation over another might be the value the company/team attributes to maintainability of the codebase. Writing to hardware registers directly could be considered a 'brittle' approach, especially when the hardware changes. An API and library might carry overhead but the abstraction they provide in that situation may be considered valuable by the architect, maintainers and indirectly customers.Personally, it's not been my experience that there's anything of real significance which is arbitrary within good software designs. There may be more than one way to achieve the same outcome, but if all routes have roughly equal cost, that's fine. However mostly, all major choices will flow from functional and non-functional specifications and constraints.In bad designs, well, there may indeed be random, even poor choices. But software doesn't hold any special dominion over poor design.

author: madires
author_rank: Super Contributor
timestamp: April 16, 2025, 01:42:51 pm
content: There's also reasoning in software development, it's just not documented. So you see some code and have no idea why it is done that way. For the hardware side it's easier to guess the 'why'.

author: NE666
author_rank: Frequent Contributor
timestamp: April 16, 2025, 02:23:23 pm
content: Quote from: madires on April 16, 2025, 01:42:51 pmThis is what comments are for.Don't tell me what you're doing, that's self-documenting; I'm reading your code. But, if it must be done *that* way, and only that way, then leave a comment to tell me why, so that it doesn't either inadvertently get refactored out, or equally, left in long after its necessity and any utility has passed.

author: tooki
author_rank: Super Contributor
timestamp: April 16, 2025, 07:31:53 pm
content: Quote from: BadeBhaiya on April 16, 2025, 08:16:28 amNo. For abstraction. That lets you much more easily move to a different MCU.Also, APIs should have at least some error checking. Diddling with registers affords no such checks.

author: SteveThackery
author_rank: Super Contributor
timestamp: April 16, 2025, 09:19:31 pm
content: I think I have the opposite opinion from the OP. Let me say, though, that I rarely, if ever, work with someone else's code these days. When I'm designing a widget for some trivial purpose I start out with a blank sheet of paper for both the hardware and the software.As I work through the hardware and the software, I almost always enjoy working on the software more. One big reason is that making changes to the hardware is much more of a ball-ache. Especially once you've committed to a layout and then find a hardware "bug". Also, as already pointed out, hardware is constrained in all sorts of ways, including the laws of physics. But also in terms of physical size and shape, power consumption, voltage requirements, EMC, etc. Making changes to hardware is generally very tedious.Software, on the other hand, is so much more flexible. Yes, it too has constraints such as memory size and possibly operating speed, but for me a massive advantage is that I can make as many changes as I like at essentially zero cost. I can even totally scrap and rebuild the whole thing from nothing, and all I have to do is zap it into the microcontroller. It costs a few seconds of time compared with scrapping and rebuilding the hardware.It is in my nature to adopt a subset of the "Agile" approach to widget development. That is, I tend to start with something that is functionally incomplete, revising and improving it until it does everything I want and I'm satisfied with it. Justifying that approach is for another post, but continually refining hardware is so much more time-consuming (and expensive, potentially) than continually refining software.I like being able to "polish" the software as I fine tune it to perfection. It's not remotely as easy to polish the hardware elements of your widget.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 16, 2025, 09:42:58 pm
content: While I don't fully agree with or maybe fully get the bulk of your rant, I think many can relate to your title, although maybe formulated a bit differently.Certainly when you're a hardware person, you may end up hating the way software is currently made. Not really software per se, but the way it's developed and how the software industry has evolved. It's not really new: Niklaus Wirth, who was initially a EE, fought his whole life for leaner and more reasoned software. So, there's certainly a link.I know quite a few EEs that have "switched" careers though and have ended up focusing on a software career - not because they particularly liked it, but because there was much more money to make and often in less strict environments. That is changing a bit as of late, though, so that's a career switch I would not necessarily recommend these days.

author: jonpaul
author_rank: Super Contributor
timestamp: April 17, 2025, 04:46:29 am
content: My favorite programming language is solderMy old friend the late and great Bob PeaseUsed to meet at the Silicon Valley ham radio fleasBon soiréeJon

author: rstofer
author_rank: Super Contributor
timestamp: April 20, 2025, 04:38:33 pm
content: Developing hardware for various applications circa 1980, I often found it necessary to provide the software folks with a simple example showing how to use the hardware.As most development was done in assembly language, I would just write some driver macros and then the sample application. The macros could do parameter checking to further aid the software developer.For embedded projects, I don't see how a hardware EE can avoid writing code. Perhaps not the entire application suite but certainly low level examples.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: April 20, 2025, 04:52:57 pm
content: Quote from: NE666 on April 16, 2025, 02:23:23 pmA classic example of this. I was/am a systems guy. Not top dog at either hardware or software, but sort of OK at both. Got called in during a software audit where nobody could figure out why a certain line of code in a piece of test equipment for physical hardware include a strange arithmetical scaling. The measured results were multiplied by 22 and later divided by 7. Many of you will know immediately why, almost all of you will say of course once you realize, but it had stymied the team involved for a couple of days when I was called in. Took a few minutes before I figured it out too.It was a simple way to approximate pi in a system that didn't have a predefined constant and whose limited word size made scaling better with selected order of operations. The pi was dictated by the physics of the hardware under test. A simple comment statement would have save a lot of man hours.

author: tszaboo
author_rank: Super Contributor
timestamp: April 20, 2025, 08:57:02 pm
content: Quote from: madires on April 16, 2025, 01:42:51 pmNothing is documented in software development. Because that's boring. Testing also boring.If I would design my hardware the same way software people do, people would be set on fire.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2025, 09:48:48 pm
content: Quote from: tszaboo on April 20, 2025, 08:57:02 pmProbably.

author: Smokey
author_rank: Super Contributor
timestamp: April 20, 2025, 09:51:35 pm
content: Quote from: jonpaul on April 17, 2025, 04:46:29 amBob Pease was awesome. I have all his books.With that said.......creating or even just having with this sort of circuit on the bench is about my idea of a true nightmare..My take on the OP is that one is not better than the other. For most real world applications of moderate complexity, hardware and software are compliments. Good hardware design supports the software and good software design supports the hardware.There are some circuits that, while still possible to build in pure hardware, are significantly easier/faster/more-flexible to implement in software. (ex. switching motor control stuff or multi-variable control logic and long scale timing)Same goes for software features that are better done in hardware. (ex. safety critical stuff, or basic signal conditioning/filtering)Obviously if you screw up one side the other side will suffer too, which is just more reason to not screw up any of it.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 21, 2025, 10:42:45 am
content: Quote from: BadeBhaiya on April 16, 2025, 08:16:28 amThis is quite sensible way to do it. People cannot havedeepskills in any arbitrary number of fields, but many sure can managetwo. These two being hardware design and embedded (firmware-oriented) programming skills is one of the most synergetic combinations. Because: for efficient hardware design you need to deeply understand how the final firmware will operate. Programming details like availability and desired configuration of peripherals leaks through to HW design. And vice versa, hardware design choices affect how the software product will look like - how easy it is to write, efficiency of it.So if these two tasks is separated to two different people (or teams), then both of them need to understand ~50% of what the other one is doinganyway. And then they need to communicate a lot thorough the process, and communication incurs overhead and risk of misunderstandings.If the company (or team assigned to the project, even if the company itself had 10000 employees!) is small enough to, say, employ just 10 people anyway, combining HW+FW to one poor guy is the most sensible thing to do. Of course for truly very large projects that will not happen.Therefore being good at both of them is also a good skillset, you are going to be very valuable for not only startups but also medium sized companies who built small-ish teams to accomplish a limited-size task.Another factor why HW+FW plays so well together is project timing (calendar planning). HW is almost never continuous work, it comes in cycles, and it has waiting periods. You design HW, then you order prototypes and wait. That wait is perfect for writing FW, especially when you are the HW designer so have all details in your working memory. Very quick start.QuoteYou are so right. World of software and computer science is seriously devastated by sheer amount of religiousness and cargo cult engineering. Solutions that are simple, practical and easy to prove using technical/scientific methods are shot down using cult-like argumentation, and this is so widely spread that even otherwise quite sensible people are susceptible to it without ever realizing it. People are ready to flush 1000 man-hours through the drain for some idealistic framework model they want to build making a product which never works and is impossible to maintain, and then concentrate on some superficial and totally irrelevant detail like existence of goto statement somewhere in the codebase.The best you can do is to become a very good combined-skill HW/FW developer who can operate in small enough units to make your own decisions, ignoring any bullshit. You deliver results, and your methods will be trusted because the results work. If you get into that position, software starts to feel enjoyable again, too.

author: krish2487
author_rank: Frequent Contributor
timestamp: April 21, 2025, 04:36:58 pm
content: Quote from: Siwastaja on April 21, 2025, 10:42:45 amI will disagree with this aspect of your statement.. Just my opinion anyway. While there is some truth to this statement, I would wager that a fw engineer can hit the ground running at the same time or earlier than HW engineers. If the system design and architecture is fleshed out, then as fw engineer can get started with a dev kit and breakout boards for sensors and actuators and what not.. The bulk of the application logic and adapters / abstraction layers to make the fw flexible enough to adapt to the final hw prototype and unit tests and integration tests and so on.. these can be abstracted away and / or mocked. I do agree about the HW design aspect. but specifically wrt project timings and scheduling, there is no reason to couple both, if anything it makes sense to decouple and let the progress run concurrently.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 21, 2025, 06:06:49 pm
content: Quote from: krish2487 on April 21, 2025, 04:36:58 pmYeah, I understand this. It really depends on the project. If the HW is uncertain and HW part is large, then it sure pays off to parallelize it to a HW designer working on it, and FW developers working with stuff like devboards, with both parties in close communication with each other.But even in situation like this, combined skillset is good to have so that you understand each other better.And after the HW is ready for production, there might not be more work for the HW-only guy, which is also why HW design work is often outsourced to specialized companies or freelancers doing just that, so that they can swap to a completely different project for a different company. This is something I don't personally like, I want to have a mental commitment to a project and keep working on it, seeing it succeed. For those who are similar, combined HW+FW skillset is very valuable.

author: vk6zgo
author_rank: Super Contributor
timestamp: April 22, 2025, 06:43:03 am
content: Quote from: Smokey on April 20, 2025, 09:51:35 pmAs a Tech, I have been confronted with an EE's "spider web" contraptions which worked perfectly, but when the "Ginger Beer" designed a PCB, didn't work, due to the additional stray capacitance.Quote

author: westfw
author_rank: Super Contributor
timestamp: April 23, 2025, 09:00:34 am
content: QuoteDitto.In software, you get immediate gratification (or not), better error indication, and ease of re-doing things when they go wrong. I realized in HS that all of the hardware projects I had built could be been programmed into one of the microcomputers of the day, but I still went after that EE degree. Hmmph.

author: madires
author_rank: Super Contributor
timestamp: April 23, 2025, 01:33:49 pm
content: It doesn't need to be either hardware or software. Over here you can get an EE degree with a specialization in computer engineering which also includes software development (multiple programming languages, methods, algorithms, OSs, ...).

author: rdenney
author_rank: Regular Contributor
timestamp: April 23, 2025, 09:19:36 pm
content: For me, creating stuff was easiest using software, because I'm not a EE and just didn't know hardware (still don't at anywhere near the level I would like). Butrepairingstuff is easiest with hardware-based systems, simply because they can be trouble-shot in three dimensions, although surface-mount technology has evened that up a bit.Rick "gets tired of software-driven devices that can't be repaired, particularly after the manufacturer loses interest" Denney

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: May 01, 2025, 08:09:50 pm
content: * I have to read 50 pages worth of documentation to just use a half working sensor driver (polling only btw) for a chip that has a 5 page datasheet. I could implement in a few minutes, but it takes me longer to fight with the environment to just include the existing driver and get it to work.* You have to use an RTOS that is among 15 other RTOSes with no difference between them, just a different syntax.* You were sold the RTOS because it supposedly supports a lot of sensors and it will save cost and time, but you find out it comes with 10 drivers in total. So much for "industry" support* You have 5 sensors on your board talking on whatever busses, one is partially supported by the RTOS (which locks you into the ecosystem) but the rest 4, you will have to write the driver yourself as the RTOS gets in your way and you get frustrated as to why you can't just write directly to the I2C or SPI peripherals registers and do the transactions that way instead of an RTOS macro layer which throws nonsensical compiler errors (seriously, think about it, if its more work to use the API instead doing it directly, isn't something wrong?)* The RTOS supposedly gives you "portability" but no one ever has actually needed such portability ever because when the platform is changed, a lot of features are added or removed anyway, so you will still have to make extensive changes to the business logic.* I have to include arbitrary header files into the code, which contain arbitrary code which may or may not follow any proper organisation. The only way to learn to use the API is by reading examples (let's be real, documentation alone does nothing for you)I still love what I can make with the software but I don't enjoy writing it. I enjoy what I get in the end.

author: westfw
author_rank: Super Contributor
timestamp: May 02, 2025, 01:37:17 am
content: Ah yes. With software, there is frequently a significant battle with the environment that for "reasons" you are forced to work within.With hardware, the significant battle is against Physics. :-)

author: Siwastaja
author_rank: Super Contributor
timestamp: May 02, 2025, 06:28:46 am
content: Quote from: BadeBhaiya on May 01, 2025, 08:09:50 pmThis is the typical experience when you fall in the trap of using "industry-proven" "ready-made" "solutions" instead of doing everything from scratch. Doing all by yourself is usually an order of magnitude faster. The only problem is that very few peoplebelievethis since it seems counter-intuitive. Just like many won't believe if you tell them that same foodstuff in bigger package costs more per weight than in smaller package, even when it's true.Therefore, you need to be in a position where you are responsible for technical choices and just deliver of a working product. Then software can be very enjoyable; you know what needs to be done, and you do it. Simple things are simple and you don't need to waste time with them; and hard things are hard, but challenging and interesting. Like, they are not made artificially hard.Trying to use shortcuts that are told to ease your work tends to make the simple things much MUCH more difficult. In very best case, some of the harder things might get easier, but don't count on it. Usually they are still hard, or become impossible ("this library does not support this feature because it was too hard to implement, please do it from scratch" - in which case you wasted time with the library, and then had to start over and do it from scratch anyway).

author: krish2487
author_rank: Frequent Contributor
timestamp: May 02, 2025, 07:27:38 am
content: Quote from: Siwastaja on May 02, 2025, 06:28:46 amWell said.. I agree completely.. I suspect this is largely due to the extreme application of "make sw / fw flexible for change" in embedded systems. You have your "industry standard, ready made drivers" that the vendors provides.. and you write an adapter as per your application.. and voila.. reuse the same sensors / library combo across different platforms. Again, there is some advantage to this, however it seems like more and more managers are forgetting that embedded systems are purpose built for a specific application at hand. It is, IMHO, completely ridiculous to make the fw for this very flexible and layered. We dont / cant make HW flexible in the same manner.. so why go to such extremes for fw? We spend absurd amounts of energy and manpower optimizing hw and supply chain.. only to push those responsibilities to the fw to account for any screwups in the aforementioned areas.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 02, 2025, 05:33:01 pm
content: Core of the problem aremanagerswho lead the programming work, without being programmers themselves.Theyare scared about writing code, because to them coding is awkward, slow and difficult work, because they have done so little of it, and it isn't their passion. They mistakenly think that writing new things from scratch is always very slow, expensive and leads to "version 2.0 syndrome" or "NIH syndrome", which of course are real risks of course but greatly exaggerated. They believe that code is magic which comes from the few select companies, and key to success is to reuse work of others as much as possible.In reality, just like chefs make the same dishes thousands of times again and again, and surgeons do the same surgeries over and over again - every situation is after all a bit different so it can't be automated - writing new code is not a problem at all for actual programmers. I would even say that is the deciding factor if someone is a programmer, or an imposter. Making mistakes and even shitty code is something that can be fixed, but if one fears doing their job, that can't.It might feel stupid use of time to learn implementing sorting algorithms on university courses when we can just call a library on Python but that's for good reasons.In a very similar fashion of being afraid of new code, some manager-types are very afraid of using "dangerous languages", to the point of preventing programmers doing their job by fearing too much, or worse, pushing poor alternatives in panic mode, with no practical experience at all but blindly trusting marketing or hype. Which leads to exactly the kind of failure they feared: management's sidetrack becoming a time-sink for programmers. What's worse, these managers never realize the mistake wastheirs, instead they think that project getting slowed down is proof that programmingindeedis very hard, so we indeed need Rust or whatever.And I'm not saying managers are unnecessary, not at all. Just that managers need to have very good both fundamental and practical understanding of the work their teams are doing, to the point that they reallycouldparticipate in the actual programming work in the team.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: May 02, 2025, 11:36:13 pm
content: Quote from: Siwastaja on May 02, 2025, 05:33:01 pmThat oversimplifies it as much as the maligned managers are doing. The analogies are very strained. Chefs make the same dishes over and over again. Because for all practical purposes they can't be reused. We'll just ignore the take-out of uneaten dishes. Automation is coming to many areas of surgery. The surgeon is still there to detect those special cases, but much of the actual work is automated. Programmers often don't write "new" code. They re-use the algorithms they learned in university. If the code to be written is in the same language and a functionally similar machine they either regurgitate working pieces from memory or copy/paste. So even a "clean sheet" design often involves much re-use.There are two fundamental problems involved in software - not too dissimilar to the problems on the hardware side. First, we are in the midst of a very unstable technology environment. The hardware that software runs on changes frequently as do the problems that are being addressed and the tools used for coding. There are reasons to believe that this will improve (become more stable) in the not too distant future, but it has been true for the last 60+ years and certainly hasn't stopped yet. Second, there is no money (or employment) in using existing software. New features have to be added, or new problems need to be developed, or even the life of existing products needs to be artificially shortened to keep the dollars rolling in. The Microsoft Office Suite is perhaps the most obvious example, but the same thing happens in every other software application.

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: May 03, 2025, 09:08:29 am
content: Quote from: CatalinaWOW on May 02, 2025, 11:36:13 pmI would say this isn't limited to software but most digital crafts where the output is essentially a piece of code or some digital media. We have all seen the UI of apps and websites change every few years (or worse, every few months) without any need for the said change.The cost of making digital media is nonexistent, besides the employees' time, so employers do not feel a reluctance them on goose chase type projects. Code is a great example of this.Compare this to hardware, it's similar in the sense that design costs nothing except time but actually getting the hardware costs money, so we see a lot less iterations.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 03, 2025, 01:19:17 pm
content: Quote from: BadeBhaiya on May 03, 2025, 09:08:29 amThis difference is actually shrinking more than many think. That was mostly true in the "old days" of software, but now that a lot of it runs on servers and software is increasingly accessed remotely, the cost of the infrastructure to "serve" software has become gigantic. Not sure it compares favorably to hardware production, all things considered.The visible consequence of that is that many online services are actually NOT profitable and lose money. They've been compensating with their business "value", which hasn't been too much linked to profits, but more to the potential, at least until recently - things are changing. Investors are slowly waking up. While it's still possible to be profitable selling hardware.And, development costs tend to be higher for software too, in the end, unless you consider exceptions, like niche hardware stuff that's ultra expensive to design. Otherwise, in many cases, a software project will last longer than a hardware project and be a lot harder to predict, and so will cost a lot more.Software being "flexible" is true but has been largely overestimated. The actual cost of developing software is very high, the cost of maintaining it even higher, and the cost of running it (for any kind of online service) is very high too. And, often, the cost of deploying a bug fix can also be very high, making the idea of "fixes are easy and cheap to provide as opposed to hardware" a bit, uh... exaggerated, at the very least.Software is "cheap" and flexible when you develop it as a hobby in your room. In a professional setting, that's another story in practice.

author: SteveThackery
author_rank: Super Contributor
timestamp: May 03, 2025, 01:42:55 pm
content: Quote from: Siwastaja on May 02, 2025, 06:28:46 amI don't think I agree with this, @Siwastaja. Surely all of engineering stands upon the shoulders of those that precede us, otherwise we would still be inventing the wheel. Integrated circuits are "industry proven", "ready made" solutions. Hardware engineers use ICs because designing an op-amp from scratch, testing it, procuring the dozens of components... inmostcases would be a grossly irresponsible waste of money. There are standard circuits (eg filters, power supplies, etc) and subcircuits (current mirrors, constant current sources) that every hardware engineer uses. Obviously the engineer can run into trouble by using pre-existing solutions inappropriately, but that doesn't undermine the principle.The same sort of thing applies to software engineering. Most SW engineers use well established algorithms (sorting, searching, circular buffers, etc), and most of the time it makes perfect sense to use a library or driver that you know to be good. I don't believe many people habitually throw away every standard 'C' library and write their own. There is one big advantage in using existing code (whether it be snippets or full libraries): usually that code has been used thousands of times before and has been comprehensively debugged. That is not nothing.So I don't think it's a convincing argument that it is quicker to start from scratch than use tried-and-tested elements in your software or hardware. I think the opposite is usually true - quicker, cheaper, and tried-and-tested is good.Obviously I wouldn't dream of claiming this is universally true. @Siwastaja's description of the potential hurdles arising from using ill-fitting solutions must certainly be valid. I just think that most of the time, the opposite is true. It must be, otherwise 21st century technology would be stuck at the wheel.**PS: as a complete aside, I don't think the terminology is quite right. I think you could argue that simple wooden rollers are a type of wheel. Surely the great breakthrough was inventing thehub. That really was a tremendous breakthrough and game changing technology.

author: madires
author_rank: Super Contributor
timestamp: May 03, 2025, 02:28:28 pm
content: I'd say one has to learn how to determine if using something industry-proven or doing it yourself from scratch is better in a specific situation. Sometimes it can also make sense to customize the industry-proven solution. Experience helps.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 03, 2025, 05:15:40 pm
content: CatalinaWOW and SteveThackery, don't take my words too literally and to the extreme.Chefs avoid using canned foods but also don't reinvent every recipe from scratch, because that way they can perform the tiny (and sometimes bigger) variations that are needed to satisfy the needs of the customers, or adjust to availability of ingredients.No one suggests designing an opamp from scratch, or writing x86 bytecode to draw individual pixels on screen when you need an UI, but you also should be very careful when committing to large catch-all frameworks, sets of libraries that are said to make your work easier.A good example from microcontroller world would be nRF52 "hello world" example which consists of 200files(not lines!) of source code and a 2000-line build configuration file, takes a week to get to a point where it compiles, and then it fails to print anything; and a year later you hear that the whole SDK is now obsolete and you need to learn a new one which is completely different. Meanwhile, using the thing bare-metal is total breeze and most things can be achieved by just a few lines of code, because the hardware is so well designed and programmer-friendly. It is then absolutely hilarious to hear how peopleseriouslytell you with a straight face you are doing it wrong and you should be using the SDK because it saves so much time.So all I'm really saying is avoidunnecessary complicationsandnever assume that pre-made is easierbecause it often isn't. Sometimes it of course is and the key is finding the balance, and doing the right technology choices, and for this you need actual programming experience (a lot of it) to avoid basing technology decisions on how popular something is in Google results, or how well it is marketed in Powerpoint presentations.

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: May 03, 2025, 06:52:33 pm
content: Quote from: Siwastaja on May 03, 2025, 05:15:40 pmIts hilarious. I too was trying to get a sensor working with an nRF52840 micro with nRF Connect SDK, which led me to makethis verythread, in a frustration fuelled daze (it uses Zephyr RTOS, for people who are unaware).The learning curve being steep is a massive understatement for Zephyr RTOS, its downright brutal! The compiler errors make no sense, since its a couple of layers of compile time macros, of course it cannot make sense. It comes with an impressive number of drivers from the get go, but most of them are very simple, and don't support anything that's more complicated than "read data" or most obvious operation of a device. Basically if there are a lot of features and modes for a sensor chip in the datasheets, you will likely not find a lot of them in the drivers.Devicetrees sounds great in theory but in practice...well there's NO documentation. You can only learn writing devicetree files by reading example code and picking up from there. The syntax isn't the best.When the system works, it works well, especially when you have multiple or even a single networking stack (BLE in my case). But I still cannot get over the fact that so many multi-million dollar sillicon manufacturers are backing a project like Zephyr but not improving the documentation in any way.Anyway, I heard somewhere that Nordic is now looking to move away from Zephyr only SDK for their new nRF54 series chips, which sounds good to me I guess.The older nRF5 SDK wasn't much better, although its much lighter and closer to the hardware. Configuring it is still a pain, you have to edit a header file with a billion flags in it. I would still take this though, this was not as bad. At least errors made sense and I could be sure that I was causing the error from some carelessness, and not the environment.Nordic hardware really is quite well designed, documentation is also top notch, peripherals work exactly the way you would expect them to, although they don't have more complex peripheral like timers with dead time etc or other stuff like ST but its fine, nRF chips are made for a different purpose.

author: SteveThackery
author_rank: Super Contributor
timestamp: May 03, 2025, 08:33:22 pm
content: Quote from: Siwastaja on May 03, 2025, 05:15:40 pmWow! I am absolutely gobsmacked! 😲

author: westfw
author_rank: Super Contributor
timestamp: May 03, 2025, 10:01:35 pm
content: QuoteSo some people believe.They've obviously never tried to use some piece of "open source software" (or any product, really) that has been abandoned for a decade or so. :-(QuoteApproximately 100 files for an essentially empty "Atmel Start" project... Not including the processor .h files.It doesn't even have the excuse of having something complex like a radio...

author: nctnico
author_rank: Super Contributor
timestamp: May 03, 2025, 10:39:30 pm
content: Quote from: SteveThackery on May 03, 2025, 08:33:22 pmAnd that is quite a common situation when dealing with manufacturer provided SDKs / libraries. Usually I end up with using whatever works out of the box from the SDK/library and do the rest 'bare metal'. In many cases it is easier to just read the programming manual for the hardware than tracing back what the provided library is doing. And often the provided library is not doing exactly what is needed either. The road of least resistance is the way to happiness.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: May 03, 2025, 11:35:09 pm
content: Quote from: westfw on May 03, 2025, 10:01:35 pmThat is mostly because all of the surrounding software has been "improved" so much it doesn't work anymore.Example: I have a font editing program that worked perfectly fine on 16 bit windows. Somewhere along the line support for 16 bit windows was dropped and the only way I could use the code would be to resurrect a full 1990s environment. There are dozens (or hundreds) of examples.Which is why you are right. There is money. Because those wanting money have made it so. That includes retailers, major corporations, smaller corporations and even open source outfits.

author: Ian.M
author_rank: Super Contributor
timestamp: May 04, 2025, 05:41:43 pm
content: Quote from: CatalinaWOW on May 03, 2025, 11:35:09 pm16 bit Windows/DOS application support went away when Windows went 64 bit. Even Win XP x64 didn't support them and once Win10 went x64 only, you could no longer run them natively on a current MS OS.However there is a 3rd party FOSS solution for running most 16 bit Windows applications on x64 windows:https://github.com/otya128/winevdmMost 16 bit Windows applications work well under it so its likely your font editor will work under it. Its also worth noting that it is seamless enough and good enough to let you install old 32 bit applications that use 16 bit installers, which has saved my butt on several occasions when trying to get old scanners and imaging devices to work on Win10. Its less good for DOS programs but there are other solutions for them.As always, YMMV, and don't use it for installing legacy hardware unless you are either testing on a scratch system, or have a full (tested) backup and the time to restore it!