Archive for the ‘ANSI C & C99’ 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

Debugging Ncurses applications with QT Creator

Today I stumbled over the problems while toying around with a small C project using the Ncurses library.

I recently discovered QT Creator as a decent IDE so I started to use it.

Problem 1 with running the application at all

The program builds fine and runs with ncurses if run in a seperate terminal window.
Upon run from within QT-Creator with checkmark “run in terminal” I got this error message: “Error opening terminal: unknown

After quite some googling I found the solution as the environment passed to my application in this way does not define the TERM environment variable.

So I added the definition “TERM=xterm” to the list of passed environment variables. Now the Ncurses application runs in its own terminal window.

Problem 2 with debugging the application

Naturally I do not only want to run my application, I also want to debug it using gdb. QT creator handles this normally fine so I click on “Debug.”
I see the extra terminal window opening but I get a small notice “ptrace: Operation not permitted” and all collapses.

Some more googling and I discover that Ubuntu  10.04 and later deactivate the option to attach gdb to running processes. This is something QT Creator seems to try here when running the application inside the terminal window.
I simply used the directions found here at AskUbuntu and now it works. I have the application ruuning in a seperate terminal window and I can trace, singlestep and debug it with the gdb frontend from QT Creator.

What a mess!

But it only affects debugging Ncurses and maybe S-lang projects. Normal terminal output is fine and so should be SDL based stuff aswell. It is dirty and slight hacky, but all in all it is working.

Sourcecodeumzug für Quadromania nach GitHub

Da Google Code seine Pforten schliessen wird, habe ich die Sourcen für mein Spiel Quadromania nach GitHub umgezogen.Vielleicht arbeite ich ja mal am Projekt weiter, aktuell ist das aber eher unwahrscheinlich.

Projekt-URL zum Auschecken bei GitHub lautet: https://github.com/simonsunnyboy/quadromania

CMake Toolchaindefinition für GP2X Wiz

Ich hatte schon vor längerer Zeit eine Toolchaindefinition zur Verwendung des GP2X Wiz GNU Crosscompilers mit CMake geschrieben. Diese möchte ich natürlich öffentlich zugänglich machen.

Damit kann man Projekte, die CMake (Was ist CMake?) verwenden, einfacher für den GP2X Wiz übersetzen.

Verwendet wird die Toolchaindefinition mit CMake wie folgt:

cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-GP2XWiz.cmake ..
cmake -DCMAKE_TOOLCHAIN_FILE=Toolchain-GP2XWiz.cmake <Pfad zur CMakeLists.txt>

Download

Quadromania Sourcecode now at Google Code

The sources for my opensource game Quadromania are now hosted at Google code:
http://code.google.com/p/quadromania/

Included is the complete history of my sofar local Subversion repository starting with the first public 2009 release.

How to configure PySVN to use Kdiff3 as the Diff tool

PySVN is a nice graphical client for Subversion. Unfortunately the builtin Diff tools are pretty awkward to use, esp. if the user (like me) is rather well known with Kdiff3.

How to configure PySVN to use Kdiff3

How to configure PySVN to use Kdiff3

I figured a bit with the settings and now PySVN diffs gracefully with Kdiff3 for me.

The settings are simple:

Set “External GUI Diff Command”, “Diff Tool” to kdiff3 and the “Tool Arguments” to -L1 %tl -L2 %tr %nl %nr

Happy Diffing!

Die Tücken der Spieleportierung

Gestern habe ich wegen dem stürmisch schlechten Wetter, bei dem man ja kaum vor die Tür wollte, am Nachmittag ein wenig programmiert. Ziel sollte es sein, das alte Spiel Megadash, ursprünglich für den Atari ST in GFABASIC geschrieben, auf PC bzw den GP2X Wiz zu portieren.

Ansich ging das ganz gut, binnen 2 Stunden hatte ich die meisten notwendigen Teilmodule in C neugeschrieben, eine Umgebung mit Code::Blocks aufgesetzt, meine ParadizeLib eingebunden und generell auch zum Laufen gebracht.

Am Ende des vorigen Nachmittags hatte ich dann das Spiel mit allen Mechaniken am Laufen, wie die Steine fallen, etc. Nur das Timing habe ich irgendwie nicht 100% abgebildet bekommen. Stellen, die im Originalspiel zwar mit Tücken bestückt waren, aber spielbar waren, funktionieren in meinem Port irgendwie nicht mehr. Die Steine erschlagen den Spieler an Stellen, wo man im Originalspiel erfolgreich “um sein Leben” rennen konnte.

Ich habe verschiedene Timingparameter angepasst, aber keinen zufriedenenstellenden Zustand gefunden. Entweder ist es immer noch zu schwer, oder viel zu leicht und auch da nicht immer nachvollziehbar.

Mal sehen, ob der Fehler noch gefunden wird. Im Moment liegt es jedenfalls als begonnenes Projekt auf der Platte.

ParadizeLib – meine Abstraktionsschicht für die Abstraktionsschicht

Toller Titel, ich weiss ;)

Im Jahr 2009 habe ich mir ja eine Opensource Handheld, einen GP2X Wiz zugelegt. Natürlich wollte ich dafür auch programmieren. Mit Quadromania war auch irgendwann mein erstes Spiel in C fertig und auch schrittweise erweitert.

In Zuge dessen fiel mir dann auf, daß SDL nicht gleich SDL ist. Auch wenn man SDL benutzt, muss man leider gerade was Joystickabfrage angeht immer noch Softwareweichen vorsehen, je nach Target. Beim GP2X Wiz zum Beispiel ist der SDL Joystick zwar vorhanden, aber er bietet keinen Achsenevents, da er digital arbeitet. Also muss man im Code ummappen.

Irgendwann dachte ich dann über eine Abstraktionsschicht nach und die ParadizeLib war das Ergebnis. Hier wird grundlegendes Einstellen des Bildschirms über SDL, Einsammeln von Tastendrücken, Joystick und Mauseingabe auf plattformunabhängige Aufrufe gelegt. Das Benutzerprogramm benutzt nur die ParadizeLib, die dann sich danach richtet, ob für einen GP2X Wiz oder eben ein normales Linux compiliert wird.

Die ParadizeLib abstrahiert zum Beispiel einen Joystick mit 2 Achsen und bis zu 4 Tasten. Am PC kann das dann ein USB Gamepad sein, am GP2X Wiz ist es aber das Steuerkreuz und die zugehörigen Tasten.

Lange Rede, kurzer Sinn, das Projekt gammelte seit 2 Jahren auf meiner Platte rum, und ich dachte mir, bevor ich es vergesse, mache ich es lieber OpenSource und arbeite vielleicht daran ab und an weiter.

Ich habe hier eine kurze Seite eingerichtet, vgl. im Menu, aber das eigentlich Repository liegt bei Google Code und ist per Mercurial abrufbar. Die Projektseite lautet http://code.google.com/p/paradizelib/

Wer Spass daran hat, kann sich die Library ja mal ansehen und vielleicht weiter daran entwickeln. Ich stehe gerne für Diskussion zur Verfügung. Irgendwann schreibe ich auch hoffentlich mal ein Spiel, welches diese Library auch verwendet.

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

Quellcodeformatierung mit Artistic Style

Zu einem guten Codierstyleguide gehört immer auch eine Formatierungsansage. Es ist deutlich einfacher, fremde Quelltexte zu lesen, wenn diese gleichförmig formatiert sind. Unschön formatierte Sourcecodes gibt es zuhauf. Auch man selber ist nicht immer gefeit, die eigenen Stilvorgaben und Vorlieben auch einzuhalten. Auch wenn man in einem Team gemeinsam Sourcen bearbeitet, kann ein solcher Styleguide helfen. Beim Hatari Projekt ist das z.B. recht uneinheitlich.

Wie genau ein Quellcode nun einzurücken und zu formatieren ist, das bleibt immer eine persönliche Frage, z.B. wie geschweifte Klammern zu setzen sind. Hauptsache, der Stil ist einheitlich.

Dabei helfen natürlich kleine Tools, bessere IDEs wie Code::Blocks oder Eclipse bieten gleich entsprechende Plugins. Häufig rufen diese aber auch nur fertige Tools für die Kommandozeile auf.

Unter Linux kommen direkt 2 Kandidaten infrage:

Ich habe mich für Artistic Style entschieden, da es die von mir genutzten Optionen auf Anhieb anbietet. Ich habe nur ein wenig experimentiert und meine Vorlieben sehen wie folgt aus:


#
# astylerc for Matthias Arndt
#
# history:
# 2011-05-26 initial version
#

# main style:
style=bsd

# indentation with TABS (4 spaces per TAB):
indent=tab

# contents of switch case statements are indented, including the break:
indent-cases

# preprocessor statements that are split are indented:
indent-preprocessor

# loops and if statements are seperated by empty lines:
# (associated block comments are kept)
break-blocks

# parenthesis are padded with spaces:
pad-paren

# unnecessary empty lines are deleted:
delete-empty-lines

Das Ganze kann man nach $HOME/.astylerc speichern und schon braucht man das Tool nicht mehr mit Kommandozeilenparametern zu füttern.