Posts mit dem Label C werden angezeigt. Alle Posts anzeigen
Posts mit dem Label C werden angezeigt. Alle Posts anzeigen

Samstag, 5. August 2017

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.

Mittwoch, 18. November 2015

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.

Sonntag, 1. Februar 2015

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.

Mittwoch, 15. Januar 2014

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.

Mittwoch, 8. Januar 2014

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.

Samstag, 30. November 2013

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.

Donnerstag, 21. November 2013

[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.