Privacy by Directive

New European Union privacy directive - 679/2016/EU or GDPR as the common term is - will be either reason for celebration or horrible business-breaking problem, depending on how prepared you are. And of course how invasive your information excavation happens to be (*cough*facebook*cough*).

From purely personal perspective it's pretty great - no longer can these huge privacy-sucking corporations just vacuum out everything about you and post it for anyone to take without you having any say about it.

But for many businesses it can be a huge problem, scope of which many haven't realized yet. Aside the typical issues mentioned just about everywhere, there is also how personal data is defined;

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

This is direct copy from directive text. If you start reading this like the proverbial devil reads the bible, this is a huge can of worms. For example, if you have web page somewhere, there very likely is an access log there too, one that logs IP addresses. Now, that IP address may not tell you who the user is, but indirectly it can be used - when combined with other data, say, logs from other services - to identify the user.

No, I am not kidding. I was just recently in a meeting where a lawyer actually said this - there is already a court case that essentially said this.

This meeting went on, but the end result was that just about anything can be 'personal data' and must be treated as such. By this point I had loads of alarm bells going on in my head, and the IP log mentioned above wasn't even close of top issue in my mind.

How are your logs and databases doing, by the way?

STM4F469 and USB HID

At some point I started playing with STM32F469 chip - essentially newer, bigger and better version of STM32F429 I've mentioned before. Mostly it was really simple just to drop it in the design in place of older -429, almost everything worked right away (there are minor changes in pinout though, even with nominally same package, so consult transition info first!)

Almost.

Unfortunately the old two-way USB HID routines I had working with -429 were essentially dead. They compiled and ran, but did not do anything. And since they were build from ST's horrible mess of "libraries" (those things do not really deserve to be called that, they're just that bad to read), there was not much that I could do to figure out why they wouldn't work. Some tiny change in USB, somewhere.

So I took newer version of same horrible libraries and adapted them. And the result was...

"The device cannot start". Well, thanks, windows, mind elaborating a bit here? (if you have ever tried to program USB in windows, you know the answer to that already - "no!". And that is the short, cleaned up version, add few expletives and you'll get the real answer that windows usually offers in these cases)

I spent way too many hours trying to find the issue. Maybe some USB descriptor field is a bit off? Maybe this or that... Tweak something, try, fail, repeat. Frustrating effort, to put it mildly. Even tracking USB handshake sequence progress by tapping into it proved fruitless.

And eventually I thought of changing the PID - the USB product ID the device is identified by. And the damn thing worked right away!

So, my guess here is this: Previously I used different chip, with different libraries but with identical USB descriptors and VID/PID codes. As USB is (should be) identified and made working with this information alone, different chip and libraries shouldn't matter as they offer same descriptors and services windows sees.

But apparently something somewhere did matter. Windows most likely had stored something it expected to match the VID/PID pair, somewhere, and when it wasn't exactly as it wanted, it refused to work altogether and just gave that completely useless error message, instead of - say - discarding old, obviously stale data and starting over. Figures.

The good news is, this typically isn't something that you would run onto in production, as there everything should be fixed and just stay the same. And if there is a major revision - change of USB chip or something, for any reason - just change the PID. It seems to make life so much easier.

Oh, someone want to get a example copy of those USB HID libraries for STM32F469 or -479? Raise your hand...