Archive for the 'Programming' Category

Creating Time-Consistent Loops for Embedded Systems

In an embedded system there are typically four main ways to architect the code: Simple loop, foreground-background, cyclic executive, and RTOS. In this article I will look at how to create a simple main loop with a time-consistent execution period, similar to what a cyclic executive does.

Continue reading ‘Creating Time-Consistent Loops for Embedded Systems’

Ardunio Programming: C++ and Embedded Systems

Ideally we would use assembly language to wring the last drop of performance from small microcontrollers, and at one time that really was the only way to do it. But assembly language programming is tedious and error-prone, and if I never have to wrestle with another assembly language program that would be fine with me.

With the advent of C, things got a lot easier in the embedded systems world. As its creators stated, C is essentially a close relative of an assembler, rather like a macro assembler (there’s a good Google/Wikipedia topic, if you don’t know what a macro assembler is). A C program can be compiled into very tight and efficient code, with an almost one-to-one correspondence to the underlying assembly language that the compiler generates.

But times change, and things are extended, improved, and expanded, and thus C++ arose from C. Over time C++ has become one of the dominant languages in programming, but there are challenges when attempting to use it with a microcontroller. Continue reading ‘Ardunio Programming: C++ and Embedded Systems’

Determining Python program behavior based on available imports

Python’s import statement is an executable statement like any other. This means it can be used to determine if a particular external module is available. If a module is not available for import, the program can either modify its behavior accordingly, or shut down in a graceful fashion. Continue reading ‘Determining Python program behavior based on available imports’

Why Software Matters

Software matters because without it a computer-controlled instrument, device, or system is just a collection of plastic, metal, and silicon. It does nothing.

Without software an interferometer is just a bunch of mirrors and lenses. Without software a CCD or CMOS image sensor is just a slab of inert silicon. Without software a deep space probe is a piece of very expensive metal sculpture. Without software data collection and analysis becomes an exercise in jotting numbers in a notebook, pushing a slide rule to get approximate numerical results, and dealing with errors. Lots of errors.

Good software is not trivial, nor is it easy. It is not the simple exercises encountered in undergraduate courses, nor is it the hacked logic and unreadable gibberish generated by overcaffeinated graduate students late at night. Good software is the result of applied discipline, resulting in the creation of an abstract logical construct that is coherent, readable, elegant, and reusable. Good software is beautiful.

Continue reading ‘Why Software Matters’

Dealing With Arrogant Passive-Agressive Programmers

I don’t know what it is about programming and software engineering, but these two fields seem to attract a significant number of people with some serious personality issues.

One of the types I’ve encountered on a regular basis is what I call the APAP, or Arrogant Passive-Agressive Programmer. These are the people who will go in and rewrite existing code just to show off how clever they think they are, but can’t be bothered to document what they did or why. Heaven forbid that they should go and actually talk to the original author of the code before making changes to it. Another variation on this is the person who won’t talk directly to the person originally responsible for the design or the initial code, but instead go to the group manager, or someone not even directly associated, and discuss issues and changes with them instead.
Continue reading ‘Dealing With Arrogant Passive-Agressive Programmers’

Wrestling with Visual Studio

A few months ago I had a relatively large C++ source code set for a suite of applications dropped into my lap. Well, that’s OK, I don’t mind C++, but what I did mind was that it was all written using Visual Studio.

It’s been a long time since I had to work with Windows code, and now that I’ve waded through line after line of code and  wrestled with Visual Studio along the way, I’ve recalled now why I don’t like working with Windows.

Continue reading ‘Wrestling with Visual Studio’

Some more reasons why Software Engineering is so damned important

This is a slightly altered version of the summary of a report I wrote for a company that attempted to explain to them why they should have a software engineer (a real one) on their staff, and why it would help their bottom line.

Reviewing and working with most legacy software typically leads to an observation that is hard to avoid: Software engineering is arguably the most important aspect of any software implementation activity.

Continue reading ‘Some more reasons why Software Engineering is so damned important’