Pin in abhängigkeit einer variablen ein/aus-schalten

[Dominik (Gast)]

guten abend,
ich habe ein kleines logisches Problem.

Ich möchte den Pin (AVR) anhand einer variable setzen.
Dies habe ich bisher mittels einer if-Bedingung

if(1 == ledOn)
{
  DDRD |= (1 << PIND3);
}
else
{
  DDRD &= ~(1 << PIND3);
}

gibt es da auch einen eleganteren weg, wo ich direkt den wert der 
Variable benutzen kann?

[Falk B. (falk)]

Dominik schrieb:
> gibt es da auch einen eleganteren weg, wo ich direkt den wert der
> Variable benutzen kann?

Jain. Man kann es über eine Tabelle machen. Wo liegt denn dein Problem? 
In der Ästhetik?

[Dominik (Gast)]

Falk B. schrieb:
> In der Ästhetik?

Ja

naja, zumindest kann ich dafür ne inline funktion machen. Damit wird es 
doch ein bisschen leserlicher.

[Sebastian (Gast)]

Man kann eleganterweise "1 == " weglassen

Man kann das auch in einer Zeile schreiben:

DDRD = DDRD & ~(1<<PIND3) | (ledOn<<PIND3);

Aber ob das eleganter ist?

LG, Sebastian

[HildeK (Gast)]

Dominik schrieb:
> gibt es da auch einen eleganteren weg, wo ich direkt den wert der
> Variable benutzen kann?

Schau dir mal die sbit.h von Peter D. an. 
Beitrag "Re: Frage zu Struktur für IO-Port bei AVRs"
Dann könnte die Stelle so aussehen:

#include "sbit.h"
.
.
.

 LED = ledOn;

wenn ledOn nur die Werte 0 und 1 annimmt. Und hinter LED steht ein 
Makro.

[HildeK (Gast)]

Ich habe noch meine Demodatei dazu gefunden ...

[Rolf M. (rmagnus)]

HildeK schrieb:
> wenn ledOn nur die Werte 0 und 1 annimmt.

Idealer- und ästhetischerweise nutzt man dafür einen bool, dann ist das 
automatisch gegeben.

[Jim M. (turboj)]

Rolf M. schrieb:
> Idealer- und ästhetischerweise nutzt man dafür einen bool, dann ist das
> automatisch gegeben.


Nö, ist es AFAIK nicht - und kann einem bei -Os oder -O3 auf die Füße 
fallen.
Der Optimizer darf das in einem ganzen Register belassen, damit sind 
auch Werte <0 oder >1 möglich.

[EAF (Gast)]

Jim M. schrieb:
> und kann einem bei -Os oder -O3 auf die Füße
> fallen.

Beispiel?

[Michael B. (laberkopp)]

Dominik schrieb:
> gibt es da auch einen eleganteren weg,

digitalWrite(3,ledOn); aus der Arduino-Bibliothek.

Aber das setzt nicht das Datenrichtungsregister DDRD sondern das 
Ausgaberegister PORTD, und es nutzt nicht die Eingangspinbitnummer 
PIND3, sondern PD3.

Die Frage ist also, was du eigentlich wolltest und warum das alles.

[Stefan F. (Gast)]

Dominik schrieb:
> gibt es da auch einen eleganteren weg, wo ich direkt den wert der
> Variable benutzen kann?

Man kann den Code hinter einem Makro verbergen:

#define writeBit(port,bit,value) { if ((value)>0) (port) |= (1<<bit); else (port) &= ~(1<<bit); } 

writeBit(DDRD,3,ledOn)

Aber wirklich eleganter ist das auch nicht. Ich habe früher zu viele 
solcher Makros verwendet. Sie verschleiern, was wirklich passiert. 
Dadurch provozieren sie falsche Verwendung und machen Fehlermeldungen 
schwerer verständlich.

Eine ganz normale C Funktion ist gut lesbar und produziert in der Regel 
genau den gleichen Maschinencode, ist also nicht ineffizient:

void setze_status_led(bool ein) 
{
    if(ein)
    {
       DDRD |= (1 << PIND3);
    }
    else
    {
       DDRD &= ~(1 << PIND3);
    }
}

setze_status_led(ledOn);

Wobei man auch aufpassen muss, wie man die Variable nennt. "ledOn" kann 
die LED nämlich auch aus schalten. Gute passende Namen sind wichtig, 
falls es kein Wegwerf-Projekt ist.

[Rolf M. (rmagnus)]

Jim M. schrieb:
> Rolf M. schrieb:
>> Idealer- und ästhetischerweise nutzt man dafür einen bool, dann ist das
>> automatisch gegeben.
>
> Nö, ist es AFAIK nicht - und kann einem bei -Os oder -O3 auf die Füße
> fallen.

Nein.

> Der Optimizer darf das in einem ganzen Register belassen, damit sind
> auch Werte <0 oder >1 möglich.

Der interne Wert, den der Compiler für einen bool nutzt, kann dir aber 
egal sein. Wenn man ihn in einen Integer konvertiert, kommt immer 0 für 
false und 1 für true raus. Das garantiert der Standard.

[EAF (Gast)]

Stefan F. schrieb:
> eleganter

Über "elegant" kann man streiten.

Hier ein eleganter und optimierter "Arduino" Code:

#include <CombiePin.h>

using Led = Combie::Pin::OutputPin<LED_BUILTIN>;

int main() 
{
   Led{}.init();
   Led{} = 1;
   while(1);
}

Und das zugehörige Kompilat:

00000080 <main>:
          #endif  
        }
        
        void  INLINE initOutput()
        {
            *getDdrPort(arduinoPin) |= getMaske(arduinoPin);
  80:  25 9a         sbi  0x04, 5  ; 4

00000082 <.LBB23>:
          return *getInPort(arduinoPin)  &  getMaske(arduinoPin);
        }
    
        void  INLINE setHigh()
        {
          *getOutPort(arduinoPin)  |=  getMaske(arduinoPin);
  82:  2d 9a         sbi  0x05, 5  ; 5

00000084 <.L2>:

int main() 
{
   Led{}.init();
   Led{} = 1;
   while(1);
  84:  ff cf         rjmp  .-2        ; 0x84 <.L2>

[Eine Anmerkung (Gast)]

> Die Frage ist also, was du eigentlich wolltest und warum das alles.

Das Problem ist doch gerade, jeder Programmiere wählt die Lösung, die 
ihm persönlich am besten gefällt.

Dominiks ursprüngliches Beispiel ergibt ewig langen Programmcode. Nach 
dem runter scrollen hat man schon wieder vergessen, was oben stand.

Arduinos digitalWrite() ist zwar kompakt, hat sich aber außerhalb der 
Arduino Welt nicht durchgesetzt.

Jeder bastelt da irgend etwas anderes. Der Code lässt sich nicht 
wiederverwenden. Nachvollziehen, was die Macros, Wrapper und Frameworks 
machen, wird aufwendiger als komplett neu entwickeln.

Nimm als Beispiel die Normen aus Maschinenbau oder Bauwesen. Alle 
Ingenieure benutzen die selben Symbole und die selben Bezeichnungen. 
Jeder sieht auf den ersten Blick, was der Kollege konstruiert hat.

Wieso können wir uns nicht auf einen einheitlichen Weg einigen?

[Stefan F. (Gast)]

EAF schrieb:
> Und das zugehörige Kompilat:

Das der Compiler so etwas gut optimieren kann, brauchst du nicht zu 
beweisen. Das Thema hatten wir schon oft genug. Auch eine ganz normale 
Funktion erzeugt in der Regel den selben optimalen Maschinencode.

Die Frage nach der "Ästhetik" finde ich viel wichtiger.

Eine Anmerkung schrieb:
> Arduinos digitalWrite() ist zwar kompakt, hat sich aber außerhalb der
> Arduino Welt nicht durchgesetzt.

Der Maschinencode der dabei heraus kommt ist aber alles andere als 
Kompakt. Wenn man sich mal den Quelltext der Funktion anschaut, wundert 
mich das auch nicht. Da passiert ja noch einiges mehr, als nur den 
einzelnen PIN auf HIGH oder LOW zu setzen. Womit wir wieder beim 
"verschleiern" sind. Die Funktion macht mehr, als ihr Name suggeriert, 
was ich nicht gut finde. Andererseits ist sie trotz der Verschleierung 
halbwegs deppensicher, das muss man auch mal würdigen.

[EAF (Gast)]

Stefan F. schrieb:
> Das Thema hatten wir schon oft genug

Und doch gibt es hier weiterhin eine "Arduino Basher" und "C++ auf µC 
ist ineffektiv/unsinnig" Fraktion.
Erinnere dich!

[spess53 (Gast)]

Hi

>Und doch gibt es hier weiterhin eine "Arduino Basher" und "C++ auf µC
>ist ineffektiv/unsinnig" Fraktion.

Immer noch die gleichen Phrasen, die du schon als 'Arduino Fanboy' von 
dir gegeben hast.

MfG Spess

[Mirko (Gast)]

Einen µC-Pin in Abhängigkeit von einer Variablen schalten...
Zu schwer?

Warum nicht Ikebana?
Da gibt es sehr schöne VHS-Kurse, die dich hoffentlich nicht so
schnell überfordern...

[Wilhelm M. (wimalopaan)]

Dominik schrieb:

>

> if(1 == ledOn)
> {
>   DDRD |= (1 << PIND3);
> }
> else
> {
>   DDRD &= ~(1 << PIND3);
> }
>

>
> gibt es da auch einen eleganteren weg, wo ich direkt den wert der
> Variable benutzen kann?

Meinst Du wirklich DDRD? Oder sollte es eher PORTD sein? Kennst Du den 
Unterschied?

[M. K. (sylaina)]

Dominik schrieb:
> guten abend,
> ich habe ein kleines logisches Problem.
>
> Ich möchte den Pin (AVR) anhand einer variable setzen.
> Dies habe ich bisher mittels einer if-Bedingung
>

> if(1 == ledOn)
> {
>   DDRD |= (1 << PIND3);
> }
> else
> {
>   DDRD &= ~(1 << PIND3);
> }
>

>
> gibt es da auch einen eleganteren weg, wo ich direkt den wert der
> Variable benutzen kann?

DDRD setzt aber nur die Datenrichtung des angegebenen Pins, nicht seinen 
logischen Zustand. Was du wohl eher möchtest ist

if(1 == ledOn)
{
  PORTD |= (1 << PD3);
}
else
{
  PORT &= ~(1 << PD3);
}

Wenn ledOn nur den Zustand 0 oder 1 annehmen kann, dann kann man das 
verkürzt schreiben mit:

PORTD = PORTD & ~(1 << PD3) | (ledOn << PD3);

Das ist aber IMHO etwas schwerer zu lesen, die If-Bedingung ist meiner 
Ansicht nach für den Menschen übersichtlicher/einfacher zu 
lesen/verstehen und der Compiler wirds eh passend optimieren.

[Wilhelm M. (wimalopaan)]

EAF schrieb:
> Stefan F. schrieb:
>> eleganter
>
> Über "elegant" kann man streiten.

In der Tat!

> Hier ein eleganter und optimierter "Arduino" Code:
>

> #include <CombiePin.h>
> 
> using Led = Combie::Pin::OutputPin<LED_BUILTIN>;
> 
> int main()
> {
>    Led{}.init();
>    Led{} = 1;
>    while(1);
> }
>

Wenn Du schon ein Monostate einsetzt, dann sollte man das auch richtig 
machen ;-) So ist das jedenfalls unnötiger Murks.

[EAF (Gast)]

Wilhelm M. schrieb:
> dann sollte man das auch richtig
> machen ;-)

Dann mache doch mal eine Vorführung.

[Wilhelm M. (wimalopaan)]

EAF schrieb:
> Wilhelm M. schrieb:
>> dann sollte man das auch richtig
>> machen ;-)
>
> Dann mache doch mal eine Vorführung.

Ok, schicke Dir einen Link zum nä. Konzert ;-)

Du weißt was das Monostate-Pattern ist?

[Peter D. (peda)]

HildeK schrieb:
> LED = ledOn;
> wenn ledOn nur die Werte 0 und 1 annimmt.

Das ist egal, LED verlangt ein Bool, da Bitvariable. Bei Bedarf erfolgt 
eine automatische Umwandlung.

[HildeK (Gast)]

Peter D. schrieb:
> Das ist egal, LED verlangt ein Bool, da Bitvariable. Bei Bedarf erfolgt
> eine automatische Umwandlung.

Nicht ganz, aber mein Durchblick bei sbit.h ist nicht so der Renner 😀.

Im Simulator sieht es zumindest so aus, als ob der Wert nur mit der 
Maske 0x01 behandelt wird. Heißt:
LED = 1; // on
LED = 2; // off
LED = 3; // on  - und so weiter.
Das ist für mich keine automatische Umwandlung in Bool, denn es ist 
nicht das selbe wie: alles, was ungleich 0 (false) ist, ist dann 1 
(true).

Deshalb war mein Hinweis nicht ganz unberechtigt.

[Mascha V. (maschak)]

Eine Anmerkung schrieb:
> Jeder bastelt da irgend etwas anderes. Der Code lässt sich nicht
> wiederverwenden. Nachvollziehen, was die Macros, Wrapper und Frameworks
> machen, wird aufwendiger als komplett neu entwickeln.
>
> Nimm als Beispiel die Normen aus Maschinenbau oder Bauwesen. Alle
> Ingenieure benutzen die selben Symbole und die selben Bezeichnungen.
> Jeder sieht auf den ersten Blick, was der Kollege konstruiert hat.
>
> Wieso können wir uns nicht auf einen einheitlichen Weg einigen?

Als Mädchen mit entsprechenden Erfahrungen sage ich es so: Jeder will 
den Größten haben...

Einheitlicher Weg würde ja bedeuten, dass niemand mehr "Java ist 
besser!", "Nein C ist besser!", "Nein Rust ist besser!" sagen dürfte, 
sondern dass sich alle einigen müssten auf ein gemeinsames Ziel. Aber 
das geht doch nicht! Nicht unter Jungs jedenfalls ^^

[Mascha V. (maschak)]

Eine Anmerkung schrieb:
> Wieso können wir uns nicht auf einen einheitlichen Weg einigen?

Ich nochmal... Mir kommt das so vor als ob es darum geht, ob 
Programmieren Kunst oder Handwerk ist. Manche wollen Geld damit 
verdienen, und manche wollen Applaus ^^

[Peter K. (Gast)]

VAR LED1 : BOOLEAN;
If LED1 = 1 THEN PortD.3:=1 ELSE PortD.3:=0;

MfG
 Pascal:-)

[Mascha V. (maschak)]

Dominik schrieb:
> guten abend,
> ich habe ein kleines logisches Problem.
>
> Ich möchte den Pin (AVR) anhand einer variable setzen.
> Dies habe ich bisher mittels einer if-Bedingung
>

> if(1 == ledOn)
> {
>   DDRD |= (1 << PIND3);
> }
> else
> {
>   DDRD &= ~(1 << PIND3);
> }
>

>
> gibt es da auch einen eleganteren weg, wo ich direkt den wert der
> Variable benutzen kann?

Der Code ist grundsätzlich scheiße.

Warum? Weil ihn niemand versteht, der nicht C-Experte ist so wie du.

Wenn ledOn bool ist, dann ist die if-clause schon falsch. Und zweitens 
gehört (1 << PIND3) in eine eigene Funktion verpackt, weil "don't repeat 
yourself".

[Rolf M. (rmagnus)]

HildeK schrieb:
> Peter D. schrieb:
>> Das ist egal, LED verlangt ein Bool, da Bitvariable. Bei Bedarf erfolgt
>> eine automatische Umwandlung.
>
> Nicht ganz, aber mein Durchblick bei sbit.h ist nicht so der Renner 😀.
>
> Im Simulator sieht es zumindest so aus, als ob der Wert nur mit der
> Maske 0x01 behandelt wird. Heißt:
> LED = 1; // on
> LED = 2; // off
> LED = 3; // on  - und so weiter.
> Das ist für mich keine automatische Umwandlung in Bool,

Anders herum wird ein Schuh draus. Auf der rechten Seite der Zuweisung 
muss ein bool stehen, und dann kommt in LED eine 0 an, wenn der false 
ist und eine 1, wenn er true ist. Eine 2 oder 3 gibt es dann gar nicht. 
Es ging doch darum:

HildeK schrieb:
> #include "sbit.h"
> .
> .
> .
>  LED = ledOn;

und um meinen Hinweis, ledOn dann als bool zu definieren.

[HildeK (Gast)]

Rolf M. schrieb:
> Anders herum wird ein Schuh draus. Auf der rechten Seite der Zuweisung
> muss ein bool stehen, und dann kommt in LED eine 0 an, wenn der false
> ist und eine 1, wenn er true ist. Eine 2 oder 3 gibt es dann gar nicht.

Ja, richtig! Welcher Typ die Variable 'ledOn' beim TO jedoch hatte, ist 
unbekannt. Deshalb schrieb ich dazu:

HildeK schrieb:
> wenn ledOn nur die Werte 0 und 1 annimmt.
also auf den boolschen Zahlenraum beschränkt ist.
Du hast sinnvollerweise ergänzt, dass man für ledOn gleich eine 
Boolvariable nehmen sollte. Zumindest wäre einen Cast auf bool nötigt.

Nur Peter D. hatte gemeint:

Peter D. schrieb:
> Bei Bedarf erfolgt eine automatische Umwandlung.

Diese Umwandlung sehe ich nicht. Deshalb hab ich das mal getestet.

[Stefan F. (Gast)]

Mascha schrieb:
> zweitens gehört (1 << PIND3) in eine eigene Funktion verpackt,
> weil "don't repeat yourself".

Den Scherz finde ich nicht lustig.

[Mascha V. (maschak)]

Stefan F. schrieb:
> Den Scherz finde ich nicht lustig.

War ja auch keiner ;)

[Norbert (Gast)]

Ich hätte den hier im Angebot:

DDRD = ledOn ? DDRD | (1 << PIND3) : DDRD & ~(1 << PIND3);

[Dirk F. (dirkf)]

Beim Microchip XC8 Compiler für PICs  ist diese Funktion direkt dabei:

#define LED1 LATAbits.LATA2
#define LED2 LATBbits.LATB4

LED1 = 1;
LED2 = 0;

[Norbert (Gast)]

Dirk F. schrieb:
> Beim Microchip XC8 Compiler für PICs  ist diese Funktion direkt
> dabei:
>
> #define LED1 LATAbits.LATA2
> #define LED2 LATBbits.LATB4
>
> LED1 = 1;
> LED2 = 0;

Gratulation! ;-)
assert(PIC == AVR) -> failed
assert(question == answered) -> failed