Sur-prize, surprise!

This post is about hi-fi cables and connectors, and my recent experiences with them. A few months ago, I wrote a letter to a hi-fi magazine, and they made it ‘Letter of the month’, for which they offer a prize! In due course, I received a Russ Andrews 1 m Yello mains cable, with a UK 13 amp plug on one end and an IEC mains connector on the other. Sur-prize! 😀

I have always paid attention to hi-fi signal leads and connectors, but had assumed that the mains cables supplied with my kit (from reputable manufacturers) would be up to the task. I replaced the mains cable on my amplifier with the Yello cable, not really expecting to hear any difference.

But there was a clear improvement to the overall sound. Not a transformation, but a modest and noticeable enhancement. The sound was (and remains) a little airier, each instrumental strand just a little clearer, and bass guitar notes a little more defined. Not bad for free!

But I can hear you thinking I should’ve expected this. Magazines and reviewers have been praising cables for many years. With hindsight, I can see, as you can, that I should’ve known better. But now comes the interesting bit:

I ordered a second Yello cable. My thought was that I could try it on the PC, hoping it might improve the sound on my ‘phones. 😯 [I listen to music stored on my hard disk, via foobar2000 and a Chord Mojo2.] If this fantasy didn’t work out, I could surely use it to some benefit on the CD player.

I got lucky! Although any computer is a strong source of digital noise, a Yello cable did improve the sound, much as before, but bass and drum notes were just a little more prominent too. Not a bad thing when you use open-back headphones.

But my surprise was that sound originating from a computer can also benefit from decent power cables. Is this news to you too?

Chord Mojo 2

In 2017, just after I bought my Chord Mojo mark 1, I ‘reviewed’ it here in my blog: https://carelesstalkblog.wordpress.com/2017/10/11/hi-fi-and-windows-10/

I compared the Mojo1 with its predecessor, an Audioquest Dragonfly Black (V1.2). The difference that was most obvious to me was that the Mojo did transients and notes much better.

As I compare my Mojo2 with its Mojo1 predecessor, I find I am making the same comments. At first I thought this was strange, or that I was mistaken, but I realised that it just reflects the nature of the Mojo2 – it does everything Mojo1 did, but better. So it is to be expected that I would note the same improvements I heard when I got the Mojo1.

Each and every detail of the Mojo’s performance has been improved. The notes made by bass and drums are more obvious. The bass goes a little lower. The feeling of airiness is much clearer. And so on. The Mojo2 is exactly the sort of product you hope for when you see “new and improved”, a phrase that can often mean the opposite of what it promises. Not so here.

Mojo2 offers tone controls too, and a crossfeed feature, to make headphone listening seem less ‘inside the head’. These features are accessed using LED-coloured buttons, as opposed to the visual or voice-controlled interfaces that are more common these days. Although this interface is a bit difficult to master, the truth is that they are rarely used, except for the volume control buttons.

Listening to music – the whole point of hi-fi, after all – the Mojo2 separates the strands of the music more clearly, so that they can be individually distinguished. And yet the music is more of a whole, not less. Bass is more extended, to the point where my open-backed headphones sound more like closed-back units. But the overall sound is actually much airier, as open-backed headphones normally are.

The Mojo2 embodies a few seeming contradictions in its sound. Perhaps this means that Chord has hit the right compromises, dead centre? It is crisp and clear, but smooth and rich at the same time. And so on. You need to hear one yourself, listening to your own favourite music, with your own headphones. Even if you already have a Mojo1, as I did.

Today, as I wrote this, I had my digital music collection on shuffle-play, and I noticed an especially tuneful bass guitar. When I checked it out, it was playing an old 192 kbps mp3 of a Bunny Wailer album. Even with such a low-quality source, the extra tunefulness of the bass was clear and obvious.

In contrast, on high-quality versions of Joni Mitchell’s “Blue” and “Court and spark” albums, the beautiful vocals show all kinds of improvements compared to the Mojo 1. Richer, clearer, smoother and not a trace of sibilance.

Such comparisons continue for as long as you have different music, and different instrument sounds, to assess. You need to hear your own favourite albums or tracks through a Mojo 2.

In my opinion, there is no better DAC available for less than £500. But even today, £500 is not pocket change. If you are in the market for a new DAC to improve the sound from your laptop or phone, you really should audition the Mojo2 for yourself. I use mine to drive my headphones, and my main stereo too. It acquits itself excellently in both applications.

Enthusiastically recommended. Enjoy the music.

I am not a hi-fi reviewer, just a lifelong music lover. I have no commercial or professional connection with Chord, or any other hi-fi company.

I am totally open to bribes – a Chord Dave + Hugo M Scaler wouldn’t go amiss 😉 – but I have received none, nor am I likely to. 😐

Behind the mask

In my last post, I wrote about how autistic people communicate naturally. This post is about masking, or passing, and it’s about how autistic people communicate un-naturally, by pretending to communicate like NTs (neurotypical people). Generally, we’re not very good at it. Autistic women tend to be much better at it than men, to the extent that they are often undiagnosed. But they don’t achieve this without demanding and exhausting effort; none of us do.

Masking is something that many of us feel we have to do, but there are good reasons why we don’t like it. Here is my take on those reasons.

First, and least, is that we don’t like to communicate as NTs do. We find it confusing and uncomfortable. We can overcome this, of course, but it is still hard for us not to communicate naturally.

Secondly, masking is hard work! Our brains are slightly differently wired (connected) to yours, and perhaps the most common feature of this is that the part of your brain that helps with social interaction is wired for some other purpose in an autistic brain. Analogy: It’s as if successful communication requires numeracy and you all have a scientific calculator in your brains, but we don’t. It’s not that our social skills are untrained or underdeveloped, it’s that we aren’t equipped to do it as you do.

So, when we mask, we must use pretence. We try to avoid situations or conversations where social prowess is highlighted. We try to guess what an NT might say in our current situation, and we review the words we are about to say many times before we say them, looking for the interpretations that NTs might place upon them. It’s very difficult, so it’s not surprising that we’re not good at it.

The final reason is the most significant for me, and for many other autistic people. It’s about why masking is considered necessary. It’s as if society says to each and every autistic person “We don’t like you. In fact, we dislike you so much that we will never admit you to our society. As a person, you have no attractive or redeeming qualities, and we reject you.“

Of course these words are never spoken. It’s unlikely that any NT individual even thinks this, consciously. But society‘s response to us, endlessly confirmed by the life experience of autistic people, is as simple and brutal as my words relate.

Please bear in mind that the training, therapies, and support offered to autistic people are not meant to make us happier in society, they’re to make society happier with us. Masking is one of these techniques.

It’s very hard to know that you, as you naturally are, are not acceptable to others, and that you must pretend to be someone else if you want to be accepted. It is hurtful and depressing. Did you know that the life expectancy of an autistic person is 56? If we are unlucky enough also to have special educational needs, this drops to 36!!! The reasons for this revolve around social rejection, and its effects.

“But why don’t you just communicate like everyone else?” looks like a reasonable question. After all, you are a huge majority, so why don’t we come into line with all of you? It seems fair, until we remember that autistic people aren’t equipped to do that. We don’t do it because we can’t do it. When we must, when masking seems unavoidable, we do our best, but we often fail, and we suffer the social consequences.

Footnote: a few people in our autistic community have little or no speech. I have not discussed their difficulties, as they are unknown to me. But these people should not be forgotten. Read Naoki Higoshida‘s books to find out more.

Thank you for reading.

Separated by a common language

The autistic community is as diverse as the neurotypical (NT) community, but in general, we communicate differently. We aren’t ‘literal’, that’s just a myth-understanding; we communicate explicitly. All of the meaning we intend to convey is explicitly present in the words we choose to use. We say what we mean, and only what we mean. It’s difficult to explain this difference clearly enough. We speak and write explicitly, so we don’t make use of implication, which is so central to NT language use. The effect this has is fundamental and far-reaching.

If I speak to you, and you perceive (say) a negatively-critical judgement in my words, that judgement is implied; implied by you, but not by me. I don’t use implication; I didn’t put it there, but somehow you found it anyway. If you find me rude, I beg you to consider the possibility that this rudeness is implied; I did not intend it. This is a major source of misunderstanding when autistic people speak or write to NTs. If you ‘read between the lines‘ of what an autistic person says, you will find stuff, just as we all can see faces in clouds. But the stuff you find was not put there by the autistic speaker/writer.

The thing is, if you used the words that I use, you would have put the implications there on purpose, and the stuff between the lines too. And your intended meaning would intentionally include these implicit additions. Everyone does it. That’s how (NT) people communicate. It’s natural to decode the words of others in this way, but when you do it with an autistic person, communication breaks down.

I think we don’t like implication because we don’t generally lie. It’s not that we’re too saintly to lie, or that we can’t lie, it’s just that we really don’t like dishonesty of any sort. We see implications, and the like, as dishonest, so we choose not to use them.

Every day, we see NT people using implication to get away with saying stuff they wouldn’t say straight out. People say “Where have you been?”, but what they mean is “You’ve kept me waiting for half an hour, and I’m angry! Account for yourself!” And if the hearer has a good reason for being late, they will react angrily. At this point, the original NT speaker falls back on the explicit meaning – the meaning an autistic person would have intended! – and claims they knew there was a good reason why you were delayed, and they just wanted to know what it was. This use of deniability and deception is clear and obvious to autistic people. It shouts out to us so that we can’t not see it even if we wanted to. And we don’t really like it, so we choose not to do it.

From our point of view, NT communication seems, at its core, deceptive, intentionally misleading, and intentionally dishonest. From your point of view, we can only assume you do this unconsciously, out of habit, as surely no-one would deliberately base their communications on dishonesty?

Autistic people use body language too. It’s not as overt as that used by NTs, and it’s a little different too, as we might expect! But it combines with our preference for explicit speech without implication or deception to result in our being cast out (of society). We are social lepers. And the reason is simply misunderstanding. We are not doing (or saying) anything wrong. You are not doing anything wrong either. There is no blame to be usefully assigned here. But if autistic people and NTs are ever to communicate effectively, you need to make that stretch of the imagination to see what we intend to communicate, even though we do it differently from you.

To set aside your natural way of communicating, and to do it so differently that you need to concentrate on doing it consciously? That’s a lot to ask. It’s exhausting to do something consciously, with effort, especially when it’s something you would normally do unconsciously, without effort. Autistic people do this all day, every day of their lives. It would help us a lot if you would try to see what we mean.

Will you try? Please?

The second part of this post, “Behind the mask“, considers what happens when people with autism try to communicate like NTs.

^{4th October 2020 – Minor edits and additions in the light of comments received (thank you!).}

Notes from the show

Last June, I attended the North West Audio Show again, at Cranage Hall in Holmes Chapel. My old schoolmate Chris was there with me too, like last year.

It was great to see so many people there; the show was bigger than ever. Despite the popularity of videos and gaming, hi-fi can still draw an audience, which is nice to see. However, I’m not as mobile as I used to be, so we decided to cherry-pick, instead of trying to see every room. There are too many to see – and hear! – in one day.

This blog is so late because I misplaced my notes. I want to post this anyway, though, to pass on my impressions of a small handful of particularly impressive products. Impressive enough, I think, to justify such a long delay before publication.

I’m not quite sure about the names here, but in the Watt room were Markaudio loudspeakers, showing the class D MA-01 power amp and their range of Frugel Horn single-driver speakers.

The amp was offered as a Kickstart on the net, and I saw it just after I’d invested in my new amplifier. Humph! Now they’re available directly, powered by your choice of Hypex N-core modules, and still priced reasonably. They sound good too!

The speakers were also more than impressive, using single full-range drivers in a horn-based cabinet. I would have loved to audition them directly against these:

The new PMC fact.12 speakers were magnificent! Luxman-driven, they sounded good enough to blow your socks off, and to blow your savings on! Everyone who could afford £15k for a pair of speakers should hear them.

And finally, that star of the show: the Chord Hugo M Scaler. I’m not even going to try to explain how it works, but the results are much simpler. I’d love to tell you how it tightens up the treble, and clarifies the bass, and all that stuff. And it does. But the abiding impression that it left me with is that it (delves into the digital data, from where it mathemagically recovers and) restores the beauty to the music.

We heard the music, via a top-flight Chord front end, with and without the Scaler. The differences were very clear and obvious. This is a revolutionary product that anyone who uses digital hi-fi should investigate. It’s the reason why we attend hi-fi shows in the first place.

[No commercial or other association with any product mentioned.]

North West Audio Show

I visited the North West Audio Show at Cranage Hall on Sunday 24^th June, with my old schoolmate, Chris. These are my memories of a full and enjoyable day. We dawdled wherever the music sounded good, so we missed a few of the bedrooms. Overall, the sounds were good, and those that weren’t were mainly due to the sound being turned up too loud. Refreshingly, most visitors were asking exhibitors to turn the volume down, not up. But do you want the good news or the bad news first? Yes, you’re right. It’s better to end on a high note. 🙂

.

I’m a big fan of PMC speakers, so I was disappointed to hear awful sounds from them. We arrived at the end of the show, and heard the last half of the last track they played before packing up. Heavy rock was jack-hammering out from Luxman-driven PMC IB2s. I choose to believe it was just a poor recording, played too loud. Someone who hadn’t heard PMCs before might not be so kind.

.

Earlier on, we heard some sweet sounds over Amphion Krypton3s, driven by Caas electronics. They’re quite large (tall), and feature ports made of lots of little holes, up beside the mid-range drivers. Nice music, and interesting looks. Those who visited the room stayed for a good while, enjoying the music. We did too.

.

Next, a novelty. In the audiopro room, a small pair of active speakers were sitting on a table, sounding quite good, if not exceptional. As hifi speakers, that is. Then I realised they were computer-desk bookshelf monitors, which is the novelty. As such, they were Very Good. They will surely exceed the quality of what you feed them, unless you’ve already got a Chord Mojo. More details here.

.

Vox 3 mini monitors awaited us in the Sound Kaos room. As ever, the sound was open, airy, and entrancing. This seems to be their family sound. Although we were running out of time to see all the rooms, we stayed and listened to the music for a while. We did last year too.

.

In the Neat Acoustics room, we auditioned their new Xplorers. I had especially looked forward to these, and I wasn’t disappointed. Great highs from the AMT driver, and well-rounded isobaric bass. They have been added to my list. You know, the one I’ll return to when I win the lottery….

.

And finally, a treat from Puresound, in the form of Heco Direkt speakers. They have drawbacks, admittedly (see this review), but I haven’t had so much fun in years! A pre-recorded reel-to-reel tape of the Ramsey Lewis Trio offered superb percussion, such as I have rarely heard. You should consider these speakers to be like old-fashioned horns. A bit lacking in the extremes, but always lively and exuberant. A bit of light classical sounded nice too. Probably not for all music, or all music-lovers. Hear them if you can.

.

I came with a particular interest in hearing speakers, so I’m afraid I neglected many other worthwhile things. These were my personal highlights. If you didn’t make it to the Show, come next year? See you there.

.

[Dots between paragraphs to ensure paragraph spacing. It looks awkward: sorry! 😉 ]

On writing your own RTOS

This is a consideration of issues associated with designing your own RTOS. It’s a follow-on from the RTOS post I wrote a little while ago. It isn’t a practical project, although you could make it so, if you choose. If you do, please let me know how you get on. I don’t know your needs, so I will use my own, as they were when I was a working designer, when I need examples. I may also refer to our in-house RTOS, which I will refer to as PAX. The -X implies that, like many OSs, it is based on Unix. In this case, a very tiny Unix. It was originally written for an 8031 platform, to support task-oriented architectures.

Every working firmware application contains the core functionality of an RTOS: hardware initialisation, peripheral device drivers, a kernel, (software) timers, tasks and a scheduler. The latter might not be immediately obvious, but even in the all-in-one applications we wrote in the 80s, there are methods that execute repetitively during normal operation. They are the tasks, and the mechanism by which they are executed is the scheduler.

Given the title of this post, we’ve already decided our applications do not need the facilities a commercial RTOS provides. After all, if there’s already an existing solution that properly meets our needs, we’d use it, wouldn’t we? It would almost certainly be cheaper. But our applications run on platforms with limited resources. We have less than 64k of RAM to play with, maybe as little as 256 bytes, in some cases. So we need minimum RTOS functionality, which we will design ourselves.

Hardware initialisation code and peripheral device drivers are usually provided free by our microcontroller or build-tool vendor. Our only concern is the API. Will a future platform, or a different micro-controller, make it difficult to maintain a consistent API for our existing and future applications? If so, do we need to provide wrapper ‘classes’, making a consistent API easier to maintain, even though every OS call will have to execute our wrapper code too? We can do as I did, and refactor the provided driver code to suit our preferred API. But when the vendor updates their code, we will probably need to shadow these updates in our own code….

Our RTOS will provide tasks, but will our applications be task-based? PAX was created to support apps that employed task-centric design. But I designed applications based on OO principles, coded in C. Each class occupied one .c file, with its public API defined in the .h file. My classes each owned zero or more tasks, and used them as necessary. So I used tasks, as attributes, and my applications were class-based. It’s a philosophical point, but it does affect how tasks are designed into our RTOS. We’re designing our own RTOS, so we can orient it to suit the way we work, and to improve the way we work.

More important than this: my decision to use OO meant that the methods of one class must be able to call the methods of another class (instance) during normal operation. This is important when we come to consider task-switching.

Preemptive task-switching supports isolated tasks, as Windows supports the multiple applications (tasks) I’m running as I write this. It makes inter-task messaging difficult and inefficient. Such messaging is easily supported by PCs, but less so by our tiny microcontrollers. Co-operative task-switching supports co-operating and communicating tasks, and is better suited to (almost) all firmware applications. Without it, I could not have allowed direct communication between my classes, not knowing whether they had been task-switched while their internal states were in transition. So our RTOS will use co-operative task switching. Is that right for your needs too?

Co-operative task-switching means that each task runs until it terminates, before the next task can be scheduled and run. Its big flaw is obvious: if a task runs too long, or never terminates, the application will fail. In practice, I never found this to be an issue, but if you’re worried, you’ll need to use a hardware watchdog timer, restarted every time a task is started. But what will you do if the timer expires? Reboot, I suspect….

With tasks as attributes of object instances, they are just a way to activate and execute instance methods as required. They need no parameters. [The RTOS has no information as to what parameters such a task might need; the class/instance takes care of that via its state/class/instance variables.] This simplifies implementation, and why not? As simple as it can be, but no simpler, is our mantra, here and wherever else it applies. So our scheduler needs little apart from a list of function pointers to the task methods. Contrast this with PAX, which provided an extended parameter list, intended to support all kinds of different data being passed to tasks.

Tasks also need (optional) timed execution, but we’ll deal with that when we talk about timers. For completeness, we also need tasks to be executable on a round-robin basis.

In firmware, the sort that’s simple enough for us to consider writing our own RTOS, we don’t need dynamic memory. Our programs execute forever, in theory, so fragmentation, maybe leading to a crash, is a serious issue for us. It’s a risk we don’t need to take. Timers, private class variables, and the like, are created during initialisation, and exist for the lifetime of the program.

Talking of simplicity, our scheduler needs only to loop through all tasks, and execute those that are active. Timed tasks are checked to see if execution is due before they are run. It is inefficient to loop through all tasks, as some of them will be inactive. But the alternative is a separate active task list, which consumes memory, and takes processor cycles to traverse. Some time ago, I tried looping through all tasks, just to see if the inefficiency caused problems. I expected it to, but it didn’t. So I adopted this much simpler way of working. See if it works for your RTOS too.

Interrupts are an interesting topic in RTOS design. Ideally, we might work without interrupts, ensuring a single thread of execution: our application. But I never found a satisfactory way of doing this. However, I did settle on one simplification that I found worthwhile. I did not allow nested interrupts, thus guaranteeing no more than two threads: interrupts and the app. We still have to consider re-entrancy effects, but in their simplest form. And, with all interrupt routines hidden away in the (RTOS) driver classes that own the interrupting hardware, it is easy to control what methods can be called from interrupts, and take the necessary steps to ensure this doesn’t cause problems.

While we must have a kernel, it doesn’t do much. It’s the main() of our RTOS (and of our application, as we can only have one main()). It executes hardware initialisation methods, then RTOS initialisation, application initialisation, and finally the kernel executes the scheduler, which runs forever. That’s about it for the kernel.

The only core RTOS feature we haven’t yet covered is timers. They’re loads of fun! I have spent many happy hours thinking about timers, over the years, and I’ve implemented them many times too, to work in various environments. Timers can be active or passive. Active timers carry out a predefined function when they terminate. This is very handy for the designer, but it comes at a price. Each timer must be checked every system tick, to see if it has expired. Yes, we could implement linked-lists of active timers, listed in order of their expiry, but the overhead is still considerable when it is traversed every system tick.

Passive timers do nothing. We query them when we want to know if they’ve expired. If they have, we do what needs doing. Ah, you’re thinking, what’s the difference between a timer task querying them, to produce active timers, and the application querying them when it thinks it should? The application knows how long the timer is supposed to run for. Some timers have a watchdog function, and are never expected to expire. When we need active timers, we use a timed task. Overheads minimised; (necessary) functionality supplied; job done. Will this design decision suit your RTOS too?

I keep asking ‘will this suit you too?’, but that’s what design decisions are about. They suit one project, one application, one way of working, but not all. I’m trying to make these decisions visible, and also emphasising that my decisions might not be best for you.

Timers are used and queried often. They need to be efficient as well as providing all the features we need from them. [We’re firmware designers, after all, and processor cycles don’t grow on trees!] When we delve deep into timer implementation, we find rollover to be a problem. That is when the timer-counter rolls over from its maximum value to zero, and also if the system tick timer rolls over. The picky way we have to code this is horrible. But there is an alternative for some of us, if our build tool supports 64-bit integers.

Timers count system ticks, and the system supports a regular interrupt to update its count. Ticks are between 1 and 10 ms in most applications. I used the former. A 32-bit timer or tick-counter only runs for 49.7 days (1 ms ticks), and our applications run for much longer than that, so rollover will occur. But 42-bits will give you 140 years, which is infinite, for our purposes. Using a 64-bit integer for timers and tick-counters means we can discount rollover completely. Our oft-called timer query code has suddenly become much more efficient. Behind the scenes, it uses library functions to manipulate 64-bit integers on a 32-bit (or less) microcontroller, but these are usually written in (efficient) assembly language, and the overall improvements in simplicity are well worth having.

Timer state flags? We need one bit — one flag — to say whether the timer is running or not. So split the 64-bit integer as you see fit, as long as the timer count is greater than 41 bits, and the flag space is one bit or more. But does a timer store its start time, its expiry time, or both? And should it store its duration too, so that it can easily be restarted? To store start and end times as well as duration is 24 bytes per timer, which is roughly 2400 bytes. [Typical applications use around 100 timers, in my experience.] This is a lot of RAM to most firmware designers, so we have to think carefully about what we really need to store. My most recent implementation stored only the expiry tick-count and a 1-bit running/stopped flag, relying on the application to know the duration if restart is needed. This amounts to about 800 bytes per application. This is still significant, but manageable in most cases. Tiny applications need fewer timers, decreasing the overhead.

Our timer API is also important. What do we, timer users, need? I suggest stop, start, restart and status (query). [Start is when we start the timer from now; restart is when we start it from the time it expired. We need the latter for repetitive timers, so that they don’t drift if we are a little late processing their expiry.] The only wrinkle we might decide to implement is in the status method. Mine returns RUNNING if the timer is active, STOP if it isn’t, and EXPIRED if this is the first query since expiry happened. The latter is very useful, and easier to code than it sounds: if the timer count is less than the system tick count [i.e. timer has expired], but the flag is set to RUNNING, reset the flag and return EXPIRED. That’s it.

And that about completes our tour of RTOS, and I hope it’s given you a good grounding in what’s involved. Maybe enough to go ahead and write your own? Please do, if that’s what you/team/applications need, and please let me know how you go on.

Now is the time to say goodbye…

Hi Sam,

I retired just as you started out as a firmware designer. I want to pass on something, both to round off my career, and to offer yours a flying start. So I’ve based this on my time-travel letter. You know, the one that old-me sends to young-me, brimming with wisdom, wit and good advice? 🙂 So here is a view of my career, in the context of my learning to do what a designer does. [That is, to get from customer needs to an executable that meets those needs.] First I’ll cover what I learned while writing this (more than I could possibly have imagined!), and then the things I learned that I can date, if only roughly. Then I’ll describe the things that just crept up on me.

When I started this letter, it was to be the list of ego-driven imperatives that you might expect from a programmer. 😉 But young-me would’ve binned a list of commandments without compunction, and I’m sure you would too. So the first thing I learned is that I need to offer you something useful, or you won’t read it. This is my best effort at that. Enjoy! 😉

As I looked back with the wisdom of hindsight, I made connections I hadn’t made before. Things I had thought important or significant turned out to be neither when viewed from a historical perspective. And things I had overlooked turned out to be pivotal. If I’d known how much I would learn from serious consideration of my progress, I would’ve done it every ten years. No less than that: we need the temporal distance for hindsight to work. Ten hours of solid introspection, every ten years, would’ve vastly improved my rate of progress!

The jobs I had, in the order I had them, influenced my journey more than anything else (except a mentor) could have done. My employers’ attitudes to training, the provision of tools and equipment, their development processes, and the work that was available for me to do, defined and constrained how I could progress. If I could do it all again, I would give much greater priority to selecting the right employer for me, at that point in my career.

My first job offered three highlights: I learned C, got exposed to an OS, and had to leave in a hurry.

Having previously flirted with FORTRAN, BASIC, assembly language and Pascal, I picked up C quite easily, and learned that all languages are basically the same, and provide the same features. I had a shock when I encountered C++, but it was true for the languages I had encountered so far.

We used OS-9, a multi-user, multi-tasking OS. Uniquely in firmware, we used it on our development and target systems. Having learned the benefits of an OS on the target, I was open to RTOSs when I encountered them later.

I also learned an uncomfortable lesson in reality. Friday morning: we told the boss we would have something working in 6 to 8 weeks; Lunch: the boss promised the customer a demonstration on Monday; Late afternoon: the boss instructed me to work 20-hour days over the weekend to reify his lunacy. I refused, and had to find a new job. Not all lessons are happy ones.

My next job was a disaster, something else I only realised while writing this. As I look back, I can see nothing worthy of mention, and I was designing firmware there for five years! I should’ve been aware of my stagnation, and moved on sooner. As it was, I moved when our senior managers destroyed the company. I suppose that was a lesson of sorts.

My next job introduced design methodologies, Quality Processes, OO and C++, software patterns, and I gained access to the internet. I learned a lot in my ten years there. [Sadly, as above, I also left after senior managers destroyed the company.]

I mistook design methodologies for ‘design’, at first. We used Schlaer-Mellor, which wasn’t known as S&M for nothing. Of course, there was no training; we were expected to pick up what we needed by our own undirected efforts. I learned doublethink. We pretended to use waterfall. We dutifully wrote and reviewed useless documents. But we actually did what we needed to do to make our firmware work.

I encountered Quality Processes for the first time, and learned that a QA process can be a good thing, if (and only if) it helps us make quality products. I learned to be an ISO9000 auditor, to add credibility to my claim that you can have a firmware development process that is useful, usable and ISO9000-compliant. [In a later job, I wrote such a process, and we used it with success for years.]

This is when I got internet access at work. No websites yet, but I could access mailing lists and newsgroups. My learning had been limited to books and magazines. Now I discovered software patterns and OO, and gurus like Cope and Uncle Bob. I learned so much from these people! I asked ignorant, arrogant questions, and they responded with patience and courtesy. <blush> I started to get a proper idea of what design was/is, and even how I might go about practicing it. I conversed with some of the greatest software designers of the last 50 years. Not on equal terms, you understand. But I did learn.

It is unfortunate that my employer was unwilling to let me deviate from company processes and practices, to try out some of this amazing new knowledge. [My next employer was the same, but I played dumb, and started using TDD and software patterns anyway. When they queried me, I acted surprised that they didn’t already use them, and got away with it.]

In my final job, I applied what I had learned. I introduced them to software patterns and TDD (as I mentioned above), and wrote a firmware development process that (I think) is still useful and in use. I started to take part in product design discussions much earlier. In short, I was doing design properly. When I finished, I still had ideas that I hadn’t got around to trying, but I was doing good work, and still getting better at it. Then our employer closed and outsourced our development department. As suddenly as that. And that was it.

We have covered all my employers now, but there are other things I learned that I can’t tie to a time or a place. These are they:

There are no binding rules or laws in firmware design, only guidelines. But our guidelines are based on years of thought and experience. They may be broken freely, but only if you can justify it to your peers in a design review! There are no laws, but you are not thus a law unto yourself.

Perspective is a magical spell, stolen ages ago from the Plane of Design. The more you have, the better. Mostly. Sometimes, irreconcilable requirements can be reconciled just by finding and adopting the right perspective. Perspective also evokes viewpoint, paradigm, metaphor, analogy, vocabulary (words, symbols and concepts), and so on. It’s about the way you (choose to) look at something. Imagination is the only limit. See yourself standing on the API of your new class, looking out at the application. Look at your design from a Taoist perspective, if it helps.

A perspective that is sometimes useful is that your software design will tend to grow, or evolve, organically. This isn’t a problem, as long as it doesn’t compromise your clear and easily-understood design. When and if it does, some gentle refactoring is in order.

Simplicity is not a virtue, it’s a necessity. But avoid the mistaken KISS acronym: it isn’t stupid to produce complex designs, it’s human. The quote usually attributed to Einstein — “as simple as it can be, but no simpler” — is a much better guide. As well as the obvious message, it also warns us that a too-simple solution cannot adequately meet all of its requirements. Simplicity is hard work, but we need to pursue it, or complexity renders our designs unmanageable and incapable of change.

Clarity is second only to simplicity when it comes to desirable attributes our designs should display. Everything about a design should be clear: code, diagrams, documents, processes…. Everything. [Code] readability is just clarity by another name, and we all know how important and valuable readability is … don’t we? 😉

The ‘just enough’ concept is strongly related to simplicity. It applies to everything that has an optimum value that lies between extremes. Just enough documentation, design, testing, and so forth, are things to aim for. But there’s no such thing as just enough bugs….

Context is all, as it is for many disciplines. Designs don’t exist in a vacuum. Neither do designers or design teams. Context is almost always more extensive than we think. Your manager, that guy who compromises your work with those ridiculous demands, is part of your development context. You are too. Consider all influences on your firmware, whatever they are. If you cannot control them, at least be aware of them, and their effect(s).

Discussion is useful when co-operative, and counter-productive when adversarial. We developers have to find a way to embrace this, and many of us find it difficult. I did. I made the final push when I realised that, if I didn’t grow up (in this particular way), I could progress no further as a designer. [Being a designer meant, and still means, a great deal to me.] Find your own reason to avoid the worst consequences of ego, without losing your opinions, creativity or imagination.

Testing. In my experience, unit-testing – often referred to as “TDD” (Test-driven Design) or “TFD” (Test-First Design) – is unavoidably vital. If you don’t test your code, you can’t know it will work as you intend. Speed of execution is more important than you might think too. If your unit-tests execute in 300 ms, you will run them often. If it takes several hours, you will run them rarely, and gain no benefit from them. Once you’ve acquired the skill of TFD and unit-testing, it will save you time, even though the tests seem to demand extra work that you would not otherwise have done. You will save that time ten times over during debugging.

Abstraction is a useful, common and well-known way of looking at our designs. The lowest abstract level for us is the hardware. It’s not the least important, it just exists at the lowest abstract level. The highest abstract level is the view of your design as a single entity, existing in the context of the product, the customer, life, the universe and everything. A successful designer is aware of their design at all abstract levels, from the tiniest detail to the most general overview. If you lose track of your design, at any abstract level, the universe will bite you for it, sooner or later, in my experience.

Estimation of timescales is an impossible task that will be demanded of you. Managers will ask how long it will take to create your firmware. From their perspective, this is not only reasonable, but essential. But they rarely appreciate that a designer must create a solution to a problem that has not been solved before. [If it had, we would use the existing solution, wouldn’t we?] Creating something new introduces uncertainties, making prediction difficult, especially timescales.

N.B. managers will expect four man-days of effort, done by a team of two, to take two days.

When estimating, make your best guess as to how long it will take, double it (to account for the things you haven’t accounted for!) and then add between ten and a hundred percent for ‘contingencies’. That’s how long it will actually take, after the delay waiting for the new equipment to arrive, Ken’s unanticipated illness, and so forth.

When your manager tries to enforce a timescale, or reduce your estimates, explain that less time means fewer features, and ask them to decide which of their requirements can be sacrificed. Otherwise you will fail to bring your project in on time, and the blame will fall on you. No designer is capable of doing a week’s work in a day.

Best wishes on your journey,

Great-uncle Pattern-chaser

Sam is my fictitious relative, invented for the purposes of this article. No firmware designers were harmed during the creation of this document.

This is my final firmware blog. As time passes, firmware development recedes from me, and what I have to offer becomes less useful, less helpful, and just … less. Thank you for reading. If you care to leave a comment, that would be great.

P.S. I reserve the right to edit and add to this blog as improvements occur to me. If I could’ve made it perfect first time, I would have done! 😉 Continuous improvement, as they say…. 🙂

Edit #1. 05/12/2017. Minor text clarifications. Added a paragraph on ego.

Edit #2. 06/12/2017. Added paragraph about clarity.

 Edit #3. 20/05/2021. Added paragraphs about testing and abstraction.

Edit #4. 26/04/2023. Added paragraphs about estimation.

Edit #5. 08/07/2023. Added a paragraph about organic growth.

 

Hi-fi and Windows 10

The Chord Mojo is what you buy if the sound from your mobile or laptop isn’t all you could hope for. It plugs into your device and bypasses your inboard sound hardware with something much better. You probably connect your TV sound through your hi-fi; this is the same thing, for the same reasons. I wanted to write a review of the Mojo, but I don’t have the experience of competing products, and so on. [If you want a proper review, here’s a link.] Anyway, the story went its own way, as you will see. For now, here are my, er, opinions of the Mojo.

Mojo does two things better than most: transients and notes.

Good transients let you hear the start of each note, and the rest of it then follows on quite easily. This helps distinguish the instruments, and makes the music clearer and easier to enjoy. This is especially helpful with low-quality recordings. Your low-bit-rate mp3s will still sound murky, but better. Higher quality files will sparkle accordingly. 🙂

I thought I left one-note bass behind years ago, but I hadn’t. At least, not to the extent that Mojo plays notes. The effect covers the whole spectrum, but is more obvious in the lower registers. Bass and drums, in particular, have a note as well as a sound.

Good transients and good notes lead to good timing/rhythm and good tunes. What more could you want? 🙂 Mojo delivers a full, balanced and well-rounded sound. Follow the Golden Rule, and listen for yourself. As for me, I’m rediscovering my music collection. I am living the cliche! 🙂

Configuring a Windows PC for hi-fi sound

I had some difficulty configuring my laptop to reproduce hi-fi. The problem lies with Microsoft Windows. It is nothing to do with Chord or the Mojo. You can’t avoid this irritation by buying (say) an Audioquest Dragonfly instead. The same problems apply. Having said that, Chord market the Mojo for use with Windows PCs….

Normally, when you plug in a new USB device to your PC, it auto-loads a driver, or you download one from the vendor’s website and install it, and you’re done.

This is not the case with a music device!

Windows 10 will grab your music, and process it as it knows you would want, if only you were as clever as it is. 😦 It will run your music through its mixer and volume control, up- or down-sample your music, and who knows what else. This is Windows’ default sound scheme, called Direct Sound. To avoid it, you will need to put in some extra and unfamiliar effort. You need to use an alternative sound scheme: ASIO or WASAPI.

“Bitperfect” is a misleading term to describe a system whereby your music player program can pass the music direct to your Mojo without Windows getting its grubby hands on it. Only ASIO and WASAPI support this. I can hear no difference between them, and the hi-fi community seems to favour ASIO, so that’s what I’ve gone for.

To use your audio device, you need to install ASIO at both ends. Download and install Asio4All. This will connect the ASIO output to the Chord driver, and thereby to the Mojo hardware. Then you must configure the front end, your music player, by enabling it to support ASIO. Chord support JRiver, but I found it painful to use, and went for foobar2000, which is almost as well regarded, and it’s free. But you will still need to download and install a ‘component’ to support ASIO operation.

If this is too much for you, try WASAPI instead. A single component for foobar2000 will get you going.

One other thing. Some Windows PCs can become misconfigured. This results in intermittent and severe problems with channel balance. It isn’t just that one channel is missing, it’s more complicated than that, but your ears will know if you have a problem. If you do, as I did, you need to open a console box (right-click on cmd.exe and select ‘Run as Administrator’ — this bit is important) and type:

net localgroup Administrators /add networkservice

net localgroup Administrators /add localservice

This should solve your problem.

Finally, you need to enable ‘exclusive access’ to your audio device in the Windows driver settings*, and you should be able to listen to hi-fi on your Windows PC. At last. 🙂

* — Go to Settings/Control Panel/Sound. Select your output device, then Properties, then the Advanced tab. Tick both of the ‘Exclusive mode’ boxes.

Conclusion

I spent 32 years developing software (not Windows software), using PCs as a ‘power user’ since 1983. And I’m not especially stupid. I promise. But I misunderstood, and bought a £400 product after auditioning on an incorrectly configured laptop*. [It’s lucky I’m so delighted with it!] Learn from my mistake.

* — N.B. This is not the fault of my dealer, Audio T. I told them my laptop was correctly configured, as I thought it was. Mike (Audio T) and Tom (from Chord) helped me sort all this out, once I told them I had a problem. Thanks to both of them!

If you’re anxious about all this, you could ask your dealer to help configure your Windows computer. I’m sure many of them would be happy to assist a valued customer like you. 😉 Alternatively, if you have the option, you could build your music machine using Linux. 😉

The Chord Mojo is a little box of joy and wonder. You should treat yourself to one. You won’t regret it.

I have a degree in Electronics, and I worked in electronic hardware and software design for many years. I have no qualifications as a hi-fi reviewer, and no connection with Audio T or Chord, apart from being a satisfied customer. I am a lifetime hi-fi and music enthusiast. I am not a huge fan of Microsoft Windows.

Have you had problems with hi-fi on your Windows 10 PC? Please leave a comment. Thanks for reading this. Oh, and if you expected a firmware blog, I’ll try to do better next time. 😉

 

Firmware – the tunnel at the end of the light

I think we have reached a point where the demise of firmware is clearly visible. It’s quite a way away, but now is the time to start planning.

Let’s be clear. If you still dream of 64k of contiguous RAM for your (application + RTOS + stack(s) + heap), then you write firmware. If your target hardware comfortably exceeds this, you write embedded software. [I know these terms aren’t universally agreed or understood, but this is how I’m using them.]

These days, fast 32-bit micro-controllers are available cheaply; RAM is the main limitation on what we can do with them. As the amount of RAM in micro-controllers increases, it will reach a point where they can support embedded software.

Embedded software is more mainstream than firmware. Applications run under grown-up OSs like Linux or Android. And they’re coded in modern languages that firmware target platforms can’t yet support. Like much modern software, embedded software is largely independent of its target hardware. It’s a different world.

When affordable micro-controllers can support embedded software, the need for firmware will start to decrease. Eventually, firmware will become a backwater, a small one. Before this happens, we firmware designers need to have expanded our skills into embedded software.

This means that we must embrace software design to a greater extent than we have in the past. Embedded software is less tolerant of, er, laxity than our smaller and simpler firmware designs. And embedded software is where the future lies. It’s what the tunnel in the title of this post leads to.

Today, firmware is a thriving discipline, and this will continue for some time. It will take a while before on-chip micro-controller RAM reaches the threshold needed to support embedded software (256k? 1M?). But when it does, the transition will be rapid, I think. Firmware will become a maintenance occupation. In my experience, many firmware-containing products stay in the field for ten years or more, sometimes a lot more. For as long as these products are supported, there will be a need for firmware designers.

So the end of firmware is visible, on the horizon, and we have years to prepare. Any improvement we decide to make in our design skills will benefit our firmware in the short term, as well as preparing us for the future. So this post is not a woe-ridden ‘the end is nigh!‘ sort of thing. It’s more like: forewarned is forearmed.