Konfigurationsschalter auf Platine verdreht, Software Korrektur

[Sven (Gast)]

Guten morgen,

ich lese einen Konfigurationsschalter (DIP Schalter 4 polig) in meinen 
Atmega88 ein. Der Schalter hängt an Port C und zwar genauer gesagt an 
PC0 bis PC3.
Nun ist mir ein kleiner Lapsus unterlaufen. Eigentlich sollte Schalter 1 
an PC0, Schalter 2 an PC1, usw.
Leider ist mir beim routen der Leiterplatte passiert, dass der DIP 
Schalter 180° gedreht ist, d.h. Schalter 4 hängt nun an PC0, Schlter 3 
an PC1, etc. Klar man kann diesen gedreht einlöten, aber dann stünde er 
im eingebauten Zustand auf dem Kopf --> unschön.

Wenn ich jetzt den Schalter einlese erhalte ich statt 1 den Wert 15, 
statt 2 den Wert 8 usw.

Gibt es eine geschickte Möglichkeit das in der Software zu korrigieren?

Mir fällt nur ein, das ganze zwischen zu speichern, jedes Bit einzeln zu 
maskieren (also 4x) und entsprechend seiner Stelle links zu schieben (um 
es an die richtige Stelle zu rücken) und dann in der eigentlichen 
Variable zu verodern. Das wäre dann im Prinzip 4x maskieren, 4x schieben 
und 4x verodern.

Geht das irgendwie "trickreicher".

Besten Dank.

VG
Sven

[troll (Gast)]

Sven schrieb:
> Geht das irgendwie "trickreicher".
Tabelle. Ansonsten mal die Suche fragen, hatten wir neulich erst (Bits 
eines Bytes umdrehen oä).

[Sven (Gast)]

Danke für den Hinweis. Ich meine den Beitrag gefunden zu haben und darin 
diesen Link:
Beitrag "Re: Inline Assembler- Bits spiegeln"

Denke, dies ist die Routine, welche du angesprochen hattest.

[Knut B. (Firma: TravelRec.) (travelrec)]

In der Praxis ist es gar nicht mal unüblich, Bauelemente oder Peripherie 
so anzuschliessen, dass das Routing vereinfacht werden kann. Bits zu 
schieben oder zu spiegeln kostet kaum Rechenzeit und kein Geld. Mehr 
Bohrungen, Kreuzungen oder Lagen hingegen kosten sehr wohl Geld.

[Michael (Gast)]

Wenn man die Software so schreibt, dass es egal ist, macht das die Sache 
aber auch einfacher

#define PIN-SCHALTER PINC
#define SCHALTER1 (1<<0)
#define SCHALTER2 (1<<1)
#define SCHALTER3 (1<<2)
#define SCHALTER4 (1<<3)

und jetzt, weil falsch verdrahtet:

#define PIN-SCHALTER PINC
#define SCHALTER1 (1<<3)
#define SCHALTER2 (1<<2)
#define SCHALTER3 (1<<1)
#define SCHALTER4 (1<<0)

im Code selber dann nur

if (PIN_SCHALTER & SCHALTER1) AktionFuerSchalter1();
if (PIN_SCHALTER & SCHALTER2) AktionFuerSchalter2();
.
.
.

da kannste sogar mit verschiedenen Make-Files arbeiten und beide 
Hardware-Configs durch ein flag unterscheiden, braucht keine Verwaltung 
unterschiedlicher Programmcodes:

#ifdef CONF1
    //Hier Konfig1, siehe oben
#ELSIF
    //hier Konfig2, siehe oben
#ENDIF

[Rufus Τ. F. (rufus)]

Noch viel einfacher aber ist es, einfach die Dokumentation des Schalters 
anzupassen ...

[Knut B. (Firma: TravelRec.) (travelrec)]

Rufus Τ. Firefly schrieb:
> Noch viel einfacher aber ist es, einfach die Dokumentation des Schalters
> anzupassen ...

LOL :-)

[Shuzz (Gast)]

Rufus Τ. Firefly schrieb:
> Noch viel einfacher aber ist es, einfach die Dokumentation des Schalters
> anzupassen ...

Da spricht der erfahrene Inscheniör... :)
Danke für den Satz, you really made my day! :)

[Ralph (Gast)]

Michael schrieb:
> #define PIN-SCHALTER PINC
> #define SCHALTER1 (1<<0)
> #define SCHALTER2 (1<<1)
> #define SCHALTER3 (1<<2)
> #define SCHALTER4 (1<<3)
>
> und jetzt, weil falsch verdrahtet:#define PIN-SCHALTER PINC
> #define SCHALTER1 (1<<3)
> #define SCHALTER2 (1<<2)
> #define SCHALTER3 (1<<1)
> #define SCHALTER4 (1<<0)
>
> im Code selber dann nurif (PIN_SCHALTER & SCHALTER1) AktionFuerSchalter1();
> if (PIN_SCHALTER & SCHALTER2) AktionFuerSchalter2();
> .
> .
> .

Diese Lösung ist einfach, lesbar, übertragbar, flexibel,..... ==> also 
absolut ungeeignet. Das passt einfach nicht in unstrukturierten 
SpagettiCode.

Rufus Τ. Firefly schrieb:
> Noch viel einfacher aber ist es, einfach die Dokumentation des Schalters
> anzupassen ...

PSSTTT verrate doch nicht alle Tricks, Wie soll man denn so den Kunden 
noch klarmachen wie viel Geld man für die Arbeit haben will.