For quite awhile I wondered why SDCC (the free Small Devices C Compiler – http://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!
Hier ist ein gutes und freies einführendes Buch bei wikibooks über Embedded Systems.
Das Buch beschreibt allgemeines über Eingebettete Systeme, ihren Entwurf undd as generell Hearngehen. Auch Betriebssysteme und diverse Mikrocontrollerarchitekturen werden darin besprochen.
Für Anfänger und generell Interessierte sicherlich nicht uninteressant, zumal man auf Basis eines solchen Buches auch einen kompletten Kurs gestalten kann.
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.
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.
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)
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
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
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!
Durch Zufall stieß ich gerade auf einen freien Assembler (leider ohne Quellcode) als Binary für Motorola 68HC11 und 68HC12 Mikrocontroller.
Der Assembler ist ein Kommandozeilenprogramm. Einfach das Archiv entpacken, die beiden Dateien im Pfad, z.B. /usr/local/bin/ ablegen und ausführbar machen (chmod +x asm11) und dann läuft der Assembler. Die Binaries gehen wohl auch auf AMD64, wie bei mir gerade ausprobiert.
Da ich selber mit 68HC11 Controllern nicht arbeite, kann ich konkret zum Output und Syntax oder zu anderen möglichen Problemen nichts sagen. Aber wenn jemand einen kurzen Erfahrungsbericht schreiben möchte, einfach als Kommentar anhängen.
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
Mein aktuelles Testprogramm versucht, die Taster auf dem Evaluationboard von Pollin anzusteuern.
Das funktioniert auch recht gut. Zwei Dinge sollte man dabei beachten:
Die Pins bitweise über das Register PIND einlesen und nicht PORTD. Das ist leider ein AVR Spezifikum.
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.
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
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.
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.
