LED1 OK. aber LED2 blinkt nicht mit voller Helligkeit

[Joey N. (joey_n)]

Hallo, bin Anfänger und habe das Problem, wenn ich zwei einfache LEDs 
blinken lasse, blinkt LED1 an PB0 sauber mit voller Hellichkeit, LED2 
blinkt auch an PB1 aber nicht mit voller Leuchtkraft.

Ports und LEDs sind OK.

Was kann ich tun bitte?
Würde mich über Tips sehr freuen, vielen Dank.

Hier der Code, Beispiel aus dem Netz, aber PB1 habe ich hinzugefügt,für 
ein Attiny13 der extern an 5 Volt geschaltet ist.
 */

#define F_CPU 1000000UL

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
  // Pin 1 von Port B (PB1) als Ausgang schalten  "DDRB |= (1 << PB1);"
  
  DDRB = (1 << PB0);
  
  // Endlosschleife
  
  for (;;) {    
    PORTB |= (1 << PB0);  // bit im Portregister auf 1 setzen => LED leuchtet
    _delay_ms(100);    // warten

    PORTB &= ~(1 << PB0); // bit im Portregister auf 0 setzen => LED aus
    _delay_ms(5000);    // warten
    
    PORTB |= (1 << PB1);  // bit im Portregister auf 1 setzen => LED leuchtet
    _delay_ms(500);    // warten

    PORTB &= ~(1 << PB1); // bit im Portregister auf 0 setzen => LED aus
    _delay_ms(500);    // warten
    
    }

}

[Dominik S. (dasd)]

Mach aus

> DDRB = (1 << PB0);

mal

> DDRB = (1 << PB0) | (1 << PB1);

Da hätte man aber auch selbst drauf kommen können.

[user (Gast)]

DDRB = (1 << PB0);
zu
DDRB = (1 << PB0)|(1 << PB1);

[Stefan F. (Gast)]

Wen willst du veräppel?

Du musst nur den Befehl in diesem Kommentar ausführen.

 // Pin 1 von Port B (PB1) als Ausgang schalten  "DDRB |= (1 << PB1);"

[Joey N. (joey_n)]

Super, vielen Dank
Bin/war blind.

Klasse....

[Peter D. (peda)]

Divide et impera

Mache 2 Tasks daraus:

#define F_CPU 1.2e6

#include <util/delay.h>
#include "sbit.h"

#define LED0    PORT_B0
#define LED0_oe  DDR_B0
#define LED1    PORT_B1
#define LED1_oe  DDR_B1

void task_0( void )
{
  static uint16_t cnt_10ms;
  switch( ++cnt_10ms ){
    case 100:   LED0 = 0;
                break;
    case 300:   LED0 = 1;
                cnt_10ms = 0;
                break;
  }
}

void task_1( void )
{
  static uint16_t cnt_10ms;
  switch( ++cnt_10ms ){
    case 250:   LED1 = 0;
                break;
    case 350:   LED1 = 1;
                cnt_10ms = 0;
                break;
  }
}

int main()
{
  LED0_oe = 1;
  LED1_oe = 1;
  for(;;){
    _delay_ms( 10 );      // main timebase: 10ms
    task_0();
    task_1();
  }
}

[meckermann (Gast)]

Peter Dannegger schrieb:
> Mache 2 Tasks daraus:

Bleibe konsistent beim Setzen der Klammer-Ebenen.

z.B.:

int main()
{
  LED0_oe = 1;
  LED1_oe = 1;
  for(;;)
  {
    _delay_ms( 10 );      // main timebase: 10ms
    task_0();
    task_1();
  }
}

[HildeK (Gast)]

meckermann schrieb:
> Bleibe konsistent beim Setzen der Klammer-Ebenen.

Peter Danneggers Variante scheint bei den meisten C-Programmierern 
üblich zu sein (so auch bei meinen SW-Kollegen), ich verwende aber auch 
deine Variante, weil sie mir übersichtlicher erscheint.
Also keine Konsistenzfrage und nichts zu meckern :-)!

[Joey N. (joey_n)]

Wow, dankeschön Peter und sogar die sbit.h mitgesandt.
Das ist Profi

Bin gespannt und berichte gleich mal...

[Joey N. (joey_n)]

Danke Hilde,
bin in C absolut Neu und gebe dir Recht
Allerdings finde ich Peters Code auch übersichtlich, wenn ich denn den 
Code in einigen Jahren evtl. mal verstehen werde.:)

[meckermann (Gast)]

HildeK schrieb:
> Also keine Konsistenzfrage

Doch, sonst müsste ja man (ich hab den Code ja im Ganzen zitiert)
mit

int main() { ....

anfangen.

Der "Unsinn" die Klammer an einer anderen Ebene zu schliessen
gegenüber dem Punkt wo sie geöffnet wurde ist sogar in ATMEL
Code (ASF) weit verbreitet. Für mich ist das Chaos .....

[Walter (Gast)]

HildeK schrieb:
> Also keine Konsistenzfrage
vermutlich wegen

int main()
{

und nicht
int main(){

aber ich verwende wegen Übersichtlichkeit wie Du die { in einer neuen 
Zeile

[meckermann (Gast)]

meckermann schrieb:
> Für mich ist das Chaos .....

In einem kleinen Projekt bzw Source Code mag das noch
überschaubar sein, aber wenn es der Klammer-Ebenen zuviel
wird dann ist es echt Chaos.

[Joey N. (joey_n)]

Danke für deine Gedanken
lg

[Georg G. (df2au)]

meckermann schrieb:
> Klammer-Ebenen zuviel
> wird dann ist es echt Chaos.

Wenn man statt edlin einen vernünftigen Editor verwendet, bleiben beide 
Varianten und nach 4711 Schachtelebenen übersichtlich.

SCNR

P.S.: Ich bevorzuge auch Peter Variante.

[Peter D. (peda)]

meckermann schrieb:
> Bleibe konsistent beim Setzen der Klammer-Ebenen.

Ich benutze den Klammerungsstil als Unterscheidungsmerkmal.
Nur eine Funktion hat die '{' in einer extra Zeile.
Dadurch kann ich leichter erkennen, wann eine neue Funktion beginnt und 
wann nur ein conditional Block darin.

[HildeK (Gast)]

Naja, solange man nur den eigenen Code verstehen muss, sind die 
verwendeten Varianten weitgehend egal. Ich kann hier im Forum gut mit 
beiden oder den gemischten Varianten leben.

Ich habe eher Probleme, den Teile von Peters Code in sbit.h zu 
verstehen:

struct bits {
  uint8_t b0:1, b1:1, b2:1, b3:1, b4:1, b5:1, b6:1, b7:1;
} __attribute__((__packed__));
#define SBIT_(port,pin) ((*(volatile struct bits*)&port).b##pin)
#define SBIT(x,y)       SBIT_(x,y)

speziell mit den Ausdrücken:

 __attribute__((__packed__))

oder 

((*(volatile struct bits*)&port).b##pin)

Wenn du mal Zeit hast, dann kannst du mir hier vielleicht auf die 
Sprünge helfen ...
Vielleicht lerne ich es noch :-)

[Peter D. (peda)]

Joey N. schrieb:
> wenn ich denn den
> Code in einigen Jahren evtl. mal verstehen werde.:)

Warum so pessimistisch.
Frag ruhig, wenn Du etwas nicht verstehst.
Ich habe ihn absichtlich nicht kommentiert.
Ich hab auch nicht versucht den Zeitablauf aus Deinem Code zu 
extrahieren.
Ich denke aber, daß das Prinzip klar wird, wie man mehrere Tasks 
gleichzeitig und unabhängig voneinander ausführen kann.

[Joey N. (joey_n)]

Hallo Peter, Entschuldigung, das war  keine Kritik an dich.
Ich wollte nur zum Ausdruck bringen, das ich Neu bin und gerne so 
programmieren könnte wie du.


Das war sowieso mein nächstes Ziel, wie ich die  LEDs unabhängig 
voneinander ansteuern kann.

Ich bedanke ich mich nochmals für den tollen Code und frohes Neues.


lg

[Karl H. (kbuchegg)]

HildeK schrieb:

> #define SBIT_(port,pin) ((*(volatile struct bits*)&port).b##pin)
> #define SBIT(x,y)       SBIT_(x,y)
> [/c]
> speziell mit den Ausdrücken:
>

>  __attribute__((__packed__))
>

der Zweck von 'packed' besteht darin, dass der COmpiler nicht auf blöde 
Ideen kommt, und zwischen die einzelnen Strukturmember in

struct bits {
    uint8_t b0:1, b1:1, b2:1, b3:1, b4:1, b5:1, b6:1, b7:1;
} __attribute__((__packed__));

noch Alignment Bytes hineinpackt, weil er dir schnellstmöglichen zugriff 
auf die Member ermöglichen will. An dieser Stelle wollen wir den 
Compiler dazu zwingen, dass er alle 8 Bit Member in genau 1 Byte packt.

>

> ((*(volatile struct bits*)&port).b##pin)
>

https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html

## 'hängt' einfach nur 2 Tokens zusammen und generiert daraus einen 
neuen Token.
Steht 'pin' für die Zahlenkonstante 5, dann generiert 'b##pin' daraus 
'b5'.

[HildeK (Gast)]

@Karl Heinz (kbuchegg)
Herzlichen Dank für die Erklärung!
Ich habe bisher nur die einfachen Preprocessor Kommandos verwendet. Da 
scheint viel möglich zu sein, ich muss mich wohl damit mal intensiver 
beschäftigen ...

[Joey N. (joey_n)]

Hilde hats auch echt drauf, danke