Menu Close

Tag / code

How to Deal with Badly Written Code

Sadly there is a ton of badly written code out in the wild. Hardware related code, seem to suffer more in this regards. I imagine, many developer in this segment are unwillingly to invest time in quality or are just inexperienced.

Even if you are dedicated in reliable and high quality code, you will probably run into the situation, where you have to use a library with really low standards.

Strategies

There are a number of strategies to deal with this code:

  1. Rewrite the library.
  2. Refactor the code.
  3. Wrap the library.
  4. Wrap the interface.

Rewrite the Library

This is actually the best you can do and it is also the most time-consuming approach. Yet, write the code from scratch will give you several benefits:

  • You will perfectly understand how the original library and the accessed hardware works. Actually you have to understand it, otherwise you are unable to rewrite the code.
  • The new code will be modern, fast, reliable and in your coding style.
  • If you open source the new code, you will give people an alternative and a better example how to implement something the right way.
  • You can also selectively remove unwanted/bloated parts from the original code, which can reduce the overall binary size of the final project.
  • It will also give you the option to implement a proper error handling in the new code.

If you have the time and motivation to rewrite the code, do it!

Refactor the Code

Changing the code, without changing the functionality is called code refactoring. This is a good strategy, a compromise, between rewriting and wrapping. Usually you will just go, line by line, through the original code, modernise it and cleaning it up.

Continue Reading

Make your Code Safe and Readable with Flags

Flags play an important role in embedded software development. Microcontrollers and chips are using registers where single bits or combinations of bits play a big role in the configuration. All the bits and their role are described in the specification, but writing the bits directly in the code would be very confusing and hard to read:

AHBMASK.reg = 0x14 // Huh!?

For this reason it makes sense to write an interface to access the registers of a chip. This interface will define identifiers, in the form of constant values, to build bit combinations to write into the registers.

The Outdated and Bad Approach

Chip manufacturers are well known for their extremely bad and outdated interfaces to access chip registers. Let us have a look at the CMSIS implementation from Atmel. This is part of the interface to access registers in one of the microcontrollers. Please ignore the copyright block, it is just added for legal reasons.

To be fair, CMSIS is a hardware abstraction layer standard defined by ARM. It shall standardise the software interfaces across all Cortex-M products. Therefore Atmel had no choice as to follow this standard.

Do you feel the dust on this code? There are a vast amount of problems caused by this interface.

First the values are defined as macros instead of constants. All this identifiers will clutter the global namespace of your code and make naming conflicts very likely. Way better would be using simple constants like this:

const uint8_t PM_AHBMASK_DSU_Pos = 3;
const uint32_t PM_AHBMASK_DSU = (0x1ul << PM_AHBMASK_DSU_Pos);

This would give the compiler the correct hint about the used data type for the registers. All this constants could be put into a own namespace to prevent any name collisions with the user code.  It would still not prevent incorrect assignments.

I can write and compile the following code, which absolutely makes no sense:

CPUSEL.reg = PM_AHBMASK_DSU; // nonsense!

There will be not even a compiler warning about any problems and this is exactly what makes debugging embedded code very difficult.

Use the C++ Language!

I personally think, many software developers writing C++ code for hardware do not make fully use of the language. One reason could be the lack of support of many language features at the beginning or just the lack of experience.

In the the last 10 years, there was a huge progress in the development of the C++ language. Ignoring this progress would be silly in my opinion. Especially the C++11 standard added lots of useful features to the language.

A good support for the C++11, C++14 or even better for C++17 is very important, especially for embedded software development. Many of the introduced features will improve your code, make it simpler and more readable, without adding any additional byte to your firmware.

The features I describe in this article will not increase the size of the final firmware, they will just affect safety, readability and simplicity of your code. At the end, the optimiser in the compiler will resolve all the code and generate small and compact binaries.

Continue Reading

How to Design a Cheap Plant Watering Sensor (Part 4)

This is the fourth part of the meta-tutorial, where I talk about designing a cheap plant watering sensor. If you did not already read the firstsecond and third part please do it now. These parts contain a lot information which lead to this point of the tutorial.

The third part ended with step 18, planing the final firmware. There a decision was made about the language and style of the firmware. This article will focus on the code of the firmware itself.

Step 19: Write a Preliminary Firmware

In order to be able to do some final tests with the prototypes and be able to work on the final PCB, I need a firmware which is is very close to the final one. In the Atmel Studio, I start a new C++ project in a new folder.

The first thing I do is checking the chosen compiler options for the project. Everything looks reasonable, I just add the option --std=c++11 to the C++ compiler options to get the latest language features.

In a section below I will describe all modules I wrote and will point details about the functions. I obviously did not wrote the whole firmware sequentially in that order, instead I use a incremental approach to develop the software:

  1. Create empty frameworks for all modules.
    • Create a header and implementation file for each module with the correct name.
    • Add the header comments, the namespace, #pragma once and the #include for the own header file.
    • At this point, each module should be ready, so I can easily add new functions to each module.
  2. Start with the hardware module.
    • Write the initialisation for the hardware, like CPU speed, port directions and other important stuff.
    • Layout the interface for the hardware module and prepare empty implementation blocks to be filled with code.
    • At each place where code is missing, I write a comment // FIXME!! to be reminded that there is something missing.
  3. Start the logic module.
    • Write the main entry point of the logic.
    • Call this entry point in the main() method of the firmware.
    • Add the hardware initialisation to the logic.

At this point, I have the structure of the firmware prepared as planed. This structure will lead me through the development process. Continue Reading

Lucky World – A jump’n’run game for MeggyJr RGB

Today I release a full featured jump’n’run game for the MeggyJr RGB platform. It has an intro, a level map with more than 16 levels packed with obstacles and even a end scene. This game uses most of the flash of the ATmega328P and it was an interesting challenge to keep everything as compact as possible. In the past, when I learned to develop software, a very limited RAM was normal. Creating this game for this platform brought back a little bit of this nostalgia.

I release all sources of the game under the GPL v2 license. Feel free to create your own fork and improve this game even further. You can download a ZIP with the sources for version 1.0 here:

https://github.com/LuckyResistor/LuckyWorld/archive/v1.0.zip

To give you a quick impression of the gameplay, I created the following video.

Read more about the requirements for the game in the sections below.

Continue Reading

How to Debug Time Critical Code using an Oscilloscope

From time to time you have to debug time critical code. If you are using interrupts, you are interested in the actual performance on the code. This is especially true, if you are using timed interrupts.

In this cases, using the serial interface is impossible. If you write to the serial interface, the whole timing of your application changes and you will get no usable results.

If you own an oscilloscope, there is a really simple way to debug many applications. I used this technique many times, for example with projects featured on these pages: For the timing of the sound output of the cat protector, or the timing of the display interrupt of the Meggy Jr library.

This technique is obvious ans simple. Nevertheless I hope this article will give some inspiration to help solving timing problems.

Continue Reading