@j_b_ It's just that I have seen things like that more often than should be expected
I as well, no offense taken. That is one of the risks that need to be juggled when making this sort of decision. Many times things do go right on the cheap, so the increased cost of better tools would have then been the wrong decision. "Do more with less..." If the successes outweigh the failures then one is still ahead in the long run.
Bad decisions do impart the accumulated experience needed to better judge the difficulty level and try to make a more accurate prediction the next time. Or at least not get bitten by the same bug twice.
Of course,there are always those situations where one knows the tools are wrong. But then one must convince management to spring for the cost of better tools. ("Well, you came through last time with that same scope, why do you need a new one for this project?")
Surely you're right. It's just that I have seen things like that more often than should be expected ... instead of planing first and then using what's best there was some stuff at hand and that was used because one could start right away and continuing down that road one compromise led to another and when, after some considerable time, people looked back and wondered how this little problem could have cost so much work it turned out that a cleaner approach with "real" tools and a bit more planing could have led to a direct solution. Of course any real-life situation carries its own logic and limitations, so - sorry if I sounded judgemental, no offense intended.
Yes it is, and with no reason ahead of time to anticipate any problems the beauty of the PIC board was that several were already in house and ready to use, with no additional cost. The physical interface to the SIMM had to be constructed regardless, no matter what I/O board was used. One cannot solve any resulting problems until they crop up and make themselves known.
Sorry, but I really think it was a bad decision to use that PIC board in the first place. Since you had to order other material anyway you could have ordered some really working and proofen hardware with enough I/Os and simple programming model. That way you would have eliminated all the risks which inevitably come with such unprofessional homebrew boards as the one described. I mean - even the soldering of the missing caps took more time than the ordering of a nice SoM. OK, OK, it's always easy in hindsight. I agree. But really the quality of the PIC board should have let to doubts concerning its developer. My experience - do not attempt to go cheap when doing something which is complicated on its own. Use the right tools.
The more traditional title would probably be "analog/mixed-signal engineer," but that one has the connotation of an analog engineer who also knows digital. There are many engineers who might be better described as "digital/mixed-signal."
It owuld be great if microcontroller them selves shows up a message that wrong voltage level is applied to their pins instead of deep digging into the datasheet. I hope the Microcontollrer companies are looking at this.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.