Alle Beiträge von chef

Propeller – Composit Video Ausgang

Es kommt einfach kein Signal aus dem Composit Video Ausgang.

An den Ports P12,P13,P14 und P15 hängen Widerstände mit 1,1 kOhm, 560 Ohm, 270 Ohm und 560 Ohm. Auf der andere Seite der Widerstände werden alle zusammen geschlossen und bilden das Video Signal. Mit dem Oszilloskop habe ich dort gemessen, nachdem ich den Videotreiber mit tv.start(12) gestartet habe. Es kommt null Komma nichts an Signalen heraus.

Allerdings funktionieren die Ports. Wenn ich sie per Hand auf 1 oder 0 schalte reagiert der Videoausgang entsprechend mit einer Spannung. Da ich mir nun keinen Rat mehr wusste habe ich mal im Propeller Forum angefragt. Mal sehen ob jemand eine Idee hat.

propeller_cvbs_ausgang

Propeller Chip – LCD funktioniert wieder

Heute habe ich den RAM Befehl (zeigt Hauptspeicher Inhalt im Hexformat) stark umgeschrieben und verbessert. Wenn in der letzten Ausgabezeile nicht die vollen 16 Bytes ausgegeben wurden, so gab es keine Ausgabe der ASCII-Zeichen. Das habe ich nun beseitigt. Ferner habe ich einen Peek und Poke Befehl hinzugefügt. Der Poke Befehl schreibt ein Byte in das RAM und der Peek Befehl gibt es wieder aus.

Auf einem zweiten Cog habe ich eine Routine gestartet, die den Dezimalpunkt der 7-Segment Anzeige im Sekundentakt blinken lässt, damit man erkennt das der Propeller läuft. Diese Routine musste ich jedoch wieder deaktivieren weil die Ports 16-23 sowohl zur 7-Segment Anzeige als auch parallel zum LCD Display verbunden sind.

Als ich das LCD Display wieder ansprechen wollte funktionierte dies erst nicht wegen dem blinkenden Dezimalpunkt. Nach abschalten der Blink Routine ging alles glatt. Es gelang mir abermals das Wort “Hallo” auf dem LCD Display auszugeben. Abermals deshalb weil mir die alten Programme zur LCD Ansteuerung verloren gegangen waren.

propeller_lcdfunktioniert

Propeller Chip – RAM Monitor funktioniert

Von morgens früh bis jetzt 14:40 habe ich am RAM Befehl gearbeitet, der einfach einen Bereich des Propeller Hauptspeichers, hexadezimal und in ASCII Form auf einem Terminal ausgibt. Man gibt einfach ‘ram’ + ENTER ein, danach fragt der Rechner von selber nach der Startadresse. Dann drückt man wieder ENTER und er fordert zur Eingabe der Endadresse auf. Nach nochmaligem drücken von ENTER geht’s los. Die Ausgabe kann mit der SPACE Taste pausiert/fortgesetzt werden und mit ESC jederzeit abgebrochen werden.

propeller_gif_ram_funktioniert

Propeller Chip Locks – Grundlagen

Wenn zwei Cog’s auf den gleichen Speicherbereich zugreifen verhindert der Propeller eigenständig Kollisionen wenn es sich nur um einzelne Byte, Wort oder Langwort Zugriffe handelt. Diese Zugriffe eines Cog’s werden erst abgearbeitet bevor der nächste Cog Zugriff bekommt.

Wenn ein Cog jedoch in einer Schleife einen Block von Daten schreibt und ein anderer Cog diesen Datenblock zugleich liest, kann der Propeller nicht mehr sicherstellen, das alle Daten beim lesen zuvor komplett geschrieben wurden, da die HUB Rotation einfach weiter läuft.

  • Routinen die exclusiven Zugriff auf einen Hauptspeicherbereich benötigen benutzen den LOCKNEW Befehl der einen Wert zurückgibt (-1=ERROR ansonsten eine Lock-ID). Nur ein Cog sollte den LOCKNEW Befehl ausführen, dieser Cog sollte die Lock-ID auch an alle anderen Cog’s kommunizieren die diesen Speicherbereich benutzen
  • Jeder Cog der auf diesen Speicherbereich zugreifen will muss zuvor erfolgreich  die  Lock-ID sperren. Ein erfolgreiches Sperren wird durch den Rückgabewert FALSE des LOCKSET (Lock-ID) Befehls angezeigt. Falls LOCKSET TRUE zurückgibt beansprucht gerade ein anderer Cog den Speicherbereich. Der Cog muss warten bis ein LOCKSET Befehl erfolgreich ist
  • Der Cog der einen LOCKSET Befehl erfolgreich ausführt, kann den Speicherbereich nach belieben benutzen. Wenn dessen Bearbeitung fertig ist muss der Speicherbereich mittels LOCKCLR (Lock-ID) wieder freigegeben werden, damit andere Prozesse wieder auf den Speicherbereich zugreiffen können. In einem sauberen System kann der Rückgabewert von LOCKCLR ignoriert werden, solange der freigebende Cog der einzige mit der Berechtigung war, die Sperre aufzuheben.
  • Wenn ein Speicherbereich nicht länger benötigt wird sollte die darauf bezogene Sperre mittels LOCKRET (Lock-ID) wieder zurückgegeben werden. Normalerweise geschieht das durch den Cog der den LOCKNEW Befehl gegeben hat.

Zu beachten ist, daß der Haupspeicherzugriff nicht wirklich geblockt wird. Weder vom HUB oder dem Lock. Es liegt also an den einzelnen Prozessen die Regeln einzuhalten. Auch ordnet der HUB einen LOCKNEW Befehl nicht dem aufrufenden Cog zu. Jeder andere Cog kann Locks wieder freigeben.

Einplatinencomputer mit 6504 CPU

Hier noch ein von mir gebauter Einplatinencomputer mit der 6504 CPU. Die CPU ist kleiner, hat weniger PIN’s als die 6502 CPU und kann auch nur 8kByte Speicher adressieren. Die 6502 CPU kann 64kByte Speicher adressieren.

Bestückt ist das Board mit einem 2kByte 6116 SRAM Chip, einer 8255 PIO und der 6551 SIO mit nachgeschaltetem MAX 232 (leerer 16 pol. Sockel). Oben rechts sieht man ein zugeklebtes EPROM. Das EPROM diente hier als MMU (Memory Management Unit) um den knappen Adressbereich der 6504 besser ausnutzen zu können.

Bei meinen ersten Einplatinencomputern hatte ich immer einen 74LS138 Chip (Demultiplexer) benutzt um die CS (Chip Select) Signale aus den oberen drei Adressbits zu generieren.Das hat jedoch den Nachteil, das man den gesamten Adreßbereich der CPU in 8 gleichgroße Bereiche teilen muss. Der Adreßbereich einer 6502 ist 64kByte, geteilt durch 8 wären das Speicherblöcke von je 8kByte größe. Das ist geradezu verschwenderisch wenn man nur eine PIO oder SIO adressieren will, die gerade einmal zwei oder drei ansprechbare Register besitzen.

74hc138_2 74ls138

Also habe ich ein EPROM genommen, welches sehr viel mehr Adreßleitungen aufnehmen kann, und mit seinem 8-Bit Datenbus quasi eine programmierbare Speicherbereich Zuweisung  ermöglicht. Ich erinnere mich die oberen 8 Adressleitungen der CPU zur MMU geführt zu haben, das ermöglichte bei 64kByte eine Blockgröße von nur noch 256 Byte. Mit der Programmierung des EPROM habe ich ihm Einplatinencomputer mit 6504 CPU weiterlesen →

Propeller Oszillator – Grundlagen

System Takt

Die internen Funktionen des Propeller Chip werden von einem System Takt kontrolliert der bestimmt wie schnell der Propeller läuft und wie schnell die Ausführung von Programmen ist.

Es gibt vier Taktquellen von denen der System Takt abgeleitet werden kann

  • der interne langsame Oszillator (RCSLOW 20kHz)
  • der interne schnelle Oszillator (RCFAST 12MHz)
  • einem Quarz oder Schwingkreis
  • einem Frequenzgenerator

Benutzt man einen Quarz, Schwingkreis oder einen Frequenzgenerator kann zusätzlich ein PLL aktiviert werden, der den System Takt 16fach beschleunigt.

Der System Takt kann bis zu 80MHz betragen. Bis 100MHz läuft der Propeller unter normalen Bedingungen noch stabil. Höhere Frequenzen lassen den Propeller instabil werden.

RCSLOW

Wenn der Propeller Chip theoretisch mit 20kHz läuft, kann sich der Takt in Wirklichkeit zwischen 13kHz und 33kHz befinden (Hersteller Toleranzen).

Der Oszillator ist über kurze Zeitspannen recht stabil. Allerdings verschiebt sich die Taktfrequenz mit der Zeit. Das ist hauptsächlich abhängig von der Temperatur des Propeller Chip und dessen Versorgungsspannung.

Für einen präzisen und stabilen Systemtakt ist ein externer Quarz, Schwingkreis oder Frequenzgenerator unabdingbar.

RCFAST

Wenn der interne Oszillator mit 12MHz läuft sind es in der Realität zwischen 8MHz und 20MHz.

Der Propeller Chip benutzt den RCFAST Oszillator beim Bootvorgang und wenn er ein Programm von einem PC empfängt. Um die Takt Werkstoleranzen der Propeller Chips auszugleichen benutzt das Empfangsprotokoll einen Mechanismus der kein 100 Prozent genaues Timing benötigt.

Quarz oder Schwingkreis

Der Propeller unterstützt das direkte anschließen eines Quarz oder Schwingkreises mit Frequenzen von 0 bis 80MHz. Ist der interne PLL aktiviert muss die Frequenz des externen Taktgebers zwischen 4MHz und 10MHz liegen. Bei einem externen Frequenzgenerator werden keine Kondensatoren benötigt. Sein Ausgang wird einfach an den entsprechenden Propeller PIN angeschaltet.

Frequenzgenerator Modul

Der Propeller unterstützt das direkte anschalten eines Frequenzgenerators mit einer Frequenz von 0 bis 128MHz. Ist der interne PLL aktiviert muss der externe Takt zwischen 4MHz und 10MHz liegen.

PLL

Ist der interne PLL aktiviert kann er einen externen Takt bis zu einem Faktor von 16 beschleunigen. Der PLL Schaltkreis multipliziert den externen Takt immer 16fach und ein nachgeschalteter Teiler erzeugt den finalen Systemtakt. Der PLL erzeugt Frequenzen von 64MHz bis 160MHz. Das erfordert einen externen Takt zwischen 4MHz und 10MHz. Der höchste Systemtakt sollte 80MHz betragen. Das erfordert eine Teilung des Taktes hinter dem PLL die einen Takt von maximal 80MHz erzeugt.

Das bedeutet wenn der PLL aktiviert ist sollte der externe Takt nur in einem bestimmten Bereich liegen, maximal 10MHz. Wenn man einen Systemtakt von 80MHz benötigt, braucht man einen externen Takt von 5MHz (5*16/1) oder 10MHz (10*16/2).

In der Praxis kann der Systemtakt problemlos 96MHz (6MHz extern) erreichen. Die Firma Parallax berichtet das alle Propeller Chips einen Test mit 104MHz absolvieren müssen.

externe Frequenz PLL Teiler 2 PLL Teiler 1
4MHz 32MHz 64MHz
5MHz 40MHz 80MHz
6MHz 48MHz 96MHz
6.25MHz 50MHz 100MHz
6.5MHz 52MHz 104MHz
7.3728MHz 59MHz 118MHz
8MHz 64MHz verboten
10MHz 80MHz verboten
14.31818MHz 114.5MHz verboten

Propeller Interrupts – Grundlagen

Der Propeller Chip besitzt keine Interrupt Eingänge wie andere Microkontroller. Alle externen Ereignisse müssen wiederholt abgefragt werden oder es muss auf ein High oder Low an einem Port PIN gewartet werden. Für die Mehrkern Architektur des Propeller stellt das aber kein Problem dar. Man stellt einfach einen oder mehrere Cog’s zur Interrupt Verwaltung ab. Diese(r) wartet in einer Schleife bis die gewünschten Interrupt Ereignisse eintreten während in den anderen Cog’s weitere Programme unbeeinflusst ablaufen.

Bei mehreren Interrupts deren Timing unkritisch ist kann ein Cog mit einer zyklischen Abfrage auf mehrere Ereignisse reagieren. Kritische Interrupts können von einem einzelnen Cog binnen weniger Taktzyklen erfasst werden.

Ein Propeller Chip Programm läuft z.B. in einem Cog während andere Cog’s sich um Interrupts kümmern. Da alle Cog’s unabhängig arbeiten können mehrere Interrupts parallel bearbeitet werden. Das kann kein anderer Einkern Microcontroller, ausgenommen solche mit Hardware Interrupt Eingängen.

Da jeder Cog Hardware Zähler besitzt kann man auch kurze Signal Impulse erkennen. Das kann von einem Cog dazu verwendet werden um zyklisch Interrupt Eingänge abzufragen und ein eintreffendes Ereignis quasi nebenher zu bearbeiten.

Ein Cog der zyklisch mehrere Interrupt Eingänge abfragt kann eine eigene Interrupt Priorisierung durchführen. Durch diese zyklische mehrfach Abfrage ist es auch möglich Massnahmen einzuleiten, die auf dem Eintreffen mehrerer gleichzeitiger Interrupts basieren und nicht auf einem einzelnen Interrupt. Die Polarität der Interrupt Eingänge ist nur vom Programm abhängig und kann wenn erforderlich zur Laufzeit geändert werden.