C-Code -> Verständnis problem..

[Jan H. (janiiix3)]

Moin Moin,

hier mal ein Code Ausschnitt..

void ht1632c_set(uint8_t x, uint8_t y, uint8_t val)
{
    uint8_t bitval;
    int addr;

    if ((x < 0) || (y < 0) || (x > 31) || (y > 7)) 
  {
      return;
    }
  
    bitval = 8>>(x&3);  // compute which bit will need set (Will equal 1, 2, 4, or 8)
    addr = ((x>>3)<<4)+(y<<1)+((x&4)>>2);  // compute which memory word this is in
  
    if (val) // Modify the shadow memory
  {  
      ht1632_shadowram[addr] |= bitval;
    }
    else 
  {
      ht1632_shadowram[addr] &= ~bitval;
    }
 
}

Das ganze ist ein Teil für eine 8x8 Matrix mit einem "Schattenspeicher".
Ich bin noch nicht ganz auf den Sinn von dieser Zeile gekommen..

    bitval = 8>>(x&3);  // compute which bit will need set (Will equal 1, 2, 4, or 8)

Wieso wird genau mit '3' verUNDET?

--
Augenkrebs.

[PittyJ (Gast)]

x&3 nimmt die letzen beiden Bits von x.
Man erhält dann
0&3 -> 0
1&3 -> 1
2&3 -> 2
3&3 -> 3
4&3 -> 0
5&3 -> 1
6&3 -> 2
7&3 -> 3
.. usw

[Carl D. (jcw2)]

PittyJ schrieb:
> x&3 nimmt die letzen beiden Bits von x.
> Man erhält dann
> 0&3 -> 0
> 1&3 -> 1
> 2&3 -> 2
> 3&3 -> 3
> 4&3 -> 0
> 5&3 -> 1
> 6&3 -> 2
> 7&3 -> 3
> .. usw

Und man die Acht (1000) max. drei mal nach rechts schieben kann, bevor 
sie "unten" rausfällt.

[yesitsme (Gast)]

Da braucht jemand die zwei niederwertigsten Bits. Vielleicht ist der 
darunter liegende Speicher als 4-Bit pro Adresse organisiert. Hast du 
ein Datenblatt zu dem Chip?

[Jan H. (janiiix3)]

yesitsme schrieb:
> Da braucht jemand die zwei niederwertigsten Bits. Vielleicht ist der
> darunter liegende Speicher als 4-Bit pro Adresse organisiert. Hast du
> ein Datenblatt zu dem Chip?

Habe ich jetzt auch heraus gefunden.. Das war mir unklar wieso man das 
so auf den ersten Blick "kompliziert" gemacht hat..

Datenblatt ist im Anhang.

[Dietrich L. (dietrichl)]

Was mir hier:

Jan H. schrieb:
> void ht1632c_set(uint8_t x, uint8_t y, uint8_t val)
> {
> ....
>
>     if ((x < 0) || (y < 0) || (x > 31) || (y > 7))

auffällt: da "x" und "y" unsigned int sind, kann es doch eigentlich kein 
"<0" geben!? Oder was C bzw. der Compiler daraus?

[Jan H. (janiiix3)]

Jan H. schrieb:
> addr = ((x>>3)<<4)+(y<<1)+((x&4)>>2);  // compute which memory word this
> is in

Da muss man auch erstmal überlegen..
Hat jemand eine "einfache" Erklärung?

[yesitsme (Gast)]

Jan H. schrieb:
> Hat jemand eine "einfache" Erklärung?

Es ist einfacher zu verdrahten wenn man ein paar Spalten/Zeilen anders 
anschließt.

[Jan H. (janiiix3)]

yesitsme schrieb:
> Jan H. schrieb:
>> Hat jemand eine "einfache" Erklärung?
>
> Es ist einfacher zu verdrahten wenn man ein paar Spalten/Zeilen anders
> anschließt.

Meinst Du wirklich das es etwas mit der Verdrahtung zu tun hat?

[Jan H. (janiiix3)]

Scheint wirklich immer in 4 Bits unterteilt zu sein.
Addr. 0x01 ist das erste Nibble vom Byte, Addr. 0x02 dann das zweite 
usw...

[Falk B. (falk)]

Jan H. schrieb:
> Jan H. schrieb:
>> addr = ((x>>3)<<4)+(y<<1)+((x&4)>>2);  // compute which memory word this
>> is in
>
> Da muss man auch erstmal überlegen..
> Hat jemand eine "einfache" Erklärung?

Das sind halt viele Bitmanipulationen in einer Zeile. FÜr BASCOM-Fans 
eher unverdaulich ;-)

addr = ((x>>3)<<4)+(y<<1)+((x&4)>>2);

(x>>3) schiebe X um 3 Bit nach rechts, sprich Division durch 8
((x>>3)<<4) schiebe das Ergebnis wieder um 4 Bit nach links damit wird 
erreicht, daß die unteren 4 Bit 0 sind.
(y<<1) Y um 1 Bit nachnlinks Schieben, Multiplikation mit 2
(x&4) Maskierung von Bit #2, alle anderen werden auf 0 gesetzt
>>2 Das Ergebnis 2 Bit rechts schieben, Division durch 4

Auf Seite 5 vom Datenblatt sieht man die Speichermatrix, daraus kann man 
die Berechnung der Adresse ableiten.

[Falk B. (falk)]

Jan H. schrieb:
> Scheint wirklich immer in 4 Bits unterteilt zu sein.
> Addr. 0x01 ist das erste Nibble vom Byte, Addr. 0x02 dann das zweite
> usw...

Ja logisch, schon mal SELBER in das Datenblatt geschaut! Das sind 64x4 
Speicherbits!

[Joe F. (easylife)]

Dieser Code hat Optimierungspotential.

if ((x < 0) || (y < 0) || (x > 31) || (y > 7)) 
{
}

Das würde ich z.B. komplett weglassen, und darauf achten, dass beim 
Funktionsaufruf die Grenzen von x und y eingehalten werden.
Testen auf negative Werte macht aus bereits genannten Gründen eh keinen 
Sinn.

addr = ((x>>3)<<4)+(y<<1)+((x&4)>>2);

Hier würde ich eine Look-Up-Table vorziehen.
Insgesamt benötigt diese dann 64 Einträge (Bytes).

const uint8_t addr_lut[8][8] = {
(...)
};

addr = addr_lut[y][x>>2];

[Jan H. (janiiix3)]

Joe F. schrieb:
> Dieser Code hat Optimierungspotential.
>
> Hier würde ich eine Look-Up-Table vorziehen.
> Insgesamt benötigt diese dann 64 Einträge (Bytes).
>
>
>

> const uint8_t addr_lut[8][8] = {
> (...)
> };
> 
> addr = addr_lut[y][x>>2];
>

Schicke Idee, Wie komme ich jetzt auf die Adressen? Ist sicherlich sehr 
simpel?

[Falk B. (falk)]

Jan H. schrieb:
> Schicke Idee, Wie komme ich jetzt auf die Adressen? Ist sicherlich sehr
> simpel?

Die stehen in der Tabelle . . .

Wobei das hier Overkill ist, die Berechnung tut es auch und ist nicht 
wesentlich länger.

[Tim T. (tim_taylor)]

Jan H. schrieb:
> Schicke Idee, Wie komme ich jetzt auf die Adressen? Ist sicherlich sehr
> simpel?

Scharf nachdenken oder von der Routine für alle gültigen Kombinationen 
von x und y ausgeben lassen.

Gehe mal davon aus das deine Frage darauf abzielt woher du die Werte für 
die Tabelle bekommst.

[Falk B. (falk)]

Ich glaub die Adressberechnung geht deutlich einfacher und 
übersichtlicher.

addr = y<<1;
if (x<4) addr++;

[Dr. Sommer (Gast)]

Joe F. schrieb:
> Hier würde ich eine Look-Up-Table vorziehen.

Warum überhaupt? Ein Haufen Zahlen in einem Array ist wohl eher nicht 
lesbarer als ein paar Bit-Manipulationen.

[Dr. Sommer (Gast)]

Falk B. schrieb:
> Ich glaub die Adressberechnung geht deutlich einfacher und
> übersichtlicher.

Glaube ich nicht.
z.B. x=31, y=0.

((x>>3)<<4)+(y<<1)+((x&4)>>2) ist dann 49. Bei dir kommt 0 raus.

Ich finde die Formel gar nicht so schlimm. Man könnte noch

addr = ((x & 0xF8)<<1)|(y<<1)|((x>>2)&1);

draus machen, ist aber Geschmackssache. Der Compiler wird eh die 
effizienteste Variante wählen. Ein guter Kommentar würde es vielleicht 
richten:

Bildet die Bits von x und y auf addr ab:
Bits 3-4 von x auf 4-5
Bits 0-2 (alle) von y auf 1-3
Bit    2 von x auf 0

[Falk B. (falk)]

Dr. Sommer schrieb:

>> Ich glaub die Adressberechnung geht deutlich einfacher und
>> übersichtlicher.
>
> Glaube ich nicht.
> z.B. x=31, y=0.

Dann hat irgendwer x und y verwechselt. Auch im Originalcode!

[Jan H. (janiiix3)]

Dr. Sommer schrieb:
> ((x>>3)<<4)+(y<<1)+((x&4)>>2) ist dann 49. Bei dir kommt 0 raus.
>
> Ich finde die Formel gar nicht so schlimm. Man könnte nochaddr = ((x &
> 0xF8)<<1)|(y<<1)|((x>>2)&1);draus machen, ist aber Geschmackssache. Der
> Compiler wird eh die
> effizienteste Variante wählen. Ein guter Kommentar würde es vielleicht
> richten:
> Bildet die Bits von x und y auf addr ab:
> Bits 3-4 von x auf 4-5
> Bits 0-2 (alle) von y auf 1-3
> Bit    2 von x auf 0

Da gebe ich Dir vollkommen Recht. Wenn man nicht gerade den Code 
geschrieben hat und nicht wirklich das "Vorgehen" versteht, hätten ein 
paar Zeilen Kommentar einiges leichter gemacht.

[Yalu X. (yalu) (Moderator)]

Der Chip ist ja für Displays mit 32 Zeilen und 8 Spalten (32z×8s), oder
wahlweise auch 24 Zeilen und 16 Spalten (24z6s) gemacht.

Die Routine aus dem Eröffnungsbeitrag scheint für 8z×32s-Displays
vorgesehen zu sein:

    if ((x < 0) || (y < 0) || (x > 31) || (y > 7))

Am einfachsten wäre es, das 8z×32s-Display wie ein um 90° gedrehtes
32z×8s-Display zu behandeln (oben im Bild). Dann ist

  bitval = 1 << (x & 3);
  addr   = (x << 1) + (y >> 2);

Möglicherweise hat es jemanden gestört, dass bei dieser Vorgehensweise
Zeilen zu Spalten und Spalten zu Zeilen werden, und das Display deswegen
so angeschlossen wie unten im Bild gezeigt. Dadurch wir die Berechnung
der Adresse etwas komplizierter.

Jan H. schrieb:
> Das ganze ist ein Teil für eine 8x8 Matrix

Wenn nur ein 8×8-Display angeschlossen ist, ist x<8, so dass

    addr = ((x>>3)<<4)+(y<<1)+((x&4)>>2);

vereinfacht werden kann zu

    addr = (y << 1) + (x >> 2);

was (mit vertauschten x und y) exakt dem Ausdruck von oben entspricht.

[Jan H. (janiiix3)]

Yalu X. schrieb:
> Der Chip ist ja für Displays mit 32 Zeilen und 8 Spalten (32z×8s), oder
> wahlweise auch 24 Zeilen und 16 Spalten (24z6s) gemacht.
>
Das mit der "umständlichen" Berechnung muss schon so sein. Das Display 
ist anscheinend so verdrahtet.
Die "if" Abfrage kann natürlich verbessert werden.

[yesitsme (Gast)]

Jan H. schrieb:
> Meinst Du wirklich das es etwas mit der Verdrahtung zu tun hat?

Ja. Warum sollte man sonst x in 2 Teile teilen, auseinander schieben um 
Platz für y zu bekommen?


Yalu X. schrieb:
> Möglicherweise hat es jemanden gestört, dass bei dieser Vorgehensweise
> Zeilen zu Spalten und Spalten zu Zeilen werden, und das Display deswegen
> so angeschlossen wie unten im Bild gezeigt. Dadurch wir die Berechnung
> der Adresse etwas komplizierter.

Vielleicht ist

- - - -

- - - -

besser zu routen als

| || || || |

("-" bzw. "|" = 8 Pins eines LED Matrix Modules in Reihe)

[yesitsme (Gast)]

Joe F. schrieb:
> Dieser Code hat Optimierungspotential.
> if ((x < 0) || (y < 0) || (x > 31) || (y > 7))
> {
> }
>
> Das würde ich z.B. komplett weglassen, und darauf achten, dass beim
> Funktionsaufruf die Grenzen von x und y eingehalten werden.

Im grunde will jeder Benutzer dieser Funktion die Prüfung haben. Also 
warum die Verantwortung hier an alle Benutzer geben anstatt es einmal an 
Zentraler Stelle zu lösen?


> Testen auf negative Werte macht aus bereits genannten Gründen eh keinen
> Sinn.

Wenns kein undefined behaviour ist, würde ich das der 
Vollständigkeithalber drin lassen.

[Dr. Sommer (Gast)]

yesitsme schrieb:
> Wenns kein undefined behaviour ist, würde ich das der
> Vollständigkeithalber drin lassen.

Der Compiler wird den Vergleich einfach wegoptimieren und ggf. warnen.

yesitsme schrieb:
> Im grunde will jeder Benutzer dieser Funktion die Prüfung haben

Man könnte auch in der Funktion ein assert() verwenden. Werte außerhalb 
des Bereichs zu übergeben ist ein Fehler, der dann in der Debug-Version 
zum Abbruch führt.