• 2013-06-14: sepi/fpletz hacken an https://github.com/muccc/netfbd
  • Ziel: Streaming eines (virtuellen) Framebuffers

Wir haben eine Flipdotmatrix.

• 198 schwarze und 4 blaue Module
  • 4 der schwarzen Module sind noch den Ingolstädtern designated!
  • 1 x Schwarz bei Karsten (SR-Student von lila)
  • 4 (oder 6?) x Schwarz bei Flop
  • 2 x Hannover, McFly, schwarz
  • 2 x Hamburg, McFly, schwarz
  • 1 × datenwolf, schwarz

Um dem Chaos ausnahmsweise entgegen- und nicht zu-zuwirken legen wir hier feste Worte für die einfachere Kommunikation fest!

• Modul (Panel) == 1 Object voll mit Dots; besteht aus: Dot-Matrix mit 16 Zeilen und 20 Spalten. Hat hinten noch die Treiberplatine dran.
• Treiberplatine == nimmt seriell Daten entgegen und gibt dieses Parallel auf die Dot-Matrix eines Moduls.
• Zeile == horizontal aggregierte Ansammlung von Dots, typischerweise 20 Dots
• Spalte == vertikal aggregierte Ansammlung von Dots, typischerweise 16 Dots
• Der Ursprung ist oben links und mit X0Y0 beschriftet

ACHTUNG: Eventuell ist im Rest der Wikiseite alles vertauscht. Das sollte später gefixt werden!

• 10 8-Stufe Schieberegister (80 bit) 74HC_HCT4094
  • Aufgeteilt in row + column register
• Normalbetrieb am orginal-'Tafelrechner': 23V (24V?!), 0.2A → 0.5 Watt
• Einmal komplettes Durchschieben: 1.6A fuer ca. 2 Sekunden → 74 Joule, 37 Watt
  • : Wo kommt die Zahl her, gilt das für ein Modul, also eine Steuerplatine?

Thx an x5444 von den Ingolstädern für das PIN-Layout!

Das row register ist 24px lang. (effektiv werden beim chainen noch 4px fnord mitgeschickt)
Das col register is 16px lang.

?1 == durchverbunden, kann man wohl am abschluss für nen rückkanal nutzen, so dass man die anzahl der segmente zählen kann
DO == Ausgang des zweiten nichtinvertierten Schieberegisters für die Spalten auf der input Seite bei Kaskadierung von Modulen
?2 == ind ein wenig komisch, die sind jeweils ein bestimmter pegel (hab ich grad nicht im kopf) sobald an einer der steuerplatinen in der kette die matrix die tatsächliche display-einheit verbunden ist

Das Fenster ist ca. 210x215cm, die es zu füllen gilt. Damit braucht es dann 7×9, also63 Panele.

Man nimmt ein kleines FPGA, und etwas RAM(z.B. im FPGA enthalten) und hat einen Prozess,
der die Daten zu den Schieberegistern schreibt. Der Pin9 sollte zum Prueflesen benutzt werden.
Nun teilen wir den RAM in 2 Bildschirmspeicher ein:
Einer der Speicher wird angezeigt, und der andere kann geladen werden.
Ein Toggle-Bit im config-Register des FPGA schaltet zwischen Bildschirmspeicher und Vorbereitungs-
Speicher um. Bei Flankenwechsel des Speicherschalt-Bits wird der Update-Prozess ausgeloest.

Insgesamt kann man das Verhalten wie bei den grafikfaehigen Industrie-Displays LCD gestalten, sodass
man vorhandene Linux-Treiber fuer den Druckerport nutzen und anpassen kann.

Von der Ansteuerungsseite aus wird man z.B. 2 Addressen sehen, mit 8bit breiten Daten.
Addresse0 ist das Daten-Transferregister.
Adresse 1 ist config register:

Beschreibung:

Wenn error-flag gesetzt, bringt ein read vom
dataport den errorcode
wenn error-flag nicht gesetzt, bringt read vom
data port, den zuletzt mit addresse selektierten
ram_inhalt.

Man kann im Config-Register 2 Register unterbringen,
wenn Register nur lesbar oder nur schreibbar sind, wird
je nach richtung das Register selektiert.

Also haben wir eine Address-Select-Leitung
und eine 8-bit-Datenleitung fuer den hackerport

Bedeutung der Kommandos:
Config-Register:
Bit0 invert: invertiert den bildschirmspeicher. Zusammen mit Redraw zum Blinken und Oelverteilen /W 1=Invert
BIT1 redraw: Schiebt den Bildschirmspeicher raus bei jedem uebergang 0→1
BIT2 speed: 0=slow, 1=fast, Speed fuer schieberegister /W
BIT3 error_flag (irgend ein error ist da) /R error_clear /W
BIT4 ADDRESS_STROBE fuer Addresse_Highbyte wird aus Inhalt, der im Register an Addresse 0 liegt, gesetzt
BIT5 ADDRESS_STROBE fuer Communikations-Register an Addresse0 → Addresse_Lowbyte wird aus Inhalt, der im Register an Addresse 0 liegt, gesetzt
BIT6 DATA_STROBE fuer Communikations-Register an Addresse0 → Daten werden in zuvor selektierte Addresse
BIT7 TOGGLE_FRAMEBUFFER →1=Higher Buffer wird angezeigt, lower kann gefuellt, gelesen werden. /W
Redraw: entweder 3xToggeln Bit 7 oder Bit1 toggeln,
je nach Erfahrungen mit dem Schieberegisterkram.
Wir koennen auch den Redraw unabhaengig vom Buffer-Select BIT7
machen, sodass man mit Bufferselect ein Redraw befehlen muss, wenn man rausschreiben will.
So koennte man evtl. auch den Aktuellen Puffer manipulieren, um einen Blink-Cursor zu machen.
Intelligente Ansteuerung nach “Was hat sich geaendert” werden die Schieberigister nicht koennen oder?
Wenn ja koennte man die Elemente einzeln an das FPGA machen und so z.B. auch nur das sich geaenderte
Element updaten. I/Os haben FPGAs genug

Rambedarf ist Pixelzahl zweimal
Mein Vorschlag waere ein kleines automotive-fpga von actel.
Als Bildspeicher:
Wenn ichs richtig hab:
20*16*11*18
63360BIT*2
rund 128Kbit, also 16KBYTE RAM, ein paar Addressleitungen und 8 bit datenleitung zum
FPGA und fertig. Wird auf nen 1-Lager passen.
Als RAM ein altes CAcHE-SRAM vom 586er oder 486er Mainboard, denn SRAM ist zahm in der Ansteuerung,
kein Refresh und so zeugs. Address/Datenbus, r/W, da wars schon.

Asynchrones Reset und Clock versteht sich fuer das ganze Design von selbst.

Takt mit beliebigem Quarz z.B. 14.xxx MHZ aus Bastelkiste/ISACLK aus altem Mainboard.

Wegen altem Mainboard, frueher TM war IDE nur ein per Puffer und Addressdekoder rausgefuehrter ISA-BUS!
Und das Zeugs ist aufwaertskompatibel. Man koennte das FPGA-Ding als “Festplatte” an den IDE/ISA-Bus haengen,
denn IDE wird aehnlich addressiert:-)
ich waere dafuer, dass man die beiden 8-bit Register (Config und Data) zusaetzlich ueber SPI zugreifbar macht,
einen SPI-Core von opencores.org nimmt, und so das Teil an irgendeinen OpenWRT-Router drandengeln kann,
und so ein web-interface hat, wo man SW-BMPs hochladen kann.

Ob man jetzt per Parallel-Port oder SPI drauf geht ist egal. SPI waere aber schon cool wegen Router-Recycling.
Hab mal fuer ein MIL-Projekt SPI per LVDS angesteuert, ist sicher fuer einige Meter ok.
Vorteil der FPGA-Loesung ist, dass das SW-Timing voellig egal ist, denn das FPGA kuemmert sich um das Geschiebe und das Timing
Theoretisch koennte man durch das Prueflesen des Schieberegisters bis zur Geschwindigkeitsgrenze der HW gehen.
Ich wuerde aber sagen, dass 2MHZ schiebe-Clock genug sind. Wir nehmen z.B. besagten 14MHZ-Quarz oder sonst was ab 10MHZ,
und teilen uns den Clock wie wir ihn brauchen. Evtl, im Configregister noch ein Flag fuer FAST/slow shift haben
(z.B. 2MHZ vs 500kHz)

• uC: ATMEGA162 (~3-5€ für 100, 1 Stück)
• ethernet: ENC28J60 (~3€ ab 1 Stück)
• ethernet buchse mit magnetics: ~2€ / Stück
• Step-down converter LM2675-3.3: 2€ / 100 Stück oder 4€ einzeln
• total/board min 11€
• total: 200*11€ = 2200€

Da noch platinen hergestellt werden müssten und ethernetkabel

Jedes Modul bekommt einen Modulcontroller. Er ist mit einem AVR mit SPI bestückt. Desweiteren hat er einen ENC28J60 SPI Ethernet controller an Bord. Zusätzlich braucht die Platine noch diverse Widerstände, Kondensatoren, zwei Quarze, zwei Linearspannungsregeler, zwei Quarze und eine RJ45-Buchse mit Magnetics. Als Treiber für den Ethernet-MAC kommt https://code.google.com/p/enc28j60-avr/ zum Einsatz. Ein Modulkontroller sollte nicht mehr als 10€ kosten (Könnte schwierig werden).

Alle Module werden über eien Hub mit einem Raspberry PI oder anderem Linux Rechner verbunden. Auf dem Raspi läuft ein eigener Framebuffertreiber, der über Ethernet mit den Modulen spricht. Mehrere Framebuffer können konfiguriert werden und somit mehrere logische Flipdotanzeigen separat treiben. Multicast/Broadcast wäre auch möglich. Die MAC-Adressen der Module werden aus der Geometrie & einer Startadresse berechnet. Die Geometrie kann man bestimmt über Parameter bei der Framebufferinitialisierung konfigurieren.

Module bekommen ein ganzes Bild (16*20 = 320 Pixel ~ 40Byte) pro Ethernet frame übertragen. Man könnte auch eine Art Diff übertragen um höhere Framerates zu erlauben.

Framebuffer hat den Vorteil dass man sehr viel Inhalt dafür hat: Mplayer, X11, eigenes Zeug, Konsole, SDL, etc. Ethernet ist gut weil die Verkabelung einfach ist, weil man Switches benutzen kann, weil die Ansteuerung einfach ist, evenutell später auf UDP/IP umsteigen kann, es multicast und broadcast kann, es grosse Reichweiten hat, zuverlässig ist, einfach zu debuggen ist, standard ist.
AVR hat den Vorteil einer guten freien Toolchain, relative niedrigen Preises, genügender Performance.

• Atmega core 4MHz@3V = 5mA
• I/O Pin = max 40mA
• ENC28J60 TX = 180mA
• Total ~ 500mA

Also wären 1A@3.3V ganz nett