7-Segment multiplexen - was bedeutet DB-Angabe mit Duty-Cycle?

Hallo Hans

Ein 7-Segment sind ja eigenlich sieben LED's. Wie du schon gesagt hast, 
werden diese kurzzeitig mit einem grösseren Strom beliefert um eine 
normale Helligkeit hinzubringen. Da nimmst du einfach diese 160mA vom 
Datenblatt.
Diese 0.1ms sind ebenfalls zum Schutz der LED's. Wenn diese Zeit länger 
wird, geht sie evtl. kaputt.
Wenn du nun mehr als 10% der gesamten Zeit eine LED leuchten lässt, 
musst du den Strom ein wenig reduzieren, aber grundsätzlich halten LED’s 
viel mehr aus, als im Datenblatt angegeben.

*alle Angaben ohne Gewähr

Lg dabidas ;)

dabidas schrieb:
> Wenn du nun mehr als 10% der gesamten Zeit eine LED leuchten lässt

Ja, ok, aber von welcher gesamten Zeit? 10% von 100us sind ja was 
anderes als 10% von einer Sekunde. Oder darf die längste Zeit halt nicht 
die 100us überschreiten?

Du darfst 160mA maximal für 0,1ms pro LED anlegen. Danach muss für 0,9ms 
ruhe sein und dann wieder von vorne. Also 1/10 von 1ms Wiederholrate.

genau, diese 10% dürfen nicht länger als 0.1ms sein, wenn du das ganze 
schneller machst, bist du auf der sicheren Seite

Ahhh, alles klar! Das mit der 9/10 Ruhezeit klingelt jetzt. Vielen Dank!

Ist ja trotzdem ganz schön heftig...dann brauche ich ja schon 700mA 
allein für die Anzeige (mal 100mA angenommen). Kann ich ja noch die 
Segmente in den einzelnen Anzeigen zusätzlich multiplexen...aber dann 
müsste wohl noch ein größerer Strom her.

Alles klar, danke!

ja 700mA ist ja nicht so viel, mit deinen ca. 2V kommst du nur auf 1.4W

So, also da jetzt die Hardware geklärt ist...mal noch ein paar Fragen 
zur besten Umsetzung in C:

Ich schreibe mir die üblichen Funktionen zum Zerlegen von Zahlen in ihre 
einzelnen Ziffern usw.

Mal als Beispiel mit einer 4-stelligen Anzeige.Wenn ich hier jetzt einen 
Wert ausgeben will, wo mache ich welche Schritte am besten?

Mittels Timer schalte ich immer eine Stelle weiter - schicke ich in der 
ISR auch direkt die neuen Daten los, oder setze ich nur ein Flag, 
welches dann in der main die Daten schickt? Je nachdem, wie viel in der 
main berechnet wird, kann es ja evtl. zu ungleichmäßigen Zeiten zwischen 
den Anzeigen kommen.

Ich hatte z.B. schonmal den Fall, da hatte ich in der ISR auch nur die 
Anzeige markiert, die als nächstes ihre Daten bekommen sollte...je 
nachdem, wie groß die anzuzeigende Zahl war, dauerte die Zerlegung (da 
passierte natürlich noch mehr) unterschiedlich lang, was man an einem 
Flimmern erkennen konnte. Umso kleiner die Zahl wurde, desto besser 
wurde es dann wieder - so war auf jeden Fall nicht richtig gelöst.

Also wäre ich erfreut über Vorschläge, wie man es am Besten löst. Wenn 
ich in der ISR direkt die Daten losschicke, dann löst der Interrupt 
evtl. aus, wenn gerade die neuen Daten aufbereitet werden.

Wie macht man es am besten?

Hallo Karl-Heinz,

vielen Dank für den Beitrag. Ich merke gerade, ich habe eine wesentliche 
Information nicht hingeschrieben...sowohl die einzelnen Stellen, wie 
auch die Segmente einer jeden Stelle werden über zwei Schieberegister 
angesteuert. Ich schicke also nur 16Bit per SPI auf zwei 595er. Daher 
die Frage, ob ich die Daten in der ISR verschicken soll. SORRY.

Karl Heinz Buchegger schrieb:
> Für jede 7-Seg-Anzeige hast du eine Variable (am besten als Array
> zusammenfassen), in dem schon fix fertig das Muster vorliegt, welches
> beim jeweiligen ISR Aufruf an die jeweilige Anzeige gehen muss.

Genauso habe ich es auch.

Karl Heinz Buchegger schrieb:
> DIe ISR macht nichts anderes, als reihum immer wieder einfach nur den
> Inhalt dieser Variablen auszugeben.

Ja, ist klar, das verstehe ich, nur wie (keider jetzt erst erwähnt) 
schicke ich die Daten per SPI raus. Daher die Frage, ob Flag setzen, 
dass neue Stelle aktuell ist und Daten gesendet werden sollen.

Meine Idee:

Timer-ISR:

Neue Daten für nächste Stelle per SPI senden.


SPI-Senden-Fertig-ISR:

Latch für 595er togglen, damit zugleich neue Stelle und Zahlenmuster 
angezeigt wird.

Karl Heinz Buchegger schrieb:
> static uint8_t PatternCode[10] = { .., ... };

Das habe ich mir auch so zusammengebaut, das ist ganz praktisch.

Nun noch zu den veränderlichen Daten. Es kann ja garnicht vorkommen, 
dass ein Array-Element gerade geändert wird, wärend die ISR zuschlägt, 
da ich ja erstmal in einer zusätzlichen Variable das neue Byte erstelle 
und dieses dann komplett in das Array-Element kopiere - das passiert ja 
in einem Befehl, welcher nicht unterbrochen werden kann, richtig? (Jetzt 
mal angenommen, ich würde ein Byte erstellen und es nicht fertig aus 
einem #define herholen, was praktisch natürlich Unsinn ist).

Obwohl...:


Gruß, Hans

Karl Heinz Buchegger schrieb:
> void showNumber( uint16_t num )
> {
>   uint8_t i;
>
>   for( i = 0; i < MAX_STELLEN; ++i )
>   {
>     Pattern[MAX_STELLEN - 1 - i] = PatternCode[ num % 10 ];
>     num /= 10;
>   }
> }

Hier könnte es ja theoretisch schon vorkommen, dass gerade erst die 
halbe Zahl fertig ist, die ISR sich aber noch eine alte holt. Nur das 
wird man wohl kaum mitbekommen.

Das "Gruß, Hans" sollte natürlich nach unten ;-)

Vielen Dank!

Ich werde das so erstmal umsetzen!