SMD's / LED's "Feuerwehr im Einsatz" Hinweisschild für Kfz mit 12V Anschluss

[DG3YCS]

So, hier mal noch zwei Fotos von meinem Testaufbau.
(Ich habe ja schon welche gepostet)

Darauf erkennt man dann auch, warum ein Nachbau OHNE proffessionell gefertige Platine nicht in Frage kommt. Meine Platine ist DREISCHICHTIG, die kleine Platine daneben ist die eigendliche Steuerung. Im Testaufbau extern angeschlossen um verschiedene Varianten testen zu können!

Mal von den mechanischen Abmessungen ganz abgesehen...!

Das Video zeigt die verschiedenen fest einprogrammierten Schriftzüge.
Diese werden mit den DIP-Schaltern auf der kleinen Steuerung umgescahltet.
In der endgültigen Version wird das aber wohl über einfache Lötbrücken geschehen.
Denn das soll ja nicht laufend geändert werden!

Die Ausleuchtung ist nicht ganz ideal. Das kommt aber durch den geringen Abstand zum Schild. Ab ca. 1m Abstand erscheint die Ausleuchtung gleichmäßig!

Hier der Link zum Video:
http://www.files.to/get/181614/wsxi1sweg3

Achtung: Es sind einige MB´s (ca. 50!)

Gruß
Carsten

[Shinzon]

Moin..

Ich habe im computer nun eine Variante für 5x7 Matrix, in Gruppen zu 4 Stück, beliebig anreihbar,
also man nimmt 4x 5x7, 8x 5x7 .... 128x 5x7 .. naja, man kann übertreiben.

Texte werden in EEPROM gespeichert, sind je nach Wunsch per RS232, LAN oder WLAN
programmierbar, über dasselbe Interface oder ein immer vorhandener Up/Down/Select Drehtaster
auszuwählen. Es wird kein Schriftsatz mit fester Breite verwendet, 8 "Stellen" ergeben als nicht
unbedingt nur 8 Zeichen.

Je einseitiger, selbstgeätzter Platine kommen etwa 45 EUR Kosten auf den Interessenten zu.
Die Platinen sind identisch, aber werden entweder mit CPU/EEPROM bestückt oder wenn sie
zur Anreihung verwendet werden, ohne CPU/EEPROM.

Platinengrösse pro 4x 5x7 ist 305x70 mm .. Zeichengrösse ist 53mm ..

Mehr als der Entwurf im Computer existieren noch nicht, da mir im Moment das Geld zum
Prototypenbau fehlt. Es werden bis auf CPU-Sockel und EEPROM-Sockel (und LEDs) nur
SMD-Bauteile verwendet. Baupläne kann ich bei Interesse mal online stellen, Software dafür
ist noch nicht wirklich fertig, ist aber ne einfache Sache, da man ja nur mit ner Grafikdisplay-
Tabelle arbeiten muss .. krieg ich sicher aus vorhandenen Teilen schnell zusammengeklickt..

So long, muss nu pennen ;)
Tim

[Freakmaster]

@Carsten: Respekt! Ich muss schon sagen nicht schlecht für ein "Wenn ich nicht schlafen kann Projekt".

Ich bin dabei wenn bestellt wird :)

[DG3YCS]

@Carsten: Respekt! Ich muss schon sagen nicht schlecht für ein "Wenn ich nicht schlafen kann Projekt".

Ich bin dabei wenn bestellt wird :)

Hi,

Naja, zum Schluss war das eher ein: "Deshalb kann ich nicht schlafen" Projekt ;-)
Wenn dann noch die einen oder anderen kleinen Probleme auftauchten, die man unbedingt lösen wollte...
Aber nun läuft es ja. die FW ist sowiet erst einmal fertig. Sobald morgen die anderen Quarze ankommen werde ich mal schauen wie schnell ich das ganze bekomme. (Multiplexfreqeunz).
Und wie sich das ganze EMV Technisch dann verhält!
Dementsprechend wird dann das Timing in der Firmware noch verändert, das war es aber dann auch ersteinmal.

Allerdings schreibe ich gerade an einer anderen Firmware für einen anderen Zweck:
Mit Tonfolgeauswerter und Anzeige. Evtl. kommt später auch noch POCSAG oder FMS-Text.
Aber das sind dann auch wieder: "Wenn ich mal Lust habe" geschichten.
Laufen soll es aber auf dem selben Board. Werde das beim Design mit einplanen...
(Verursacht ja NULL extrakosten)

Im Moment bin ich gerade dabei die PSW auf C++ zu portieren um daraus eine Windoof Anwendung zu machen. (Au man, ist mein C eingerostet... ;-) )

@Shinzon
Hi Tim,

kleine Manöverkritik:

Moin..

Ich habe im computer nun eine Variante für 5x7 Matrix, in Gruppen zu 4 Stück, beliebig anreihbar,
also man nimmt 4x 5x7, 8x 5x7 .... 128x 5x7 .. naja, man kann übertreiben.
(...)
Die Platinen sind identisch, aber werden entweder mit CPU/EEPROM bestückt oder wenn sie
zur Anreihung verwendet werden, ohne CPU/EEPROM.

Die Idee mit Anreihbaren LED-Modulen ist grundsätzlich eigendlich nicht schlecht...
Ich habe das auch mal vor einigen Jahren (um 2002) für eine Sonderanwendung so gebaut.
Jeweils ein Buchstabenfeld mit einem EEPROM als Speicher. DAs ganze wurde dann zu einer 3X10 (Buchstaben) Anzeige zusammengesteckt und lief (läuft...) ganz ohne µC ;-)
(Ich liebe die CMOS 4000´er Logikserie...)

Aus der Erfahrung einige Anmerkungen zu deiner Idee:
1. Du hast eine Matrixgröße von 5x7 LED. Das ist natürlich die Standartgröße um Buchstaben darzustellen. Damit bekommt man alle Buchstaben/Zahlen und sehr viele Sonderzeichen klar erkennbar hin!
ABER:
Wenn du mehrere dieser 5x7 MAtrixen aneinander reihst, (Unter anreihbar verstehe ich, das sich der Abstand der letzten LED der Matrix eins von der ersten LED der MAtrix2 nicht von dem Abstand zweier LEDs innerhalb einer MAtrix unterscheidet!) dann hast du Buchstabe an Buchstabe ohne Abstand. Das sieht nicht gut aus und ist nicht klar erkennbar!
(vgl. die Fotos 1 & 2 )
Deshalb ist eine 6x7 Matrix die deutlich bessere Wahl!

2.Mit den unterschiedlichen Modulen (Mit und Ohne µC!) zur Aneinandereihung wirst du wahrscheinlich vor die Wand fahren... Zumindest wird es nichts universelles Werden!
Mache alle Module absolut IDENTISCH und berücksichtige das evtl in deiner Firmware!!!
(Ggf. kann man auch ein Master-Modul incl. PC-interface und beliebig viele Slave-Module die aber alle eine µC haben sollten planen)

Der Grund ist einfach:
Du lädst die Schaltung ja mit einer Tabelle in der festgelegt ist, wann welche LED leuchtet.
Diese Tabelle ist VÖLLIG anders, wenn man nun 1,2,3,4,5,6 Module hat!
Und wenn du nun sagen wir mal 6 deiner Module = 24 Buchstaben = 120 Spalten x 7 Zeilen zusammensteckst, DANN bekommst du mit nur einem µC echte Probleme.
Du wirst nicht genügend Portleitungen für ein direktes Betreiben haben. Also bleiben dir nur zb. Schieberegister. Das bedeutet du benötigst für eine für mobile Anwendungen empfohlene Mux-Frequenz von 100Hz eine Zeit von KLEINER 10µS pro Bit! (die SR werden mit 84 000 Baud geladen). In dieser Zeit müssen die Daten aus dem Speicher gelesen, zur Ausgabe vorbereitet, ausgegeben, Clock Signal gesetzt, nach minimum Clock Zeit wieder gelöscht, erkannt welches Bit als nächstes ausgegeben wird oder ob die Zeile voll ist und die Nächte Aktion eingeleitet werden. Dann müssen alle DAten übernommen werden und die Spalte umgeschaltet. DAS WIRD ENG! Und je länger die Anzeige wird, um so schwieriger wird es!
Darüberhinaus muss noch eine Feststellung darüber etroffen werden wie lang deine Anzeige nun gesamt ist um dies Anzupassen!
Natürlich könnte man nun wieder argumentieren, dass man mit 24 Buchstaben nicht mehr Mobil ist und das deshalb rund 30Hz Mux Frequenz ausreichen... Aber dann hast du wieder nicht festgelegte und varierende Ergebnisse.
Programmiertechnisch ist das ein Bockspringen ohne gleichen!

Wenn man nun aber jedes Modul mit Eigenintelligenz versieht, dann umgeht man das ganze.
Man benötigt einen gemeinsamen BUS, der das Zusammenspiel der Module und die Programmierung übernimmt. (Das spricht für eine MASTER-SLAVES Lösung).
Im Normalbetrieb arbeitet dann jedes Modul (synchronisiert) für sich!
Es müsste jetzt nur noch eine individuelle erkennung jedes einzelnen Moduls erfolgen und bei der Programmierung entsprechende Umrechenarbeit. Aber das kann die PSW im Leistungsstarken PC übernehmen und auch nur einmalig pro Prog-Vorgang!
Die Mehrkosten: 2Eur pro Modul... Aber viele gesparte Nerven!

(...)Texte werden in EEPROM gespeichert, sind je nach Wunsch per RS232, LAN oder WLAN
programmierbar, über dasselbe Interface oder ein immer vorhandener Up/Down/Select Drehtaster auszuwählen. Es wird kein Schriftsatz mit fester Breite verwendet, 8 "Stellen" ergeben als nicht unbedingt nur 8 Zeichen. (...)

Eine speicherung der Texte im EEPROM ist natürlich Sinnig.
Allerdings kommt hier wieder etwas problematisches hinzu:
Größe, Timing und Bedarf!
Größe und Timing lassen sich aber lösen...
Auf jedenfall mit der M/S Technik!
Soll es denn Serieller oder Paralleler Speicher werden?

Zum Bedarf: Die Frage ist jetzt benötigt man so viele extra Texte das sich die verwendung von externen Speicher lohnt? Für das vorliegende Projekt wahrscheinlich eher nicht!
Hier geht es ja darum das nur ein einfaches Schild für das Auto gebaut werden soll, das möglichst universell ist, damit die Produktion möglichst günstig ist!
Jeder Anwender will aber wohl nur 1-2 Schriftzüge schalten können.
Für andere Anwendungen (Großdisplays) ist es etwas anderes...

Genauso ist es mit der Programmierung:
Eine Prog-Möglichkeit ist eigendlich gar nicht nötig. Da man mit vorgefertigten Texten 99% des hier entstehenden Bedarfs abdecken kann! Aber da die Technik es nun einmal ohne Mehrkosten hergibt, habe ich die möglichkeit RS232 implementiert. (auf TTL-Pegel!)
So können einige Eintellungen incl. zweier Texte verändert werden!
Eine LAN-bzw. WLAN Verbindung ist für andere Anwendungen (Großdisplays!) sicherlich interessant. Hier aber unnötig, eher störend. Die dafür benötigte Technik ist groß und teuer (im Verhältnis!) Für ein Schild an der Sonnenblende wenig Sinvoll!
Evtl. währe Minimalismus die bessere Wahl.
Genauso mit einem UP-DOWN-DREHTASTER! NAtürlich ein nettes Gimmick, aber auch hier eher unnötig und (mechanisch) Störend. Dazu sind die Dinger noch Teuer!
Wenn dann einzelne Taster, Dip-Schalter oder einfach Lötbrücken!

Die Variable Textbreite habe ich auch in Betracht gezogn und ist bei mir grundsätzlich auch möglich (ebendso das Design "neuer" Zeichen am PC).
Aber ich habe aus optischen Gründen bei den Standart-Texten daruaf verzichtet!
Einheitsbreite finde ICH schöner/besser Lesbar. Ist aber wohl Geschmackssache!

Je einseitiger, selbstgeätzter Platine kommen etwa 45 EUR Kosten auf den Interessenten zu.

EINSEITIG?
Wie hast du das Gelöst? -Respekt!-
(Aber nur, wenn nicht durch unzählige Brücken!) ;-)
Ich habe es nicht geschafft ein sauberes 1 Seitiges Layout hinzubekommen!

Platinengrösse pro 4x 5x7 ist 305x70 mm .. Zeichengrösse ist 53mm

Ist die Angabe von 30x7cm für 4 Buchstaben wirklich richtig???
Oder eher ein Tippfehler?
Dann währen wir bei 3 Modulen für das Wort Feuerwehr!
also fast 1m ... Ist das nicht vieleicht etwas Groß???
Wenn man die Leerspalten weglässt, dann würde man mit 2 Modulen auskommen, was aber 1. auf die Lesbarkeit/Optik gehen würde, und 2. immer noch 62cm erfordern würde!
Für das aktuelle Projekt sicher nicht geeignet!
Auch einsparungen durch "schmalere" Schriftzeichen hast du in FEUERWEHR nicht.
Da gibt es kein I´s, kleine t-s oder l-s...

(...)So long, muss nu pennen ;)
Tim

Na Toll und mir hast du wieder ein zu lösendes Problem beschert, was meinen Ehrgeiz geweckt hat (nachdem ich das eine fertig hatte!

Verstehe mich nicht falsch!
ICh will dein Projekt keinesfalls Madig machen!
Aber ich meine halt einige GROBE Designmängel zu erkennen.
Ganz sicher ist es für den aktuellen Threat am Bedarf vorbei!
(So Simpel wie möglich bei größtmöglicher Universallität! Kosten- und Größenminimierung)

Für andere Zwecke (Großdisplays) ist die Grundidee des Modularen Aufbaus sicher nicht schlecht, habe ich ja selbst schon gemacht! Aber auch hier sind noch einige Probleme zu lösen!
Und nur das ist meine Intention- Dir diese Mängel aufzuzeigen, bevor du jetzt viel Geld in einen Prototyp investierst und es dann erst merkst!

GRuß
Carsten

P.S. die im TExt erwähnten Fotos folgen sobald meine DIGICAM aufgeladen ist!

[DG3YCS]

So, hier nun die Fotos aus dem oberen Beitrag

Es geht hier um die Lesbarkeit eine 6x7 Matrix vs. einer 5x7 Matrix!

Bild 1 Zeigt die 6x7 Matrix, Bild 2 die 5x7!

Gruß
Carsten

[Mr. Blaulicht]

Aber warum sollte ich mir ein Schild mit dem Schriftzug "Shinzon" isn Auto hängen? ;-)

[DG3YCS]

Aber warum sollte ich mir ein Schild mit dem Schriftzug "Shinzon" isn Auto hängen? ;-)

BLÖDMANN!!!

[Mr. Blaulicht]

BLÖDMANN!!!

Das wäre in der Tat mal ein ccoler Schriftzug für die Sonnenblende. Könnte man bei manchem Fabrikat auch serienmäßig einbauen...

Gruß, Mr. Blaulicht

[Shinzon]

Na zu meinen Ehren ! ;)

Moin ..

Also - natürlich habe ich mir über einiges, was du zurecht erwähnst, gedanken gemacht.
In der Tat ist der einzige Unterschied der Platinen, ob die CPU gesteckt ist oder nicht,
das EEPROM wird ja nur - in der Tat bisher seriell - an die entsprechende CPU gehängt,
man könnte es also weglassen, wenn eh keine CPU dran hängt.

Die Platinen sind in der Tat so gefertigt, das die LED-Module ohne Zwischenraum wie
bei den bekannten LED-Laufschriften zusammenstehen, Leerstellen werden in der Software
eingefügt, um deine "Shinzon" Bilder zu "umgehen". Wenn ich mich recht entsinne, hab
ich die Technik damals beim C64 das erste mal kennengelernt, wenn ich Sprites berechnet
habe.

Die Idee einer absolut identischen Platine habe ich eben aus Timing-Gründen verworfen, da
ich "keine Zeit habe", die Daten über die Module durchzureichen. Jedem Modul "seine" Buchstaben
aufzubrennen erscheint mir auch unpraktisch, daher hab ich meinen "Datenbus" durchgeschleift.
Solange eine CPU fehlt, wird der nicht benutzt - konkurrierend würde ja auch nicht funktionieren.

Bei 5x7 hab ich 7 Bit "Datenbus-Row" und die 5 Bit Column über Treiber-IC angehängt, 4 Bit
bleiben "übrig" für die "Modul-Selektion", kann also pro CPU 15 Module anhängen (15x4 Module).
"Beliebig" anreihbar wird's nur, wenn man nen zweites CPU Modul per seriell anhängt - was auf
"Modulebene" zu aufwändig war, denke ich, sollte für 15/16 Module eher funktionieren. Es reicht
ja ein "LED an/aus" Kommando.

Das Multiplexing war zunächst in der Tat ein Problem - aber mal ehrlich, wenn man einen Text
lädt, hat man sicherlich eine kaum merkliche (aber durchaus messbare) Zeit, um 74373 zu laden,
damit die CPU "nur noch" diese Bitmuster ein und auschalten muss. Ein Umladen verschiedener
Text sollte in ausreichender Zeit zu erledigen sein, Ist halt kein "echtes" Wechseln zwischen den
Bitmustern, sondern ein "zeigen - aus - neu setzen - zeigen" .. definiert natürlich Grenzen für die
Blinkfrequenz.

In der Tat rückt dadurch wieder die von dir genannte Eigenintelligenz pro Modul in den Fokus,
ohne es getestet zu haben halte ich aber den "Modulzähler" noch immer für die einfachere Wahl,
da ich "nur" die Modul-Spalten (pro Modul 20) per load/forget behandeln muss, und natürlich den
Modulübergang einrechnen. Effektiv würde ich es wohl wie damals mit Tabellenüberladen
versuchen, eine Tabelle für die Buchstaben an sich, und eine für die Offsets - ne Menge unnötiger
Daten auf den ersten Gedanken ;)

Zum EEPROM - in der Tat würde der interne EEPROM Speicher (genauso wie der interne RAM
Speicher) vollkommen ausreichen - ich dachte an einen externen Chip, um den gesockelt einfach
mal tauschen zu können wie einen "Programmierstecker" - vmtl. unnötiger Luxus.. Timing und
Architektur halte ich für recht unkritisch, da ich die Daten ja nur beim Reset aus dem EEPROM ins
RAM lade und von da umrechne/ausgebe. Du sagtest, das die PSW das erledigen könnte - hier
wäre zwar mehr RAM, aber weniger Code in der MCU nötig - auch ein Ansatz.. nur bin ich mit
Hochsprachen so derart eingerostet..

Zum LAN/WLAN Modul - eigentlich nur 20 bzw 40 EUR Aufpreis, seriell zu (W)LAN Wandler,
Lantronix lässt grüssen. So belaste ich auch nich die CPU .. eigentlich kann man das, wie du
selbst schreibst, auf RS232/TTL lösen und extern dranhängen - wer es denn will ^^ ..

Den Drehgeber dachte ich mir als einfachste Variante, zwischen Texten umzuschalten - klar,
man will hinter der Sonnenblende sicher nicht zwischen DRK und ASB wechseln.. aber ich glaub
die Polizei hat auch mehrere Texte auf ihren Einrichtungen gern - in der Tat reines Gimmick,
eben weil man ja die Organisation selten vor/auf der "Einsatzfahrt" wechselt. Und wesentlich
teurer als andere Schalter hab ich die eigentlich nicht in Erinnerung, da sie doch so massig in
Autoradios verbaut sind.. (Power-Volume)

Einseitig war für mich einfach ein Muss, weil ich bisher nie in der Lage war, doppelseitige Platinen
selbst herzustellen (*schäm!!*) .. und bei den Grössen ist Selbstätzen wesentlich günstiger
umzusetzen als eine Bestellung, gerade wegen dem "Hobbycharakter" des Projektes.. Wegen
der Treiber hab ich in der Tat eine handvoll Brücken, viele habe ich als Designalbtraum durch die
vielzitierten LED-Vorwiderstände lösen wollen .. doch bei SMD-Widerständen ist nicht viel Platz
*lach* .. Spass beiseite, in der Tat trifft "Designalptraum" am ehesten zu. Meine Lösung des
Problems war eigentlich nur, das ich die SMD-Bauteile unter den Modulen routen kann, was bei
Einzel-LEDs einfach nicht machbar ist. Bei den Modulen hab ich nur zwei "Kontaktleisten" und
viel Platz dazwischen - die Module haben ja schon die Matrixfunktion.

Die variable Schriftbreite ist in der Tat bei den hier genannten Texten nicht so gut rauszuarbeiten,
aber ..erm.. naja.. ich war faul und hab ne vorhandene Font-Tabelle verwenden wollen ;) Feste
Breite wäre in der Tat leichter zu "rechnen" ..

Dein Intention verstehe ich natürlich absolut nicht falsch - im Gegenteil .. ich werde dieses Projekt
vermutlich irgendwann mal in Form von einer oder zwei Modulen bauen - just to proove it.. in
der Tat wollte ich einfach mal meine Gedanken zum Ausdruck bringen, die ich beim Eagle-Routen
hatte - ich glaube nicht, das die Firmware eine leichte Hürde wäre (auch wenn ich sowas gerne
ein wenig runterspiele - tut das nicht jeder ASM-mächtige? NIEMALS würde ich zugeben, das die
Firmware in einer Hochsprache wesentlich einfacher programmiert wäre.. hat was von EMACS vs.
VI, findest du nicht? *G*)..

Falls ich dir schlaflose Nächte beschert haben sollte - sorry, war nicht meine Absicht .. ich konnte
halt nicht schlafen, um wirklich an anderen Projekten zu arbeiten war dennoch die Müdigkeit zu
gross .. also bastelt man mal im Halbschlaf und schaut am nächsten Tag, was für nen Mist man
da am Vortag geroutet hat.
Gerade aufgrund von deinem Fortschritt wird das für mich nur ein Konzept-Projekt bleiben, glaube
ich.. vielleicht aus Langeweile mal nen Board geätzt, wie gesagt.. die Kosten, die ich erwähnt habe,
sind in der Tat einfach nur die Bauteilekosten, die ich selbst hätte, um eine Grössenordnung zu
nennen .. dein Projekt ist in der Gesamtheit zweckdienlicher und günstiger, also ist mein Projekt
keinerlei Konkurrenz - eher einfach was, um die grauen Zellen mal rotieren zu lassen.

Wer weiss - vielleicht stellt sich schon früh in der Programmierphase heraus, das ich mit alter
Video-Spritetechnik gar nicht so weit komme, wie ich will - hätte aber den Vorteil, das ich ohne
grosse Prozessorlasten den Text verschieben könnte - was auf nem <1 MHz C64 klappte, wird
auf ner 8-16 MIPS MPU (je nach Systemtakt) doch sicher zu lösen sein - Negativ an der MCU
ist schon jetzt, das ich kein richtiges "bit-banging" damit kann - AVR halt..

Wenn ich mal wieder Langeweile hab, schau ich mal weiter daran, habe ab Ende der Woche
zwar wieder viel frei, aber dennoch irgendwie viel zu wenig echte "Freizeit" ;)

Gruss,
Tim

PS: Wem nun der Kopf raucht - gern geschehen ^^
PPS: Carsten, gerne lasse ich mir helfen, wenn dieser oder jener Denkfehler drin ist,
gerade weil du sowas schon gebaut hast, aber bedenke bitte, das es nur Hobby ist und
ich kein Problem habe, bei grossen Problemen anderen Projekten wesentlich mehr
Priorität und Blut zu spenden..

[DG3YCS]

Hi,

AHSO,
Ich sehe schon wir verfolgen in unseren Lösungen unterschiedliche Konzepte ;-)
Wobei ich gleich in Bezug auf dein PPS anmerken will, das es bei mir ja absolut dasselbe ist.
Die "Entwicklung" ist ein wenig Spielerei, halt zu Zeiten wo ich "wichtige" Sachen nicht mehr machen kann/will, mein Kopf aber noch ein wenig arbeiten möchte!
Ebendso wie du möchte ich nicht, das hier jemand auf die Idee kommt, das ganze sei eine Konkurenzveranstaltung. Ich will mit diesem Projekt nur mein eigendliches Hobby wieder ankurbeln. Die letzten JAhre habe ich das sträflich vernachlässigt. Ich habe hier ein kleines aber exquisites Elektroniklabor, mit Messtechnik und MATERIAL (auf Vorrat) im Wert einen neuen Mittelklassewagens stehen und habe in den letzten drei jahren fast nur repariert und vieleicht mal eine Schaltung zur Pegelanpassung gebaut!
Das letzte Programm welches ich geschrieben habe war zum berechnen des Eprominhalts für die BOSCH KF4 Serie im Jahr 2003! Mein letztes Bauprojekt (entwicklung) war die Modifikation von KF4 auf Geräte mit allen Kanälen und BOS FuG8b1 Bediengerät! (ebendfalls 2003)
Aber ich werde mich jetzt wieder bessern ;-)

So, BTT:
Ich hoffe ich habe deine Ausführungen jetzt richtig verstanden:
1. Du verwendest für deine Lösung "vorgefertige" LED-Matrixen.?
Das Spart natürlich Zeit und Arbeit, kostet dafür aber mehr und man ist hinsichtlich der Abmessungen eingeschränkt! Ich habe auch mit dem Gedanken gespielt
Mich hat aber die schwierige Verfügbarkeit mit damit verbundenen langen Lieferzeiten abgeschrekt. Zwei drei Module waren immer zu bekommen- Aber bei großen Stückzahlen wurde es schwierig (in großen Größen und Bezahlbar!)
Aber es hält den Aufwand stark in grenzen, denn mit einer einzeln aufgebauten MAtrix geht es nur Doppelseitig!

2. Du verwendest einen speziellen Treiber, welcher über einen 16Bit breiten Datenbus betrieben wird. Wobei die oberen 4 Bit das CS Signal sind?
OK, damit verringerst du schon einmal die nötige Geschwindigkeit deutlich!
Ich treibe ja rein Seriell, meine MAtrix wird mit einem 64 Bit Datenstrom pro Zeile gefüttert!
Dafür brauche ich aber auch nur drei Steuerleitungen! (CLK, DATA und Strobe)
Als Vertreter der PIC Anhänger hat man ja nicht soviele Ports zur Verfügung ;-)
Aber ich wollte ja auch noch mit Atmega spielen!
Der Vorteil ist halt das ich einfach verfügbare Bauteile habe, die extrem Billig sind.
(die kpl. Treiber-Geschichte für alle 9 Buchstaben kostet mich keine 4 Euro!)
Allerdings lässt sich so die MAtrix nicht beliebig vergrößern...

Besitzt dein Treiberbaustein einen größeren Speicher? Also kannst du ein Zeichen (oder mehrere) KOMPLETT laden und dann nur aktivieren? DAs hätte natürlich auch seine Vorteile.
Allerdings ist dann der Schritt eigendlich nicht mehr weit um statt des speziellen Treibers gleich wieder einen µC einzusetzen.

Zur ganzen Programmierung habe ich mir ja auch gedanken gemacht.
ICh habe ja für die erste Version noch einen 16c84 verwendet, den ich hier rumliegen hatte.
Habe mir dann ersteinmal ein Sortiment aktuellere µC bestellt (schon wieder 200Euro futsch... ;-) )
Beim 16c84 hatte ich ja nur 1024 Worte Programmspeicher, 64 Byte EEPROM und 36 Byte freien RAM. Da habe ich mich für die einfachste Variante entschieden...
Der PIC hat nur eine Aufgabe: Den gewählten Text auswählen und Seriell aufgeben.
Datenmanipulationen werden nicht durchgeführt!
Das habe ich kpl. der PC-Software überlassen, die dem PIC bereits die fertig errechnete Tabelle zur Verfügung stellt. Den freien Programmspeicher habe ich zum Ablegen der Tabellen verwendet. Mittlerweile setzte ich einen 16F628A ein, mit 2048 Worten Programmspeicher, 128 Byte EEPROM, aber 224Byte RAM! (von denen ich aber nur 34 byte nutze!)
Allerdings nimmt das Hauptprogramm bloß 232 Worte in Anspruch. (incl. RS232 Routine)
Der Rest des Programmspeicher dient dem Ablegen der Fixtexte!

3. Auch wenn du in Hochsprachen eingerostet bist: Nehme diesen Weg!
Vor allem übt das (deshlab mache ich das ja!). Ich habe die Font Tabelle schnell selbst erstellt. Das war da Hochsprache absolut kein Thema. Ich habe dank "Copy and Paste" für alle Buchstaben des Alphabets in Groß&Klein, die Umlaute, Zahlen sowie 10 Sonderzeichen rund eine dreiviertelstunde gebraucht. Weitere Zeichen sind eine Sache von 2 Minuten.
Aber in meiner PSW gibt es auch die Funktion Zeichen (vom Anwender) selbst zu definieren!
Dazu wird die Matrix eingeblendet (mit oder ohne vorher eingegebenen Text) und dann kann man mit der Maus einfach LEDs einzeln Ein- oder Ausschalten, das ganze Rechts oder Links verschieben oder Abstände vergrößern bzw. verkleinern.
Aus diesem Bild errechnet dann die PSW die Bilddatei...
Etwas zum Eingeben der Texte musst du ja sowieso schreiben...!

Ausserdem hätte es evtl. mehrere Vorteile bei verwendung von externen EEPROM.
Allerdings nicht bei deinem Entwurf! Ich würde überlegen, ob ich bei einem Parallelen Datenbus nicht auf einem Parallelen EEPROM Ausweichen würde...
(Je nach dem was du für einen µC verwendest. Mit einem Atmega 16 ja kein Thema)
So könntest du den EEPROM mit hilfe des µC Programmieren, aber im Betrieb steuert der µC nuch noch den Adresszugriff. Die Daten gehen direkt aus dem Eprom in den Treiber!
(Merkt man das ich "einfach Strukturierte" Programme und "hard-wired logic" liebe?)

Ich habe bei meiner Lösung auch über eine Variante mit 24C16 EEPROM nachgedacht, mit gemeinsamer DATA Leitung für die MAtrix und EEPROM, aber mit zwei getrennten CLK Leitungen ;-) Während der EEPROM die Daten ausgibt, geht der DAtenbus direkt auch an die SR, die CLK für i2C und SR laufen PArallel. Während der Steuerkomandos bleibt die CLK für die SR auf Low! Der µC steuert nur noch den Speicherzugriff und die Datenabspeicherung im EEPROM. Allerdings habe ich dann mit hinblick auf den aktuellen Schriftzugbedarf darauf verzichtet, da mir nichteinmal 12 Sinnvolle Texte eingefallen sind und es ja zwei Variable Texte gibt! Ich überlege aber noch, ob ich den I2C EEPROM auf dem Board mit vorsehen soll!
(Das man den bei Bedarf bestücken kann!)

Generell muss ich aber sagen, das ich ein gerne unkomplizierte Programme schreibe und notfalls auch Aufgaben auf externe Bauelemte (4000´er Reihe zb.) übertrage.
Ist immer eine Kosten/Nutzen Rechnung. Auch mag ich "verteilte" Intelligenz, also viele kleine schlaue Baugruppen, die ihre spezielle Aufgabe erfüllen und nur untereinander synchronisiert werden! Ist leichter zu entwickeln, läuft stabiler und man hat mehr Recourcen...!
Aber auch da gibt es ja zwei Lager :-)

4. Mit dem LAN Adapter verstehe ich schon, ist natürlich auch interessant ;-)
Aber wie schon geschrieben eher für "Große" Anwendungen... 20 oder 40 Euro sind schon eine Menge Holz nur für eine Programmierschnittstelle!

5. Mit dem Drehtaster muss ich sagen habe ich aktuell keinen Preis vorliegen.
Habe mal etwas gesehen was "sehr" teuer war. ICh wüsste aber im Moment auch nicht, wo ich diese Drehtaster "einfach" bestellen kann (Nachbausicherheit! ICH würde die schon kriegen, aber wer noch?) Evtl. währe ein Drehencoder eine Möglichkeit, da man ja eh einen µC verwendet. Aber da bist du mit 10Eur. dabei!

Ich lasse mich aber mal überraschen was bei dir so rauskommt! ICh finde es ja schon interessant, was es bei einem "so einfachen" Projekt alles zu bedenken gibt!
(Ach, was habe ich das vermisst! Jetzt macht löten wieder Spass!)

während ich meinen vorherigen und diesen Beitrag geschrieben habe, habe ich im Kopf schon einen Entwurf für ein Modularsystem ausgearbeitet. Mal schauen ob ich das im Angriff nehme.
Ein Vergleich der Ergebnisse währe dann schon interessant! Evtl. kann man dann das beste daraus vereinen ;-)

Mit den Leiterplatten bin ich genauso gehandicapt wie du! ICh habe heute Abend das ersteinmal meine Küvette hervorgekramt und Gereinigt! Auch habe ich hier noch einen Gesichtsbräuner der gerne ein Belichtugnsgerät werden möchte (von Ebay, seit 3 Jahren steht der hier rum!)
Für meine letzten Platinen (2003!) habe ich noch einen ALTEN Gesichtsbräuner mit Quecksilberdampf-Hochdrucklampe!!! (soetwas darf heute ja gar nicht mehr als Gesichtsbräuner verkauft werden!) ICh habe schon so manches mal nach mehreren Belichtungsvorgängen Sonnenbrand gehabt ;-) (empfohlene Bräunungszeit 0,5 - max 5 min!)
Das bringt aber keine tollen Belichtungsergebnisse, ZU STARK!

Meine µC Programme schreibe ich übrigends auch Ausschließlich in Assembler!
NAtürlich ist C (oder Basic) für viele Anwendungen einfacher, aber ebend auch nicht so effektiv! Und wenn man mit Makros und Copy & Paste arbeitet, dann kann man auch schon einen gewissen Kompfort erreichen UND hat maximale Effizienz und volle Kontrolle über die Laufzeiten! Aber es kommt halt auch auf die Anwendung an, die man damit realisieren will, was nun letztendlich besser/schneller ist...

Zu EMACS vs.VI kann ich aber nichts sagen, habe zwar Linux auf der Platte (auch) und sogar schon mal mit vi gearbeitet... Aber das war es schon!

Und was den Vergleich mit dem C64 angeht:
So ganz kann man das nicht vergleichen! Der c64 hatte zwar einen langsameren CPU Kern, aber dafür wesentlich mehr Speicher (64Kbyte), ausserdem war/ist es ja genaugenommen ein Multiprozessorsystem (VIC/SID usw. sind ja auch Prozessoren!)
Aber es stimmt: Was die damsl aus der Kiste herasugeholt haben war Wahnsinn!
ICh habe übrigends hier noch einen aufgebaut stehen... Manchmal spiele ich auch noch eine runde Giana Sisters oder FalcanPatrol (und andere Daddel-Games) ;-)

So, jetzt muss ich aber ins Bett!
Ist schon wieder zu Spät!

Gruß
Carsten