No wonder it didn't work

When the parameter download to device failed, I pretty much knew where the problem is. Visual inspection only confirmed the suspicion:

Not very good photo, I know, but without macro lens this is just about best I could do. Maybe I should try to build some kind of adapter so I could attach camera to the microscope...

Yes, it's typical serial EEPROM on I2C bus. One leg raised (VCC), another just barely soldered. Easily fixed and good to go.

Which allows me to awkwardly transit to another serial item, RS232 I praised previously. Soon(-ish, time allowing) I'll be posting some simple code examples on how to build communication between two devices with increasing complexity and safety.

Ode to RS-232

The RS-232 serial communications was first introduced in 1960s (and amended and changed numerous times after that) and its death has been proclaimed over and over again, lately by ubiquitous USB. New computers haven't shipped with RS-232 ports for years now, unless you deliberately seek out specialized motherboards for some extra cash.

On paper just about anything else is superior to RS-232. Data speed is very limited. It is point-to-point link (no multiple devices on same wire). And cable length will quickly limit transmit rate even further. And so on and on.

Yet I still find myself building RS-232 cables even today. Simply because one very - nay, extremely - important factor:

It just works.

Just about my entire career I've been dealing with devices that carry certain expectations. When customer pays more than 100k€ for device, you just can't tell them to turn it off and then on again, just because some stupid peripheral device connected internally with USB decided to crap out. Dealing with that was one of my first lessons on reliability (*snicker*) of USB. Not exactly fun, and when dealing with COTS components, not much you can do about it either. But somehow we managed.

Lately the price tag of devices I work with is smaller but issues are the same. When USB link hiccups, it just doesn't reset itself and carry on, but it will need to explicitly power cycled to recover. Small thing but still annoying, and frustrating to user (even if the reset itself happens automatically and semi-transparently).

Granted, RS-232 isn't immune to broken connection problems either, but at least it is easy (relatively speaking) to build fail-safes and recovery to protocol code, and I have to admit, a lot of my protocol code is fairly paranoid nowadays, at least in places where it matters. Framing, timeouts, connection resets and what not everywhere.

Now someone might ask why don't I use CAN or other such bus that is designed for reliability. The answer is availability. RS-232 is everywhere. Every single MCU you pick (except maybe the tiniest ones like PIC10 I wrote about earlier) will have it. All you have to do is connect two (or three) wires and write simple routines (typically about 20-30 lines of C - and I mean C that directly uses hardware registers, no libraries involved) and you will be good to go (okay, you might need MAX2323 or other such chip there somewhere unless you want to fiddle with (LV)TTL link - and for reliability some nicer protocol on top, but sometimes simple commands is all you need to hack something together).

So there, you'll have to pry RS-232 link from my cold, dead fingers before I'll give it up. Because there is nothing that can beat its simplicity and reliability.

JKartta update - import your custom maps

Since last time I've implemented GPX data import/export and more interestingly ability to use your own custom maps (imported in slightly modified MapInfo .tab format) with the app. With that addition I felt that I could publish the app in Jolla store, however I ran into slight snag; Translations.

So far the app has used exclusively Finnish map data, and thus there really was no need to support anything else but Finnish language. Now with custom maps it became usable elsewhere too, but I hadn't really though of translations yet.

Fortunately there weren't that many texts so adding English translations didn't take long (granted, translating main help/manual file is still work in progress). There just seems to be fun bug in Sailfish that prevents applications from automatically detecting current UI language with usual methods (QLocale::system() and getenv()). So far I haven't found any (sane) workarounds either.

Damn. Oh well, the version with map import can be (soon) downloaded from http://www.trippi.fi, as long as you can tolerate it speaking (umm.. reading?) Finnish to you. We'll see how it goes with the official store.

JKartta officially

Now it's (a bit more) official.

JKartta main page (page in Finnish; since this is about Finnish topological maps I'd expect not many foreigners are that interested, although it might come in handy if you are into hiking for example)

Now then, why am I writing this in English? Well, the app definitely isn't finished yet. Something I'd like to add at some point;

On-screen compass
Resuming previous track (after shutting phone down for overnight stay)
Reducing power consumption (I suspect there are many unnecessary screen updates, especially when phone's screen is off)
OpenStreepMap integration (it's already partially done although very glitchy; if I'd also have access to tile server this would allow me to make that part of software free)
Overlays (custom highlighting on top of map, like allowed hunting regions, or own map tiles)
...And whatever I feel like adding yet