Archive for the ‘SDCC’ Category.

Finite State Machine Generator for C

For quite a long time I’m thinking about simple code generating tools. I don’t want to use a special XML syntax or descriptive language but a simple Excel or OpenOffice sheet instead.

The aim is to generated C source code for small microcontroller applications or retrocomputing systems.

For the start I made a simple generator for finite state machines (Wikipedia entry)

It is also my first script written in Python and thus not really as tidy and neat as I prefer. But it is working for now.

It takes the sheet from an OpenOffice .ods table like this:

@brief autofire button statemachine
@see    
     
State Event Next State
INIT KeyPressed PULSE_ON
INIT KeyNotPressed AUTOFIRE_OFF
AUTOFIRE_OFF KeyPressed PULSE_ON
PULSE_ON KeyNotPressed AUTOFIRE_OFF
PULSE_ON PulseTimeElapsed PULSE_OFF
PULSE_OFF KeyNotPressed AUTOFIRE_OFF
PULSE_OFF PulseTimeElapsed PULSE_ON

and generates a switch-case style state machine in C with callback functions for state and event handling.

A version with support for object oriented programming with pointers to statemachine objects is planned aswell. Check the github for functional updates.

The actual code can be found on Github: https://github.com/simonsunnyboy/gen-fsm

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!

Low-Cost kooperatives Multitasking mit State Machines

Im Internet findet man durchaus höchst interessante Artikel im Bereich Embedded.

Der folgende Artikel beschreibt ein simples, aber effizientes Konzept, um einfaches kooperatives Multitasking zu realisieren.

Die Grundidee besteht darin, jeden Teil der Applikation gezielt und by Design in State Machines mit vielen Unterzuständen abzubilden und somit ohne einen komplizierten Scheduler einfach im schnellen Wechsel kleine Automatenzustände im Wechsel abzuarbeiten.

In Summe erinnert dieser Entwurf für Software schon stark an Hardwaredesign, wie es im VHDL-Bereich zwingend nötig ist. Hard- und Software-Co-Design, da kommen wir hiermit hin.

Link: http://www.eetimes.com/design/embedded/4207786/Low-Cost-Cooperative-Multitasking-Part-1-Building-a-simple-FM-player-

Sehr lesenswert, wenn man sich für kleinere Embedded Systeme und den Entwurf von Mikrocontrollerfirmware interessiert!

Wie man effizienten C Code für Mikrocontroller und 8 Bit Systeme schreibt

Im Netz fand ich den folgenden Artikel, der recht schön zusammenfasst, wie man seinen ANSI C Code für 8 Bit Systeme und im besonderen Mikrocontroller, etwa AVR oder 8051, optimiert.

http://www.netrino.com/Embedded-Systems/How-To/Efficient-C-Code

Der Artikel ist zwar in Englisch, aber das sollte den Hobbyisten oder gar den professionellen Embedded Entwickler ja nicht schocken!

Eventuell schreibe ich nochmal eine deutschsprachige Zusammenfassung. Mal schauen…

SDCC tutorial

This is a small tutorial how to invoke and use the Small Devices C Compiler (SDCC).
SDCC can be found at http://sdcc.sourceforge.net/. It is a cross compiler for ANSI C with various MCU targets including MCS51, PIC14 and Z80.
All testing has been done under GNU/Linux and the instructions to build and operate SDCC under other operating systems may vary considerably.

Building the compiler

The compiler comes as a standard GNU package as sourcecode licensed under the GNU General Public License. Just go to http://sdcc.sourceforge.net/ and grab a current source distribution. Now follow these simple steps to build, test and install the compiler:

  • change to a directory of your choice to build the compiler ~/src/ might be an optimal choice
  • $ tar xvzf path/to/sdcc/source/sdcc*.tar.gz
  • $ cd sdcc
  • $ ./configure
  • $ make             # this will take some time!
  • $ su -c “make install”
  • now typein your root passwort to install the SDCC system into /usr/local

To build SDCC, you will need GNU Make, GCC, Flex and somemore tools. A standard GNU development and compiling environment should suffice.

First test

The first compiler test is simple: just type at your shell prompt:

  • $ sdcc -v

If you see the following output in your terminal, all went well and SDCC was properly installed on your system.

SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.4.8 #977 (Mar 202005) (UNIX)

Now SDCC is installed and should be ready to build programs for any supported MCU.

Your first program

As I have a mcu board with a MCS51 compatible controller, we’ll assume from now on that you will want to develop your C program for a MCS51 target.
Write your C program with your favourite editor, make sure to include 8051.h to gain access to all 8051 SFRs.

#include <8051.h>

Write a simple program like the following:

#include <8051.h>
void main(void)
{
int i=1;
P1=0;  /* clear PORT1  of the MCS51 – P1.7 used as LED output */
for(;;)
{
P1_7=!(P1_7);   /* toggle P1.7*/

for(i=1;i<15000;i++);
/* idle loop – eat CPU time */

}
}
Now save it as porttest.c.

Now build your C program by typing:

  • $ sdcc porttest.c

SDCC will output an awful lot of temporary and listing files while compiling the program. If all goes well, you will get an Intel HEX file called porttest.ihx.

It is a good idea to use the packihx command on the resulting .ihx as the output of SDCC is not compatible with all loaders. It works with IO redirection:

  • $ packihx <input.ihx >output.hex

By default SDCC will relocate your program to address 0x0 including a proper interrupt vector table in case you have defined interrupts from C. That is possible, just refer to the SDCC documentation. Now put the HEX file into your code memory and run it.

Relocating your program to a different location

Sometimes you will not want to relocate your program to run from 0x0. Perhaps you have a board with RAM mapped as code memory and it does not start at 0x0. Using assembly language you would simply put an ORG 0x4000 or similar into your source. SDCC has to be instructed with a compile time parameter to achieve the same effect.
Try:

  • $ sdcc –code-loc 0x4000 porttest.c

SDCC will now compile and build your program as usual but it will now have its reset vector and interrupt vector table relocated to 0x4000 and up. This means to run your program now, you have to run your code with a jump or similar from 0x4000.
Important: SDCC will still generate the interrupt vector table but it will not be initialized at the proper location. Your startup code or some sort of utility has to copy the contents of the C code interrupt vectors into the MCS51 interrupt table by hand to activate it.

Alternate output file format

SDCC cannot only output your program as a Intel HEX file but also in Motorola S-Record format. Just use a commandline like this:

  • $ sdcc –out-fmt-s19 –code-loc 0x4000 porttest.c

In case you need different output formats you can use the SRecord software package to convert from Intel Hex or Motorola S-Record to many lesser known file formats.

Using the C library

SDCC comes with a implementation of the standard C library known as libc under GNU/Linux. You can use it as normal but note that you’ll have to implement your own functions for putchar() and getchar(). All other terminal I/O functions use these and you have to link your program with a serial I/O driver and put proper putchar() and getchar() functions in. Interestingly putchar() and getchar() are no macros but real functions in SDCC contrary to the ANSI C standard.

Last words

For more detailed documentation, especially on usable memory models, inline assembler and interrupt handling, refer to the excellent SDCC documentation which should be included in your SDCC source package.
This concludes our little SDCC tutorial and we hope you will be able to get started with software development in C for your MCU with the SDCC system.