(Ab)use of serial ports for fun and profit

Serial ports (as in RS-232) are a wonderful thing. If you are working with microcontrollers RS-232 is superior to USB in just about any way - just about every chip supports it directly, it's extremely simple to use, cheap and you don't have to worry about driver updates bricking your devices (reference explained - while I see their point, destroying users' devices is absolutely disgusting and I personally will never, ever use their products due to this.)

Of course your customers might not like RS-232 that much, but when you are a hacker scratching your own proverbial itch that doesn't matter.

And you can (ab)use the hell out of RS-232 port - just like parallel (printer) ports too, before modern operating systems pretty much killed ability to do so. Unlike parallel port however you can still control almost every signal line of RS-232 with your application directly - and when you realize the implications of this a world of unforeseen applications suddenly opens up.

For example at one point we made a chip card reader that connects to RS-232 port and doesn't need any external power, using just handful of resistors, capacitors and transistors. Simple, efficient and completely against every RS-232 specification that exists!

That chip card reader worked beautifully -- until it met first actual IBM-built PC (yeah, this was a long time ago when IBM actually built PCs and they had actual serial ports built-in.)

RS-232 line specification requires that voltages are either -5 to -15 volts (logical 1) or 5 to 15 volts (logical 0), and everything in between is undefined (I might remember exact voltages wrong but values are close enough for the topic here). So voltages between -5 and 5 are officially invalid, but most RS-232 implementations are happy with logical voltages between -15 to 3 ; and 5 to 15, respectively and approximately. So our reader used zero as logical 1 and whatever port supplied (often 6-12 volts) as logical 0.

This IBM however wasn't having any of it. Its RS-232 port didn't work at all when voltage was at the forbidden zone - between -5 and 5 volts. So we had to upgrade the reader so that it also used negative voltage provided by port so the signals would be more valid. And the troublesome IBM started cooperating too.

This was (I think) close to 20 years ago, so technology-wise this is ancient history, but I suspect that few of these readers might still be in use somewhere. RS-232 however is still the same as back then, so this hack should work as well today as back then. And even with USB-RS232 converters most hacks of this kind still work today.

It'd dead, the lens

I've been using my Canon EF-S IS 17-85mm lens for - well, quite many years now (since 2008 possibly). Despite the weight it became my primary lens for general use due to large zoom area and image stabilization.

Just last summer I had to do some work on it (fixing stuck lens), and now it's completely dead. I previously mentioned that we just took two-week holiday, and of course it started to fail just halfway through that visit. First it randomly started giving error 001 (communication failure) after taking picture, and fairly quickly after that it stopped responding to camera completely. With a week of holiday still to go. F*ck.

We still had old pocket cam (Canon Digital Ixus series) so it wasn't complete loss (I still consider phone cameras as absolutely last resort option only, right after canvas, palette and brushes). However I'm so used to tweaking just about every lighting parameter of camera to get shot just right in more difficult situations (I'm using Av mode about 95% of time, remaining 5% being mostly full manual with occasional other modes thrown in here and there) so lack of any useful adjustments in those point-and-shoots is frustrating, to put it mildly. But at least I got the usual holiday snapshots.

Back home I took the lens apart again, but there wasn't anything obviously wrong so I gave up. The build of the thing is quite interesting though so I'm considering doing a better teardown of it later. The build of these things is absolutely fascinating, from systems design point of view.

But anyway, I had also used my old Canon 450D body just about the same time as the lens, so it was time to upgrade that too, to nice Canon 700D and brand new EF-S 18-135 IS STM (that's for APS-C sized cell, Image Stabilizer and Stepper (focusing) Motor, for those less familiar Canon terminology). Let's hope those serve me as well and as long as the old lens and camera.

And no, I didn't throw the 450D body away - it is still perfectly functional so it is my backup camera now.

Old way is new again (in graphics)

It just occurred to me that computer graphics seems to be reaching a point of full cycle (kinda-sorta).

Back in the days there was just direct hardware access (and I mean direct, as in "absolutely nothing between your software and video card registers.")  To get full performance from the graphics you had to know your hardware (both processor and video card) inside and out - memory mappings, instruction timings and interleaving (pentium pipelines) and everything. You had to micromanage all the small details to make hardware fast.

This is how (for example) original Doom and Quake were able to achieve usable frame rates with relatively slow computers. Back then there really wasn't any hardware acceleration available for games (on PCs; other computers had dedicated blitters and whatnot), so if you wanted your program to run fast, you had better to learn it all. I, too, spent considerable time fine tuning inner loops of my blit-equivalent function.

Then came the first hardware accelerators and their APIs. Now you "only" needed to link a library and call functions there. Just call a function and a triangle is drawn. So much easier - as long as user had the same video card. If not, well, too bad.

Then came OpenGL (again, to PCs, it did exist earlier) and more importantly DirectX. Both provided most of the functionality (either directly or with add-on libraries) that you'd need to write fast 3D code. And with abstraction things like memory access and timings became mostly irrelevant, or at least focus changed to entirely different level (optimizing batches of triangles instead of single pixels.)  Since the APIs handle the hardware abstraction, you can't really even know what is happening inside libraries, drivers and hardware.

DirectX even had retained mode where libraries did just about all the work for you. No need to know, well, almost anything. But where is the fun in that, really.

And then the cycle started to go back, although somewhat different path. With newer APIs (OpenGL 3.0+, I'm not really familiar with DirectX today but I'd guess it's on similar path) more and work is being pushed back to the user. Old matrix operations were taken out, as well as fixed function pipeline (it took me a long time to let go of it completely as it made some things easier) and now you have to do all that math-heavy work yourself (libraries of course exist to do that for you if you want).

And with new upcoming APIs like Vulcan you have to take over things that have been take care by driver for ages - like memory (texture and buffer) management (I admit that I'm not familiar with details, I'm mostly repeating what I've heard). All this in name of efficiency and speed. You'll have to micromanage all the small details again, for same reason as in the old times - speed!

I don't think that we get back to raw hardware access ever again (again, at least on PCs, with operating system on your way) so this is very likely as far as the raw access gets, but who knows.

Of course, most people don't need to delve there. Commercial engines like Unreal and Unity will take care of those nasty details, but point still stands. You can once again get your hands dirty with low(ish) level access to hardware - if you want to.

And if you pick some other platform (say, embedded systems), you can get direct memory access and register tweaking too if you want to. After all, there's just something extremely satisfying when the first pixel appears on display after hours and hours (if not days) of work on registers... It might not be the most productive way to do things, but I'm pretty sure you'll learn way more about hardware with that single pixel than after years of work with high-level APIs!

Things change

Sometimes it feels like nothing really changes, but then something happens and offers some perspective. Like communications when travelling and data storage.

I mentioned before that we were at South-East Asia for several weeks back in 2007 - 9 years ago now. Back then if I wanted to write email home I had to find a local net cafe (not that hard, even smallest villages we were in tended to have one somewhere), buy network time (cheap) and use their computers (very likely full of viruses, spyware and keyloggers) to log onto webmail. Yes, I used disposable mail account for that very reason. I of course had my phone, but calling and SMS were Expensive with capital E so I preferred to avoid them when not absolutely necessary.

I just returned from a holiday in Thailand and things are very different. Now almost all hotels and restaurants offer free WiFi. Just use your cheap phone to log onto your email or whatsapp or whatever's your favorite method and chat away. While that wifi might still be spied on (be it spyware on router or passive listening) that isn't really a problem with HTTPS and SSL (or if you are really paranoid, VPN). I don't think I even saw net cafes this time.

Then the storage. Back then I already had DSLR camera (the very first Canon 300D) that used CompactFlash cards. Those were still expensive, and I think I had just few 512MB cards. So at least weekly I had to somehow offload all that data to somewhere (I use raw format exclusively so pictures tend to be large). That somewhere was iPod (with 80GB hard drive, which funnily enough would be luxurious even today - you just can't get players with that much internal storage any more) with camera adapter. Show as hell, and horrible battery hog but it got the job done. Back then I chose that iPod because of the camera adapter and storage alone. Had it not been available my solution would have been something very different and very likely less practical.

These days I carry bag of smallish (typically 2GB) SD cards. Cheap enough to be almost disposable. For some reason I have never trusted SD cards that much, and by using small cards I only lose that much of data if one fails. No need for external storage, but I do take care not to abuse them. Losing data sucks, doubly so if that is for some dumb mistake like pouring your beer on it (none of the cards I have have failed so far, but knocking on wood...)

My camera is still Canon, but features in my current 700D (with 18-135mm lens that has image stabilizer) are something I would only have dreamed about back then (and it is something I still prefer to stay hidden in my backbag when it's not used, no reason to draw more attention to yourself than necessary)
So much has changed over the years, but when that change is gradual you kinda miss it. Only now, when I could make direct comparation to what I had available back then and now it suddely came clear and surprised me. Wonder what we'll have in another 10 years or so...

Budget tip: Lunch restaurants

Finland isn't one of the cheapest countries you can visit. Specifically eating may be expensive if you want to - or have to - eat at restaurants all the time.

Here is one very valuable tip if you want to save there: Work lunch.

A lot of workers eat out at lunch time, which typically is from 10:00 to 14:00 or so. For this reason there is a huge number of restaurants that offer nothing but lunch, and these places are relatively cheap - less than 10€ will get you food, drinks (water or milk mostly, alcoholic drinks aren't typically available at all at lunch-only restaurants) and coffee with some small dessert. Meal selection is typically limited (often two or three different options) but these days there is almost always at least some vegetarian option (there are places suitable for strict vegans too, but they're a bit less common)

The only problem is that most of these places aren't always easy to find. Unlike typical restaurants these places tend to be hidden on some side street, in a non-descript building with maybe just a small, simple sign outside, if even that - some places, especially in larger office buildings may not advertise their existence at all outside the building.

Even as a finn one might have problems spotting these places if you aren't familiar with local selection. I remember one time at Kalajoki where I was looking for a lunch place. I spotted one place that from outside looked like a typical bar. I was about to leave to look from elsewhere but I happened to notice a man in blue coveralls exiting this place. This being noon and drinking in work being frowned upon I had to ask, and his response was that this is just the best lunch place in town. Once again looks can be deceiving, although place did serve as a bar too - on evenings.

And like absolutely everywhere else on earth, you'll want to go to a place where the locals eat. Those places tend to have the best food. So following some hungry-looking group might lead you to some really nice place hidden from the view.

Of course many "normal" restaurants do offer lunch menus too, but for more authentic home cooking-like meal you'll want to find one of these places that serve lunch only. I'm almost certain that you'll be pleasantly surprised.

Screw paperless office

About the same time first personal computers started to appear people started talking about paperless office. Well, screw them. I like paper. Making sketches and notes on paper beats screens and even tablets still every single time. Including - no, especially when doing electronics design.

These are just a few I found on my desk, with notes for part footprint design, functionality placement and overall design. For footprint design I usually need to calculate specific coordinates, so printing out datasheet and calculating/drawing these on paper makes it easier (some datasheets are great on this regard, some close to useless). This one on top is fairly simple part and had most (but not all) information I needed already so there's just few numbers there.

Or take the paper with LQFP176 there; this processor (STM32 series) has a lot of functionality, some that can't be (easily) relocated (USB), some that offer few alternatives (most LCD pins, FMC, UARTs and SPI) and some with a lot of options (ADC and GPIO).

So I process in that order; first pick peripherals that must be at specific place and put them there. Then take next peripheral that has options and decide where to put them. And next and next - until last some random slow GPIOs can be placed where there is a just about any pin remaining (and these can be easily relocated if space runs out at some part of layout design.)

Markings on paper makes this process much easier than any paperless option. Can I place input GPIO on PA2? No, taken by peripheral, so maybe PC2 or some other port.

And there is absolutely nothing that beats thinking with sketchpad and pen on my hands and feet on my desk.

Screw paperless - you can have my A4s when you pry them out of my cold, dead fingers.