Category: AVR

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

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.

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…

Der kurze Weg zur RS232

Da mein neuer ACER AS X1301-3 von Haus erstmal keine RS232 Schnittstelle mitbrachte, hatte ich schon beim Kauf darüber nachgedacht. Schließlich brauche ich einen solchen Port für meine Mikrocontrollerprojekte und -basteleien.

Da der Rechner laut Datenblatt über einen PCI Express x1 Slot verfügte, kaufte ich gleich eine passende Steckkarte mit. Heute morgen habe ich mich dann daran gemacht , die Karte einzubauen. Das Garantiesiegel am Rechner habe ich geflissentlich ignoriert und die Seitenverdeckung abgeschraubt.

ACER AS X1301-3 von innen (PCIe Slots oben rechts)
ACER AS X1301-3 von innen (PCIe Slots oben rechts)

Wie man schön sieht, ist die Grafikkarte doch nicht Onboard, sondern belegt einen PCI Express x16 Slot ganz oben. Immerhin, das erlaubt später mal einen Austausch. In den x1 Slot darunter setzte ich also die RS232 Karte von Delock. Genau eine Delock 89236 mit 16C950 Uart.

Delock 89236 RS232 für PCI Express x1
Delock 89236 RS232 für PCI Express x1

Windows  7 erkannte die Karte erstmal nicht, mochte sie aber nach dem ich von der Treiber-CD einen passenden Treiber eingespielt hatte. Mit Teraterm konnte ich dann auf mein Phytec Mikrocontrollerboard über die frische RS232 zugreifen. Warum Windows die Schnittstelle allerdings als COM3 einbindet, wenn es sonst keine RS232 im System gibt, erscheint mir aber fragwürdig.

Unter Linux war es zunächst etwas wackelig. Beim ersten Booten zeigte der Kernel die Schnittstelle zwar korrekt über dmesg an, aber beim Zugriffsversuch bekam ich einen I/O Error.

[    0.650679] Serial: 8250/16550 driver,
 4 ports, IRQ sharing enabled
[    0.650942] serial 0000:03:00.0:
 PCI INT A -> Link[AE2A] -> GSI 16 (level, low) -> IRQ 16
[    0.650950] 1 ports detected on
 Oxford PCI Express device
[    0.651010] ttyS0: detected caps 00000700
 should be 00000100
[    0.651014] 0000:03:00.0: ttyS0 at MMIO 0xfd9fd000
(irq = 16) is a 16C950/954

Nach einem Reboot funktionierte es allerdings und ich konnte das Board wie unter Windows mit gtkterm ansprechen:

GTKTerm
GTKTerm

Ob die Schnittstellenkarte auch mit meinem AVR-Board harmoniert, muss ich noch herausfinden. Da allerdings Linuxseitig der reguläre Treiber für RS232 Schnittstellen verwendet wird, bin ich eigentlich recht zuversichtlich.

Insgesamt müsste die Delock 89236 Karte damit Linux tauglich sein!

AVR flashen leicht gemacht mit AVR8 Burn-O-Mat

Mein Einstieg in AVR Mikrocontroller war bisher sehr angenehm und erfolgreich. Bekanntlich benutze ich ja avrdude um meine AVRs im Pollin Evaluation Board zu flashen. Von innerhalb Eclipse geht das ja ganz gut, aber ich möchte das natürlich auch unabhängig machen. Beispielsweise möchte man mal kurz ein anderes altes Programm flashen und testen. In diesem Use-case möchte ich natürlich nicht erst komplett Eclipse starten.

Natürlich geht alles von der Kommandozeile, aber ab und an ist ein GUI von Vorteil. Ein GUI für avrdude ist AVR8 Burn-O-Mat. Dieses Tool ist in Java programmiert und ruft einfach das installierte avrdude auf. Unter Windows läuft es problemlos, bei mir unter Linux musste ich erst eine aktuelle Java-Version installieren. Scheinbar wird Java 1.6  zwingend benötigt. Eine ntsprechender Hinweis im README oder auf der Webseite wäre schön gewesen, aber auf Nachfrage lies sich das Problem klären. Der Autor des Tools war jedenfalls sehr hilfsbereit und freundlich. So soll Open Source Software sein :)

Die Bedienung von AVR 8 Burn-O-Mat ist kinderleicht. Im Prinzip muss man nur Programmiergerät und Schnittstelle auswählen. Alles, was avrdude kann, kann AVR8 Burn-O-Mat auch. Die Fuses kann man auslesen und problemlos grafisch ändern und entsprechend zurückspielen. Hexfile und EEPROM-Inhalt kann man ebenfalls idiotensicher angeben und auf Knopfdruck flashen. Die Ausgabe von avrdude wird dabei im Fenster angezeigt. Leicht zu bedienen, effizient und mächtig. Ein sehr empfehlenswertes Tool für alle, die für AVRs entwickeln!

Zum Abschluss meine Konfiguration für das Pollin Evaluation Board in AVR8 Burn-O-Mat:

AVR8 Burn-O-Mat Einstellung für Pollin Evaluation Board
AVR8 Burn-O-Mat Einstellung für Pollin Evaluation Board

Zum Vergrößern auf den Screenshot klicken!

AVR Einstieg Teil 5: Die Taster auf dem Pollin Evaluationboard

Mein aktuelles Testprogramm versucht, die Taster auf dem Evaluationboard von Pollin anzusteuern.

Das funktioniert auch recht gut. Zwei Dinge sollte man dabei beachten:

  1. Die Pins bitweise über das Register PIND einlesen und nicht PORTD. Das ist leider ein AVR Spezifikum.
  2. Die Taster schalten nicht gegen Masse, sondern gegen 5V, also active high. Daher müssen die internen Pullups deaktiviert werden, sonst sieht man dauernd eine 1 an den Eingangspins.

Ansonsten geht es eigentlich wie erwartet.

Testprogramm: taster.c.gz

AVR Einstieg Teil 4: Das erste Testprogramm

Mein erstes Testprogramm für das AVR Evaluationboard von Pollin möchte ich hier gleich kurz vorstellen.

Offenbar suchte schon der eine oder andere danach. Für den ersten Einstieg in das Board habe ich einen kleinen LED-Blinker mit avr-gcc programmiert:

/*
 * first-avr.c
 *
 *  Created on: 16.07.2009
 *      Author: marndt
 */
#include <avr/io.h>
#include <stdint.h>
#include <util/delay.h>
int main(void)
{								// (2)
 DDRD = 0xff;		// (3)
 PORTD = 0x20;		// (4)
 while (1)
 {			// (5a)
 /*
 * "leere" Schleife
 */// (5b)
 PORTD = 0x20;		// (4)
 _delay_ms(5000);
 PORTD = 0x40;
 _delay_ms(1000);
 }				// (5c)
 /*
 * wird nie erreicht
 */
 return 0;			// (6)
}

Das Programm schaltet abwechselnd die beiden LEDs an und aus (Jumper müssen gesetzt sein). Dabei leuchtet die eine LED für 5 Sekunden und die andere für 1 Sekunde

first-avr.c.gz herunterladen

AVR Einstieg Teil 3: Wie aktiviere ich den 16Mhz Quarz auf dem Pollin Evaluationboard?

Die Frage ist völlig berechtigt, denn für viele Projekte ist der im AVR eingebaute 1MHz RC Takterzeuger zu ungenau.

Dazu muss man beim Flashen des Bausteins bestimmte Konfigurationsworte, sogenannte Fuses programmieren.  Im Datenblatt zum Chip werden die Optionen erläutert. Und siehe da, im AVR-Plugin für Eclipse geht das alles automatisch durch Anklicken (Projekt Properties -> AVR -> avrdude  -> Reiter “Fuses”)

Ganz wichtig: zuerst die vorhandenen Fuses auslesen und sich anzeigen lassen!

Grundsätzlich gilt: was man nicht versteht, nicht ändern!

Die naheliegende Einstellung, “Ext. Clock”, funktioniert leider nicht. Diese sollte nur in späteren fertigen Boards verwendet werden, wo ein kompletter eigenständiger stabiler Taktgenerator verbaut wird. Die Quarzkonstruktion mit zwei kleinen Blockkondensatoren wie auf den Evaluationboard von Pollin verlangt eine andere Einstellung. Ich hatte es irrtümlich ausprobiert, und danach ist der Chip im Board leider nicht mehr ansprechbar, da der AVR dann keinen gültigen Takt mehr bekommt.

Mit den Settings “Ext. Crystal/Resonator High Frequency” und “16K CLK + 64ms”, also hoher Anlaufzeit, läuft es hier offenbar dann mit meinem ATmega16 in der 40poligen Fassung.

Analog wird es für den 8MHz Quarz und die 8pinnigen Controller im Board funktionieren. Mangels Testobjekt habe ich das aber noch nicht verifiziert.

Vielen Dank an das Forum von mikrocontroller.net! Dort wurde mir kompetent geholfen!

Mal sehen, in welche Richtung ich mit den AVRs weitermache. Im Moment bin ich da recht motiviert, zumal ich längere Zeit nicht aktiv mit Mikrocontrollern gearbeitet habe.