Bits shiften - ich verstehe es nicht.

[NegativeOne! (Gast)]

Hallo Leute,

ich bin überfordert...

Kurzbeschreibung:
Über drei BCD Codierschalter soll eine Dezimalzahl eingestellt 
werden...0-999.

Diese drei Codierschalter hängen an zwei Schieberegistern, allerdings 
nicht so, dass ich die Bits der Reihe nach in eine 16 Bit Variable 
shiften könnte. Die Stellen der drei Schalter sind nämlich vertauscht.

Ich muss daher die bits der beiden, aus dem Schieberegister gelesenen 
Bytes, neu zusammensetzen und dabei auf drei 8-bit Variablen verteilen.

Und dazu auch noch negiert werden, denn was in den Ergebnis-Bytes eine 1 
sein muss, kommt als 0 aus dem Schieberegister.

Also zum Beispiel:

uint8_t hunderter = 0;
uint8_t zehner = 0;
uint8_t einer = 0;

firstbyte  = readBCDSwitches();
secondbyte = readBCDSwitches();

  // Hunderter: 
  // 00000000
  //     ||||
  //     |||+--- !firstbyte.0
  //     ||+---- !firstbyte.2
  //     |+----- !firstbyte.1
  //     +------ !firstbyte.3
  
  // Zehner:
  // 00000000
  //     ||||
  //     |||+--- !secondbyte.4
  //     ||+---- !secondbyte.6
  //     |+----- !secondbyte.5
  //     +------ !secondbyte.7

  // Einer:
  // 00000000
  //     ||||
  //     |||+--- !secondbyte.0
  //     ||+---- !secondbyte.2
  //     |+----- !secondbyte.1
  //     +------ !secondbyte.3

hunderter = (..????..);

Kann mir vielleicht jemand ein Beispiel geben, wie man das Bit 2 aus der 
Quellvariable negiert als Bit 1 in die Zielvariable schreibt?

Ich checks einfach nicht...

Vielen Dank für jeden Tip.

[Jens M. (schuchkleisser)]

Ziel = 0;
if Quelle.bit=0 then ziel.bit=1;
und dann einfach 11 weitere ifs.

In Assembler sind das je nach Prozessor so ~27 Befehle (3 clr, 12x bit 
test und bit set).
In C etwas mehr zu schreiben, aber ebenfalls trivial.

Wie man Bits abfragt und setzt weißt du aber?

[Christoph db1uq K. (christoph_kessler)]

negieren geht durch ein VerUNDen mit 0xffff

Und wenn die Zehner nur in der falschen Richtung laufen, kann man sie 
z.B. über das Überlaufflag in eine andere Variable in umgekehrter 
Richtung reinschieben. Aber hier sind die vier Bits ja noch 
komplizierter angeordnet.

[H.Joachim S. (crazyhorse)]

Am einfachsten mit einer Tabelle aus 16 Werten, also zu deiner Belegung 
steht die jeweilig richtige Zahl. Dazu noch ein bisschen maskieren und 
bei secondbyte 4xschieben.

[Jens M. (schuchkleisser)]

Christoph db1uq K. schrieb:
> negieren geht durch ein VerUNDen mit 0xffff

Seit wann? Wenn dann XOR. und ein Byte XORt man mit xFF.
Aber nötig ist das negieren hier nicht.

H.Joachim S. schrieb:
> Am einfachsten mit einer Tabelle aus 16 Werten, also zu deiner Belegung
> steht die jeweilig richtige Zahl. Dazu noch ein bisschen maskieren und
> bei secondbyte 4xschieben.

Oh ja, eine LUT. Noch mehr Speicher und noch komplizierter. Und dann 
noch maskieren und schieben.

[Bitshifter (Gast)]

oder mal nachdenken, ob es so gehen kann :-) :

1. Bit 1 in der Zielvariablen löschen
2. Inhalt der Quellvariablen so shiften, dass Bit 2 anschließend an der 
Stelle Bit 1 steht.
3. alle Bits ausser Bit 1 löschen (inverse Maske von 1.)
4. mit der Zielvariablen "verodern"

[Bitshifter (Gast)]

ach ja: vor Schritt 3 noch negieren

[Jens M. (schuchkleisser)]

So etwa:

int main()
{
    unsigned char foo=0x03;
    unsigned char bar=0;
    
    printf("Input: %x\n", foo);

    if (foo & 0x01) bar += 0x10;
    if (foo & 0x02) bar += 0x20;
    if (foo & 0x04) bar += 0x40;
    if (foo & 0x08) bar += 0x80;
    
    printf("Output: %x\n", bar);

    return 0;
}

[Marten Morten (Gast)]

NegativeOne! schrieb:
> Also zum Beispiel:
>
>

> firstbyte  = readBCDSwitches();
> secondbyte = readBCDSwitches();
> 
...
>   // Zehner:
>   // 00000000
>   //     ||||
>   //     |||+--- !secondbyte.4
>   //     ||+---- !secondbyte.6
>   //     |+----- !secondbyte.5
>   //     +------ !secondbyte.7
> 
>   // Einer:
>   // 00000000
>   //     ||||
>   //     |||+--- !secondbyte.0
>   //     ||+---- !secondbyte.2
>   //     |+----- !secondbyte.1
>   //     +------ !secondbyte.3
> 
>

Wenn du wirklich nur zwei Bytes bekommst, dann können Zehner und Einer 
so nicht im zweiten Byte kodiert sein.

Ansonsten sind immer nur die mittleren Bits (2 <-> 1, bzw. 6 <-> 5) 
vertauscht. Ausmaskieren und zurück tauchen:

unit8_t swap21(uint8_t in) {
    return (in & !0x06) | ((in & 0x02) << 1) | (in & 0x04) >> 1) 
}

unit8_t swap65(uint8_t in) {
    return (in & !0x60) | ((in & 0x20) << 1) | (in & 0x40) >> 1) 
}

Negieren kann man vorher oder nachher. firstbyte ist nach dem swap21() 
direkt das hunderter Byte. secondbyte muss nach swap21() und swap(65) 
noch auseinander "geshiftet" werden. Wie genau hängt davon ab wo sich 
Zehner und Einer wirklich in secondbyte befinden.

[Wolfgang (Gast)]

NegativeOne! schrieb:
> Diese drei Codierschalter hängen an zwei Schieberegistern, allerdings
> nicht so, dass ich die Bits der Reihe nach in eine 16 Bit Variable
> shiften könnte. Die Stellen der drei Schalter sind nämlich vertauscht.

Da wurden beim Routen der Platine ein paar Minuten eingespart, die 
Entwicklungsarbeit wurde verkürzt. Die Software muss es jetzt ausbaden. 
;-(

Wenigstens scheinen die Gebersignale alle in gleicher Weise verknotet zu 
sein, so dass du mit einem über das Gebersignal indizierten Zugriff auf 
ein 16er-Array die Sache ohne große Bitschieberei richten kannst.

[NegativeOne! (Gast)]

Hallo zusammen,

vielen Dank für die Hilfestellung. Ich habe aus dem ein oder anderen 
Kommentar eine Lösung geformt, die mir vorallem einigermaßen gut lesbar 
erscheint.
Vielleicht probiere ich die kompakteren Möglichkeiten hier auch noch 
aus, aber ich bin nicht so geübt damit und setze daher erstmal auf (für 
mich) bessere Lesbarkeit ;)

  hunderter  |= !(firstbyte & (1 << 0)) << 0;
  hunderter  |= !(firstbyte & (1 << 2)) << 1;
  hunderter  |= !(firstbyte & (1 << 1)) << 2;
  hunderter  |= !(firstbyte & (1 << 3)) << 3;

Marten Morten schrieb:
> Wenn du wirklich nur zwei Bytes bekommst, dann können Zehner und Einer
> so nicht im zweiten Byte kodiert sein.

Stimmt - Formatierungsfehler. Sorry... so wäre es richtig:

  // Zehner:
  // 00000000
  // ||||
  // |||+------- !secondbyte.4
  // ||+-------- !secondbyte.6
  // |+--------- !secondbyte.5
  // +---------- !secondbyte.7

  // Einer:
  // 00000000
  //     ||||
  //     |||+--- !secondbyte.0
  //     ||+---- !secondbyte.2
  //     |+----- !secondbyte.1
  //     +------ !secondbyte.3

Vielen Dank nochmal!

[NegativeOne! (Gast)]

Wolfgang schrieb:
> Da wurden beim Routen der Platine ein paar Minuten eingespart, die
> Entwicklungsarbeit wurde verkürzt. Die Software muss es jetzt ausbaden.
> ;-(

Ich fürchte, genau das ist wurde hier gemacht. Oder ein Fall von 
"Security by Obscurity"? ;)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jens M. schrieb:
> Oh ja, eine LUT. Noch mehr Speicher und noch komplizierter. Und dann
> noch maskieren und schieben.
Irgendwie trotzdem kompakt:

//                           Bits 1 und 2 im Nibble vertauscht!
//                    {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};
uint16_t remap[16] =  {0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15};

//                 Hunderter             Zehner                          Einer
uint16_t result =  remap[firstbyte]<<8 | remap[(secondbyte>>4)&0xf]<<4 | remap[secondbyte&0xf];

Dazu auch ein Screenshot vom onlinegdb.com C-Compiler.

[H.Joachim S. (crazyhorse)]

Jens M. schrieb:
> Oh ja, eine LUT. Noch mehr Speicher und noch komplizierter. Und dann
> noch maskieren und schieben.

Schieben musst du auch...
Komplizierter ist es nicht.
Und ob mehr Speicher verbraucht wird, wäre erst mal zu überprüfen. Der 
Unterschied wird minimal sein, vielleicht ist es sogar kompakter.
Spielt hier zwar keine Rolle, aber Laufzeit ist mit Sicherheit kleiner.

einer=tab[secondbyte & 0x0f];
zehner=tab[secondbyte>>4];
hunderter=tab[firstbyte & 0x0f];

Aber ich schiebe es trotzdem nicht durch den Compiler, beides geht.

Ok, da war Lothar schneller :-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

H.Joachim S. schrieb:
> zehner=tab[secondbyte>>4];
Stimmt, da war ich zu übervorsichtig, da muss man eigentlich nichts 
maskieren... ;-)

Dahingehend korrigiert sieht mein Vorschlag so aus:

//                 Hunderter             Zehner                    Einer
uint16_t result =  remap[firstbyte]<<8 | remap[secondbyte>>4]<<4 | remap[secondbyte&0xf];

Das Ergebnis bleibt sich gleich.

[Andreas B. (bitverdreher)]

Falls Dich Tabellen stören:

zahlneu = (zahl&249) | ((zahl & 2)<<1) | ((zahl & 4)>>1))

[Nick M. (Gast)]

Die Methode mit dem remap ist jedenfalls die lesbarste von Allen.
Ja, braucht mehr Platz und ist wohl auch nicht so schnell wie maskieren 
und shiften.
Aber jedenfalls eleganter als die 12 if aus der 1. Antwort (OMG!)


Nick

[H.Joachim S. (crazyhorse)]

Er wills ja gar nicht in eine 16bit-Zahl haben, sondern in 3 einzelne 
chars.

NegativeOne! schrieb:
> und dabei auf drei 8-bit Variablen verteilen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Nick M. schrieb:
> Ja, braucht mehr Platz und ist wohl auch nicht so schnell wie maskieren
> und shiften.
Worauf basieren diese Annahmen?
Der Compiler kann so einen Arrayzugriff recht effizient umsetzen...
Das Array braucht einmalig Speicher (und wenn der unbedingt gespart 
werden muss, dann kann man da auch ein uint8_t Array draus machen, muss 
dann aber vor dem <<8 noch auf uint16_t casten, denn denn sonst kommt da 
sicher 0 raus).

H.Joachim S. schrieb:
> wills ja gar nicht in eine 16bit-Zahl haben, sondern in 3 einzelne chars.
Warts ab, was danach noch kommt. Üblicherweise braucht man solche Werte 
im Programm nämlich "am Stück" in einer einzigen Variablen. Nenne es 
einfach "Hellsehen"...  ;-)

[Andreas B. (bitverdreher)]

Lothar M. schrieb:
> Warts ab, was danach noch kommt. Üblicherweise braucht man solche Werte
> im Programm nämlich "am Stück" in einer einzigen Variablen. Nenne es
> einfach "Hellsehen"...  ;-)

Nee, glaube ich nicht. Er redet von BCD codieren. Das habe ich aber auch 
überlesen.

[Nick M. (Gast)]

Lothar M. schrieb:
> Worauf basieren diese Annahmen?

Auf Erfahrung. Aber man kann ja den Code compilieren und die Größe 
beider Varianten ansehen.

Nick

[H.Joachim S. (crazyhorse)]

Beides möglich :-)

Weil ich ja so gern recht habe:
Lieber schuchkleisser, dein if/foo/bar-Gekröse braucht 28Byte mehr.
Soviel zu voreiligen Behauptungen :-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas B. schrieb:
> Er redet von BCD codieren.
Dann dürfte der Schaltern nur 10 Stellungen haben und dann muss man die 
Umrechnung in 1 einzigen Wert so machen:

uint16_t result =  remap[firstbyte]*100 + remap[secondbyte>>4]*10 + remap[secondbyte&0xf];

[H.Joachim S. (crazyhorse)]

Lothar M. schrieb:
> Dann dürfte der Schaltern nur 10 Stellungen haben

hat er ja auch:
NegativeOne! schrieb:
> Über drei BCD Codierschalter soll eine Dezimalzahl eingestellt
> werden...0-999.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

H.Joachim S. schrieb:
> hat er ja auch:
> NegativeOne! schrieb:
>> Über drei BCD Codierschalter soll eine Dezimalzahl eingestellt
>> werden...0-999.
Da passt ja mein letzter Vorschlag wie die Faust ins Auge: als result 
kommt genau so eine Zahl heraus... ;-)

Auf dem AVR braucht dieses Programm dann 280 Bytes im Programmspeicher 
und 20 im Datenspeicher:

#include <avr/io.h>
#include <stdio.h>
#include <stdint.h>

uint8_t firstbyte  = 0x01; // Hex Eingabe = 1, 2, 3
uint8_t secondbyte = 0x45;
uint16_t result;

//                           Bits 1 und 2 vertauscht!
//                    {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};
uint8_t remap[16] =   {0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15};

int main()
{
  //        Hunderter                        Zehner                    Einer
  result =  (uint16_t)remap[firstbyte]*100 + remap[secondbyte>>4]*10 + remap[secondbyte&0xf];

  while(1);
}

Die leere main(), also mit auskommentierter result Berechnung, braucht 
172 Bytes im Programmspeicher und 0 Bytes bei den Daten. Verbleiben 108 
Bytes für die Berechnung.

Die angepaste Lösung mit der if-Abfrage der Werte braucht 286 Bytes 
Programm und 4 Bytes Daten, was abzüglich der leeren main() dann 114 
Bytes Programmspeicherbedarf ergibt:

#include <avr/io.h>
#include <stdio.h>
#include <stdint.h>

uint8_t firstbyte  = 0x01; // Hex Eingabe = 1, 2, 3
uint8_t secondbyte = 0x45;
uint16_t result;

int main()
{
  unsigned char foo;
  unsigned char bar=0;
  
  foo = firstbyte;
  if (foo & 0x01) bar += 0x1;
  if (foo & 0x02) bar += 0x4;
  if (foo & 0x04) bar += 0x2;
  if (foo & 0x08) bar += 0x8;
  result = bar*100;

  foo = secondbyte>>4;
  bar = 0;
  if (foo & 0x01) bar += 0x1;
  if (foo & 0x02) bar += 0x4;
  if (foo & 0x04) bar += 0x2;
  if (foo & 0x08) bar += 0x8;
  result += bar*10;

  foo = secondbyte&0xf;
  bar = 0;
  if (foo & 0x01) bar += 0x1;
  if (foo & 0x02) bar += 0x4;
  if (foo & 0x04) bar += 0x2;
  if (foo & 0x08) bar += 0x8;
  result += bar;  
  
  while(1);
}

[H.Joachim S. (crazyhorse)]

Fast, er will keine 16bit-Zahl.
Eigentlich war die Ursprungsfrage/Ziel absolut vollständig gestellt, das 
ist selten hier :-)
-3 BCD-Schalter werden seriell in 2 Byte eingelesen
-die Schalter liefern negative Logik
-die Bitpositionen sind verwurstet, aber bei allen gleich
-Ziel: 3 8bit-Variablen mit je 0..9, also unpacked BCD

[Wilhelm M. (wimalopaan)]

Und wer die LUT für beliebige Vertauschungen im Layout nicht zu Fuß 
erstellen möchte (und auch zusätzlich noch eine Laufzeitfunktion zum 
Vertauschen beliebiger Bits haben möchte), kann folgendes machen 
(Erstellen der LUT zur Compile-Zeit):

#include <cstddef>
#include <array>

template<uint8_t Bit1, uint8_t Bit2, typename T>
inline constexpr T swapBits(T v) {
    static_assert(Bit1 != Bit2);
    static_assert(Bit1 < sizeof(T) * 8);
    static_assert(Bit2 < sizeof(T) * 8);
    
    constexpr T mask1{(1 << Bit1)};
    constexpr T mask2{(1 << Bit2)};
    constexpr T mask{mask1 | mask2};
    
    return T(v & ~mask) | T(((v & mask1) >> Bit1) << Bit2) | T(((v & mask2) >> Bit2) << Bit1);
}

constinit auto lut = []{
    using lut_type = std::array<std::byte, 16>;
    using size_type = lut_type::size_type;
    lut_type l;
    for(size_type i = 0; i < l.size(); ++i) {
        l[i] = swapBits<1,2>(std::byte{i});
    }
    return l;
}();

volatile std::byte firstByte;
volatile std::byte secondByte;

int main() {
    auto c1 = lut[uint8_t(firstByte & 0x0f_B)];
    auto c2 = lut[uint8_t(secondByte >> 4)];
    auto c3 = lut[uint8_t(secondByte & 0x0f_B)];
    
    while(true);
}

[Jens M. (schuchkleisser)]

H.Joachim S. schrieb:
> Lieber schuchkleisser, dein if/foo/bar-Gekröse braucht 28Byte mehr.

Wo?

Im PIC geht das mit insgesamt 27 Instruktionen/Words.
Das Compiler so dämlich sind und das nicht können, und/oder das die 
Architektur hier nicht genannt wurde, dafür kann ich nix.
LUT und Schieberei sind da definitiv größer. Das mag unter bestimmten 
Prozessoren egal sein, aber ich bin ein Freund kompakten Codes, und 
damit mein ich nicht das geschriebene, sondern das Ergebnis. Was nicht 
bedeuten muss das es unleserlich wird.

Das mein Vorschlag natürlich ebenso gleich die dezimalisierung 
übernehmen kann ist klar.
Und seid mir nicht böse, aber die Umsetzung der Tabelle (4bit) in ein 
uint16 und die Schieberei der Bits finde ich alles andere als 
übersichtlich.
Wenn da steht (Schalter a, Bit 1 = tausender bit 3) und man dann 
"x+=800;" schreibt, da weiß man wenigstens wie der Wert berechnet wurde.
Auch wenn ich zugeben muss, das es als Zweizeiler sehr kompakt 
geschrieben ist.

Wobei die Gesamtlösung auch z.B. vom Schaltplan abhängt: sind wirklich 
alle 3 Schalter gleich vertauscht? Wenn nicht, braucht man 2 oder 3 
LUTs.
Aber bitte, jeder hat seins.
Meine Lösung hat z.B. den Vorteil, beliebig viele Bits aus beliebigen 
Bytes in andere beliebige Bytes transferieren zu können, inklusive 
teilweiser negierung oder dezimalisierung.
Das erleichtert die Layouterstellung enorm, macht den Schaltplan aber 
nicht unbedingt lesbarer...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

H.Joachim S. schrieb:
> -die Schalter liefern negative Logik
Also vorher noch invertieren ;-)
> -die Bitpositionen sind verwurstet, aber bei allen gleich
> -Ziel: 3 8bit-Variablen mit je 0..9, also unpacked BCD
Dieses "Ziel" erscheint mir angesichts der Formulierung "ich muss 
daher..." eher als "Zwischenziel", das dem sequenziellen Programm- und 
Lösungsablauf geschuldet ist.

Finales Ziel dürfte die Aufgabenstellung in der ersten Zeile sein, wo
NegativeOne! schrieb:
>>> soll eine Dezimalzahl eingestellt werden...0-999

Aber warten wirs ab...

[Jens M. (schuchkleisser)]

Lothar M. schrieb:
> foo = secondbyte&0xf;
>   bar = 0;
>   if (foo & 0x01) bar += 0x1;
>   if (foo & 0x02) bar += 0x4;
>   if (foo & 0x04) bar += 0x2;
>   if (foo & 0x08) bar += 0x8;
>   result += bar;

weil das ja auch gar nicht f-ing uneffizient implementiert ist.
Wenn man direkt if (secondbyte &0x..) macht und direkt (result += ..), 
spart man die Maskierung, Zuweisungen und die Multiplikation ein, was 
den Code verkürzt und die Lesbarkeit nicht verschlechtert.
Teste das bitte nochmal, aber diesmal mit nicht auf "ich beweis das 
meine Lösung kürzer ist"-Voreinstellungen... ;)

Wilhelm M. schrieb:
> Und wer die LUT für beliebige Vertauschungen im Layout nicht zu Fuß
> erstellen möchte (und auch zusätzlich noch eine Laufzeitfunktion zum
> Vertauschen beliebiger Bits haben möchte), kann folgendes machen
> (Erstellen der LUT zur Compile-Zeit):

Ach du Sch....
Das ist weder lesbarer, noch kürzer. Mit Glück flexibler...
Wie lange muss man im dunklen Keller C büffeln bis man so ein Monstrum 
lesen und konstruieren kann?

[Frank M. (ukw) (Moderator)]

Jens M. schrieb:
> Wie lange muss man im dunklen Keller C büffeln bis man so ein Monstrum
> lesen und konstruieren kann?

C hilft da nicht weiter. Das ist C++. Und auch nicht jedes x-beliebige, 
sondern ein neuerer Dialekt, wenn nicht sogar der allerneueste. Damit 
verhindert man erfolgreich, dass man das Programm-Beispiel mit 
demjenigen gcc-Compiler zum Laufen bringt, den man gerade so zufällig 
auf dem Rechner rumfliegen hat. Wenn Wilhelm seine C++-Beispiele 
auspackt, ist meistens erstmal eine Neuinstallation angesagt, um das 
nachvollziehen zu können.

Möchte das vielleicht noch jemand in Oberon oder Python formulieren, um 
noch mehr Unsicherheit für den TO zu schaffen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jens M. schrieb:
> Teste das bitte nochmal, aber diesmal mit nicht auf "ich beweis das
> meine Lösung kürzer ist"-Voreinstellungen...
Häh, wo habe ich das gemacht? Ich habe doch sogar bewiesen, dass die 
if-Afragerei nur ein Fünftel des Datenspeichers braucht.

Das Weglassen der foo ändert gar nichts. So schlau ist der Compiler 
offenbar sowieso, dass er die Berechnungen nicht 4 mal macht, sondern 
einen Zwischenwert ausrechnet:

int main()
{
  unsigned char bar=0;
  
  if (firstbyte & 0x01) bar += 0x1;
  if (firstbyte & 0x02) bar += 0x4;
  if (firstbyte & 0x04) bar += 0x2;
  if (firstbyte & 0x08) bar += 0x8;
  result = bar*100;

  bar = 0;
  if (secondbyte>>4 & 0x01) bar += 0x1;
  if (secondbyte>>4 & 0x02) bar += 0x4;
  if (secondbyte>>4 & 0x04) bar += 0x2;
  if (secondbyte>>4 & 0x08) bar += 0x8;
  result += bar*10;

  bar = 0;
  if (secondbyte&0xf & 0x01) bar += 0x1;
  if (secondbyte&0xf & 0x02) bar += 0x4;
  if (secondbyte&0xf & 0x04) bar += 0x2;
  if (secondbyte&0xf & 0x08) bar += 0x8;
  result += bar;  
  
  while(1);
}

Ergebnis:
Program Memory Usage   :  286 bytes
Data Memory Usage   :  4 bytes


Und diese Lösung:

int main()
{
  result = 0;
  if (firstbyte & 0x01) result += 100;
  if (firstbyte & 0x02) result += 400;
  if (firstbyte & 0x04) result += 200;
  if (firstbyte & 0x08) result += 800;
  if (secondbyte>>4 & 0x01)  result += 10;
  if (secondbyte>>4 & 0x02)  result += 40;
  if (secondbyte>>4 & 0x04)  result += 20;
  if (secondbyte>>4 & 0x08)  result += 80;
  if (secondbyte&0xf & 0x01) result += 1;
  if (secondbyte&0xf & 0x02) result += 4;
  if (secondbyte&0xf & 0x04) result += 2;
  if (secondbyte&0xf & 0x08) result += 8;
  
  while(1);
}

braucht:
Program Memory Usage   :  432 bytes
Data Memory Usage   :  4 bytes


Bewertung (samt Abzug der leeren main() Funktion) bitte selber 
durchführen, sonst wird nur wieder der Überbringer der Botschaft 
gesteinigt.

Der Grund für den großen Codebedarf der letzten Variante liegt darin, 
dass die ganzen zu addierenden unterschiedlichen Zahlen 1,2,...800 ja 
alle als 16-Bit Integer in den Code müssen.

[leo (Gast)]

Wilhelm M. schrieb:
> template<uint8_t Bit1, uint8_t Bit2, typename T>

und weitere ~30 Zeilen.

Wie immer die laengste, komlizierteste, unleserlichste und unnoetigste 
"Loesung" weit und breit ;-)

leo

[Jens M. (schuchkleisser)]

Danke für den Beweis.
OmfG was sind Compiler schlecht.

PIC kann so (Man möge mir verzeihen, AVR-Assembler kann ich nicht):

clrf result1
clrf result2
clrf result3
btfss firstbyte,x
bsf result1,y
btfss firstbyte,x
bsf result1,y
btfss firstbyte,x
bsf result1,y
...

Abseits der vorhandenen RAMs für die Eingangs- und Ausgangswerte kein 
weiterer RAM-Verbrauch und nur 27 Flashzellen.
In AVR sollte das ähnlich gehen, der hat allerdings ja auch 
mehrbyte-Befehle.
Gibts da BitTest und BitSet?

[Wilhelm M. (wimalopaan)]

leo schrieb:
> Wilhelm M. schrieb:
>> template<uint8_t Bit1, uint8_t Bit2, typename T>
>
> und weitere ~30 Zeilen.
>
> Wie immer die laengste, komlizierteste, unleserlichste und unnoetigste
> "Loesung" weit und breit ;-)

Naja, swapBits<> steckt man einmal in seinem Leben irgendwo in eine 
Headerdatei. Fertig.

Die Generierung der LUT verhindert Copy-n-Paste-Fehler oder schlichtes 
Verrechnen.

Zusätzlich hat man hier eine beliebig konfigurierbare Lösung für 
beliebige Vertauschungen im Layout.
Und man kann wählen, welchen Speed <-> Memory-Tradeoff man haben will 
(bis zu dem Punkt, wo die LUT 256 Einträge hat). Flexibler geht es kaum. 
Und die LUT-Lösung ist die kürzeste und schnellste.

[Wilhelm M. (wimalopaan)]

Jens M. schrieb:

> Gibts da BitTest und BitSet?

Na klar, und die benutzt dre Compiler auch.

[Marten Morten (Gast)]

Lothar M. schrieb:
> Andreas B. schrieb:
>> Er redet von BCD codieren.
> Dann dürfte der Schaltern nur 10 Stellungen haben und dann muss man die
> Umrechnung in 1 einzigen Wert so machen:
>

> uint16_t result =  remap[firstbyte]*100 + remap[secondbyte>>4]*10 + 
> remap[secondbyte&0xf];
>

Viel zu einfach :-)

Da es im Thread nur noch um das Aufblasen von Code geht würde ich für 
die Konvertierung von BCD nach Binär den Reverse Double Dabble 
Algorithmus vorschlagen.

Da kommt anständig was zusammen. Bei drei BCD Ziffern sind das für die 
Wandlung bis zu 10 Iterationen mit je einem Shift pro Iteration. Dazu 
pro BCD Ziffer ein Vergleich pro Iteration, also drei pro Iteration, 
eventuell mit vorheriger Maskierung. Nicht zu vergessen je nach Ergebnis 
des Vergleichs eine Subtraktion pro BCD Ziffer und Iteration, also 
maximal 30 Subtraktionen. Zum Schluss das Nachjustieren des Ergebnisses 
mit Shifts wenn weniger als zehn Iterationen benötigt wurden. So macht 
Code mit Bit-Shiften richtig was her :-)

[guest (Gast)]

Lothar M. schrieb:
>   if (secondbyte>>4 & 0x01)  result += 10;
>   if (secondbyte>>4 & 0x02)  result += 40;
>   if (secondbyte>>4 & 0x04)  result += 20;
>   if (secondbyte>>4 & 0x08)  result += 80;

Wozu denn die Bitshifterei?

  if (secondbyte & 0x10)  result += 10;
  if (secondbyte & 0x20)  result += 40;
  if (secondbyte & 0x40)  result += 20;
  if (secondbyte & 0x80)  result += 80;

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

guest schrieb:
> Wozu denn die Bitshifterei?
So:

int main()
{
  result = 0;
  if (firstbyte & 0x01) result += 100;
  if (firstbyte & 0x02) result += 400;
  if (firstbyte & 0x04) result += 200;
  if (firstbyte & 0x08) result += 800;
  if (secondbyte & 0x10)  result += 10;
  if (secondbyte & 0x20)  result += 40;
  if (secondbyte & 0x40)  result += 20;
  if (secondbyte & 0x80)  result += 80;
  if (secondbyte&0xf & 0x01) result += 1;
  if (secondbyte&0xf & 0x02) result += 4;
  if (secondbyte&0xf & 0x04) result += 2;
  if (secondbyte&0xf & 0x08) result += 8;
  
  while(1);
}

sinds dann
Program Memory Usage :  426 bytes
Data Memory Usage    :  4 bytes

[Jens M. (schuchkleisser)]

426 Bytes, ein Horror.
Wird das weniger, wenn man statt der Addition den Compiler mit der Nase 
drauf stößt und ein Or benutzt?
Ich denke, der hat tatsächlich eine gestackte 16-Bit-Addition mit 
eingebaut und merkt sich 12 16bit große Integer, anstatt einfach ein 
BitSet zu machen.

[Peter D. (peda)]

Man kann das noch weiter optimieren, indem man zuerst das Low-Byte 
berechnet:

uint16_t bcd3(uint16_t in)
{
  uint8_t outl = 0;
  if (in & 0x0001) outl += 100;
  if (in & 0x1000) outl += 10;
  if (in & 0x2000) outl += 40;
  if (in & 0x4000) outl += 20;
  if (in & 0x8000) outl += 80;
  if (in & 0x0100) outl += 1;
  if (in & 0x0200) outl += 4;
  if (in & 0x0400) outl += 2;
  if (in & 0x0800) outl += 8;
  uint16_t out = outl;
  if (in & 0x0002) out += 400;
  if (in & 0x0004) out += 200;
  if (in & 0x0008) out += 800;
  return out;
}

Sind auf dem AVR 72 Byte Code.

[Peter D. (peda)]

Jens M. schrieb:
> Wird das weniger, wenn man statt der Addition den Compiler mit der Nase
> drauf stößt und ein Or benutzt?

Nein, weil das falsch ist. Er will ein int als Ergebnis, damit er damit 
rechnen kann.
Ich kenne keinen C-Compiler, der intern mit packed BCD rechnet.

[Wilhelm M. (wimalopaan)]

Peter D. schrieb:
> Sind auf dem AVR 72 Byte Code.

Worum geht es denn: Ausführungszeit, Flash-Size, ggf. RAM-Size, 
Wartbarkeit, ...?

[Jens M. (schuchkleisser)]

Peter D. schrieb:
> Sind auf dem AVR 72 Byte Code.

Alleine nur, weil keine 16bit-Addition dabei ist. Nice!

Peter D. schrieb:
> Nein, weil das falsch ist. Er will ein int als Ergebnis, damit er damit
> rechnen kann.

Was ist der Unterschied zwischen "Addiere 0x40" und "Setze Bit 6"?
Beides unter der Voraussetzung, das der Wert vorher genullt wurde...
Richtig: keiner. Nur ist der Compiler so dämlich das er das nicht merkt 
und fröhlich den (leeren) 16-bit-Wert "0" auf den Stack schiebt, dann 
den zu addierenden "0x0040" hinterher, dann kommt der Call der 
offensichtlich ncht gerade kleinen Addierungsroutine, anschließend wird 
der Wert des Ergebnisses vom Stack in den Variablenspeicher kopiert.
All das ist ein einziger BitSet-Befehl.
Der Peda hat's ja schon gezeigt, alleine nur die 8-Bit-Rechnung spart 
schon ~80% Code ein.

[Peter D. (peda)]

Wilhelm M. schrieb:
> Worum geht es denn: Ausführungszeit, Flash-Size, ggf. RAM-Size,
> Wartbarkeit, ...?

Diese Variante ist in allen 4 Punkten optimal.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jens M. schrieb:
> Wenn man direkt if (secondbyte &0x..) macht und direkt (result += ..),
> spart man die Maskierung, Zuweisungen und die Multiplikation ein
Da sieht man, was der Compiler draus macht:

  result = 0;
  a6:  10 92 03 01   sts  0x0103, r1  ; 0x800103 <__data_end+0x1>
  aa:  10 92 02 01   sts  0x0102, r1  ; 0x800102 <__data_end>
  if (firstbyte & 0x01) result += 100;
  ae:  80 91 01 01   lds  r24, 0x0101  ; 0x800101 <firstbyte>
  b2:  80 ff         sbrs  r24, 0
  b4:  06 c0         rjmp  .+12       ; 0xc2 <main+0x1c>
  b6:  24 e6         ldi  r18, 0x64  ; 100
  b8:  30 e0         ldi  r19, 0x00  ; 0
  ba:  30 93 03 01   sts  0x0103, r19  ; 0x800103 <__data_end+0x1>
  be:  20 93 02 01   sts  0x0102, r18  ; 0x800102 <__data_end>
  if (firstbyte & 0x02) result += 400;
  c2:  81 ff         sbrs  r24, 1
  c4:  0a c0         rjmp  .+20       ; 0xda <main+0x34>
  c6:  20 91 02 01   lds  r18, 0x0102  ; 0x800102 <__data_end>
  ca:  30 91 03 01   lds  r19, 0x0103  ; 0x800103 <__data_end+0x1>
  ce:  20 57         subi  r18, 0x70  ; 112
  d0:  3e 4f         sbci  r19, 0xFE  ; 254
  d2:  30 93 03 01   sts  0x0103, r19  ; 0x800103 <__data_end+0x1>
  d6:  20 93 02 01   sts  0x0102, r18  ; 0x800102 <__data_end>
  if (firstbyte & 0x04) result += 200;
  da:  82 ff         sbrs  r24, 2
  dc:  0a c0         rjmp  .+20       ; 0xf2 <main+0x4c>
  de:  20 91 02 01   lds  r18, 0x0102  ; 0x800102 <__data_end>
  e2:  30 91 03 01   lds  r19, 0x0103  ; 0x800103 <__data_end+0x1>
  e6:  28 53         subi  r18, 0x38  ; 56
  e8:  3f 4f         sbci  r19, 0xFF  ; 255
  ea:  30 93 03 01   sts  0x0103, r19  ; 0x800103 <__data_end+0x1>
  ee:  20 93 02 01   sts  0x0102, r18  ; 0x800102 <__data_end>

Er verwendet natürlich den sbrs Befehl. Aber er muss nach jeder 
if-Abfrage den Wert mit 16 Bit berechnen und gleich darauf abspeichern, 
weil es ja sein könnte, dass keine der nachfolgenden if-Abfragen mehr 
greift.

Die Variante mit der direkten Abfrage von firstbyte/secondbyte und 
Berechnung auf der lokalen Variabeln bar im 
Beitrag "Re: Bits shiften - ich verstehe es nicht." 
enthält noch einen Fehler: bar ist nur 8 Bit breit.
Mit der korrigierten Variante hier

int main()
{
  uint16_t bar=0;
  
  if (firstbyte & 0x01) bar += 0x1;
  if (firstbyte & 0x02) bar += 0x4;
  if (firstbyte & 0x04) bar += 0x2;
  if (firstbyte & 0x08) bar += 0x8;
  result = bar*100;

  bar = 0;
  if (secondbyte>>4 & 0x01) bar += 0x1;
  if (secondbyte>>4 & 0x02) bar += 0x4;
  if (secondbyte>>4 & 0x04) bar += 0x2;
  if (secondbyte>>4 & 0x08) bar += 0x8;
  result += bar*10;

  bar = 0;
  if (secondbyte&0xf & 0x01) bar += 0x1;
  if (secondbyte&0xf & 0x02) bar += 0x4;
  if (secondbyte&0xf & 0x04) bar += 0x2;
  if (secondbyte&0xf & 0x08) bar += 0x8;
  result += bar;
  
  while(1);
}

ergibt sich dann natürlich Mehraufwand:
Program Memory Usage   :  312 bytes
Data Memory Usage   :  4 bytes

Und das ist ein Ausschnitt fürs Hunderternibble vom Assemblercode:

int main()
{
  uint16_t bar=0;
  aa:  42 2f         mov  r20, r18
  ac:  41 70         andi  r20, 0x01  ; 1
  ae:  50 e0         ldi  r21, 0x00  ; 0
  b0:  ca 01         movw  r24, r20
  
  if (firstbyte & 0x01) bar += 0x1;
  if (firstbyte & 0x02) bar += 0x4;
  b2:  21 fd         sbrc  r18, 1
  b4:  04 96         adiw  r24, 0x04  ; 4
  if (firstbyte & 0x04) bar += 0x2;
  b6:  22 fd         sbrc  r18, 2
  b8:  02 96         adiw  r24, 0x02  ; 2
  if (firstbyte & 0x08) bar += 0x8;
  ba:  23 fd         sbrc  r18, 3
  bc:  08 96         adiw  r24, 0x08  ; 8
  result = bar*100;
  be:  24 e6         ldi  r18, 0x64  ; 100
  c0:  28 9f         mul  r18, r24
  c2:  a0 01         movw  r20, r0
  c4:  29 9f         mul  r18, r25
  c6:  50 0d         add  r21, r0
  c8:  11 24         eor  r1, r1

Und zu guter Letzt nochmal die LUT-Variante, bei der vorrangig die 
beiden Multiplikationen (und dabei besonders die *10 mit ihren vielen 
Additionen) hervorstechen:

int main()
{
  result =  remap[firstbyte]*100  + remap[secondbyte>>4]*10 + remap[secondbyte&0xf]; // 278-172 = 106 Bytes
  a6:  20 91 10 01   lds  r18, 0x0110  ; 0x800110 <secondbyte>
  aa:  e0 91 11 01   lds  r30, 0x0111  ; 0x800111 <firstbyte>
  ae:  f0 e0         ldi  r31, 0x00  ; 0
  b0:  e0 50         subi  r30, 0x00  ; 0
  b2:  ff 4f         sbci  r31, 0xFF  ; 255
  b4:  30 81         ld  r19, Z
  b6:  e2 2f         mov  r30, r18
  b8:  e2 95         swap  r30
  ba:  ef 70         andi  r30, 0x0F  ; 15
  bc:  f0 e0         ldi  r31, 0x00  ; 0
  be:  e0 50         subi  r30, 0x00  ; 0
  c0:  ff 4f         sbci  r31, 0xFF  ; 255
  c2:  80 81         ld  r24, Z
  c4:  90 e0         ldi  r25, 0x00  ; 0
  c6:  ac 01         movw  r20, r24
  c8:  44 0f         add  r20, r20
  ca:  55 1f         adc  r21, r21
  cc:  88 0f         add  r24, r24
  ce:  99 1f         adc  r25, r25
  d0:  88 0f         add  r24, r24
  d2:  99 1f         adc  r25, r25
  d4:  88 0f         add  r24, r24
  d6:  99 1f         adc  r25, r25
  d8:  84 0f         add  r24, r20
  da:  95 1f         adc  r25, r21
  dc:  44 e6         ldi  r20, 0x64  ; 100
  de:  34 9f         mul  r19, r20
  e0:  80 0d         add  r24, r0
  e2:  91 1d         adc  r25, r1
  e4:  11 24         eor  r1, r1
  e6:  e2 2f         mov  r30, r18
  e8:  ef 70         andi  r30, 0x0F  ; 15
  ea:  f0 e0         ldi  r31, 0x00  ; 0
  ec:  e0 50         subi  r30, 0x00  ; 0
  ee:  ff 4f         sbci  r31, 0xFF  ; 255
  f0:  20 81         ld  r18, Z
  f2:  82 0f         add  r24, r18
  f4:  91 1d         adc  r25, r1
  f6:  90 93 13 01   sts  0x0113, r25  ; 0x800113 <__data_end+0x1>
  fa:  80 93 12 01   sts  0x0112, r24  ; 0x800112 <__data_end>

Wobei hier bereits das Abholen der Variabeln und Abspeichern des 
Ergebnisses 16 Bytes brauchen... ;-)

Jens M. schrieb:
> Der Peda hat's ja schon gezeigt, alleine nur die 8-Bit-Rechnung spart
> schon ~80% Code ein.
Nur kommt da halt keiner drauf. Oder eben nur einer von vielen mit dem 
Hintergrundwissen, dass man dem Compiler "nach dem Maul" programmieren 
und zuerst so lange wie möglich mit einem 8-Bit Wert rechnen muss.


Peter D. schrieb:
> Sind auf dem AVR 72 Byte Code.
Ich habe diesen "Netto"-Code mal angewendet und komme in der realen 
"Brutto"-Anwendung wie hier:

uint16_t bcd3(uint16_t in)
{
  uint8_t outl = 0;
  if (in & 0x0001) outl += 100;
  if (in & 0x1000) outl += 10;
  if (in & 0x2000) outl += 40;
  if (in & 0x4000) outl += 20;
  if (in & 0x8000) outl += 80;
  if (in & 0x0100) outl += 1;
  if (in & 0x0200) outl += 4;
  if (in & 0x0400) outl += 2;
  if (in & 0x0800) outl += 8;
  uint16_t out = outl;
  if (in & 0x0002) out += 400;
  if (in & 0x0004) out += 200;
  if (in & 0x0008) out += 800;
  return out;
}

int main()
{
  result =  bcd3((uint16_t)firstbyte<<8 + secondbyte);

  while(1);
}

auf
Program Memory Usage   :  288 bytes
Data Memory Usage   :  4 bytes


Dann habe ich die LUT-Variante zum ernsthaften Vergleich auch mal 
umgebaut und einen Funktionsaufruf draus gemacht:

uint8_t remap[16] =   {0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15};

uint16_t bcd3(uint8_t firstbyte, uint8_t secondbyte)
{
  return remap[firstbyte]*100  + remap[secondbyte>>4]*10 + remap[secondbyte&0xf];;
}

int main()
{
  result =  bcd3(firstbyte, secondbyte);

  while(1);
}

Ergebnis:
Program Memory Usage   :  290 bytes
Data Memory Usage   :  20 bytes


Schlüsse bitte selber ziehen...

Peter D. schrieb:
>> Ausführungszeit, Flash-Size, ggf. RAM-Size, Wartbarkeit, ...?
> Diese Variante ist in allen 4 Punkten optimal.
Bei der Wartbarkeit möchte ich da mal einhaken: ich bin mir 100% sicher, 
dass einige schon bei der ersten if-Abfrage in dieser Funktion ins 
Schleudern kommen und die nach unten umsortieren. Dorthin, zu den 
Hundertern, wo sie ihrem Gefühl nach auch hingehört...  ;-)

So etwa:

uint16_t bcd3(uint16_t in)
{
  uint8_t outl = 0;
  if (in & 0x1000) outl += 10;
  if (in & 0x2000) outl += 40;
  if (in & 0x4000) outl += 20;
  if (in & 0x8000) outl += 80;
  if (in & 0x0100) outl += 1;
  if (in & 0x0200) outl += 4;
  if (in & 0x0400) outl += 2;
  if (in & 0x0800) outl += 8;
  uint16_t out = outl;
  if (in & 0x0001) out += 100;
  if (in & 0x0002) out += 400;
  if (in & 0x0004) out += 200;
  if (in & 0x0008) out += 800;
  return out;
}

int main()
{
  result =  bcd3((uint16_t)secondbyte<<8 + firstbyte);

  while(1);
}

Ergebnis dieser Änderung im obigen Gesamtprogramm:
Program Memory Usage   :  292 bytes

[Peter D. (peda)]

Lothar M. schrieb:
> Aber er muss nach jeder
> if-Abfrage den Wert mit 16 Bit berechnen und gleich darauf abspeichern,
> weil es ja sein könnte, dass keine der nachfolgenden if-Abfragen mehr
> greift.

Und genau deshalb sollte man globale Variablen meiden, wie der Teufel 
das Weihwasser.

[S. R. (svenska)]

Wilhelm M. schrieb:
> Die Generierung der LUT verhindert Copy-n-Paste-Fehler
> oder schlichtes Verrechnen.

Und wenn man dem Template falsche Parameter gibt (z.B. durch 
Copy-n-Paste-Fehler oder schlichtes Verrechnen aus dem Schaltplan), dann 
sucht man daran stundenlang herum. Einfach hinschreiben macht es für den 
Menschen einfacher.

[Lutz S. (lutzs)]

Interessante Diskussion, vielen Dank an alle Beteiligten.

[Marten Morten (Gast)]

Lothar M. schrieb:
> Bei der Wartbarkeit möchte ich da mal einhaken: ich bin mir 100% sicher,
> dass einige schon bei der ersten if-Abfrage in dieser Funktion ins
> Schleudern kommen und die nach unten umsortieren. Dorthin, zu den
> Hundertern, wo sie ihrem Gefühl nach auch hingehört...  ;-)

Manche Programmierer verwenden Kommentare um auf solche Besonderheiten 
hinzuweisen :-)

> Ich habe diesen "Netto"-Code mal angewendet und komme in der realen
> "Brutto"-Anwendung wie hier:
>
> uint16_t bcd3(uint16_t in)
> {
>   uint8_t outl = 0;
>   if (in & 0x0001) outl += 100;
>   if (in & 0x1000) outl += 10;
>   if (in & 0x2000) outl += 40;
>   if (in & 0x4000) outl += 20;
>   if (in & 0x8000) outl += 80;
>   if (in & 0x0100) outl += 1;
>   if (in & 0x0200) outl += 4;
>   if (in & 0x0400) outl += 2;
>   if (in & 0x0800) outl += 8;
>   uint16_t out = outl;
>   if (in & 0x0002) out += 400;
>   if (in & 0x0004) out += 200;
>   if (in & 0x0008) out += 800;
>   return out;
> }
>
> int main()
> {
>   result =  bcd3((uint16_t)firstbyte<<8 + secondbyte);
>
>   while(1);
> }


Ohne es ausgemessen zu haben und für einen Compiler der keine 
Integer-Promotion von 8-Bit Argumenten macht:

//
// Convert the BCD input to an int.
// Accounts for the fact that bits 2 <-> 3 and 5 <-> 6 are
// swapped in the input due to hardware idiosyncrasies
//
uint16_t bcd3(uint8_t first, uint8_t second)
{
  // perform as many operations as possible with 8-bit 
  uint8_t outl = 0;

  // Tenth (second byte high nibble)
  if (second & 0x80) outl += 80;
  if (second & 0x40) outl += 20; //  \_ swapped
  if (second & 0x20) outl += 40; //  /
  if (second & 0x10) outl += 10;

  // Ones (second byte low nibble)
  if (second & 0x08) outl += 8;
  if (second & 0x04) outl += 2; //  \_ swapped
  if (second & 0x02) outl += 4; //  /
  if (second & 0x01) outl += 1;

  // Hundreds (first byte low nibble)
  // 100 still fits in the 8-bit outl variable, so we
  // add it here, not below
  if (first & 0x01) outl += 100;

  // Remaining values don't fit in the 8-but outl, so 
  // convert to 16 bit for the remaining values
  uint16_t out = outl;

  if (first & 0x08) out += 800;
  if (first & 0x04) out += 200; //  \_ swapped
  if (first & 0x02) out += 400; //  /

  return out;
}

int main()
{
  result =  bcd3(firstbyte, secondbyte);

  while(1);
}

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter D. schrieb:
> Und genau deshalb sollte man globale Variablen meiden, wie der Teufel
> das Weihwasser.
Danke für den Impuls... ;-)
Durch eine lokale Variable auf diese Art:

#include <avr/io.h>
#include <stdio.h>
#include <stdint.h>

uint8_t firstbyte  = 0x01; // Hex Eingabe = 1, 2, 3
uint8_t secondbyte = 0x45;
uint16_t result;

int main()
{
  uint16_t r = 0;
  if (firstbyte & 0x01)      r += 100;
  if (firstbyte & 0x02)      r += 400;
  if (firstbyte & 0x04)      r += 200;
  if (firstbyte & 0x08)      r += 800;
  if (secondbyte>>4 & 0x01)  r += 10;
  if (secondbyte>>4 & 0x02)  r += 40;
  if (secondbyte>>4 & 0x04)  r += 20;
  if (secondbyte>>4 & 0x08)  r += 80;
  if (secondbyte & 0x01)     r += 1;
  if (secondbyte & 0x02)     r += 4;
  if (secondbyte & 0x04)     r += 2;
  if (secondbyte & 0x08)     r += 8;
  result = r;
  
  while(1);
}

sieht das Ganze schon wesentlich besser aus:
Program Memory Usage   :  270 bytes
Data Memory Usage  :  4 bytes

Und auch die Variante mit Funktionsaufruf sieht gut aus:

uint16_t bcd3(uint8_t firstbyte, uint8_t secondbyte)
{
  uint16_t r = 0;
  if (firstbyte & 0x01)      r += 100;
  if (firstbyte & 0x02)      r += 400;
  if (firstbyte & 0x04)      r += 200;
  if (firstbyte & 0x08)      r += 800;
  if (secondbyte>>4 & 0x01)  r += 10;
  if (secondbyte>>4 & 0x02)  r += 40;
  if (secondbyte>>4 & 0x04)  r += 20;
  if (secondbyte>>4 & 0x08)  r += 80;
  if (secondbyte & 0x01)     r += 1;
  if (secondbyte & 0x02)     r += 4;
  if (secondbyte & 0x04)     r += 2;
  if (secondbyte & 0x08)     r += 8;
  return r;
}

int main()
{
  result =  bcd3(firstbyte, secondbyte);

  while(1);
}

Program Memory Usage   :  278 bytes
Data Memory Usage   :  4 bytes

Das simple Umsortieren der Abfragen und Zuweisungen analog zu Pedas 
"erst mal nur Bytebearbeitung"-Strategie spart nochmal 4 Bytes:
Program Memory Usage   :  274 bytes

uint16_t bcd3(uint8_t firstbyte, uint8_t secondbyte)
{
  uint16_t r = 0;
  if (secondbyte & 0x01)     r += 1;
  if (secondbyte & 0x02)     r += 4;
  if (secondbyte & 0x04)     r += 2;
  if (secondbyte & 0x08)     r += 8;
  if (secondbyte>>4 & 0x01)  r += 10;
  if (secondbyte>>4 & 0x02)  r += 40;
  if (secondbyte>>4 & 0x04)  r += 20;
  if (secondbyte>>4 & 0x08)  r += 80;
  if (firstbyte & 0x01)      r += 100;
  if (firstbyte & 0x02)      r += 400;
  if (firstbyte & 0x04)      r += 200;
  if (firstbyte & 0x08)      r += 800;
  return r;
}

int main()
{
  result =  bcd3(firstbyte, secondbyte);

  while(1);
}

Denn da erkennt der Compiler, dass er bei den ersten paar Rechnungen das 
höherwertige Byte nicht beackern muss...

[Lutz S. (lutzs)]

Marten Morten schrieb:
> if (second & 0x01) outl += 1;

Wenn man das gleich am Anfang macht kann auch die Addition noch 
entfallen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Marten Morten schrieb:
> Ohne es ausgemessen zu haben
Program Memory Usage   :  268 bytes
Das kommt allein vom Umformatieren von Pedas Code auf 2 Chars statt 1 
Short als Aufrufparameter... ;-)

Der Assembler der 2-Char-Variante:

uint16_t bcd3(uint8_t first, uint8_t second)
{
  // perform as many operations as possible with 8-bit
  uint8_t outl = 0;
  b0:  90 e0         ldi  r25, 0x00  ; 0

  // Tenth (second byte high nibble)
  if (second & 0x80) outl += 80;
  if (second & 0x40) outl += 20; //  \_ swapped
  b2:  66 fd         sbrc  r22, 6
  b4:  9c 5e         subi  r25, 0xEC  ; 236
  if (second & 0x20) outl += 40; //  /
  b6:  65 fd         sbrc  r22, 5
  b8:  98 5d         subi  r25, 0xD8  ; 216
  if (second & 0x10) outl += 10;
  ba:  64 fd         sbrc  r22, 4
  bc:  96 5f         subi  r25, 0xF6  ; 246

  // Ones (second byte low nibble)
  if (second & 0x08) outl += 8;
  be:  63 fd         sbrc  r22, 3
  c0:  98 5f         subi  r25, 0xF8  ; 248
  if (second & 0x04) outl += 2; //  \_ swapped
  c2:  62 fd         sbrc  r22, 2
  c4:  9e 5f         subi  r25, 0xFE  ; 254
  if (second & 0x02) outl += 4; //  /
  c6:  61 fd         sbrc  r22, 1
  c8:  9c 5f         subi  r25, 0xFC  ; 252
  if (second & 0x01) outl += 1;
  ca:  60 fd         sbrc  r22, 0
  cc:  9f 5f         subi  r25, 0xFF  ; 255

  // Hundreds (first byte low nibble)
  // 100 still fits in the 8-bit outl variable, so we
  // add it here, not below
  if (first & 0x01) outl += 100;
  ce:  20 fd         sbrc  r18, 0
  d0:  9c 59         subi  r25, 0x9C  ; 156

  // Remaining values don't fit in the 8-but outl, so
  // convert to 16 bit for the remaining values
  uint16_t out = outl;
  d2:  89 2f         mov  r24, r25
  d4:  90 e0         ldi  r25, 0x00  ; 0

  if (first & 0x08) out += 800;
  d6:  23 ff         sbrs  r18, 3
  d8:  02 c0         rjmp  .+4        ; 0xde <bcd3+0x38>
  da:  80 5e         subi  r24, 0xE0  ; 224
  dc:  9c 4f         sbci  r25, 0xFC  ; 252
  if (first & 0x04) out += 200; //  \_ swapped
  de:  22 ff         sbrs  r18, 2
  e0:  02 c0         rjmp  .+4        ; 0xe6 <bcd3+0x40>
  e2:  88 53         subi  r24, 0x38  ; 56
  e4:  9f 4f         sbci  r25, 0xFF  ; 255
  if (first & 0x02) out += 400; //  /
  e6:  21 ff         sbrs  r18, 1
  e8:  02 c0         rjmp  .+4        ; 0xee <bcd3+0x48>
  ea:  80 57         subi  r24, 0x70  ; 112
  ec:  9e 4f         sbci  r25, 0xFE  ; 254

  return out;
}
  ee:  08 95         ret

000000f0 <main>:

int main()
{
  result =  bcd3(firstbyte, secondbyte);
  f0:  60 91 00 01   lds  r22, 0x0100  ; 0x800100 <__data_start>
  f4:  80 91 01 01   lds  r24, 0x0101  ; 0x800101 <firstbyte>
  f8:  0e 94 53 00   call  0xa6  ; 0xa6 <bcd3>
  fc:  90 93 03 01   sts  0x0103, r25  ; 0x800103 <__data_end+0x1>
 100:  80 93 02 01   sts  0x0102, r24  ; 0x800102 <__data_end>
 104:  ff cf         rjmp  .-2        ; 0x104 <main+0x14>

Und das ist der Assemblercode von Pedas 1-Short-Variante:

uint16_t bcd3(uint16_t in)
{
  uint8_t outl = 0;
  b0:  90 e0         ldi  r25, 0x00  ; 0
  if (in & 0x0001) outl += 100;
  if (in & 0x1000) outl += 10;
  b2:  34 fd         sbrc  r19, 4
  b4:  96 5f         subi  r25, 0xF6  ; 246
  if (in & 0x2000) outl += 40;
  b6:  35 fd         sbrc  r19, 5
  b8:  98 5d         subi  r25, 0xD8  ; 216
  if (in & 0x4000) outl += 20;
  ba:  36 fd         sbrc  r19, 6
  bc:  9c 5e         subi  r25, 0xEC  ; 236
  if (in & 0x8000) outl += 80;
  be:  33 23         and  r19, r19
  c0:  0c f4         brge  .+2        ; 0xc4 <bcd3+0x1e>
  c2:  90 5b         subi  r25, 0xB0  ; 176
  if (in & 0x0100) outl += 1;
  c4:  30 fd         sbrc  r19, 0
  c6:  9f 5f         subi  r25, 0xFF  ; 255
  if (in & 0x0200) outl += 4;
  c8:  31 fd         sbrc  r19, 1
  ca:  9c 5f         subi  r25, 0xFC  ; 252
  if (in & 0x0400) outl += 2;
  cc:  32 fd         sbrc  r19, 2
  ce:  9e 5f         subi  r25, 0xFE  ; 254
  if (in & 0x0800) outl += 8;
  d0:  33 fd         sbrc  r19, 3
  d2:  98 5f         subi  r25, 0xF8  ; 248
  uint16_t out = outl;
  d4:  89 2f         mov  r24, r25
  d6:  90 e0         ldi  r25, 0x00  ; 0
  if (in & 0x0002) out += 400;
  d8:  21 ff         sbrs  r18, 1
  da:  02 c0         rjmp  .+4        ; 0xe0 <bcd3+0x3a>
  dc:  80 57         subi  r24, 0x70  ; 112
  de:  9e 4f         sbci  r25, 0xFE  ; 254
  if (in & 0x0004) out += 200;
  e0:  22 ff         sbrs  r18, 2
  e2:  02 c0         rjmp  .+4        ; 0xe8 <bcd3+0x42>
  e4:  88 53         subi  r24, 0x38  ; 56
  e6:  9f 4f         sbci  r25, 0xFF  ; 255
  if (in & 0x0008) out += 800;
  e8:  23 ff         sbrs  r18, 3
  ea:  02 c0         rjmp  .+4        ; 0xf0 <bcd3+0x4a>
  ec:  80 5e         subi  r24, 0xE0  ; 224
  ee:  9c 4f         sbci  r25, 0xFC  ; 252
  return out;
}
  f0:  08 95         ret

000000f2 <main>:

int main()
{
  result =  bcd3((uint16_t)secondbyte<<8 + firstbyte);
  f2:  20 91 00 01   lds  r18, 0x0100  ; 0x800100 <__data_start>
  f6:  30 e0         ldi  r19, 0x00  ; 0
  f8:  90 91 01 01   lds  r25, 0x0101  ; 0x800101 <firstbyte>
  fc:  98 5f         subi  r25, 0xF8  ; 248
  fe:  a9 01         movw  r20, r18
 100:  02 c0         rjmp  .+4        ; 0x106 <main+0x14>
 102:  44 0f         add  r20, r20
 104:  55 1f         adc  r21, r21
 106:  9a 95         dec  r25
 108:  e2 f7         brpl  .-8        ; 0x102 <main+0x10>
 10a:  ca 01         movw  r24, r20
 10c:  0e 94 53 00   call  0xa6  ; 0xa6 <bcd3>
 110:  90 93 03 01   sts  0x0103, r25  ; 0x800103 <__data_end+0x1>
 114:  80 93 02 01   sts  0x0102, r24  ; 0x800102 <__data_end>
 118:  ff cf         rjmp  .-2        ; 0x118 <main+0x26>

Man sieht, dass die Funktion selber exakt gleich lang ist, und der 
Aufwand nur am Zusammenbasteln des Aufruf-Parameters für bcd3() 
entsteht.

Lutz S. schrieb:
> Wenn man das gleich am Anfang macht kann auch die Addition noch
> entfallen.
Was wie macht?

[Wilhelm M. (wimalopaan)]

Lothar M. schrieb:
> Marten Morten schrieb:
>> Ohne es ausgemessen zu haben
> Program Memory Usage   :  268 bytes

Ist das das text-segment? Dann solltest Du auch den µC-Typ angeben.

[MaWin (Gast)]

Eure Betrachtungen scheinen mir akademisch,
egal wie schnell nud mit wie vielen Befehlsbytes,
denn sie liefern ALLE das falsche Ergebnis,

Laut

NegativeOne! schrieb:
> Und dazu auch noch negiert werden, denn was in den Ergebnis-Bytes eine 1
> sein muss, kommt als 0 aus dem Schieberegister.

aber wir sehen hier:

uint16_t bcd3(uint8_t first, uint8_t second)
{
  uint8_t outl = 0;
  if (second & 0x80) outl += 80;

Wenn das bit in second GESETZT ist, wird auch das bit im Ergebniswert 
gesetzt.

Es müsste

  uint8_t outl = 0;
  if (!(second & 0x80)) outl += 80;

lauten.
Der tabellengesteuerte code braucht natürlich nur andere Tabellenwerte.

[Frank M. (ukw) (Moderator)]

Hier eine Variante, die nochmals 2-4 Bytes Code einspart:

#include <stdint.h>

uint8_t firstbyte;
uint8_t secondbyte;
uint16_t result;

static uint16_t bcdnibble (uint8_t nibble, uint8_t factor)
{
  uint16_t r;
  r = (nibble & 0x09);              // same as (nibble & 0x08) + (nibble & 0x01)
  if (nibble & 0x02) r += 4;        // exchange bits
  if (nibble & 0x04) r += 2;        // exchange bits
  return r * factor;
}

uint16_t bcd3(uint8_t firstbyte, uint8_t secondbyte)
{
  uint16_t r;
  r = bcdnibble (secondbyte, 1) +
      bcdnibble (secondbyte >> 4, 10) +
      bcdnibble (firstbyte, 100);
  return r;
}

int main()
{
  result =  bcd3(firstbyte, secondbyte);

  while(1);
}

Der Witz ist die Reduzierung auf Nibbles, wo man dann mit

r = (nibble & 0x09)

direkt 2 if-Statements und eine zusätzliche Addition vermeidet.
Aber ob das leserlicher ist?

[Wilhelm M. (wimalopaan)]

Peter D. schrieb:
> Wilhelm M. schrieb:
>> Worum geht es denn: Ausführungszeit, Flash-Size, ggf. RAM-Size,
>> Wartbarkeit, ...?
>
> Diese Variante ist in allen 4 Punkten optimal.

Sicher nicht.

Die schnellste Variante ist die, die eine 8KB-LUT verwendet. Und die 
kann man sich mit meinem oben gezeigten Code ganz simpel erstellen 
lassen (zur Compilezeit).

[Marten Morten (Gast)]

Lothar M. schrieb:
> Lutz S. schrieb:
>> Wenn man das gleich am Anfang macht kann auch die Addition noch
>> entfallen.
> Was wie macht?

Wahrscheinlich meint er

uint8_t outl = 0;
if (second & 0x01) outl += 1;

an den Anfang zu setzen und dann durch

uint8_t outl = second & 0x01;

zu ersetzen.

[Frank M. (ukw) (Moderator)]

Wilhelm M. schrieb:
> Die schnellste Variante ist die, die eine 8KB-LUT verwendet.

Was glaubst Du, wieviele Millionen mal der TO die Schiebeschalter pro 
Sekunde auslesen möchte?

[Wilhelm M. (wimalopaan)]

Frank M. schrieb:
> Wilhelm M. schrieb:
>> Die schnellste Variante ist die, die eine 8KB-LUT verwendet.
>
> Was glaubst Du, wieviele Millionen mal der TO die Schiebeschalter pro
> Sekunde auslesen möchte?

Steht hier nicht zur Debatte: es es ging um die u.g. Pauschalaussage, 
und die ist nun mal falsch.

Wilhelm M. schrieb:
> Peter D. schrieb:
>> Wilhelm M. schrieb:
>>> Worum geht es denn: Ausführungszeit, Flash-Size, ggf. RAM-Size,
>>> Wartbarkeit, ...?
>>
>> Diese Variante ist in allen 4 Punkten optimal.

[H.Joachim S. (crazyhorse)]

MaWin schrieb:
> Eure Betrachtungen scheinen mir akademisch,
> egal wie schnell nud mit wie vielen Befehlsbytes,
> denn sie liefern ALLE das falsche Ergebnis,

Akademisch ist es schon lange - aber trotzdem interessant, wieviel 
Optimierungspotential selbst in einfachen Sachen steckt.

Und falsch ist es auch nicht  - es herrschte Übereinkunft, dass vorher 
negiert wurde bzw. das es vorrangi um die Sortierei geht. Natürlich kann 
man das weglassen und die Bits auf 0 testen bzw. dies bei einer 
LUT-Lösung direkt berücksichtigen.

[Wilhelm M. (wimalopaan)]

H.Joachim S. schrieb:
> Akademisch ist es schon lange - aber trotzdem interessant, wieviel
> Optimierungspotential selbst in einfachen Sachen steckt.

Wer das interessant findet, sollte sich mal die Diskussion um 
std::midpoint() ansehen.

[Peter D. (peda)]

Wilhelm M. schrieb:
> Steht hier nicht zur Debatte: es es ging um die u.g. Pauschalaussage,
> und die ist nun mal falsch.

Wenn man es unbedingt falsch verstehen will, dann ja.
Gemeint ist natürlich, daß sie in der Summe aller Faktoren optimal ist.
Klar kann man einzelne Faktoren noch weiter optimieren, wenn man die 
anderen ins Unterirdische absenkt.

[Wilhelm M. (wimalopaan)]

Peter D. schrieb:
> Gemeint ist natürlich, daß sie in der Summe aller Faktoren optimal ist.

Da legst Du dann Deine, persönliche Gewichtung zugrunde? Na prima, dass 
ist ja Politikergeschwafel!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Marten Morten schrieb:
> Wahrscheinlich meint er
> uint8_t outl = 0;
> if (second & 0x01) outl += 1;
> an den Anfang zu setzen und dann durch
> uint8_t outl = second & 0x01;
> zu ersetzen.
Stimmt, spart nochmal 4 Byte:

uint16_t bcd3(uint8_t first, uint8_t second)
{
  // perform as many operations as possible with 8-bit
  uint8_t outl = second & 0x01;
  
  // Tenth (second byte high nibble)
  if (second & 0x80) outl += 80;
  if (second & 0x40) outl += 20; //  \_ swapped
  if (second & 0x20) outl += 40; //  /
  if (second & 0x10) outl += 10;

  // Ones (second byte low nibble)
  if (second & 0x08) outl += 8;
  if (second & 0x04) outl += 2; //  \_ swapped
  if (second & 0x02) outl += 4; //  /


  // Hundreds (first byte low nibble)
  // 100 still fits in the 8-bit outl variable, so we
  // add it here, not below
  if (first & 0x01) outl += 100;

  // Remaining values don't fit in the 8-but outl, so
  // convert to 16 bit for the remaining values
  uint16_t out = outl;

  if (first & 0x08) out += 800;
  if (first & 0x04) out += 200; //  \_ swapped
  if (first & 0x02) out += 400; //  /

  return out;
}

int main()
{
  result =  bcd3(firstbyte, secondbyte);

  while(1);
}

Program Memory Usage   :  264 bytes


Frank M. schrieb:
> Hier eine Variante, die nochmals 2-4 Bytes Code einspart
Program Memory Usage   :  288 bytes
Mehraufwand durch die zusätzlichen Funktionsaufrufe...

Jetzt habe ich aber genug. Inzwischen sind gut 15 unterschiedliche 
Varianten zusammengekommen ;-)

[Frank M. (ukw) (Moderator)]

Wilhelm M. schrieb:
> Da legst Du dann Deine, persönliche Gewichtung zugrunde?

Naja, ganze 8 KB für eine Lookup-Table ist jetzt auch nicht der Burner 
gegenüber schlanken 72 Bytes an Code. Schon bei einem ATmega88 wäre hier 
Schicht im Schacht.

Mach doch mal eine Tabelle mit Gewichtungsfaktoren für Speicherbedarf, 
Geschwindigkeit usw.

Dann kann man die vorgestellten Lösungen mit dem Taschenrechner 
"ranken". ;-)

Beispiel: Wären alle Gewichtungsfaktoren gleich hoch, muss Dein Programm 
bei 113 mal höherem Speicherbedarf auch 113 mal schneller sein, um noch 
mitzuhalten.

P.S.

8192 / 72 = 113. Deinen Speicherbedarf für den Code habe ich hier noch nicht mitgerechnet.

[Wilhelm M. (wimalopaan)]

Frank M. schrieb:
> Naja, ganze 8 KB für eine Lookup-Table ist jetzt auch nicht der Burner
> gegenüber schlanken 72 Bytes an Code. Schon bei einem ATmega88 wäre hier
> Schicht im Schacht.

Der Code ist linear und 40 Bytes (s.a. Geschwindigkeit)

Natürlich ist es klar, das man das bei den Schaltern wohl nicht so 
macht, oder?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Frank M. schrieb:
> Wären alle Gewichtungsfaktoren gleich hoch, muss Dein Programm bei 113
> mal höherem Speicherbedarf auch 113 mal schneller sein, um noch
> mitzuhalten.
Wenn denn sonst kein anderer Parameter wie z.B. die 
Wartbarkeit/Verständlichkeit auch noch beeinflusst werden könnte. Ich 
zumindest möchte keinen Fehler in einer 8kByte großen LUT suchen...  ;-)

[Wilhelm M. (wimalopaan)]

Lothar M. schrieb:
> Wenn denn sonst kein anderer Parameter wie z.B. die
> Wartbarkeit/Verständlichkeit auch noch beeinflusst werden könnte. Ich
> zumindest möchte keinen Fehler in einer 8kByte großen LUT suchen...  ;-)

Den brauchst Du auch nicht zu suchen.

[Frank M. (ukw) (Moderator)]

Wilhelm M. schrieb:
> Natürlich ist es klar, das man das bei den Schaltern wohl nicht so
> macht, oder?

Natürlich ist das klar.

Und wenn es keine Schalter, sondern sonstwie schnelle Signale wären, wo 
man in Zeitnot geraten könnte:

Dann würde man so einen Fehler wie eine Vertauschung von 2 Pins partout 
vermeiden. Und schon wäre die BCD-Wandlung ohne LUT nochmal um ein 
Vielfaches schneller, wodurch der Geschwindigkeitsabstand zur Lösung mit 
LUT auf jeden Fall geringer würde.

[Frank M. (ukw) (Moderator)]

Lothar M. schrieb:
> Frank M. schrieb:
>> Hier eine Variante, die nochmals 2-4 Bytes Code einspart
> Program Memory Usage   :  288 bytes

Hm, mein avr-gcc 4.7.2 klumpt das zusammen auf 276 bytes. Aber ich weiß 
jetzt auch nicht mehr, was der bisher minimalste Wert war.

> Mehraufwand durch die zusätzlichen Funktionsaufrufe...

Ja, kann sein. Ich dachte, die würden inline durchgehen...

Aber egal, mir reichts jetzt auch. :-)

[Wilhelm M. (wimalopaan)]

Frank M. schrieb:
> Hm, mein avr-gcc 4.7.2 klumpt das zusammen auf 276 bytes. Aber ich weiß
> jetzt auch nicht mehr, was der bisher minimalste Wert war.

Na dann sag doch endlich mal für welchen Controller! Sonst kann man 
nicht viel vergleichen. Oder gibt die tatsächliche Größe des Codes an, 
ohne vector-table, etc.

[Frank M. (ukw) (Moderator)]

Wilhelm M. schrieb:
> Na dann sag doch endlich mal für welchen Controller!

Upps, der war für Atmega644. Ich habe es jetzt mal auf Atmega88 
umgestellt:

Nun sind es nur noch 202 Bytes statt 276 Bytes Programmcode.

> Oder gibt die tatsächliche Größe des Codes an,

Blick in die lss-Datei:

bcdnibble: 36 Bytes
bcd3: 56 Bytes

Macht insgesamt 92 Bytes. Hm, da klingen Pedas 72 Bytes doch besser. 
Aber auf jeden Fall besser als 8232 Bytes.. ;-)

P.S.
Ich frage mich, was Du da vergleichen willst:

1. Dein Code versagt für ATmega88
2. Dein Code versagt mit avr-gcc 4.7.2

[Yalu X. (yalu) (Moderator)]

Wilhelm M. schrieb:
> leo schrieb:
>> Wilhelm M. schrieb:
>>> template<uint8_t Bit1, uint8_t Bit2, typename T>
>>
>> und weitere ~30 Zeilen.
>>
>> Wie immer die laengste, komlizierteste, unleserlichste und unnoetigste
>> "Loesung" weit und breit ;-)
>
> Naja, swapBits<> steckt man einmal in seinem Leben irgendwo in eine
> Headerdatei. Fertig.

Man kann das natürlich so machen, wenn man Spaß daran hat.

Aber mal Hand aufs Herz:

Hast du die Funktion swapBits schon jemals früher gebraucht?

Oder siehst du eine reelle Chance, sie jemals wiederzuverwenden?

Dazu ist die Funktion trotz Vertemplatisierung zu speziell, denn beim
nächsten ähnlich liegenden Fall wird der Hardwareentwickler sicher nicht
2, sondern 3 oder gar alle 4 Bits durcheinanderschmeißen oder seinen
Fehler einsehen und alle Bits in ihrer natürlichen Reihenfolge halten.

[Wilhelm M. (wimalopaan)]

Peter D. schrieb:
> Man kann das noch weiter optimieren, indem man zuerst das Low-Byte
> berechnet:
>

> uint16_t bcd3(uint16_t in)
> {
>   uint8_t outl = 0;
>   if (in & 0x0001) outl += 100;
...
>   return out;
> }
>

>
> Sind auf dem AVR 72 Byte Code.

Nimmt man das Lesen zweier volatile (Ports) mit hinzu, so kommt man auch 
hier auf 88 Bytes Code, gegenüber 90 Bytes bei der anderen if-Variante. 
Gleiche 90-Bytes erzielt man (m.E. lesbarer und flexibler) mit 
generischem C++, oder 40-Bytes mit 8K-Monster-LUT oder 66-Bytes mit 
(256+32)-Bytes-LUT oder 82-Bytes mit 16-Bytes-LUT.

[Wilhelm M. (wimalopaan)]

Yalu X. schrieb:
> Wilhelm M. schrieb:
>> leo schrieb:
>>> Wilhelm M. schrieb:
>>>> template<uint8_t Bit1, uint8_t Bit2, typename T>
>>>
>>> und weitere ~30 Zeilen.
>>>
>>> Wie immer die laengste, komlizierteste, unleserlichste und unnoetigste
>>> "Loesung" weit und breit ;-)
>>
>> Naja, swapBits<> steckt man einmal in seinem Leben irgendwo in eine
>> Headerdatei. Fertig.
>
> Man kann das natürlich so machen, wenn man Spaß daran hat.
>
> Aber mal Hand aufs Herz:
>
> Hast du die Funktion swapBits schon jemals früher gebraucht?

Ja.

> Oder siehst du eine reelle Chance, sie jemals wiederzuverwenden?

Ja.

Ich habe eine Klasse für ein PinSet (beliebige Pins eines Ports in 
beliebiger Reihenfolge mit beliebiger LUT). Wenn es nicht sehr auf 
Laufzeit ankommt, kann man sich dadurch ggf. auch das HW-Design 
vereinfachen - also nicht versehentlich, sondern absichtlich 
vertauschen.

[Yalu X. (yalu) (Moderator)]

Wilhelm M. schrieb:
>> Hast du die Funktion swapBits schon jemals früher gebraucht?
>
> Ja.
>
>> Oder siehst du eine reelle Chance, sie jemals wiederzuverwenden?
>
> Ja.

Das soll einer verstehen: Du benutzt ständig diese sehr spezifische
swapBits-Funktion (ich persönlich hätte dafür noch nie Bedarf gehabt),
obwohl du eine weitaus generischere Funktion in der Hinterhand hast:

> Ich habe eine Klasse für ein PinSet (beliebige Pins eines Ports in
> beliebiger Reihenfolge mit beliebiger LUT).

[Wilhelm M. (wimalopaan)]

Yalu X. schrieb:
> Wilhelm M. schrieb:
>>> Hast du die Funktion swapBits schon jemals früher gebraucht?
>>
>> Ja.
>>
>>> Oder siehst du eine reelle Chance, sie jemals wiederzuverwenden?
>>
>> Ja.
>
> Das soll einer verstehen:

Was ist daran schwer (s.u.)?

> Du benutzt ständig diese sehr spezifische
> swapBits-Funktion (ich persönlich hätte dafür noch nie Bedarf gehabt),
> obwohl du eine weitaus generischere Funktion in der Hinterhand hast:

Nein. Die Funktion ist Teil der genannten Klasse.

Die Klasse zu posten wäre möglich, aber sinnlos.

[S. R. (svenska)]

Wilhelm M. schrieb:
> Natürlich ist es klar, das man das bei den Schaltern
> wohl nicht so macht, oder?

Ich dachte, du hast deine Lösung genau deswegen gepostet?