Notice the skip from workday #29 to #33. For the past three work-days and more I have been proceeding on plan B. Sadly this has not resulted in any code because I’m still trying to install a bloody tool-chain! (Tool chain, tool-chain, or tool-chain?) I’m frustrated and tired, and taking a break to write down what I have learned in the hope it sticks in my brain and comes in handy one day.
For porting code, what you need is an environment where you can have both sets of code to hand to test, and can keep close track on the differences. That means that you have to have two development systems running side-by-side. Ideally you want exactly the same code, and to be able to click on a button to compile for target A, or click on another button and compile for target B. Setting that up turns out to be a mind-boggling exercise, because it requires Eclipse or a similarly powerful IDE.
After thrashing around in the haystack reading a whole load of out-of-date, and misleading documents, documents that don’t actually tell me what I need to know, I decided that I would have to figure it out, step-by-step. The challenge is understanding the Eclipse plugin architecture, and where tool-chains have to be located, and referenced. Once upon a time I wrote this:
“One thing that amazes me is how nobody ever thinks to provide a conceptual model. There are lots of recipes, all of which become rapidly out of date. Nobody seems to understand that even a simple description of the objects, how they fit together, and what commands they implement, would so vastly simplify the process of understanding complex systems, as to enable people to figure out solutions for themselves, and eliminate most of the need for lengthy recipes.”
Turns out the Eclipse model is very flexible, and there are few general rules. Correction! There are general rules, but there are few general rules to which people universally adhere. Each tool-chain implementer has taken their own set of liberties with the intended architecture, and made certain assumptions, or put in extra configuration steps, to minimize the amount of adaptation work they have had to do.
To learn how it all fits together I had to start with an “empty” Eclipse. I started adding various components until I could compile a C program on Windows, for Windows. This sounds like a pretty easy thing to set up, and it almost is if you just install the pre-baked Eclipse for Windows C developers. But if you want to understand what all the parts are, then you have to install the plugins, the compiler/linker, and all the utilities like “make”, one part at a time. And then you have to figure out what environment variables eclipse considers, and get them set up just right, and then add all the extra variables that are needed.
It took two days for me to figure it all out so I could do it over, and over and get it to work every time. Notice that the only reliable way to check that it is done right is to delete everything: eclipse, tool-chain, plugins, utilities, then nix all the special Windows environment variables, then reboot, and start the installation (Many GB-sized downloads over the network) from scratch.
But the good news is that not only have I figured that bit out, but I am writing it down as I go!
Of course, compiling C on Windows for Windows is not what I need. I had to discover how to install a tool-chain to cross-compile for some embedded system. i.e. C on Windows for an ARM processor. It seemed like all you had to do is install a new tool-chain and point a few environment variables to new places. In principal that’s right, but in practice it’s much more messy. The Windows->Windows C tool-chain has all sorts of built-in support behind the scenes that you don’t see. For cross compilation you have to install that extra support.
What do I mean? Eclipse (and many of the contributed tool chains) were developed under Unix/Linux and to achieve portability and modularity, they lean heavily on standard Unix utilities. Many of which are just not there in Windows. Even the simplest Unix utilities don’t work on Windows – consider “rm” in Unix – it is called “del” in windows. It has different semantics, and takes different parameters. So Unix clones of these commands and utilities have to be installed.
Then of course there are different compiler chains, even for the same hardware. I already know that there are Gnu, Code-Sorcery, and Keil compilers that target ARM processors. Atmel has ARM tools too. Then there are all the plugins that know about details of a processor – like the Nordic chips with integrated BLE. So there are choices with benefits, and penalties.
So if you have go this far without dropping off to sleep you can see that it has (continues to be) a tussle. I tried all the shortcut installs, and read a bunch of stuff, but in retrospect I can now see that this tedious learning process was inevitable because I can’t get by with a single pre-packaged tool-chain. Once you need two tool-chains, you have to figure out how they can fit together without interfering with each other.
Anyway, I have learned a lot that will stand me in good stead for future stuff, and I feel a little more potent today than I did yesterday.
——————
David responds:
Far from dropping off to sleep it was very interesting. But exhausting to imagine going through it. At least you have the knowledge and background to figure it out. I wouldn’t be able to – not even to start down the path.. What a huge effort. What is everybody else in the world doing to use these tools?
Have you considered writing a book or pamphlet? But you said you would never write a book again. If you are writing it down is it something I would be able to follow and get to work on my end?
There will be hardware soon. It takes longer than one might imagine to strip back 70 wires, wrap each one around a header pin, and solder them in place. I am not stripping the wires; instead I melt the insulation away with a soldering iron, because stripping would pull on them too hard, assuming I could get the tool close enough to the board, and then the wire would get nicked and break off, leaving it too short to strip again. When I worked at Siemens we had a thermal wire stripper that burned the insulation down to the wire instead of cutting it. We were breathing those fumes all day. If I thought I would doing a lot more of it I would
buy one but I am pretty sure we won’t be mass producing these boards.
———————
Mik responds:
Yes, it’s all pretty tedious. But it’s just a matter of being relentless, which I can be. It’s the thinking part that slows me down.
I’d be very pleased if you’d try to follow my installation instructions so that I can debug them. I was half-thinking that it would be good to write them clearly enough that you could use them to setup a debug environment. But I have to be honest, my main motivation is that after a few months all the details go out of my head. So I’m trying to be meticulous, but express the process in a general sort of way so that even I can understand it in a year, and reconstruct the Eclipse system when everything stops working for some weird reason.
My plan is to write down all the gory details, and then, boil it all down to a cheat-sheet in some sort of appendix, so I can romp through it, and only need to read this dross again if it doesn’t work.
As soon as I get to the part where you can compile “Hello_C_TS06a” I will send you all the setup instructions. You could plod through and make annotations in places where things don’t work, or need clarifying. Or maybe we should get together and go through the the setup on your laptop, and I can fix the holes in the process and the documentation in real-time.
I’m very excited (and kind of worried) to hear that there will be hardware soon. You have really made a lot of progress. I had no idea there were so many tiny wires, but if I had stopped to think for a while, I guess I’d have realized the awful truth. You must be going crazy. Clearly we should invest in thermal-wire stripper. I can’t imagine that we won’t want to lash on bits of stuff, and make changes.
Maybe you could send me a photograph or two for the Blog? I’d like to record the process you are using to put it all together.
I remember the Xerox Dorado was all done with an automated wire-wrap robot, and later a stitch-weld robot. Presumably you could use a hand wire-wrap tool? I know they are fiendishly expensive. Here’s a picture I had. I actually had a Dorado stich-weld board until I gave it to the Cambridge Computer Museum last visit.
I think it will be fun in our dotage (next week?) to look back at this stuff, when all the technology has moved on. “Oh yes, we had to solder lots of little wires… none of this home-robot assembly”
Oh well, back to bashing on with the installation process…
