NAGCL [I]

In dem Eingangsartikel zu meinem Software-Projekt NAGCL (das habe ich jetzt als Interimsnamen auserkoren) bin ich kurz auf die angedachten Features des Programms eingegangen, sowie auf die Historie und Motivation dazu.
In diesem Artikel möchte ich ein kurzes Update zum aktuellen Stand des Projekts geben, sowie ein paar Implementierungsdetails vorstellen.

Für die wichtigsten Elemente des Programms bestehen mittlerweile erweiterbare Gerüste. Das trifft vor allem auf die Benutzung im Shell-Modus und auf die Übergabe von Parametern beim Programmaufruf zu.
Ebenfalls kann bereits eine Textdatei mit Pfaden zu git-Repositories eingelesen werden. Diese Pfade werden auf Existenz, Zugriffsrechte und ob diese auf ein gültiges git-Repository zeigen geprüft.

Um alle Einträge der Textdatei verwalten zu können, werden diese in einer einfach verlinkten Liste (Linked List) abgelegt. Diese Liste wird bei jedem Programmaufruf bzw. -start neu angelegt.
Im Shell-Modus bzw. als Parameter beim Programmaufruf können Elemente der Liste hinzugefügt oder entfernt werden. Ob die Liste verändert wurde, wird beim Beenden des Programms dem Nutzer gemeldet. Als letzter Schritt wird die Textdatei – sofern eine Änderung der Liste vorgenommen wurde – aktualisiert, d.h. Pfade von Repositories werden hinzugefügt oder entfernt. Die Implementierung einer einfach verlinkten Liste war notwendig um einen dynamischen Datentyp zur Verwaltung der Repositories zur Laufzeit zu erhalten. Die Implementierung ist allerdings bei Weitem nicht so elegant wie die von Linus Torvalds‘ Liste in der Kernel-Implementierung. Eine derart generische Implementierung einer Liste wird an dieser Stelle von mir aber auch nicht benötigt.

Aktuell arbeite ich daran, den Log (entspricht dem Befehl git log) eines git-Repositories auszugeben sowie den ersten Versuchen einer GUI-Implementierung. Die Implementierung der git-Funktion erfolgt mit der API libgit2, die Implementierung der GUI-Funktionen mittels der Bibliothek ncurses.

Die größte Veränderung für mich selbst war die Umstellung von Makefile zu cmake als Build-Setup.
Der Hauptgrund für den Wechsel des Build-Setups war, mich mit cmake auseinander zu setzen und einzuarbeiten. Aktuell kann das Projekt mit allen benötigten Bibliotheken gebaut und verlinkt werden, wenngleich das Setup im Moment unübersichtlich ist und noch nicht dem gewünschten Stand entspricht.
Im endgültigen Stand sollen alle benötigten Bibliotheken heruntergeladen und mitkompiliert werden. Zudem soll die Erstellung der Dokumentation mittels Doxygen unterstützt werden, sowie Testcases zur Überprüfung der korrekten Ausführen der Software bei der Installation.
Als Editor benutzte ich vim zusammen mit cscope und dem Plugin Conque-GDB zum graphischen Debuggen des Programms.

Zuletzt möchte ich erwähnen, dass ich noch offen bin für Namensvorschläge und wie immer gilt:
Schreibt, kommentiert, diskutiert und abonniert den Podcast!

Nicht noch ein GIT-Client

Vor ein paar Jahren hatte ich ein Bash-Skript geschrieben um git-Repositories automatisiert zu aktualisieren, also ein git pull auf dem aktuell ausgecheckten Branch des Repositories.
Das Skript funktioniert mit einer Textdatei in der die Pfade zu den Repositories angegeben sind und aktualisiert diese, sofern keine Konflikte vorhanden sind.
Die Ausgabe der Informationen welche Repositories überprüft werden und welche aktualisiert wurden, werden nicht nur über das Terminal angezeigt, sondern auch in einer Log-Datei gespeichert. Dieses Log kann entweder immer wieder neu erzeugt werden bei jedem Aufruf des Skripts oder als fortlaufende Datei.

Um mich in Python einzuarbeiten hatte ich im Anschluss einen Wrapper für das Bash-Skript implementiert, mit welchem man die Repository-Liste zur Aktualisierung bearbeiten kann (Reposietories hinzuügen oder entfernen) und in einem Shell-Modus läuft. Zusätzlich kann das Python-Program das Bash-Skript aufrufen, die Log-Infos der Repositories anzeigen und ein neues Terminal-Fenster mit dem Pfad eines gewünschten Repository öffnen (zumindest für die gängigsten Unix-Terminal-Programme). Letzte Funktion hat den Zweck einfach zwischen den Repositories wechseln zu können und git per CLI zu bedienen.
Da das Python-Programm im Shell-Modus läuft, habe ich zusätzlich eine Auto-Komplettierung für Repositories und Befehle implementiert.
Das Bash-Skript sowie das dazugehörige Python-Programm sind auf Github veröffentlicht und über die Jahre gab es doch den Einen oder Anderen clone des Projekts. Darüber freue ich mich auch, aber ich habe bisher leider keine Rückmeldung zur Nutzbarkeit erhalten.

Nun ist es so, dass ich persönlich kein großer Fan von Python bin und habe daher beschlossen ein C-Programm zu implementieren, dass die Funktionalitäten des ursprünglichen Bash-Skripts und des Python-Programms beinhaltet.
Das neue Programm kann als Terminal-Befehl, im Shell-Modus und mit einem Terminal-UI (ncurses) ausgeführt werden. Zusätzlich sollen weitere grundlegende Funktionalitäten implementiert werden um einen git-Client zu erhalten.
Der größte Unterschied stellt wohl die Art und Weise wie mit git von den Programmen aus interagiert wird dar. Während beim Bash-Skript und dem Python-Programm die git-Befehle als Systembefehle in einem Subprozess ausgeführt werden, soll das bei der C Implementierung mittels API funktionieren. Dazu verwende ich libgit2.
Über den aktuellen Status und die Implementierungsdetails gehe ich in Folgebeiträgen ein. Veröffentlich wird das Projekt auf Github, wenn ich die ursprüngliche Funktionalität fertig implementiert habe, also die Auto-Aktualisierung von Repositories in einer Liste.
Aktuell trägt das Projekt noch den unkreativen Namen gitmanager, aber ich denke über eine Umbenennung in yagcl (Yet Another Git CLient) oder nagcl (Not Another Git CLient) nach. Für kreative Vorschläge bin ich offen (bitte nicht Git McGitFace).

Links:

OSICs – Open Source Integrated Circuits

In der sechsten Folge der Kurzschluss Junkies habe ich mit Basti und Chris über FPGA- und
ASIC-Entwicklungen gesprochen. In dieser Beitragsreihe möchte ich Open Source Software zur IC-Enticklung vorstellen und auf deren Fähigkeiten, bzw. Möglichkeiten eingehen.

Ein Beispiel, dass mit freier Software ein IC erstellt werden kann, ist die Realisierung eines auf einem RISC-V basierenden SoCs. Der verwendete Softcore ist der PicoRV32 in einem QFN-48 Package der mit ADCs, DACs und einer seriellen Schnittstelle (SPI) erweitert und bei efabless gefertigt wurde.
Die Toolchain die dafür hauptsächlich verwendet wurde heißt Qflow und verbindet Tools zur Synthese, Logikminimierung, Placement und Routing von Standardzellen-Logik. Die Firma efabless bietet die Möglichkeit eigene Designs zu realiserun und hostet eine Toolchain die selbst teilweise auf Qflow basiert.

Der Hauptentwickler von Qflow heißt Tim Edwards und dieser hat bei eeweb.com ein Interview gegeben in dem er seine Arbeit und Philosophie zur freien Software für den Chip Entwurf vorstellt und erklärt. Der Aufbau von Qflow ist auf opencircuitdesign.com in Detail beschrieben, dennoch möchte ich nachfolgend einen kurzen Abriss über die wichtigsten Elemente der eingebundenen Software geben.

Qflow nutzt zur Synthese yosys, eine offene Synthessuite für FPGAs und ASICS, die von Clifford Wolf entwickelt wurde. Diese synthetisiert Verilog Designs und bietet – bei vorhandener Bibliothek – nicht nur eine Logikminimierung an, sondern auch ein Mapping auf Standardzellen. Die Logikminimierung erfolgt mittels abc, einem Tool das bei der Universität von Berkley entwickelt wurde und auch eine Verifikation von Logikschaltungen zur Verfügung stellt. Die Stärke von yosys liegt in den implementierten Durchläufen zur Synthese und Verifikation. Diese können je nach Anforderung adaptiert werden um so die Optimierungdurchläufe auf mögliche Besonderheiten anzupassen. Solche Besonderheiten können zum Beispiel der Standardzellenbibliothek des Herstellers geschuldet sein.
Eine weitere Stärke ist die Möglichkeit yosys über Skripte bedienen zu können.

Die Platzierung erfolgt mit graywolf, einem Tool das mittels Simulated Annealing Standardzellen plaziert. graywolf ist ein Fork des mittlerweile kommerziellen Tools Timberwolf, das für eine Lizenz einen Preis von 50k USD ausruft und in Yale entwickelt wurde.

Qrouter schließlich verbindet die Standardzellen mittels dem Lee-Algorithmus und unterstütz bis zu sechs Metalllagen. Damit lassen sich, wie das Beispiel des RISC-V basierenden SoCs zeigt, recht komplexe und große Designs realiseren.
Abgerundet wird die Toolchain mit einem LVS-Checker (netgen) swoie einem Layout-Editor mit der Fähigkeit zum DRC (magic).

Die größten limitierenden Faktoren stellen letztlich die Bauteilbibliothek und die Zieltechnologie dar. Die Bauteilbibliothek insofern, als dass diese von den einzelnen Halbleiterherstellern i.d.R. gekauft werden muss und die Zieltechnologie dahingehend, dass es eine Sache ist, ein Design mit einer 120nm-Struktur oder größer zu realisieren oder 90nm und kleiner. Die Hauptschwierigkeit stellt hier die Abschätzung der Laufzeitverzögerungen dar. Wer sich aber einfach für Chip-Entwicklung, Algorithmen und DIY-Realisierungen mit offenen (beispielhaften) Bibliotheken interessiert, oder gar mit einem Start-Up/kleinem Unternehmen Chips realiseren möchte, bekommt mit diesen Projekten einen wunderbaren Einstieg und nützliche Software an die Hand mit der wirklich etwas realisiert werden kann. Dank Quelloffenheit können diese Programme sogar angepasst und erweitert werden.

Abschließend möchte ich erwähnen, dass diese Projekte nicht nur einen tiefgehenden Einblick in die Herausforderungen für CAE-Tools zur Realisierung von integrierten Schaltungen bietet, sondern auch exzellente Beispiele für gut implementierten und dokumentierten Code sind (überwiegend C und C++).

In weiteren Beiträgen möchte ich die erwähnten Algorithmen genauer vorstellen, sowie weitere freie Software für den Chip-Entwurf sowie eine freie, erweiterbare Suite für Xilinx FPGAs. Auch kleine Tutorials und Anleitungen zur Nutzung der Software sind angedacht.
Schreibt, kommentiert, diskutiert und abonniert den Podcast!

Links:

KiCad Net Class Constraint Management

Ich bin gerade dabei ein relativ komplexes Design in KiCad zu entwicklen. Es handelt sich dabei um ein i.MX7 Prozessor mit DDR3 Anbindung. Für DDR3 sind einige Designrichtlinien einzuhalten. Diese sind neben der Leitungsimpedanz (50 Ω Transmission Line und 100 Ω Differantial Line) auch die Länge der einzelnen Signalgruppen und des Clock Signals. Darüber ein Überblick zu behalten ist nicht leicht. KiCad hat keine Funktion einfach diese Constraints zu checken und zu verwalten. Zum Glück handelt es sich um ein Open Source Projekt und daher habe ich den Versuch gestartet, pcbnew mit den nötigen Funktionen auszustatten. Ziel ist es einen angenehmen Routing-Vorgang solcher komplexen Schaltungen zu erhalten. Dazu gehören neben der Verwaltung der Constraints auch noch andere Features:

  • Live Tracking der Leitungslängen
  • Reporting der Constraints
  • DRC der Constraints
Der erste Schritt wird sein die Constraint Daten in die Netzklasse mit einzubinden. Dazu habe ich den Design Rule Dialog erweitert. Er hat 8 neue Spalten erhalten.
  1. Max Vias
  2. Topology
  3. Min Length
  4. Max Length
  5. Max Skew
  6. Stub Length
  7. Type
  8. Layer

Max Vias

Ein hochfrequentes Signal wird an jedem Materialeigenschaften-Übergang reflektiert und verliert Energie. Das können beispielsweise Änderungen des Leitungsquerschnitts, Bezugsmasse, Leitungsmaterials, oder anderer Umgebungsparameter sein. Eine Signalübergabe über ein Via in eine andere Lage ist genau so ein Übergang und führt zu Signalfehlern. Daher gibt es für manche Signale eine maximale Anzahl von Vias.

Topology

Die Routing Topologie ist die Art und Weise, wie das Signal von der Quelle zu einer Senke, oder mehrerer Senken übertragen wird. Es werden folgende Topologien erkannt:

  • STAR
    Das Signal geht von der Quelle sternförmig zu jeder Senke mit einer eigenen Leitung.
  • T
    Das Signal teilt sich (auch mehrmals) in jeweils zwei gleichlange Äste auf.
  • FLYBY
    Hier wird das Signal von der Quelle aus an jeder Senke vorbei geführt, ohne sich aufzuteilen. Alle Zwischenstücke sind gleichlang ausgelegt.
  • HORIZONTAL
    Alle Signale sollen horizontal geführt werden.
  • VERTICAL
    Alle Signale sollen vertikal geführt werden.
  • SIMPLE_DAISY_CHAIN
    Das Signal geht von der Quelle zur ersten Senke, von dort zur zweiten und so weiter. Vergleichbar mit der FLYBY Topologie.
  • MIDDRIVEN_DAISY_CHAIN
    Bei dieser Topologie geht das Signal von der Quelle nach beiden Seiten an mindestens zwei Senken. Dies ist eine Kombination aus eine Ebene T und FLYBY.
  • MULTIPOINT_TOPOLOGY
    Das Signal wird an vielen Stellen verbunden. (Niederfrequente Signale oder Spannung/Ground)

Min/Max Length

Signale, die laufzeitbegrenzt sind, oder in Relation mit anderen Signalen stehen, müssen eine gewisse Länge einhalten. Diese beiden Werte geben das Längenfenster an, in dem sich alle Signale der Netzklasse befinden dürfen.

Max Skew

Ähnlich wie die Min/Max Länge ist der Skew eine Toleranzangabe für die Länge aller Signale der Netzklasse. Beispielsweise muss ein Bus mit 8 Signalen maximal nur 60mm lang sein. Die 8 Signale sind aber auf einem Skew von 2mm begrenzt. So kann die Gruppe an sich in der Länge variieren, die einzelnen Signale sind aber strikter reglementiert.

Stub Length

Ein Stub ist eine Abzweigung des Signals. Am Ende der Leitung wird das Signal reflektiert und zurück geworfen. Das kann bei zu langen Stubs zu Problemen führen. Daher werden für diese Fälle maximale Stublängen angegeben.

Type

Hier kann zwischen den Leitungstypen Signal, Power oder Mixed gewählt werden. Diese werden an den globalen Layer Einstellungen gemessen.

Layer

Der Type Wert kann manuell überschrieben werden um die Lage in der die Leitung geführt werden darf weiter zu beschränken, oder weiter aufzulösen. Manchmal dürfen Signale nicht auf die andere Seite der Leiterkarte übertragen werden. Das kann mit dieser Einstellung konfiguriert werden.

Der aktuelle Stand ist, dass die Werte in die Tabelle eingetragen werden und mit dem Projekt abgespeichert werden können. Ich erweitere gerade die Tabelle dahin, dass die Werte schöner angezeigt werden und es für die Topologie, und Type Felder eine Dropdown-Liste gibt. Das Layer Feld soll eine Auswahlliste bekommen, in der die erlaubten Layer markiert werden können.

Live Tracking der Leitungslängen

Ein weiteres großen Feature soll das messen der Leitungslänge in Echtzeit sein. Dazu gehören mehrere Elemente. Einerseits soll auf der rechten Seite des Fensters zwischen Zeichenfeld und Toolbar eine Liste mit den zu messenden Leitungen eingeblendet werden können. Das soll ebenso wie der Layer-Dialog entweder fest am Fenster verankert, oder frei beweglich im Fenster verschoben werden können.
Andererseits soll ein weiteres Element eine Statusbar-Anzeige sein, die in Echtzeit zeigt, ob die Leitung zu lang oder zu kurz ist. Idealerweise kann hier schon eine Prognose eingebaut werden, die versucht zu ermitteln, ob mit der Länge das Ziel überhaupt erreicht werden kann. Hier werde ich am Anfang auf die „Luftlinie“ zurückgreifen und den direkten Weg als Grenze nehmen.

Reporting der Constraints

Dieses Feature ist relativ einfach zu realisieren. Alle Netze mit Constraints in der Netzklasse werden in einem Report ausgegeben und stehen als Textdatei zur Verfügung.

DRC der Constraints

Der Design Rule Check soll um die Constraints erweitert werden und mit den Fehlerklassen Report, Warning, Error über die Constraints berichten.

Converting a CC26xx Example Project Into Something Shareable


The example projects that are shipped with TI’s BLE SDK are great. They show a huge variety of use cases for the BLE stack. The codes provided are great resources when it comes to information on how to build software for the CC26xx chip family. Doing so many examples leaves us with code that is used more often than once and so it is linked into the project. Basically every file that consists of some code is a virtual link to a file on the folder structure. That leaves us with the problem that sharing the project with an SVN or GIT server only gives us the few local files and none of the code that is important. Changing the code is possible but you have to remind yourself, that the files are not considered to have changed when submitting to a version control system. 
To conquer this issue we need to have some of the files we are going to change or that are not part of the SDK in a local version on our file system. Luckily we can just copy the files to a folder in the project of the workspace. This way the files are preserved and as a next step we delete the links to the files in the project explorer.
I moved the following files to local folders:
  • simpleBLEPeripheral.c /.h
  • board_key.c /.h
  • simpleGATTprofile.c /.h
  • main.c
  • Board.c /.h
  • appBLE.cfg
You now have to add the local folders to the include paths of your project so the files can be found during build. Especially the Board.h which contains the information on how the chip is integrated in the circuit. Remember to remove all the unnecessary folders from your include paths. If your project uses available files from the example projects (like profiles and utils) you can leave the links in you project. To share the project you can use Subclipse or Git. You will have to install the same version of the SDK if you want to compile the project we created.
You can read up on this instructions on how you can create your own GATT Profile.

Das ESP-12 3$ WiFi Modul, oder wo könnte man überall Internet einbauen

Seit geraumer Zeit gibt es, vor allem aus China, ein Modul, dass einen ESP8266 Mikrocontroller, ein Flashspeicher, onboard Antenne und einige GPIOs besitzt. Verfügbar ist das Modul in so weit ich herausgefunden habe 14 verschiedenen Ausführungen, vom blankliegenden Controller bis hin zum voll geschirmten Modulpaket, dass die GPIOs als Lötpunkte auf der unterseite besitzt. Die Module sind alle über die üblichen Kanäle zu beziehen. Dabei sind auch die üblichen Lieferzeiten zu erwarten.

Aufbau des Moduls

ESP-12 Modul mit Breakout-Board
Ich habe mir das ESP-12 Modul mit einem Breakout-Board bestellt. Dadurch ist es möglich das Modul im Steckbrett unterzubringen und so schnell eine akzeptable Verkabelung zu erreichen. Das Modul besitzt eine LED, eine PCB-Antenne und ist ansonsten unter einem Metalldeckel abgeschirmt. Dieser Schirm trägt die Kennzeichnung, dass das Modul die Modellnummer ESP826WLAN. Mit diesen Parametern ist es hervorragend geeignet in einem WLAN Netzwerk eingesetzt zu werden. Das Modul hat eine Größe von 16x24mm Die seitlich angebrachten Lötpads sind mit 2mm Abstand angeordnet und befinden sich nicht im Bereich der Antenne. Die LED kann über den Controller gesteuert werden. Die beiden Lötpads für SMD Widerstände sind einam mit GPIO 15 und Chpi_Enable verbunden. Sie können dauerhaft auf GND bzw. VCC gelegt werden. Wenn anstatt der hier verwendeten Lötbrücke ein 10k 0603 SMD Widerstand eingelötet wird, können die Pins auch noch verwendet werden. Ich hatte nur gerade keine griffbereit.
6MOD besitzt und von der Firma AI-THINKER hergestellt wurde. Es besitzt eine FCC-Zulassung, arbeitet auf dem ISM 2,4GHz Band, hat eine Sendeleistung von +25dBm und verwendet das Funkprotokoll IEEE 802.11b/g/n auch bekannt als

Espressif SDK und weitere Betriebsmodi

Die Firma Espressif Systems hat für den ESP8266 eine SDK herausgebracht, das es ermöglicht die Module in zwei verschiedenen Betriebsmodi zu verwenden. Einmal als eigenständiges Modul, dass mit UART Befehlen gesteuert werden kann. Andererseits biete das GitHub von Espressif ein SDK zur Entwicklung von Software mit Hilfe von FreeRTOS in C. Aufbauend auf diesem SDK wurde NodeMcu entwickelt. NodeMcu bringt die Skriptsprache Lua auf das System und ermöglicht es den Microcontroller mit einfach zu scheibenden Skripten zu verwenden. Auch dieses Projekt ist Open-Source und auf Github verfügbar. 

Flashen der Firmware

NodeMcu Firmware Programmer
Das Flashen von Mikrocontrollern kam in der Vergangenheit immer etwas arbeitsaufwändig daher. Meistens wurden spezielle Programmieradapter verwendet, oder das Chip musste über einen JTAG Adapter angesprochen werden. Im Laufe der Zeit haben sich Bootloader etabliert, die in einem reservierten Bereich des Flashs sitzen und vor Ausführen des Hauptprogramms ein Programmieren über die serielle Schnittstelle zulassen. So auch bei diesem Modul. es ich möglich die Firmware von NodeMcu über die Serielle Schnittstelle zu flashen. Das Projekt stellt dazu sogar ein Windows Programm zur Verfügung, das völlig selbständig das Modul mit allen benötigten Speicherteilen beschriebt. 

Kommunikation mit dem Modul

ESPlorer

Nachdem die NodeMcu Firmware auf das Modul geflasht wurde, kann über die Serielle Schnittstelle die Kommunikation mit dem LUA-Interpreter aufgenommen werden. Der Interpreter lauscht mit einer Baudrate von 9600 8 Bits, 1 Stop, kein Parity. Rund um den ESP8266 hat sich bereits eine große Gemeinschaft von Leuten gebildet, die alle mit zum Entstehen von großartiger Software beitragen. Zum Beispiel das ESPlorer Projekt, das eine leicht zu bedienende Oberfläche zum Programmieren der LUA Skripte entwickelt hat. Die für die Entwicklung nötigen Informationen finden sich ebenfalls auf GitHub und können dort im Wiki und der API Dokumentation nachgeschlagen werden.

Bei den bereits verfügbaren LUA Modulen befindet sich alles was man zur Entwicklung von WLAN fähigen Geräten benötigt. Jetzt bleibt nur noch die Frage zu klären, wo kann man überall noch WLAN einbauen und wie mache ich das, damit mein Nachbar mir nicht das Licht ausschalten kann.

Reverse Engineering einer Kaffeemaschine

Meine aktuelle Projektarbeit befasst sich mit dem Innenleben eines Kaffee Vollautomaten der Firma Severin, Genauer gesagt der KV8023 S2+. Ziel dieser Arbeit ist es die Kommunikation zwischen Bedienpanel und Kaffeemaschine zu analysieren und gegebenenfalls so zu manipulieren, dass die Maschine über einen Mikrocontroller ferngesteuert werden kann. Dazu habe ich die Maschine erst einmal geöffnet und zwei Flachbaugrupppen gefunden. Eine ist Netzteil, Netzspannung-Schaltung und Controller für die eigentliche Maschine, die andere ist ein Bedienpanel mit einem eigenen ATmega1284P an board. Das Flachbandkabel, mit dem beide Platinen verbunden sind deutet darauf hin, dass die Steuerung der Maschine über ein Bussystem gelöst ist. Wo die eigentliche Intelligenz steckt ist mit eines der ersten Punkte, die es herauszufinden gibt.
Geöffneter Vollautomat Controller des Bedienpanels

Nach einer genaueren Betrachtung des Panels habe ich die Verbindungen der Bauteile in einem Plan aufgestellt. Dieser Plan zeigt alle Steckverbinder, das Displayinterface und die, an den Controller angeschlossene Hardware (Taster, Drehencoder und LED). Eine Erweiterung des Verbindungskabels mittels eines Schneidklemmsteckers erzeugt den Zugriff auf den vermeindlichen Bus. Dieses Kabel ist verbunden mit dem SPI Interface des Controllers, mit dem Display (hier fehlt noch die Belegung der Kontakte).
Ein kurzer Test mit dem Logic Analyser zeigt, dass auf dem SPI Bus tatsächlich reger Betrieb herrscht. Nach einigen Kaffees habe ich jetzt mehrere Minuten Kommunikation mitgeschnitten und werde im nächsten Schritt versuchen die Telegramme auszuwerten und zuzuordnen.
Mitschnitt zweier Telegramme der Buskommunikation
Die Übertragung startet zyklisch alle 0,126 Sekunden, es werden 10 Byte über den Bus mit Enable Low (An) übermittelt. Auf diese Bytes gibt es eine Antwort auf der MISO Leitung. Darauf folgen 540 Bytes ohne Antwort, bei denen der Enable des Flachbandkabels konstant auf High (Aus) liegt. Es liegt nahe, dass es sich hierbei um Daten für das Display handelt, denn auch dorthin ist MOSI des Controllers verbunden. Mit einem Arduino und einem kleinen Sketch kann ich also nächste Woche die 10 Byte Telegramme abfangen und zur Auswertung aussortieren. Dadurch reduziert sich die Menge der Telegramme auf ein Minimum und die Entschlüsselung ebendieser wird hoffentlich leichter fallen.
Um eine Fernsteuerung durchzuführen, muss die Kommunikationsverbindung unterbrochen werden, da sonst das Bedienpanel in die automatisierten Telegramme zusätzliche Telegramme schicken würde. Gleichzeitig muss dem Bedienpanel die Antwort der Maschine vorgespielt werden, da sonst ein Fehler angezeigt wird. Wie sich die Anzeige des Displays manipulieren lässt habe ich mir noch nicht überlegt, da der Enable Eingang des Displays nicht nach Außen geführt wird.

Projektarbeit ASURO

Der ASURO war zentraler Bestandteil der letzten Projektarbeit. Das Ergebnis ist eine Betrachtung der Hardware und eine Umsetzung in Software.

Zusammenfassung
In dieser Studienarbeit wurde die Firmware des ASURO Roboters erweitert. Ziel war es, die Sensorwerte der sechs Sensoren zyklisch abzufragen, um die Werte für den Programmierer direkt zur Verfügung zu stellen. Der Controller des ASUROs besitzt einen AD-Wandler mit sechs Messkanälen, deren Aktivierung in der Software koordiniert und deren Messwerte in die realen Werte umgerechnet werden.

Bei den Sensoren handelt es sich um Reflexionslichtschranken, optoelektronische Sensoren, Taster und Batteriespannung. Von den Reflexionslichtschranken kann auf die Umdrehungen der Räder geschlossen werden; von den optoelektronischen Sensoren kann auf die Helligkeit des Untergrunds geschlossen werden. Die Taster dienen zur Kollisionsabfrage an der Roboterstirnseite und die Batteriespannung dient zur Überwachung der Stromversorgung.

Die Abfrage der Sensoren wurde durch zyklische Auswahl der Messkanäle innerhalb der AD-Wandler Interrupt Service Routine realisiert. Die Werte werden in einem öffentlichen struct dem Rest der Roboter Software zur Verfügung gestellt.

Zusätzlich beschreibt diese Arbeit noch die Verwendung der Softwaresimulation in Atmel Studio und eine Methode für Unittests mit AVR Mikrocontrollern.

Unit Tests für Mikrocontroller [Installation und Konfiguration für AVR]

Unit Tests sind im PC Bereich mittlerweile Standard. Allerdings ist es schwierig sie auch für Software im Bereich der Mikrocontroller zu verwenden. Die wenigen Ressourcen, die der Mikrocontroller zur Verfügung stellt sollten idealerweise für die Software verwendet werden, die später dann auf dem System laufen soll, denn alles andere wäre Geldverschwendung. Es gibt dennoch die Bemühungen mit so wenig Wasserkopf wie möglich Unit Tests auch auf Mikrocontrollern zu implementieren.
Ich habe das in meinen Projekten bisher so gelöst, dass ich zusätzlich zum normalen Programmcode Testfunktionen implementiert habe. Alles was nur zu Testzwecken im Code eingefügt wurde habe ich mit Präprozessor-Anweisungen eingekapselt, sodass sie bei einem Release Built nicht beachtet wurden. Dadurch habe ich während der Entwicklungszeit die Testfunktionen zur Verfügung und später im ‚fertigen‘ Projekt wurden die Testfunktionen nicht mehr übersetzt. Das führte neben kleinerem Programmcode auch zu schnellerer Abarbeitung von z.B. Interrupt Service Funktionen im fertigen Projekt. In dieser Artikelserie werde ich die Verwendung von µCUnit anhand des ASURO Projekts erklären.
Das µCUnit Framework liegt als Open Source Projekt auf GitHub und kann von dort als zip-Archiv heruntergeladen werden. Die verschiedenen Beispielprojekte für i386, avr und arm zeigen, wie das Framework verwendet werden kann.
Da jeder Mikrocontroller und jedes Projekt unterschiedlich sein kann, muss das Framework mit Macros angepasst werden. So muss zum Beispiel die Text Ausgabe so implementiert werden, dass Textzeichen über die Serielle Schnittstelle, Netzwerk, oder Dateien ausgegeben werden können. Sollte auf der Projektplattform die printf() Funktion zur Verfügung stehen, kann sie verwendet werden, aber gerade bei kleinen Controllern ist selten genügend Platz um diese Funktionen mit in dem Programmcode aufzunehmen. Es wird zusätzlich noch eine Funktion benötigt, um das System in einen sicheren Zustand zu setzten und es komplett herunter zu fahren. Jeder Ausgangspin der Hardware sollte in einen sicheren Zustand gesetzt werden, um zum Beispiel hohe Ströme durch den Controller zu verhindern. Die Beispieldateien System.c und System.h enthalten Code, der diese Funktionen beschreibt.

Die System.c für den AVR zeigt welche Funktionen vom Framework erwartet werden. Vor allem die Abwesenheit der printf() Funktion muss behoben werden. Da der ASURO schon eine schlanke Funktion zum Ausgeben von Zeichen besitzt, muss hier nur die Funktion zum Schreiben von Strings implementiert werden:

void System_WriteString(char * s) {
while(*s)
{
UARTbyte(*s);
s++;
}
}

Alle weitern Funktionen habe ich direkt aus der Beispieldatei übernommen.

Nachdem die Funktion implementiert ist, könne wir mit dem Aufbau eines Testcases beginnen. Dazu können wir uns an der mitgelieferten Testsuit.c orientieren. Eine Test Suite ist aufgebaut aus dem Haupt Test und den einzelnen Testcases. Der Haupttest initialisiert den Prozessor und führt die einzelnen Tests durch.
Hier wird auch die int main(void) implementiert; die Funktion, die als Hauptfunktion aufgerufen wird.
Das Beispiel zeigt und diese Funktion

int main(void)
{
UCUNIT_Init();
// [...]
Testsuite_RunTests();
UCUNIT_WriteSummary();
UCUNIT_Shutdown();

return 0;
}

Die Funktionen UCUINT_Init() und UCUNIT_Shutdown() sind in der System.c schon implementiert und tun zur Zeit nichts. Die Funktion Testsuite_RunTests() ruft die einzelnen Tests auf:

void Testsuite_RunTests(void)
{
Test_BasicChecksDemo();
Test_PointersDemo();
Test_ChecklistDemo();
Test_BitChecksDemo();
Test_CheckTracepointsDemo();
}

Es werden alle Tests in der Testsuite aufgerufen. Diese Herangehensweise erlaubt es die Tests einzelner Funktionesteile (Testcases) in verschiedene Hauptkategorien (Testsuits) zu unterteilen. Somit erhält man leichter einen Überblick über die einzelnen Funktionstests.
Schauen wir uns zunächst die einzelnen Testcases an. Der BasicCheckDemo() Test führt ein paar grundlegende arithmetische Operationen aus. Alle diese Tests sollten bestanden werden. Zu Beginn eines jeden Testcases werde die darin verwendeten Variablen deklaiert und eventuell initaialisiert. Der nächste Schritt ist den Testcases zu beginnen, mit Hilfe der Funktion

UCUNIT_TestcaseBegin("Name des Testcases");

Danach kommt dann eine eventuelle Generierung von Testdaten oder sonstige Funktionalität. Danach werden die Ergebnisse der Funktionen evaluiert. Hier sieht man die Verwendung der CheckIsEqual Funktion, die wie ihr Name schon sagt, zwei Werte miteinander vergleicht. Am Ende jedes Testcases wird die Funktion

UCUNIT_TestcaseEnd();

aufgerufen um den Testcase zu beenden und das Ergebnis zu speichern.
Weiter Testfunktionen werden in den anderen Testcases vorgestellt. Ich möchte an dieser Stelle noch einmal auf die Evaluierungsfunktion CheckIsBitSet eingehen, da hier direkt die Ausgangspins des Controllers getestet werden können.

PORTB = (PB1 << 1); 
UCUNIT_CheckIsBitSet(PORTB, 1); /* Pass */

Im der Nächstem Artikel betrachten wir dann die einzelnen Funktionen des ASURO und wie wir eine Testsuite für die einzelnen Hauptgruppen und Testcases für alle Unterfunktionen entwickeln.

[WIP] ASURO mit korruptem Speicher?

Seit letztem mal schlägt das Programmieren des Mikrocontrollers auf dem ASURO bei Page 39 fehl. Die Page liefert beim Auslesen eines zuvor hineingeschriebenen Wertes einen anderen Wert zurück. Die Folge davon ist, dass ein Programm, welches mit dem Bootloader auf den Chip kopiert wird nicht korrekt übertragen wird. Nach einigen Versuchen und etwas googeln habe ich versucht eine andere Programmdatei zu übertragene und das hat ohne Probleme funktioniert. Der ASURO hat also Probleme beim Übertragen von Programmdaten, wenn diese eine Bestimmte Zeichenkette beinhalten. genauer gesagt, viele 0x00 Bytes hintereinander. Zum Glück funktioniert der Chip mit kleinen Änderungen im Quelltext wieder problemlos. Als nächstes werde ich mir die Eingangssignale der IR-Transistoren anschauen und die Signale des ADC auswerten um die Raddrehungen zählen zu können.

Nachtrag: Der Fehler mit den korrupten Pages ist wieder aufgetreten und sogar unabhängig vom verwendeten Chip und der Page. Ein Programm mit 40 Pages bricht bei Page 39 ab, eins mit 12 bei Page 11. Es ist zum Haare raufen.