Change is hard

This isn't about climate (although it's important too), but this is primarily about programming.


I've used various code editors over the years. I started programming with Turbo Pascal (TP), so its IDE was quite natural first step (I'm just ignoring anything related to BASIC before that).

Then came C, and specifically DJGPP. I think it used similar IDE - and specifically similar keyboard shortcuts - as TP so transition there was kinda easy.

A bit later I got my first actual job where Visual Studio C++ was used, and since I used it so much all the keyboard shortcuts used there became very familiar.  So, when a bit later I got C++Builder 4 for my personal use (think of Turbo Pascal for Windows (aka Delphi), but for C++), I set it to use Visual Studio emulation for keyboard.

Later I started working on my own, and since I work mainly with embedded ARM, and with limited budget, C (gcc) and makefiles were natural choice. So no IDE. But I still needed an editor.

Eventually I ended up with editor called syn. It did what I needed, and albeit a bit clunky and limited, it worked for me very well, for long time.

Until now.

Syn hadn't been updated for a while, and some things were starting to annoy me, so I started looking for modern alternatives. I am not fan of, well, massive IDEs like Eclipse so those were immediately out, I just wanted a fast (responsive) code editor.

This process took a long time, but eventually I ended up with Visual Studio Code. Out of the box, so to say, it doesn't do all things I want, but fortunately add-ons fix a lot of that. And in process, I've found several very nice features I hadn't even thought of before. I think I will be using this for a while now.

But there's few things I haven't been able to figure out. One being, how to fix include paths in C/C++ module? There are instructions I've found, but I think they are for older version of VSC as they don't work anymore. Yes yes, go to module settings, fix variable and done. But I just haven't been able to find that setting no matter how I try. Minor issue (as I use make output in shell for issues), but still kinda annoying as there's those red wavy lines everywhere.

Second being "match bracket", as in "go to matching bracket on cursor". Document says something like "shift-ctrl-/". Thanks, how about non-US keyboard layout, please? This I fortunately don't need so often, but when it's needed, it's invaluable.

Now, if only I could also include my make process there with line highlight... But let's take this one step a time...

But I guess I find solutions eventually. Change is hard. Changing code editor, especially so.

Debugging level: psychic

Over time, I've developed a kind of unofficial policy on error reports considering our devices.

Report one of issue: "Weird." (might be user error, might case of cosmic rays, might be something else)
Report two relatively close to first: "...Okay, that's curious."
Report three: "I need to take a look."

Getting a good, detailed report also helps. You know what I mean, as opposed to "I did that and it said something and then I just pressed everything and anything and now everything is gone." (cue facepalm.)

Yes, this situation happens way too often as people react to unexpected situation by panicking, when somewhat more correct procedure would be to take a step back and consider what to do. Like picking up the phone before touching anything.

But when it comes to actual troubleshooting these cases (actual issues that is), these days it seems I do most of the most of that just by reading the most-likely-relevant code and trying to figure out what needs to happen to cause the reported issues. Not that I could do much else, when a customer calls me to inform of a very rare case of weird behavior, it usually is something I can't reproduce in my test environment, at least not easily.

Most of the time that doesn't help and I have to drop the issue. But like I've said often, the mind keeps working on these things even when they are in back of your mind. In background some processing happens, and next time when I open the editor things looks a bit different, and maybe some other location needs to be examined too. That might not be enough for breakthrough, but repeat this for a few more times and usually I can construct a theory on what could go wrong to cause observed issues and fix it.

Of course I might be wrong and it is something else. But even then, at least that single potential issue is now in order. Moving on to the next.

I think this - ability to think what is going on, as opposed to using debugger or logging - is a skill anyone one develop. I do use debuggers and logging too, but when issue isn't one that I can observe directly, those don't help. Having written all of the code, including interrupt handlers, helps as well as I know it inside out, but knowing everything is not required. What is required is knowing parts that interact, even indirectly. Reading, say, data processing code doesn't help if there is for example an interrupt handler that also touches said data elsewhere and you don't know of it.

After that, it's mostly about figuring out what could happen. This is not rocket science (well, unless it quite literally is something like rocket control module), but it takes some practice and suitably paranoid mindset to think about unexpected events you might have seen or, really, thought of.

Project: ATV electric conversion

Few years back we got a small, cheap 50cc ATV for the kid to drive at our summer home. Originally we ordered (and paid for!) one with electric starter, but those were out and we settled to one with pull-start instead. This was cheaper so we should get refund for difference, right? Of course not, this seller (name escapes me, but IIRC from somewhere near Vaasa region) is one of those you shouldn't ever make business with. Eventually we got the refund, but only after numerous more or less thinly veiled threats of legal action. This left pretty bad taste so there's just about no way in hell we'll be doing any business with him ever again.

Cheap chinese kids' ATV. What can you expect? Well, bad quality, obviously. Entire pull-start system broke after just few total hours of use (numerous starts though, it stalls a bit too easily, especially in hands of less experienced rider) and even managed to damage the cast casing in the process.

The only way to start it now is with a drill. Mains-powered one, none of the battery drills I have have enough power for that. Considering tendency to stall easily, not exactly great option as it's a long way to push it back to the yard if it stalls somewhere far away. Note that engine is running in this picture and the "cooling fan/fly-wheel" is a exposed. Very dangerous for restless fingers... So I would have to start this up, attach some kind of cover and then hand it over.

While I might find some spare parts for this, I don't really want to. It's loud, smelly (requiring 4% two-stroke mix!), and as-is, dangerous to fingers. Yet it is fun for the kids, so I don't really want to get rid of it either.

So, why not take the two-stroke engine out and replace it with electrics? That's certainly not cheap nor easy either, but as a project and especially learning experience it might be kinda sorta worth it.

When I'm writing this it's start of September, so there are roughly month or two of "driving season" left for this thing before the winter. As my plan goes, I am planning the process and choosing and ordering suitable parts first, leaving the ATV to its current state for a while now so it can be driven yet. And when the winter rolls in I bring this to home and start the real work with it.

I've been doing some preliminary browsing, and at the moment I expect majority of the work being on metalworking side: Removing old parts (only if/when absolutely required), creating new structural assemblies for new parts and so on. I've never welded before, but I expect to learn some of that too - which actually is major motivation for this project. Work with electronics I expect to be almost trivial matter with variety of ready modules available these days.

So I will be posting some updates here as things progress. Like I said, I expect this to take better part of winter so updates may be quite infrequent. We'll see as I go.