Archive for the ‘Embedded Systems’ Category.

Ein DB9 Joystick auf USB Adapter

In einer Ausgabe des Load Magazin auf der Xzentrix 2012 sah ich eine Werbeanzeige für diesen Joystickadapter zum selberzusammenbauen. Damit kann man wohl 2 klassische Joysticks mit DB9 Anschluss (C64, Amiga, Atari ST, etc) per USB an der PC anschliessen und verwenden: http://retro-donald.de/sinchai-shop/index.php?main_page=product_info&cPath=1&products_id=137

Die Firmware soll noch ein paar Macken haben und unter Linux oder auf dem Mac nicht 100% tun. Mal schauen, ich notiers mir mal im Hinterkopf und schau in Zukunft nochmal nach. Prinzipiell suche ich genau so ein Teil seit langer Zeit. Ausserdem hatte ich mal überlegt, selber eines mit AVR zu basteln, habe das Projekt aus Zeitmangel aber noch nicht angefangen.

stdint.h and stdbool.h for Keil C51

Interestingly, Keil C51 does not ship with C99 compliant stdint.h and stdbool.h header files.

But there is no need to dispair. The stdint.h from SDCC seems to work ok however I personally would not trust the pointer types and widths. However in a context of a 8051 MCU, I’d rather introduce my own data type for pointers anyway due to the different possible memory spaces. A generic pointer will have to carry section information that has to be evaluated at runtime. A special typed pointer won’t waste as many resources.

The stdbool.h from SDCC can be used as well. Just make sure to be Keil compatible and use the following definitions:

#define _Bool bit
#define BOOL bit
#define bool _Bool
#define __bool_true_false_are_defined 1

DOs and DO NOTs for developing Embedded Systems software

Zum Thema “Was sollte man tun und was nicht, wenn man Software für Embedded Systems entwirft und usitzt?”habe ich mal einen Artikel zusammegestellt. Dieser Artikel ist natürlich subjektiv, ich bin gerne bereit zu diskutieren. Die meisten Aspekte habe ich aber derweil schon aus verschiedenen Onlinequellen bestätigt bekommen.

http://www.final-memory.org/?page_id=2113

Im Prinzip habe ich dort mal zusammengefasst, was ich alles seit der Universität gelernt habe. Teile davon praktisch im Job, viele andere aber auch fortbildungsmäßig aus dem Netz. Im Vordergrund steht vorallem, fiese Fallen von faul programmierten C zu umgehen. Viele der Regeln und Vorschläge sind auch sprachunabhängig und können natürlich auch auf andere Programmiersprachen angewendet werden.

Ich selber habe viele dieser Regeln früher zum Beispiel nicht beherzigt. Wenn ich die Sourcen zu meiner Diplomarbeit ansehe, dann habe ich viele davon eklatant verletzt. Aber irgendwo will man ja auch einen Lerneffekt erkennen.

Als weitergehende Lektüre kann ich auch das “Embedded C Coding Standard” von Michael Barr empfehlen.

Irgendwann schreibe ich vielleicht auch noch einengrößeren zusammenhängenden Artikel oder auch ein kleines Buch. Die Liste kann sicherlich noch erweitert werden.

Code::Blocks als IDE Alternative?

Code::Blocks

Code::Blocks

In den vergangenen Monaten und fast Jahren habe ich eigentlich Eclipse als IDE verwendet. Allerdings hatte ich schon öfters von der Alternative Code::Blocks gelesen und so habe ich diese IDE auch mal ausprobiert. Sie bietet eigentlich nur Vorteile, hat allerdings auch deutliche Einschränkungen. In Summe hat es mich aber schon überzeugt und fürs private Programmieren werde ich in Zukunft für C Projekte auf jeden Fall mit Code::Blocks arbeiten.

Vorteile nach erstem Ausprobieren der Version 8.02

  • in C++ geschrieben und damit deutlich flotter als Eclipse
  • Gute Unterstützung für C und C++
  • eigenes Buildsystem, d.h. Makefiles von Hand schreiben ist nicht mehr immer nötig
  • eingebaute Konfiguration für AVR und SDCC, inklusive Compilersettings
  • konfigurierbare Compiler, insbesonders GCC Derivate
  • schneller Editor
  • Crossplattform, Code::Blocks gibt es auch für Windows

Erkannte Nachteile

  • Vala wird nur über Custom makefiles unterstützt und kein Syntaxhighlighting dafür
  • Editorkomponente ist Scintilla und damit nicht direkt erweiterbar
  • naturgemäß kein so guter Support für Java wie etwa Eclipse
  • keine direkte SVN Integration (jedenfalls nicht unter Linux, für Windows gibt es wohl ein Plugin für TortoiseSVN)

Ich glaub in Summe muss jeder selber entscheiden, ich selbst bin so gut wie überzeugt, allein schon weil ich ja selber bevorzugt mit ANSI C arbeite und zumindest privat nicht alles über SVN ein- und auschecke.

Memory mapped I/O made easy with ANSI C

Ich habe hier mal in einem einzigen Demo-C-Source das geballte Knowhow zusammengefasst, wie man für einen Rechner mit Memorymapped I/O (z.B. ARM oder Motorola 68000/ColdFire) korrekt den Zugriff auf ein Hardwareregister via Pointer realisiert:

/*
 * Memory mapped I/O made easy with ANSI C
 * commented by Matthias Arndt <marndt@asmsoftware.de>
 */
#include <stdint.h>
/* temporary valid location for demonstration purposes */
uint8_t storage;
/* Now the magic declaration pointer to a hw register:
 * We point it to some known storage but ofcourse for pointing
 * to a real I/O hardware register, one would supply a constant
 * register address.
 *
 * a) declare it volatile because hardware I/O locations may change inside
 *    a different context (interrupt and/or hardware event)
 * b) make the pointer address const between register name and the type
 *    definition so that noone may modify the pointer
 * c) adding const before the declaration will declare a read/only register
 */
volatile uint8_t * const HWREG = &storage;
/* to point to real I/O you would use the following syntax: */
/* volatile uint8_t * const HWREG = (uint8_t *)0xF000; */
/* just some demo calls */
void task(void);
uint8_t access(void);
void task()
{
	*HWREG = 0x5a; /* set I/O for demo purpose */
	/* access to alter the pointer is forbidden! Uncomment to try! */
	/* HWREG = (uint8_t *) 0xaaaa; */
}
uint8_t access()
{
	return(*HWREG); /* read I/O */
}

Für 8051 oder andere Plattformen, die ähnlich verquerte Speicherbereiche haben, sollten zusätzliche Angaben  verwendet werden, die den Zugriff auf den richtigen Speicherbereich mappen, etwa XRAM beim 8051.

A ‘C’ Test: The 0×10 Best Questions for Would-be Embedded Programmers

A ‘C’ Test: The 0×10 Best Questions for Would-be Embedded Programmers – ich kam über einen Umweg zu diesem Artikel. Darin werden 16 Fragen gestellt, mit denen man einen Möchtegern Embedded C Programmierer (so wie mich auch) piesacken könnte.

Man kann so sicherlich die perfekten Nerds finden und ich gebe zu, ich selbst hätte vermutlich nicht alles 100% gewusst. Aber man sollte nie vergessen, jeder Kandidat sollte auch entsprechend lernwillig sein und vllt gerade so Dinge wie volatile, const und static nach und nach lernen. Beispielsweise im Rahmen von Codereviews.

Knallhart Aspiranten nach solchen Fragen auszusortieren, halte ich für falsch. Aber Potentiale oder auch Fehlerquellen erkennen, warum nicht.

Vermutlich muss sisch jeder selber ein Bild machen.

How to use the inline keyword with SDCC

Problem

For quite awhile I wondered why SDCC (the free Small Devices C Compilerhttp://sdcc.sourceforge.net/) would not compile inline C functions like the following:

volatile uint16_t adc_value;
/* public access function */
inline uint18_t GetADC()
{
return(adc_value);
}

Explanation

The answer is simple, SDCC follows the C standards and by default only ANSI C89 respectively ANSI C89 with SDCC extensions is enabled. But the keyword inline is part of the C99 standard so if C89 is allowed exclusively, the keyword is syntactically not allowed.

Solution

The solution is to enable C99 support with one of the possible command line options for SDCC:

  • –std-c99             Use C99 standard only (incomplete)
  • –std-sdcc99          Use C99 standard with SDCC extensions (incomplete)

Thanks to Jan Waclawek for making me investigate deeper!