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

[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