7-Segmentanzeige mit Farbsteuerung

[Ceos]

Das entsprricht der Lösung die ich beschrieben habe (SPI um das Signal zu produzieren) allerdings braucht das ne Menge RAM (12Byte RAM pro LED) und die NEXPs haben einen DMA

[hardware.bas]

Der Meinung von HaWe, dass es sich um eine Spielerei handelt, schliesse
ich insofern an, falls man die einzelnen Segmente individuell illuminieren
sollte. Die Zielstellung ist jedoch eine Farbsteuerung des einzelnen
kompletten Segmentes und das auch nur siebenfarbig. Dies dient einzig
und allein der komfortableren Darstellung von mehrstelligen 7-Segment-
LED-Anzeigen an oder in der Nähe von Anlagenkomponenten, für Operator,
welche nicht unbedingt die technischen Details der Maschine kennen
müssen. Dazu erscheinen mit die RGBDIGITs prädestiniert. Leider bin auch
ich bisher nicht weitergekommen, was deren Ansteuerung betrifft.
Die Nutzung von Display habe ich auch schon ins Auge gefasst, bis jetzt
jedoch auf Grund des Preis-/Nutzen-Verhältnisses und den rauhen
Umgebungsbedingungen verworfen.
Trotz Hochachtung vor den vielen in diesem Threed erwähnten speziellen
Kenntnissen und Erfahrungen, wollte ich an das eigentliche Thema noch
mal erinnern. Danke für das Verständniss.
VG Micha

[Siro]

Ich habe eben mal ein paar Versuche wegen dem "kritischen" Timing gemacht.
Es hat sich herausgestellt, zumindest bei meinen LEDs,
dass die Low-Phasen doch erheblich länger sein dürfen als im Datenblatt angegeben.
Ich habe Low Phasen von bis zu 7 Mikrosekunden drin, obwohl es angeblich nur
0,45 bzw. 0,85 Mikrosekunden sein dürfen.
Wichtig ist das Einhalten der angegebenen Highphasen.

[Ceos]

Okay, das ist neu, funktioniert das auch egal wo du die pausen machst? also z.B. mitten im Byte oder nur an bestimmter Stelle? Die DOku scheint mit +/-150nS sehr strikt zu sein was das angeht

Dann könnte man auch relativ gemütlich mit SPI arbeiten, pro millisekunde ein byte a 2 bits codiert ... dann frage ich mich warum bei mir mit der SPI lösung nach 10 LEDs nurnoch mist rausgekommen war

[Siro]

Bei mir ergibt sich das Timing bedingt durch die Software,
dass ich zwischen den Bytes 7 us Low habe und
zwischen den einzelnen Bits habe ich zur Zeit 3,8us Low.
Ich habe 57 Leds dran



Übrigens sieht man hier den "Fehler" in der RIGOL-Software vom MSO1104Z. Die automatische Min Max Funktionion für die Pulsbreite funktioniert nicht richtig.
Das wurde mir sogar bestätigt,...... Die Cursorpositionen stimmen aber BX-AX = 7us

void LedShiftOut(U8* leds, U8 count) 
{
    U8 one_byte;
    U8 bit_count;

    // damit keine Multiplikation verwendet wird:
    count=(count+count+count);             // 3 Bytes pro Led RGB
    DISABLE;   // alle Interrupts sperren
    while (count) {
        CLRWDT();              // den Watchdog bedienen, fass erforderlich
        one_byte = *leds++;    // aktuelles Datenbyte laden
        // 8 Bits durchlaufen:
        for (bit_count = 0; bit_count < 8; bit_count++) 
        {
            if (one_byte & 0x80) // wenn das oberste Bit 7 gesetzt ist dann
            {
                LATA5 = 1;  // lange High Phase einleiten
                NOP();
                NOP();
                NOP();
                LATA5 = 0;   // High Phase beenden
                NOP();   // testweise länger auf low 
                NOP();
                NOP();  
                NOP(); 
                NOP();
                NOP();  
                NOP(); 
                NOP();
                NOP();  
                NOP(); 
                NOP();
                NOP();  
                NOP(); 
                NOP();
                NOP();  

            } else  // Kurze High Phase weil das Datenbit Low ist
            {
                LATA5 = 1;  // kurze High Phase einleiten
                NOP();
                LATA5 = 0; // High Phase beenden
                NOP();   // testweise länger auf low 
                NOP();
                NOP();                
                NOP();   
                NOP();
                NOP();  
                NOP();   
                NOP();
                NOP();                
                NOP();   
                NOP();
                NOP();  
                NOP();
                NOP();
                NOP();  
                
            }    
            one_byte <<= 1;   // Das Datenbyte 1 mal links verschieben
        }
        count--;   // Anzahl auszugebener Datenbytes -1
    }
    ENABLE;   // Interrupt wieder einschaalten
    __delay_us(50);  // Das Ende der Datenübertragung erreicht wenn die Leitung länger als 50us Low bleibt.
}

Mein LedArray sieht so aus:

// so viele LEDs sollen angesteuert werden:
#define LED_COUNT 57

/* Jede LED hat 3 Bytes insgesamt also 24 Bits */
typedef  struct  // __pack weil wir keinen Speicher verschwenden wollen
{ 
    U8 green;     /* 8 Bit fuer die Helligkeit */
    U8 red;       /* 8 Bit fuer die Helligkeit */
    U8 blue;      /* 8 Bit fuer die Helligkeit */
} TLed;           /* Type Bezeichner ist TLed */

TLed LedArray[LED_COUNT];

aufgerufen wird dann so:

 
// Beispiel wie die Farben gesetzt werden, hier für LED Nr 4 (Zählung geht von 0..)

    LedArray[3].green = 0x00;     // grün aus
    LedArray[3].red   = 0x7F;      // halbe Helligkeit für rot
    LedArray[3.blue   = 0x10;      //   bissle Blau dazu

   LedShiftOut(&LedArray,LED_COUNT);

ab 7,5us Low Phase flippen die LEDs bei mir aus

- - - Aktualisiert - - -

@Ceos:
ich hatte das auch schon, dass nach einigen LEDs nur noch Blödsinn rauskam.
Bei mir war tatsächlich eine LED defekt. Die habe ich ausgetauscht und dann lief es richitg.
Hatte auch erst gedacht das es an der Software bzw. Timing liegt.

[hardware.bas]

Nach dem Studium des PDF-Datasheetes der RGBDIGITs hats jetzt bei mir
etwas Klick gemacht. Andere sind warscheinlich schon weiter und könnten
mich korrigieren. Also, offensichtlich läuft der Spass folgendermassen ab:
- Es werden 24-bit Datenpakete mit 800kbit/s benötigt
- Jede Bitinfo beginnt mit H und endet mit L
- L- und H-Bits werden durch das unterschiedliche H/L Verhältnis bestimmt
- Ub und Takteingang haben 5V, also TTL-Pegel
Diese Informationen dürften reichen, um einige RGBDIGITs zu bestellen und
den Rest, falls nicht schon jemand mehr weiss, empirisch rauszukriegen,
ohne die Bauteile zu schädigen. Mt einem teilautomatisierten BASCOM-
Programm und einen ATiny mit 16-Bit-Timer, sollten dann folgende
restlichen Fragen zu klären sein:
- genaue Zuordnung der Bits zur Funktion
- wieviel 24-Bit-Datenpakete pro Anzeigedigit
- muss permanent mit Daten refresht werden oder nicht
- könnte man Daten aus dem letzten PinOut sinnvoll nutzen
Es wird daraufhin die Entshidung fallen, ob die komplette
Anzeige über den Hauptchip des eigentlichen Systems oder
über einen eigenen ATiny bedient wird.
VG Micha

[Ceos]

Um Siro hier nochmal zu zitieren, es ist nur wichtig dass die Zeit der H-Phase stimmt, die L-Phase kann deutlich länger ausfallen als im Datenblatt beschrieben! Du musst dir also nciht unbedingt einen abbrechen die Bits auch bei 800kHz raus zu senden, solange du nur die einzelnen H-Flanken richtig machst.

Zu deinen Fragen:

- eine 7-Segment Anzeige hat wie der Name es verrät 7 Segmente (eventuell noch ein 8tes für einen Punkt wenn denn einer verbaut ist)
- die Segmente werden über eine Standardisierte Reihenfolge angesprochen mit der Segmentbezeichnung a,b,c,d,e,f,g (evtl. h für den Punkt), wie die verteilt sind verrät die Wikipedia oder ein beliebiges Elektronik Buch
- ein refresh ist nicht nötig, solange du die Pulsleitung low hälst, das Datenblatt sagt eine Pause von mind. 50µS bevor die LEDs sich automatisch mit den eingepulsten Daten updaten!

-von welchem letzten PinOut sprechen wir hier?

Nimm dir einfach folgende Daten als Hilfestellung:

1/800kHz = 1.25µS * 24Bits/LED = 30µS/LED * 7( Segmente/7SegModul = 210(240)µS/7SegModul

Wie ich schonmal geshrieben habe, musst du also nurnoch einen Kompromiss finden, wie oft du das Display aktualisieren können willst, die Zeit zum senden der Daten in Abhängigkeit der anzahl verwendeter Module von der Zeit zwischen 2 aktualsierungen abziehen und bewerten ob die verbleibende Zeit für deine restlichen Programmaufgaben ausreicht