I think it's not unreasonable in embedded systems to write a proof of concept code to help to understand what the datasheet is trying to tell you knowing full well that you'll probably have to junk it when you expand to the production app.

James

You're definitely right, considering I've prototyped a few chips now.

There's a couple where I'm leveraging the C lib wiringPi a bit too much (for specific ICs). I'm using parts of the API from there that I don't necessarily agree with, and it is forcing me to do things in my code that I don't like.

For instance, the shift register; I'm using a wiringPi library function for it, but it uses internally what are called "pseudo-pins", which collapses consistency across the board. To boot, only one set of these pseudo pins can be used per program run, so I can't include anything else that uses these pins or things break.

This means that after I get a baseline unit test automation happening, I'll be re-writing the shiftreg software myself, using techniques I've learned (bit-banging in conjunction with allowing a user to use the onboard hardware SPI), among other things. Same with iirc one other peripheral.

It just sucks that I will have to change the API in some cases; not just because it means I will have to update *insert number of tests in number of tests files here*, but for the small number of users who are using the software already, who have been providing wonderful feedback.

Thankfully, the ones that have been reaching out through issues or direct emails are all good with this. Disaster strikes for those who are using it that I don't know about.

This is a learning lesson for me. I have released some 30 odd CPAN modules, and have been able to keep my APIs pretty consistent across version bumps because my testing regimen is usually 100% coverage or it's not ready, and that includes backwards-compat. This case, there will be breakage.

It is what it is. I've learned now that when wrapping something else and going overboard with writing new low-level code to both supplant and/or augment the wrapped software, that sanity should win the day, and *everything* you're wrapping should be tested *thoroughly* like one's other software before releasing public.

It is what it is. I digress, which allows me to learn and move forward.

not just because it means I will have to update *insert number of tests in number of tests files here*

I would heavily encourage everyone to change

use Test::More tests => $n;
# ...
[download]

to

use Test::More;
# ...
done_testing;
[download]

You need to update your Makefile.PL's Test::More requirement to 0.88. No more test-counting by you, ever!

help to understand what the datasheet is trying to tell you

Well, it seems the propaganda term "Lügenpresse" was originally invented to describe some datasheets. ;-)

At work, we've encountered a datasheet for a major brand chip (a kind of serial interface bridge) that was misleading or plain wrong in almost every single detail. Overall, it took three developers about six weeks and an insane amount of workarounds to get that *BEEEEP* chip working reliably. Looking back, it would have been faster, cheaper, and easier to implement that bridge in software on an ATtiny.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

During this journey of learning, a few people have spoken to me about this, and in one case (I can't remember which chip it was), I had an issue configuring a two-byte register. It turned out that the datasheet said one thing, but in reality, four of the bits were backasswards. My frustration was through the roof, because I *thought* I was doing everything correctly, but being pretty new to the game, was ready to deskpalm my face.

I don't remember exactly what led me to reversing the bits, but I can definitely understand what you're saying here even though my experience was a lot more mild than yours was.

Lesson was (and is again re-inforced) to never take a datasheet at face value, and if one isn't getting proper results even though they're certain their code is right, the docs may not be completely representative of reality.

It's nice to hear about your shared pain. LOL. We've all been there. Eventhough, with the Web it's much easier to find help than in the days of digging through the manuals or waiting for the vendor tech support to call you back or bump it up to corporate...

James

There's never enough time to do it right, but always enough time to do it over...