7-Segmentanzeige mit Farbsteuerung

[hardware.bas]

Zum Softwaremultiplexing:
Beim Aufbau von Prototypen und darauffolgenden Softwareentwicklung
muss der Chip sehr oft per ISP nachgeflasht werden. Ein Schreibfehler
im Quelltext oder ein seltener Fehlflash ... und Digit ... tschüss
Zum eigentlichen Thema:
Bin selber grade beim Aufdröseln der entpackten Pseudotextdatei.
Klebwax hat ja schon einiges rausgefunden. Mit Bascom sind derartige
Timings kein Problem, ist ja auch nur ein Compiler. Bei der Aufbereitung
der Stellen sehe ich in Sachen Rechenperformance kein Problem, zumal
für mein Projekt zusätzlich entschärfend hinzukommt, ich brauche NUR
die Farbe des gesamten Digits zwischenzuspeichern und es reichen
dafür 7 Farben, also KEINE Zwischenfarbtöne. Eine Aktualisierung der
Anzeige im Sekundenrhythmus reicht aus. Da es sich um ein zentrales
Managmentsystem für Produktionsanlagen, welche über einen 485-Bus
kommunizieren, handelt, kommt ein ATMega 162 zum Einsatz, welchem
ich nur wenige Prozente des Programmspeichers für die
Anzeigengestaltung gönnen werde.
Autarke Anzeige:
Für universelle Zwecke wäre es auch denkbar, das Digitarray auf einer
Platine zusammenzulöten und zusätzlich mit einem ATTiny 2313 zu
versehen. Dieser schafft die Rechenleistung mit links und hat
ausreichend PINs für Jumper, so dass eine Kommunikation über
UART, SPI, I2L oder benutzedefiniert kein Problem darstellt.
VG Micha

[Ceos]

Ein Schreibfehler
im Quelltext oder ein seltener Fehlflash ... und Digit ... tschüss

Schlechtes Schaltungsdesign ... oder mangelnde Erfahrung ... Wir arbeiten hier mit Multiplexing und ich debuggen regelmäßig mit stehendem Display, da brennt nichts ab wenn man seine Schaltung einfach ausreichend sicher dimensioniert ... Die Aussage zählt nicht oder es mangelt einem an Erfahrung!

Die Webseite zielt (und der Hersteller hat mir das sogar explizit geschrieben) auf Arduino Nutzer die die Neopixel library für die Ansteuerung benutzen können

https://github.com/adafruit/Adafruit_NeoPixel/blob/4d0987ede8f8c204ff333de9a2fcbb70c646b7a5/Adafruit_NeoPixel.cpp#L122

Ich habe dir mal die Methode gelinkt, die setzt auf heftigst optimierten und auch Copntroller spezifischen Assembler Code und ist sicher um einiges schneller asl was du da zusammenbaust

Klar ich möchte dem Lernprozess nichts entgegensetzen, aber da kannst du dich mal schlau machen wie die von Adafruit das lösen

[hardware.bas]

Ceos, vielen Dank für die Links, muss jedoch gleich zur Schicht.
Deine Vermutung, dass es mir an fundierter Erfahrung in Sachen
Multiplexing fehlt, ist übrigens berechtigt, da ich mich bisher im
Wesentlichen auf Anzeigendesign, welches hell, weithin sichtbar
und flimmerfrei sein muss, also bedienerfreundlich, konzentriert
habe. Detaillierte Informationen werden eh via RS232 einem
Prozessrechner zugeführt.
Weiterhin werden Timer und Interrupts bei mir meistens für
prozesstechnische Zwecke benutzt.
Mal sehen, ob aus den jetzt verfügbaren Infos ein
entsprechender Impulsfahrplan ersichtlich wird.
VG Micha

[Ceos]

nunja, genaugenommen, langweilt sich bei unseren Applikationen der Prozessor auch relativ gut und könnte eigentlich ein 4 Stelliges Display gerade so bedienen, aber leider haben wir auch zeitkritische sachen dabei wie interrupts, die während des bitbangings nicht bedient werden DÜRFEN, das solltest du bei deiner Anwendung auch berücksichtigen

die meiste Rechenleistung verheizen wir eigentlich für den Kommuniaktionsstack für unsere Busanschlüsse ... paradox, wo die Messung und Umwandlung in z.B. ein analoges Signal geschmeidig mit diskreter Schaltung gelöst werden KÖNNTE ... aber Industrie 4.0 Ruft nu mal nach Busssystemen und deren Stacks.

Wenn ich memorymapping betreibe indem ich das Muster im RAM als Rohdaten speichere udn dann einen DMA Controller + Sende peripherie beschäftige, habe ich die CPU komplett frei, nur der Bus wird ab und an mal für einen Takt oder 2 nicht verfügbar sein und so ein winziges bisschen jitter erzeugen.

Wenn du mit DMA und SPI arbeiten kannst udn dein RAM dafür ausreicht, würde ich dir empfehlen immer 2 bits in 1 byte zu packen, dann kannst du über das bitmuster des bytes dein PPM signal erzeugen.

[HaWe]

nunja, genaugenommen, langweilt sich bei unseren Applikationen der Prozessor auch relativ gut und könnte eigentlich ein 4 Stelliges Display gerade so bedienen, aber leider haben wir auch zeitkritische sachen dabei wie interrupts, die während des bitbangings nicht bedient werden DÜRFEN, das solltest du bei deiner Anwendung auch berücksichtigen

die meiste Rechenleistung verheizen wir eigentlich für den Kommuniaktionsstack für unsere Busanschlüsse ... paradox, wo die Messung und Umwandlung in z.B. ein analoges Signal geschmeidig mit diskreter Schaltung gelöst werden KÖNNTE ... aber Industrie 4.0 Ruft nu mal nach Busssystemen und deren Stacks.

Wenn ich memorymapping betreibe indem ich das Muster im RAM als Rohdaten speichere udn dann einen DMA Controller + Sende peripherie beschäftige, habe ich die CPU komplett frei, nur der Bus wird ab und an mal für einen Takt oder 2 nicht verfügbar sein und so ein winziges bisschen jitter erzeugen.

Wenn du mit DMA und SPI arbeiten kannst udn dein RAM dafür ausreicht, würde ich dir empfehlen immer 2 bits in 1 byte zu packen, dann kannst du über das bitmuster des bytes dein PPM signal erzeugen.

Das Zauberwort heißt hier: Multithreading,
gibt es schon lange für den Arduino Due und wohl inzwischen auch für AVRs mit wenig Speicher.
Insgesamt halte ich das mit den bunten LEDs aber für eine Spielerei, hauptsächlich für Anfänger oder wo es nicht so auf Performance ankommt, ansonsten würde ich zu einem 64k-farbigen großen 2.4"-7" TFT per Hardware-SPI greifen.

[Ceos]

Das Zauberwort heißt hier: Multithreading,

HaWe, mach dir doch bitte mal die Mühe zu lesen was vorher geschrieben worden ist. Du propagierst hier gerade unpassende Informationen.

Hast du dir die Timings mal angesehen und mal nachgedacht wieviele Takte du für die Flankenwechsel hast? das sind weniger als 13 Takte bei 32Mhz ... schon der Gedanke an einen "Threadwechsel" kostet deinen Prozessor mindestens 3 mal so viel. Das ist unmöglich zu schaffen!

Du kannst nur eines machen: Bitbang 800kHz oder irgendwas berechnen. Die Operationen um einen ISR vorzubereiten, den Stack Pushen, Pointer laden, all das ist unmöglich in den 13 Takten zu schaffen ohne die LEDs dabei zu verwirren, weil du alle hintereinander ohne Pause ansprechen musst oder die ersten LEDs updaten sich und du musst von vorne anfangen!

Darum habe ich extra darauf hingewiesen, dass man für jedes einzelne 7-Segment 0.21mS Zeit einplanen muss in der man nichts berechnen kann, es sei denn man stellt (wie er schon gesagt hat) einen separaten Prozessor dafür ab, der sich nur um das Umwandeln in WS2812 kümmert und in den Aktualsierungspausen dann Daten an einer Schnittstelle entgegen nimmt.

Ich wollte mir schonmal mit einem 555, einem D-FlipFlop und 3 Byte SPI Latches die Serialisierung für dieses beknackte Protokoll als DIY Peripherie aufbauen, bin aber an zu langesamen 555s gescheitert.

Wenn ich wie gesagt einen SPI hätte könnte cih einen DMA aus dem RAM damit beschäftigen (hat ein ATMega nicht, aber XMegas) die SPI zu füttern ohne dass die CPU auch nru einen Handschalg machen muss.

[HaWe]

HaWe, mach dir doch bitte mal die Mühe zu lesen was vorher geschrieben worden ist. Du propagierst hier gerade unpassende Informationen.
...
Hast du dir die Timings mal angesehen und mal nachgedacht wieviele Takte du für die Flankenwechsel hast? das sind weniger als 13 Takte bei 32Mhz ... schon der Gedanke an einen "Threadwechsel" kostet deinen Prozessor mindestens 3 mal so viel. Das ist unmöglich zu schaffen!

ich hatte das zwar gelesen, aber tatsächlich nicht verstanden, dass Threadwechsel so viel Zeit konsumiert - stimmt ntl, dann macht auch das hier keinen Sinn.
Bleibt also doch nur ein TFT, ggf mit "nachgemachten" LED-Schriftbalken...?