Softcore CPU NEO430 mit GHDL simulieren

Für meine Masterarbeit beschäftige ich mich gerade mit Softcore-Prozessoren auf FPGAs. Dabei kommt für meine Arbeit der NEO430 zum Einsatz, ein sehr kleiner aber feiner Prozessor der an meinem Institut entwickelt wurde (von Stephan Nolting). Da ich aktuell noch nicht in einem Stadium bin, wo ich den Prozessor wirklich auf einem FPGA implementiere (auch wenn das der nächste Schritt ist) arbeite ich aktuell sehr viel mit Simulation, und da vor allem mit ModelSim. Ein bisschen was dazu hatte ich ja hier im Blog schon mal da zu geschrieben.

Nun hatte ich heute Abend die Idee, man könnte ja mal einen anderen Simulator ausprobieren. Mir hat es dabei GHDL angetan, vor allem, da er OpenSource ist, aber auch weil er einen interessanten Ansatz verfolgt: Der VHDL-Code wird mit einem umgebauten Compiler (GCC oder LLVM) direkt in Maschinencode kompiliert, und dieser Code dann ausgeführt. Dadurch soll der Simulator extrem schnell sein. Auf Windows ist das ganze etwas eingeschränkt, hier wird ein interner Codegenerator verwendet. Weiterlesen

Netze in Eagle in Schaltplan und Board verbinden

Zwei kleine Tipps zum Platinenentwurf mit EAGLE, die zwar irgendwie das gleiche Thema haben, eigentlich aber nichts miteinander zu haben 🙂

Signale im Schaltplan kreuzungsfrei verbinden

Stellen wir uns vor, wir haben die unglaubliche Schaltung aus vier Widerständen, die auf genau diese Weise verbunden werden müssen:

Mal abgesehen davon, dass man das Problem hier natürlich leicht durch Umpositionieren der  Widerstände lösen könnte, ist das doch ein häufiges Problem: Leitungen kreuzen sich nun mal. Das dabei ein Hakenkreuz entsteht ist nur eines der Probleme… Weiterlesen

Schöne Debugausgaben mit VHDL

Aktuell arbeite ich fleißig an meiner Masterabeit (einer der Gründe, warum es hier auf dem Blog so still ist…), und entwickele dafür auch ein paar Sachen in VHDL (ich entwickele also Hardware 🙂 ). Am Ende soll das ganze natürlich auf einem FPGA laufen (vielleicht sogar mal in einem echtem Chip, einem ASIC!), aber aktuell wird das ganze nur simuliert. Das ist zwar ziemlich langsam (aktuell etwa um den Faktor 1000), aber dafür kann man sich jedes Signal in seiner Schaltung ganz genau ansehen und bei Bedarf auch Debug-Ausgaben tätigen. Besonders das hat sich aktuell als sehr hilfreich dargestellt.

VHDL unterstützt das im Prinzip mit assert und report, allerdings finde ich die Ausgaben recht unübersichtlich, vor allem weil sie über mehr als eine Zeile gehen. Zudem ist alles einfarbig, so dass man schnell die Übersicht verliert. Ich habe mir als etwas überlegt, was etwas schöner aussieht (siehe Screenshot)

Weiterlesen

Einfache Sättigungsarithmetik in VHDL

Für ein Projekt an der Uni habe ich mit zwei Kommilitonen ein Malprogram („FPGArt“) auf einem FPGA implementiert. Dabei wird eine Maus per PS/2-Schnittstelle angebunden und das Bild schließlich per VGA ausgegeben. Zu dem Projekt selber später vielleicht mehr, hier jetzt nur ein kleines VHDL-Snippet das man vielleicht man gebrauchen kann.

In dem Projekt wird regelmäßig die relative Bewegung der Maus abgefragt und zu dem alten Wert addiert. Natürlich hat das Bild eine begrenze Größe und der Mauszeiger muss in diesen Grenzen von 800×600 gehalten werden. Es wird also eine sog. Sättigungsarithmetik benötigt: Sollte das Ergebnis der Addition größer als 800 (bzw. 600) sein, oder kleiner als 0 wird es auf den Grenzwert gesetzt. Das ganze ist gar nicht so einfach in Hardware zu implementieren (zumindest ist uns nichts intelligentes eingefallen…).

In jedem Fall muss es ein Zwischenergebnis geben das ausreichend groß ist, um Überläufe überhaupt zu erkennen. Die Maus kann pro Intervall Maximal um 256 bewegt werden, entsprechend muss als ein Wert von 800+256 = 1056 gespeichert werden können. Mit 11 bit kommt man auf 2048, das reicht. Hiermit kann man auch Unterläufe erkennen: 0-256 = -256 was dann 1792 entspricht. Dieser Bereich überlappt auch nicht mit den 1056 nach oben. Es ist also immer einwandfrei erkennbar, dass ein Über/Unterlauf stattgefunden hat.

Weiterlesen

ftRoboExt: Software

Nach einiger Pause gibt es mal wieder etwas neues zu meinem selbstgebauten Erweiterungsmodul „ftRoboExt“. Hardware und Gehäuse waren ja schon fertig, nun fehlte eine finale Version der Software. Inzwischen ist das ganze Projekt übrigens auf GitHub zu finden.

Das Protokoll für die Kommunikation zwischen Interface und Extension ist recht einfach, es ist im Prinzip ein SPI-Bus mit einem zusätzlichen Bestätigungssignal und einer Adresse. Über drei Adressleitungen wählt das Interface aus, mit welcher Extension es sprechen möchte. Die originalen Extensions lassen sich verketten, dabei wird das Signal aber nicht ganz unverändert durchgeschleift, sondern die Adresse wird von jedem Modul um ein verringert. Auf diese Weise ist jedes Modul adressiert, wenn es Adresse 0 sieht (das erste direkt, das zweite weil es 1-1=0 sieht). Eine sehr intelligente Lösung, denn dadurch wird die Adresse des Moduls einfach durch die Verkabelung bestimmt.

Wenn das Modul die Adresse 0 sieht, zieht es EM-ACK (die Bestätigungsleitung) auf Low. Nun beginnt das Interface 6 Bytes zu senden, die Extension gibt nach jedem Byte einen kurzen High-Puls auf der EM-ACK Leitung aus. Die originale Extension scheint recht langsam zu sein, so braucht sie etwa 700µs um die Adressierung zu bestätigen. Das Interface hat aber scheinbar auch kein Problem damit, wenn man schneller ist. Die 6 Bytes übertragenen Bytes enthalten die Nutzdaten, genaueres bei thkais.

Weiterlesen

ftRoboExt: Gehäuse

Nachdem Hardware und Software mehr oder weniger fertig sind, kam jetzt das Gehäuse an die Reihe. Der Plan stand ja schon seit der anfänglichen Planung: Das Modul sollte in eine 60er Kassette. Die Kassette stand auch schon seit dem Baubeginn hier bereit, jetzt mussten noch die Löcher in den Deckel 🙂

Dabei gab es zwei Probleme: Zum einen ist der Deckel aus Acrylglas, bei dem ich mir nicht ganz sicher war, wie gut man das bohren kann, zum anderen sind die Bundhülsen nicht ganz gerade eingelötet, so dass sich nicht wirklich ein Raster ergibt, sondern alle Löscher ein bisschen versetzt sind. Um das Problem zu lösen habe ich einfach den Deckel auf die Hülsen gelegt und dann angezeichnet, aber es war doch recht schwierig, die Markierungen auf dem Glas zu sehen, zum die Bohrmaschine leider nicht gerade an der bestbeleuchteten Ecke unserer Werkstatt steht…

Das Bohren selber war viel einfacher als gedacht. Wichtig ist nur, sehr langsam vorzugehen, und nicht zu stark zu drücken, ansonsten reißt das Glas, was mir auch ein paar Mal passiert ist. Zum Glück sind es aber nur kleine Stellen. Ich hatte befürchtet, dass die Löcher nach unten ausfransen würden, und daher das Glas von oben gebohrt. Das war insofern unpraktisch, als ich das Glas so nicht komplett auf die Unterlage auflegen konnte, weil der Deckel ja noch kleine Ecken zum festklemmen hat. Dadurch, dass der Deckel ein bisschen in der Luft hin, wurde das Problem mit dem Reißen vermutlich noch deutlich verstärkt. Ausgefranst sind die Löcher überhaupt nicht, ich hätte also auch von unten bohren können. Wieder was gelernt 😉

Weiterlesen

ftRoboExt: Fortschritt

Ja, die kleinen Fehler sind immer die gemeinsten. Das war ungefähr das Motto der letzten Runde Entwicklung an meinem ftRoboExt.

Wie üblich bei solchen gemeinen Problemen war der Fehler schwer einzugrenzen, ab und zu funktionierte die SPI-Verbindung zum Robo Interface ohne Probleme, in den meisten Fällen tat mein Controller aber gar nichts. Es lag natürlich an eigener Blödheit, ich hatte das Datenblatt nicht richtig gelesen, dort steht es im Abschnitt 19.3.1

When the SPI is configured as a Slave, the Slave Select (SS) pin is always input. When SS is held low, the SPI is activated, and MISO becomes an output if configured so by the user. All other pins are inputs. When SS is driven high, all pins are inputs, and the SPI is passive, which means that it will not receive incoming data. Note that the SPI logic will be reset once the SS pin is driven high.

Weiterlesen

ftRoboExt: Entwurf

…und am Anfang war der Entwurf. Ein eigenes Erweiterungsmodul für das Robo Interface soll es also werden. (Siehe hier für mehr Infos)

Grundlage sollte natürlich ein AVR sein, weil ich die am Besten kenne, und man dann auch immer gleich die Arduino Bibliotheken mitbenutzen kann 😉 Das Protokoll ist im Wesentlichen ein SPI Bus mit einer speziellen Bestätigungsleitung, das sollte sich also auch problemlos umsetzen lassen. Da die Schnittstelle mit 3,3V betrieben wird sollte auch das gesamte Modul mit dieser Spannung laufen. Die Motoren müssen aber natürlich mit 9V betrieben werden, so dass ein Spannungsregler nötig ist. Für die Motoren sind auch Treiber nötig, da habe ich den TLE4207 eingesetzt, mit dem anderen schon gute Erfahrungen gemacht haben.

2016-03-13 21_10_03-1 Board - C__Users_Niklas_Documents_eagle_ftRoboExt_ftRoboExt.brd - EAGLE 7.5.0Die nächste spannende Frage: In was für ein Gehäuse soll das Modul eingebaut werden? Ein Gehäuse wollte ich auf jeden Fall haben, einfach damit sich das ganze gut im Modell unterbringen lässt. Nach ein wenig Suche bin ich auf die Kassetten gestoßen, die gerade dazu einladen, Dinge dort hineinzubauen. Mit 60x60mm Grundfläche ist dort aber natürlich nicht viel Platz drin, die originalen Module haben etwa die doppelte Fläche. Nach ein wenig Überlegung kam ich dann zu dem Schluss, das gesamte Modul in SMD-Technik zu bauen, auf diese Weise kann ich die Platine zweiseitig bestücken; anders ist es kaum möglich, alles in der kleinen Box unter zu bringen.

Weiterlesen

fischertechnik Hochregallager und eine Robo Extension im Eigenbau

Vor inzwischen doch schon einiger Zeit hatte ich bei einem Besuch der Hannover ein Modell aus fischertechnik gesehen, was dort mit einer SPS gesteuert wurde. Irgendwie hat das mein Interesse an fischertechnik wieder geweckt (nachdem ich sie ja vor einiger Zeit schon mal wieder rausgekramt hatte). Geplant war ein Hochregallager, ein scheinbar ziemlich beliebtes Modell.

Nach ein wenig Gebastel war dann auch eine erste Version fertig (mit tatkräftiger Unterstützung ;)), die im Grunde auch funktionierte. Aber ich wollte mehr 👿 Äh naja, ich wollte jedenfalls gerne noch eine Version bauen, bei der sich der Hauptarm drehen konnte, und ich wollte auch gerne einen Greifer der sich öffnen und schließen konnte, statt nur von unten unter die Objekte zu fahren und sie anzuheben (ich habe leider keine Fotos von der alten Version gemacht). Da zu der Zeit Knobloch, der Einzelteilhändler gerade einen Abverkauf hatte, habe ich mich dort noch mal mit Teilen eingedeckt, speziell den Teilen für einen Greifer.

Weiterlesen