Tag Archives: Software

Damn You ISR!

I am sat here on a Sunday evening trying to debug embedded C/C++. For the most part all has been going well and the code has been behaving as expected. I have however run into one of my least favourite problems, the interrupt service routine (ISR). I have a couple of ISR's and they are presenting an unexpected start-up condition. The flow of the main body of the code is fine. I just can't understand why I am getting the current output.

All these problems take me back to a traffic light program I wrote at University. That worked fine for most of the sequence only to be tripped up by an ISR along the way and ending up in a stuck state. Not what you want from a set of traffic lights, especially if you find yourself stuck in the queue behind the red light.
Luckily there wasn't a green light & green man situation with the pedestrians finding themselves in the role of Frogger.

Only one solution for this situation; single malt.

Make List

I have been making use of the Arduino Makefile from ed.am for some time but recently I needed more functionality from the Makefile.

I ran across a case when needed to check the number of instructions/clock cycles that my C/C++ code was generating. To do this I needed to have a look at the assembly listing that was created. Reading just the assembly is tricky so adding in the C/C++ that creates it makes following it a little easier.

The instructions contained here detail the commands required to generate the debugging information and the flags for avr-objdump which allow the C++/ASM listing to be generated. Typing in all these commands takes time, hence why I am using a Makefile in the first place. What I needed was to add them to the existing ed.am Makefile.

It turns out that the easiest way to do this is not to modify the original Makefile. Instead I created a blank Makefile for my project and include the ed.am Makefile. Having done this I can overload and add to its contents.

This is what I came up with, using “make list” will generate a program listing interspersed with the source code.

# Include Arduino Makefile
# ========================
include ~/bin/arduino.mk
# Arduino Makefile downloaded from:
# http://ed.am/dev/make/arduino-mk

# Override some of the included Makefile settings
# ===============================================

# Add '-g' to compiler flag to embed debug info (doesn't end up in .hex)
CPPFLAGS += -g

# Locate avr-objdump on system
OBJDUMP := $(call findsoftware,avr-objdump)

# Create a listing of asm and C source code
list: $(TARGET).elf
	@echo "Generating Listing"
	$(OBJDUMP) -h -S $(TARGET).elf > $(TARGET).lst

# Override clean target to remove additonal files
clean:
	rm -f $(OBJECTS)
	rm -f $(TARGET).elf $(TARGET).hex $(ARDUINOLIB) *~
	rm -rf .lib .dep
	rm -f $(TARGET).map $(TARGET).lst

Poodle SSLv3

Well another week another security issue. This time it is a weakness in SSLv3. This is an older protocol (replaced by TLS) but can still be used in some circumstances. The Mozilla Security Blog article contains details. A quick fix for Firefox users is to install SSL Version Control plugin to disable use of SSLv3. SSLv3 will be disabled by default in Firefox 34 when it is released towards the end of November.

Device Menus (User/Configuration/Service)

During experimentation with my I2C board (dn2012-000) and an Arduino board, I decided that I wanted to code in a service/configuration menu to allow me to change settings and read the memory locations without having to reload the sketch. This had me thinking about menus in general and how they are implemented on different devices.

How are menus implemented on existing devices? What methods are used?

My day job working in Medical Engineering means I have plenty of opportunities to work with products from different manufacturers. Devices range in cost from the cheaper (replace rather than repair) items to the very expensive (needing maintenance/servicing over many years). The devices can be the latest the manufacturer has to offer or the ones that refuse to fail as they were built to last. Device menus are implemented in a few distinct ways.

Approaches to menu implementation

1. No menu options. The device has no changeable settings. Fixed HW/SW.
1a. No menu options. Switch or button operation to toggle modes, features. Fixed SW.

2. User accessible menu options during normal operation. Changes reset on reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]

3. User accessible menu options during normal operation. Changes preserved across reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]

4. As approach 3 but requiring user to input a code to change or save a setting.
[Used for setting default alarm triggers]

5. As approach 4 but requires user to enter multiple codes to enter different levels of nested menus. [First code for configuration options, second code for service menu]

6. Configuration/Service menu is not accessible via normal operating mode. Unit needs to be put into service mode. [Prevents accidental changes of settings]
6a. Combination of button/switch presses during power up.
6b. Change/removal of physical switch/jumper. Can be hidden/internal.
6c. Hardware dongle or key.

7. Data Port. Another device (Laptop/RS232/USB/Other) is connected to a data port to access settings. [Less complex user interface needed on product, can be used to take log data from device.]
7a. Manufacturer provided cable/programmer [Usually for non-standard ports/protocols]
7b1. Terminal Access (RS232/USB) - Standard Serial Console tools
7b2. Terminal Access (RS232/USB) - Manufacturer Application
7c1. LAN/WIFI – Access Web Interface
7c2. LAN/WIFI – Manufacturer Application
7d. Memory Card/USB Stick to upload/download settings file.

8. Multiple of any of the above approaches.

Assessment of Approaches

Creating the different menu methods requires different amounts of hardware/software to implement. Having a code to change settings needs a way to input the code and process it.

Whichever method is used depends on several factors:

  • What does the menu needs to access? (user settings, configuration, logs, service functions)
  • Who needs to access the menu? (End User, Developer, Service Personnel, Company Representative)
  • How often is access needed? (Easy access for common tasks of a few more steps for occasional options)
  • Where is access needed? (On-site, during use, on a workbench)
  • Disassembly / Tools required?

The method used will ultimately depend on which is the best fit for the product. If the user interface is sufficiently complex anyway adding extra menu options is software only. A basic user interface might encode options as numbers on LCD/7-Segment displays or just go for a data port approach.

Which Approach will I use?

My needs are simple. I am working with a serial data connection, led and 2 buttons (one is for resetting the Arduino board). My approach will use a held button and board reset to enter the service/configuration mode. The same serial console used to read data during normal operation will be used to show the menu. No additional hardware required. I have no need for codes to protect changes as the project doesn't warrant the additional security that brings. The need to enter service mode and connect with a serial terminal should be sufficient to prevent accidental changes.

The intent is to have the serial console output human readable text. This might change if the program exceeds the capacity of the chip. In this case I might resort to an external application to provide the human readable side by processing the raw serial data.

Cooling Things Down

Summer is approaching and the weather is getting slowly warmer. This brings with it the annual problem of having a computer in the bedroom kicking out heat and making it too warm. Another issue that had been causing me some bother for a few years is the power settings on my graphics card, a Radeon HD6850, when running Linux. I use the open source radeon driver as keeps improving overtime and has enough of the performance of the closed source official driver for my needs. The one thing that has been lacking in my particular case has been the dynamic adjustment (radeon.dpm) of the card to keep it running cool. I have been forced to manually set the card to a low power state each time I reboot the machine. Failing to do this means the card boots up running full speed and quite happy to warm the place up. The downside is that I am always in the low power state and any tasks that might make use of a bit of extra power never get it unless its specifically enabled.

Today was time for a bit of research and a test. I had a Radeon 7850 in my other machine and decided to swap them over. It means that I have a weaker card for gaming on Windows but I don't play that many games and out of the two machines it is the one next due an upgrade. So has it made a difference? The simple answer is yes. I found that after rebooting the Linux machine with the HD7850 that it had automatically switched to using the dynamic adjustments and all was working well, one problem solved.

The heat output was the thing I really wanted to improve and I am pleased to also report a successful change (results below). I am happy with a slight decrease in temperatures along side the enabling dynamic adjustment. I continued to experiment and discovered that it can get even better. I have 2 24" Dell monitors and these can both kick out a bit of heat. Whilst I like a dual screen setup I often switch to just one (mainly to boot the Windows machine on the other). Driving just a single monitor I have noticed a further drop in temperatures (results below). This apparent temperature drop with a single monitor was not noticed when using the HD6850.

Test Conditions:
- Ambient Temperature: 22C
- System settled on normal desktop, no user activity.
- 2 connected displays @ 1920x1200

Before (HD6850 in Low Power Mode):
- GPU Temp: 65.0C
- CPU Temp: 41.4C

After (HD7850 radeon.dpm=1 balanced profile dual display):
- GPU Temp: 47.0C
- CPU Temp: 37.1C

After (HD7850 radeon.dpm=1 balanced profile single display):
- GPU Temp: 39.0C
- CPU Temp: 36.0C

An upgrade to some slightly newer, better driver supported hardware can result in a gpu temperature drop of around 18-26C (depending on setup). It might not make a huge improvement in room temperature alone, but it is a step in the right direction.

Kivy

This week whilst thinking about how to represent an idea as a GUI application I ran into the limits of GTK3. I had a look around at matplotlib and pygame as possible work arounds but neither suited what I had in mind. It was then that I discovered Kivy.

Kivy - Open source Python library for rapid development of applications
that make use of innovative user interfaces, such as multi-touch apps.

Having had a look at some of the demo interfaces that have been created it looks like a really powerful tool. The only limitation appears to be your imagination. In addition the multi-touch aspect is appealing in the longer term as touch interfaces become more prevalent. Once I can get it fully installed/working on Fedora I will be experimenting with it a little.

Tmux – Solving The Problem Of Window Names

I was lucky enough to get a book on using tmux for Christmas. Following through the examples I noticed that I was not getting the expected behaviour when attempting to set window names.

Commandline

1
$ tmux new-window -n console

What this should do is create a new tmux window and within it a window called "console". What I was getting was a tmux window containing a window named after my command prompt e.g. 'bob@computer ~'. This was bothering me so I set about researching the problem, unluckily for me its not one that is that common. By chance I located a post linking to a RedHat bug report https://bugzilla.redhat.com/show_bug.cgi?id=969429. The report outlines a problem regarding a change in terminal escape codes and highlighted an identical problem with screen as I am having with tmux. I checked the escape codes in my .bashrc file, nothing wrong there. Next stop was /etc/bashrc.

/etc/bashrc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  if [ -z "$PROMPT_COMMAND" ]; then
    case $TERM in
    xterm*|vte*)
      if [ -e /etc/sysconfig/bash-prompt-xterm ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm
      elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then
          PROMPT_COMMAND="__vte_prompt_command"
      else
          PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;
    screen*)
      if [ -e /etc/sysconfig/bash-prompt-screen ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
      else
          PROMPT_COMMAND='printf "\033k%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;
    *)
      [ -e /etc/sysconfig/bash-prompt-default ] && PROMPT_COMMAND=/etc/sysconfig/bash-prompt-default
      ;;
    esac
  fi

/etc/bashrc contained the above code section. It comprises two different sections for different terminals, each has its own prompt with different escape codes. The but report highlighted that the problem lay with the 033k escape code where as 033]0 worked. I should only be using the problematic escape code if I am using a screen terminal. So which am I using?

Commandprompt

1
$ echo $TERM

The result from running the above command in my gnome-terminal was "xterm-256color". This was expected and what I assumed I was using. Running it from inside a tmux session I got "screen-256color". Tmux using a screen terminal is pointing back to the problematic escape code. Time to go back to the .tmux.conf and check my settings.

.tmux.conf

1
2
# Use 256 term colours
set -g default-terminal "screen-256color"

There is my problem line, I have set it to use the screen terminal, oops.

.tmux.conf - Correct

1
2
# Use 256 term colours
set -g default-terminal "xterm-256color"

By using the xterm-256color terminal I correct the problem with the escape code. Rerunning my initial tmux command tmux opens with a window named 'console'. Problem solved.

System Email

On my Fedora system I collect the system emails to my user account. This results in a selection of daily emails outlining statuses which I am prompted to deal with whenever I launch a terminal. In the past I have used the "mail" command to read and delete the messages. It is not the easiest mail reader to deal with however. The fallback has been to use Evolution which is part of Gnome. I have never been a fan of Evolution, instead preferring Thunderbird. Thunderbird does not support the maildir format used by the system email and as such has been ruled out. I am going to be trying out Mutt, it is a command line reader that I found already installed on my system. The interface is structured unlike "mail" and even lists the shortcuts for commonly used commands. For my needs I don't need to configure Mutt to do anything. I did find a couple of links that may prove useful in making Mutt your primary email client.

http://www.gentoo.org/doc/en/guide-to-mutt.xml

http://mutt.blackfish.org.uk/

Keeping My Hat On

In my previous post I outlined my thinking about moving from Fedora to OpenSuse. I installed OpenSuse 12.3 onto mylaptop and had a play about. The installer was clean and easy to use and everything was setup with the minimum of effort.

Two issues with Fedora prompting a move were the control over the firewall and the Arduino software not being up to date. I was disappointed to that the installation of the Arduino software didn't come with a desktop icon setup but the latest version was there to use. Now onto the firewall; things were not good.

OpenSuse has completely removed the iptables scripts for managing the firewall. It seems you will use their firewall daemon and associated setup program. So basically the future looks like I will be being forced into using a wrapper of some sort around the iptables rules for my firewall. What's more, after doing some reading it would appear that more applications will rely on this dynamic functionality in the future. So what do I do? I can, on Fedora at least, use my existing script in the short term but need to migrate it. Alternatively I can change distro, waiting a little longer for the inevitable push towards dynamic firewalls.

Where does this leave me now then? I'm thinking of staying with Fedora at the moment. Fedora 19 will be due out in around 3-4 months time. At this point I think a clean installation of my main machine will probably be in order. In the mean time I can work on migrating my current firewall script over to the Firewalld system. It will mean I have to manually install the latest Arduino software but that is at least a manageable task.

OpenSuse was removed from the laptop and Fedora 18 reinstalled. A clean installation does appear to have changed a few things. A series of upgrades over the years had left a few legacy options it seems. The Fedora installer was not as user friendly as the OpenSuse installer, especially when it came to creating the dual boot with Windows on a separate hard disk. That said it did install and I'm sure it will improve in the future.