Archive for the ‘AVR’ 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

ATtiny85 per Drahtverhau ausgelesen

Ich habe heute mal endlich ein wenig in meiner Bastelkiste gewühlt. Bis heute war ich mir nicht sicher, ob man AVRs wirklich mit wenig Aufwand direkt im Steckbrett programmieren kann. Ich habe es einfach mal selbst ausprobiert und einen ATtiny85 mit ganzen 8 Pins mehr oder minder direkt mit meinem mySmartUSB light Programmiergerät verbunden.

Ich habe den 6 auf 10Pin Adapter missbraucht, um einfach Steckbrücken mit Buchsen auf die Pins zu stecken. Dabei habe ich mich an ein Schemabild aus dem Netz gehalten und dabei eine möglichst ähnliche Farbcodierung verwendet. Auf meinem Steckbrett musste ich dann nur die Buchsen auf Pins abbilden und gemäß Datenblatt die Pins am Microcontroller mit den jeweiligen Signalen verbinden.

Danach habe ich einfach mal per avrdude Inhalte gelesen und geschrieben. Flash und Fuses funktionierten prächtig, beim EEPROM hatte ich mein Problem. Eventuell kommt mir da die EESAVE Fuse ins Gehege. Ich plane am langen Wochenende (morgen habe ich Urlaub) ein Testprogramm für den ATtiny85 zu schreiben, bei dem ich mal im EEPROM per Programm schreibe und lese.

Insgesamt, ja, es funktioniert. Ich konnte den Chip im Steckbrett ohne spezielle Hardware auslesen und programmieren.

ATtiny85 mit fliegender Verdrahtung im Steckbrett

ATtiny85 mit fliegender Verdrahtung im Steckbrett

mySmartUSB light – Programmiergerät für AVRs im USB Stick Format

mySmartUSB light - Programmiergerät für AVRs

mySmartUSB light - Programmiergerät für AVRs

Irgendwann im letzten Jahr stolperte ich beim Recherchieren über das mySmartUSB light Programmiergerät für AVRs. Laut der Dokumentation und Beschreibung sollte es problemlos auch unter Linux funktionieren.

Bei einem moderaten Preis um 20€ habe ich es mir dann als Ergänzung zu meinem ähnlich preiswerten Pollin Evaluationboard gekauft.

Das Gerät kommt als kleiner USB Stick daher, hat einen Anschluss für das 6polige ISP Kabel und kann kleinere Systeme auch problemlos über USB mit Saft versorgen.

Ausprobiert habe ich den Stick kurzerhand mit meinem Arduinoboard, allerdings nur lesend. Der Arduino bringt den 6poligen Sockel direkt mit, so daß das Programmiergerät direkt passt. Unter Linux wurde mir direkt ein neuer USB COM Port angezeigt und verfügbar gemacht.

Anschließend habe ich AVR8 Burn-O-Mat benutzt, avrdude auf STK500v2 Protokoll und die USB Schnittstelle eingestellt, und es hat auf Anhieb funktioniert, ich konnte den Flashinhalt des Arduinos direkt auslesen. Im Binärvergleich mit dem Arduinoprotokoll und dem Arduino direkt stimmt das FLASH überein, beim Auslesen des EEPROMs gab es Diskrepanzen, das neue Gerät zeigt ein leeres Eeprom, während mit dem Arduinoprotokoll Inhalte übertragen werden. Auch die Fuses konnte ich nur mit dem neuen Gerät und STK500V2 Protokoll korrekt auslesen. Da muss ich in jedem Fall mal mit einem leeren ATmega16 oder dgl experimentieren, vllt. hat das arduino Bootloaderprotokoll Besonderheiten oder meine avrdude Version ist zu alt.

Unter Windows muss man wohl erst einen USB Treiber installieren, aber ich gehe davon aus, daß das Gerät dort genauso und ohne Macken funktioniert.

Für 10polige Sockel gibt es wohl ein offizielles Adapterkabel, bzw ein Wechsler, der von 10 auf 6 und 6 auf 10 Pole umschaltet. Beide Formate sind in jedem Fall von Atmel standardisiert.

In jedem Fall für Embedded Entwickler, die AVRs per ISP programmieren, ein nützliches und preiswertes Gadget für den kleinen Erste Hilfe Koffer.

Mehr zum Gerät, u.a. Downloads unter http://shop.myavr.de/Topseller/mySmartUSB%20light.htm?sp=article.sp.php&artID=200006

AVR, JTAG and externel reset

Today at the office I learned a nice trick that might become handy for other AVR users.

A times a target system with AVR microcontroller exhibits an accessibility problem. The system features an ATmega644PA microcontroller unit which is debugged via JTAG interface. The board can only be flashed via JTAG if the external reset is triggered properly.

In an AVR Studio project the system can be told to enable the external reset over the wiring but access without the project over the Atmel JTAGICE MKII programmer fails. How to place the thing in reset condition so JTAG can take over?

The trick came from one of our electronics gurus who simply asked: “Can’t you short the reset and make it work?” We simply tried and yes this works. Ofcourse the flashed firmware does not boot if RESET is tied to GND but JTAG access works. The device can be flashed, fuses set and read and maybe debugging works too (we didn’t try that).

So basically if you try to access an AVR mcu with JTAG interface and no backup such as SPI, try tying the RESET line to GND. I simply made a little wire bridge shorting pins 6 (RESET) with 2 (GND) on the 10pin JTAG cable. I plug the main cable in the left socket on the programmer cable and put the bridge in the second socket whichs is probably wired in parallel. It worked well for us today!

Ein DB9 Joystick auf USB Adapter

In einer Ausgabe des Load Magazin auf der Xzentrix 2012 sah ich eine Werbeanzeige für diesen Joystickadapter zum selberzusammenbauen. Damit kann man wohl 2 klassische Joysticks mit DB9 Anschluss (C64, Amiga, Atari ST, etc) per USB an der PC anschliessen und verwenden: http://retro-donald.de/sinchai-shop/index.php?main_page=product_info&cPath=1&products_id=137

Die Firmware soll noch ein paar Macken haben und unter Linux oder auf dem Mac nicht 100% tun. Mal schauen, ich notiers mir mal im Hinterkopf und schau in Zukunft nochmal nach. Prinzipiell suche ich genau so ein Teil seit langer Zeit. Ausserdem hatte ich mal überlegt, selber eines mit AVR zu basteln, habe das Projekt aus Zeitmangel aber noch nicht angefangen.

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.

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.