Category: ANSI C & C99

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.

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.

Hatari auf dem GP2X Wiz – der erste Sonnenschein

Seit ein paar Tagen versuche ich den Atari ST(e) Emulator Hatari (http://hatari.berlios.de/) auf den GP2X Wiz zu portieren.

Nach viel Rumprobieren, Fluchen, Aufregen und bösen Postings in die Mailingliste habe ich zumindest einen ersten Ansatz, der Wiz zeigt den Atari Desktop, den man per Touchscreen bemausen kann ;)

Hatari auf dem GP2X Wiz (erstes Mal der grüne Desktop)
Hatari auf dem GP2X Wiz (erstes Mal der grüne Desktop)



Ich hoffe soweit zukommen, daß man wenigstens Demos schauen und Spiele spielen kann, denen ein Joystick reicht.

Gepatcht habe ich bisher nur die Datei  screen.c und eine spezielle Konfigurationsdatei erstellt.

Mehr Richtung Wochenende! *Freude Freude Freude*

STay cool, STay Atari /|\

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.

Vala: eine weitere objektorientierte Programmiersprache?

Vor einigen Tagen stolperte ich über einen Artikel bei Pro-Linux, in dem die mir bis dato unbekannte Programmiersprache Vala vorgestellt wurde. Zunächst dachte ich mir in etwa “Was soll dieser Unsinn? Es gibt doch Java, C# oder C++.” Dann habe ich mich ein wenig in die Dokumentation eingelesen.

Die Sprache entstand, um für den GNOME Desktop performant, aber objektorientiert entworfene Software programmieren zu können, ohne alle die nötigen Features von Hand in C realisieren zu müssen. GLib und GTK setzen schließlich zum Leidwesen einiger Leute auf C und nicht C++ auf. Vala soll diese Lücke füllen. Die Sprache fühlt sich auf den ersten Blick an wie C# oder Java, aber der erzeugte Code ist kein Bytecode oder dgl. Intern erzeugt Vala reinen ANSI C Code, der lediglich die Glib verwendet, um die objektorientierten Features zu realisieren.

Vala bietet die folgende Features:

  • Übersetzung nach C Code (daher ist das Ergebnis portabel und auf Wunsch auch ohne Vala Compiler übersetzbar, denn die C Files können erzeugt werden)
  • Zugriff auf viele wichtige APIs, unteranderem ALSA, GTK und SDL (vgl auch http://live.gnome.org/Vala/BindingsStatus)
  • C# ähnliche Syntax
  • ordentliche String Klasse und Verkettung
  • freie Software

Mich hat das soweit überzeugt, daß ich auch gleich ein paar Testprogramme ausprobiert habe. Ich muss sagen, sowohl der Ansatz, als auch die Sprache selbst gefallen mir sehr gut. Die Nachteile von C# und Java werden ausgeglichen und man gewinnt den Vorteil, theoretisch mit Vala entwickelte Software auch auf Targets zu bringen, die nur einen C Compiler bieten, etwa Embedded Systems auf ARM Basis (Wiz, Caanoo und Dingoo lassen grüßen)

Natürlich wäre ich auch neugierig, ob man damit sogar Code für kleine 8Biter erzeugen kann. Für AVR müsste es möglich sein, wenn man eine möglichst abgespeckte GLib bereitstellt (API-kompatibel) und nicht sämtliche Sprachfeatures ausreizt.

Ich werde mich jedenfalls, wenn auch nicht im riesigen Umfang, zukünftig ein wenig mit Vala befassen.

Linksammlung