fascinating report Glen, blame the io esd :) for the sram error rate
It seems most epic work gets done when various skilled people team-in as long as the analog ressource has more character and skills than ego and the digital guy is fast and verstalile in coding stuff out of his comfort zone.
After all it makes you wonder if sales&marketing driving the engineers crazy while keeping the communication channel open is one recipe for success.
Hey Martin, I once worked for a corp like that. The marketeers would wait until someone else proved a concept and started making a few bucks off it, then would jump on the bandwagon and tell engineering they had to deliver in 6 months or miss the market window.
To which the standard eng response was "Then why didn't you morons ask for it 6 months ago?"
Love your work Glen. Really good faultfinding. Goes to show - Analog skills will never really go out of fashion! We deal with similar boards in PABXs and suchlike and I wouldn't even think of deliving as deep as this, we just junk them or return them to the manufacturer for repair if they go wrong.
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.
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."
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.
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.
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.
@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?")
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by