Const vs non-const data

I've been working on STM32F4's USB now (while not otherwise occupied, so very slowly). The easiest way I figured out (considering my vast lack of deep knowledge of USB details) was to take standard peripheral driver provided by ST and adapt it for my use. So far I got it to compile but it doesn't work yet -- board isn't properly identified by Windows. So maybe later I got something there, but for now something different.

During the process I found numerous definitions in USB driver files in type of

USBD_CDC_INT_cb_TypeDef USBD_DCD_INT_cb =
  { USBD_DataOutStage,
    USBD_DataInStage,
    USBD_SetupStage, 

    ...
}

So what's wrong here? Well, strictly speaking nothing, it works fine (usually, but not in my case, but that is another thing, related to me using non-standard init code). However since these structs are typically not intended to be modified run-time they should be defined const.

So what it the difference?

If you define data non-const (like above), you strongly imply that you have intention to alter it during program execution. This of course means that the data must reside in RAM. And since this is embedded device, this means that compiler must store initial data somewhere (usually along program data in flash), allocate space for modifiable data in RAM and during program initialization copy the data from flash to RAM so it will be available when program starts. So effectively this wastes both RAM and execution time. Granted, not much, but when dealing with limited resources like so often in embedded devices it all counts. Especially when you have multiple this kind of structures in your program.

So when defining data in your program, make it const unless you absolutely intent to change it. Then linker can place the data in flash where it can be read just fine.

But wait, there is more.

Ever done a function with non-const data? (ignore buffer overflow possibility here, this is simplified example)

void sin(int angle)
{
  char sinvals[256] = { ... };
  ...
}

Since the data isn't const, it must be allocated in stack and initialized every single time the function is ran. When data is small there isn't that much overhead, but with large data it starts to get significant. And even more so in this kind of case where the function itself (typically) isn't much more than simple look-up.

Time for a new tablet ..

Some years ago I got Asus TF101 Transformer tablet with keyboard. Considering that I don't like on-screen keyboards very much (to put it very mildly)  the keyboard has been quite handy for occasional work email and such. But either way, the fact is that there is absolutely no way tablets could replace even laptop in my work use in foreseeable future. Still, when traveling, especially with kids, a tablet is absolutely work every cent to make flights more tolerable.

Over the years table has taken some - nay, a lot of abuse but still has held together surprisingly well. Only now it stopped charging completely so it was time to upgrade (although new tablet doesn't feel like upgrade - it's essentially exactly the same. Disappointing, I was kinda expecting more).

Here's the time I apologize for forgetting my SLR home -- I intended to take some pictures from insides of the thing, but I guess you'll have to look for some teardown videos/pictures elsewhere.

Suffice to say, every time I take apart something like this I'm amazed on the systems engineering that has gone into these things. Packing everything needed in relatively tiny enclosure and getting it to work as well as it does -- damn. And here I am, trying to figure out how to put way simpler device together. Granted, my design constraints are quite different - everything absolutely has to be on single PCB and all internal parts must be off-the-shelf type, so no custom modules, connectors or FFC/FPC cables are allowed to make things easier.

Unfortunately I could not figure out what was wrong with the charging. Measuring around power/battery seemed to indicate that everything is well, but still it doesn't work. Well, that was just about the extent I was willing to go to to revive it, so guess it goes to the scrap bin.

But before that I needed to clear all personal data from it. Since it didn't change anymore and couldn't even run on external power the usual factory reset route wasn't really available, so I used my ESD generator (quick googling didn't result any better links so that has to do as an example) to destroy both processor and flash chip inside. My generator is a bit bigger than one shown in article and capable of generating almost 20 kV spark so after few tens of zaps the thing should be essentially dead. At least it doesn't react to power at all now... (and yes, I did disconnect the internal battery before zapping it, thought of burning lithium on my face wasn't too inviting)

WLAN/BlueTooth to your project - cheap or certified?

Today it seems IoT being all the rage you'll quickly want to add some kind of wireless connectivity to every device you make. Quick search through your favorite vendor's site finds dozens of different all-in-chips for just few dollars, so great! Just slap it on your board with antenna and you've got a product!

Okay, let's stop here. It's not that easy. Or it kinda is, but there is a serious gotcha there that might become veeeery expensive later. I'm mostly writing from European perspective here, but same things pretty much apply on the other side of the pond too.

If you want to sell, well, just about anything electronic in Europe it absolutely must have CE marking. Note however that I said marking, not certification - there is no such thing as CE certification in many cases (notable exceptions being anything that deals with money or safety-critical systems.)

CE marking alone is nothing but manufacturer's promise that device is okay and fulfills any and all relevant regulations. Depending on device other directives apply, I won't go into too deeply in details of most things here. Oh, and I am definitely not expert either so take all here with grain of salt - I've had to do a lot of studying of these topics though...

For most electronics with any kind of oscillator directive 2004/108/EU (EMC) applies. That essentially says that device may not emit too much radio noise, and it must tolerate some some from outside. (I'm simplifying here a bit for brevity). Then there's also regulations for batteries, disposal (WEEE), devices that run on higher voltage (LVD) and so on.

But back on topic of radio modules, important directive is 1999/5/EU (R&TTE) which regulates radio devices. And here things get nasty. If you just slap chip and antenna on your board, you essentially will have to do full compliance testing for the device before you can sell it. Needless to say that costs some serious money, so the 2€ chip with 10cent antenna just became a lot more expensive.

So what happens if you don't? Well, often nothing. No one notes, no one cares. But if you happen to make mistake in your design and your device (which you just delivered 50+ units all over Europe) emit some nasty spurious RF signals on, say, military or aviation bands? Now you are in some serious trouble...

So for many small-volume products pre-certified RF module might, while expensive up front, be actually cheaper option (BT/WLAN modules start from 20€ or so; personally I like BlueGiga parts a lot as they have proven to be very reliable in my use, unlike most phones that crap out the second device drops out of range). Pre-certification here means that entire things comes as standalone module, antenna an all, already having all necessary certifications (ie, say, WLAN compatibility, R&TTE, FCC equivalent and all others). You can just slap the unmodified (that part is very very important!) module on board and use it. Just make sure that the module actually IS certified, many cheap parts aren't although they claim so. Manufacturer must be able to send you relevant certifications. Also modules tend to have things like built-in TCP/IP stacks and other nice things that makes your life so much easier too.

Of course already mentioned EMC and so on directives still apply but testing for those is way cheaper than RF stuff (your local university might have EMC lab willing to do EMC testing for 1000€ or so. They might not be accredited, but results are still often good enough to show that device is okay for sales so if you're feeling cheap it is possible to slap CE there and write Declaration of Conformity and go on for sales. Not that I recommend that, especially if you are just getting started - consult an expert (ie, not me!) first. But make sure that your expert doesn't have ties to any large testing lab - they tend to have strong bias on their recommendations for some reason.

Another capacitor failure

Our DSL modem died on one night. While waiting for operator's phone support I had enough time to ponder the failure reason and even then I suspected capacitors. Well, operator sent new one with (almost) no questions asked and didn't even want old one back so you know what happened next: autopsy.

As expected, after opening device I was instantly greeted by several bulging capacitors. No wonder it's dead.

I was thinking of doing some scope captures of voltages on the device, just to show what happens with dead cap, but its power module (random "no-name" brand, rated 2A @ 12v DC, at least claiming to have all the proper safety inspections done) appears to be dead too - it's output it essentially AC at tens of volts. Bummer, because I could think of several uses for such power adapter if it worked.

Now, did the power module fail first, killing the cap in process, or other way around?If it were just the first filter cap that had failed I'd suspect the power module, but in this case caps are all around the board so I think that the model failed first, eventually damaging power module too.

Either way, to trash bin they go.