Would you be working in assembler then? Would this (RISC) matter much if you were working in C?
I have only worked in assembler with the PICs. I am sure a C compiler would hide the issues if you could get iot to compile for on of the really small PICs that I was looking at. The problem with a bias is that it is preconcieved and brealimnk the bias is much harder once it is established.
By an even stranger quirk of fate, when I went to tthe post office this morning to pick up the mail from my PO Box there was a large envelope with a return address from Arrow. When I opened it up, there was one of the $4 PSoC 4 Prototyping kits. The mystery is why they sent it to me and why it got sent to my PO Box instead of my work address. Not that I'm going to complain mind you.
So now that I've been given both the Prototyping kit and the Pioneer kit, I guess I really need to do something with them...
But not until after Field Day (only 3 more days)....
It's often be said of me that when tasked to buy a half dozen eggs, I return with a box full of (live) chickens and enough hardware to build a chookshed, but I think I will need to abdicate in your favour.
Did you ever get to make a bipolar current output from the PSoC? There's more parts needed than might be expected to be able to do this, I'd probably opt for using an INA , if sufficient headroom were available.
It is not always bit shifts though, for converting to fixed. It usually ends up rearranging equations in such a fashion that you do not get any overflows, or get something that you divide by a large number and then get left with something that becomes so small in the middle of the calculation that it induces large errors in the rest of the calculation.
I remember where I had a case where I was getting an overflow issue because of a situation where I had forgot to rearrange a multiply so that the equation during the solving process would not overflow. This was one of those errors that was hard to catch because I just was not even thinking about it, and forgot how large that number could get in calculation.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...