7-Segment Multiplexing mittels ATmega

[Manfred W. (Gast)]

Ich möchte gerne eine Multiplexing Ansteuerung für vier 7-Segment 
Anzeigen mittels ATmega zusammenbaun.
Was nimmt man da pauschal für Bauteile? Gibt es da Standardrezept?
Also speziel jetzt um die LED's der Segmentanzeige zu treiben.

Ist der ULN2803 eine gute Wahl? Oder ULN2003? Oder ganz was anderes?

ist dieser Aufbau hier grundsätzlich in Ordnung: 
http://codeandlife.com/2012/02/24/7-segment-multiplexing-with-uln2003-pnp-transistors/

danke!

[Georg G. (df2au)]

Im Forum gibt es etwa 1001 Threads zu diesem Thema. Auch im AVR Tutorial 
und der Codesammlung sind viele Beispiele zu lesen. Bitte benutze die 
Suchfunktion.

[m.n. (Gast)]

Bevor Du irgendetwas falsch machst, zeige ich Dir lieber meine Schaltung 
:-)
Beitrag "Frequenz, Drehzahl, 4x7-Segment LED, Multiplex-Betrieb"
Oder allegemein für 7-Segmentanzeigen, insbesondere mehrstellige mit 
13mm LED. http://www.mino-elektronik.de/7-Segment-Variationen/LCD.htm

[Manfred W. (Gast)]

schönen dank, ich habe mir jetzt allerdings mal ein einfaches Beispiel 
aus dem Netz gesucht und für einen ATTiny 2313 angepasst.

Der AVR wird mit 8MHz betrieben.

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay_basic.h>

#define SEVEN_SEGMENT_PORT    PORTD
#define SEVEN_SEGMENT_DDR    DDRD

volatile uint8_t digits[3];

void SevenSegment(uint8_t n,uint8_t dp)
{
  if(n<10)
  {
    switch (n)
    {
      case 0:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b00111111;
      break;

      case 1:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b00000110;
      break;

      case 2:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b01011011;
      break;

      case 3:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b01001111;
      break;

      case 4:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b01100110;
      break;

      case 5:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b01101101;
      break;

      case 6:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b01111101;
      break;

      case 7:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b00000111;
      break;

      case 8:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b01111111;
      break;

      case 9:           //.gfedcba
        SEVEN_SEGMENT_PORT = 0b01101111;
      break;
    }
    if(dp)
    {
      SEVEN_SEGMENT_PORT |= 0b10000000;
    }
  }
  else
  {
    SEVEN_SEGMENT_PORT = 0b11111101;
  }
}

void Wait()
{
  uint8_t i;
  for (i=0;i<10;i++)
  {
    _delay_loop_2(0);
  }
}

void Print(uint16_t num)
{
  uint8_t i=0;
  uint8_t j;

  if (num>9999) return;

  while (num)
  {
    digits[i]=num%10;
    i++;
    num=num/10;
  }
  for (j=i;j<4;j++) digits[j]=0;
}

int main(void)
{
  uint16_t i;

  // Prescaler = FCPU/1024
  TCCR0B |= (1<<CS02)|(1<<CS00);

  //Enable Overflow Interrupt Enable
  TIMSK |= (1<<TOIE0);

  //Initialize Counter
  TCNT0=0;

  //Port B[3,2,1,0] as out put
  DDRB|=0b00001111;

  PORTB=0b00000001;

  //Port D
  SEVEN_SEGMENT_DDR=0XFF;

  //Turn off all segments
  SEVEN_SEGMENT_PORT=0X00;

  //Enable Global Interrupts
  sei();

  while(1)
  {
    for (i=0;i<10000;i++)
    {
      Print(i);
      Wait();
    }
  }
}

ISR(TIMER0_OVF_vect)
{
  static uint8_t i=0;
  if (i==3)
  {
    i=0;
  }
  else
  {
    i++;
  }
  PORTB &= (0b11110000);
  PORTB |= (1<<i);
  SevenSegment(digits[i],0);
}

Es zählt zwar, soweit ich das beurteilen kann, aber es flackert verdammt 
häftig.
Sind 8MHz dafür einfach zu langsam oder woran könnte das liegen?

[Uwe (de0508)]

Hallo Manfred ,

dann solltest Du dir mal die LED Refreshfrequenz ausrechnen.
Ich finde 7,6Hz doch etwas langsam.

[Karl H. (kbuchegg)]

Naja,

Was erwartetst du bei

// Prescaler = FCPU/1024

8000000 / 1024 = 7812
7812 / 256 = 30

30/4 = 7.5

7.5Hz flackert eben.

Lös doch mal die 'Handbremse'!

[Karl H. (kbuchegg)]

Und PS:

Deine Funktion 'SevenSegment' kann man auch durch ein Array ersetzen.

uint8_t digitPattern[] = { 0b00111111,
                           0b00000110,
                           0b01011011,
                           0b01001111,
                           0b01100110,
                           0b01101101,
                           0b01111101,
                           0b00000111,
                           0b01111111,
                           0b01101111,
                         };

volatile uint8_t digits[3];
....

was dann gleich auch noch den Funktionsaufruf aus der ISR entfernt und 
den GCC nicht dazu zwingt, dem Tiny unötige Mehraufgabe aufzubrummen.

macht man dann auch noch die Ausgaben in der richtigen Reihenfolge ...

ISR(TIMER0_OVF_vect)
{
  static uint8_t i=0;

  PORTB &= (0b11110000);        // erst mal alles aus!
                                // das schieb ich mal an den Anfang der ISR
                                // nur für den Fall, dass irgenwo kleinere
                                // Kapazitäten ein winziges Nachleuchten
                                // der LED nach dem Abschalten zur Folge haben

  if (i==3)                     // denn während sich das abbaut, kann der Tiny
  {                             // in der Zwischenzeit bestimmen, welches die
    i=0;                        // nächste Stelle ist. Quasi ein
  }                             // Multitasking des Tiny mit den LED :-)
  else
  {
    i++;
  }
                                // dann können die LEDs auf das neue Muster
                                // umgeschaltet werden.
  SEVEN_SEGMENT_PORT = digitPattern[ digits[i] ]; 
                                // das neue Muster liegt zwar jetzt an,
                                // leuchtet aber noch nicht
                                // Daher jetzt die LED endgültig mit dem
                                // neuen Muster einschalten
  PORTB |= (1<<i);
}

... dann ist auch gleich noch das sog. Ghosting eliminiert.

[Manfred W. (Gast)]

Danke dir Karl-Heinz!

Gibt's da sowas wie einen Rechner dafür?
Ich habe jetzt mal mit den Werten

TCCR0B |= (1<<CS01) | (1<<CS00);
TCNT0=131;

ins blaue geraten.

Damit läufts perfekt.
Die Frage ist nur ob das nicht zu viel ist.

[Uwe (de0508)]

Hallo Manfred ,

da das nennt sich Datenblatt lesen.

Dort stehen die Formeln !

und Was soll das bewirken ?

TCCR0B |= (1<<CS01) | (1<<CS00);
TCNT0=131;

Programmieren hat etwas mit wissen zu tun und nicht mit raten !

[Manfred W. (Gast)]

Ich hab mir dafür diesen Rechner hier zu gute gezogen: 
http://evolutec.publicmsg.de/index.php?menu=software&content=prescalertools

Ist dann wohl auch nicht das wahre :)

[Manfred W. (Gast)]

Aja, was ist denn fürs Menschliche Aue noch flimmerfrei? 60Hz?

[Karl H. (kbuchegg)]

Manfred W. schrieb:
> Danke dir Karl-Heinz!
>
> Gibt's da sowas wie einen Rechner dafür?

Wozu brauchst du da einen Rechner?
Einfach ein wenig nachdenken.

Der Timer wird vom Systemtakt angesteuert.
Wenn du einen Vorteiler von 1 hättest, dann würde der in 1 Sekunde bis 
8000000 zählen (ich ignorier mal, dass der nur bis 255 zählen kann)
Da du aber einen Vorteiler von 1024 hast, zählt er daher in 1 Sekunde 
wie weit?

Genau. Bis 8000000 / 1024 gleich 7812

Jetzt kann der Timer aber nicht bis 7812 zählen. Der ist ja nur 8 Bit 
gross kann nur bis 255 zählen (256 Zählschritte). Danach gibt es einen 
Overflow und er fängt wieder bei 0 an. Genau auf diese Overflows bist du 
aber aus. Denn genau bei jedem Overflow wird der Interrupt ausgelöst.
Wenn der Timer also theoretisch in 1 Sekunde bis 7812 zählen möchte, es 
aber wegen der Overflow nach jeweils 256 Zählschritten nicht kann, 
wieviele Oberflows sind das dann daher in 1 Sekunde?

genau. Das sind 7812 / 256 gleich 30 Overflows (und ein paar 
Zerquetschte, die ich mal grosszügig ignoriere)

D.h. pro Sekunde hast du 30 Overflows. Bei jedem Overflow wird eine 
andere Anzeige eingeschaltet. Du hast 4 Anzeigen. Wie oft kommt daher 
jede Anzeige pro Sekunde drann?

Genau. 30 / 4 gleich 7.5 mal


Wenn dir klar ist, was da vor sich geht, dann hast du dir die Zahlen so 
schneller hergeleitet, als du einen "Rechner" rausgekramt hast oder dir 
die Formeln im Datenblatt gesucht hast.

[Karl H. (kbuchegg)]

Manfred W. schrieb:

> ins blaue geraten.

rechne es dir einfach aus. Oder warum denkst du hab ich dir den 
Rechengang aufgeschrieben?

Welcher vorteiler ist das

  TCCR0B |= (1<<CS01) | (1<<CS00);

und mit dem wird gerechnet.

Sei nicht so faul! Das kann man alles verstehen und rechnen.

[Uwe (de0508)]

Hallo Manfred,

ich sehe 100Hz noch.

In meinem aktuellen 4-fach LED Multiplex verwende ich deshalb 250Hz LED 
Anzeigefrequenz.

Hier ist noch ein Bild vom Testbetrieb.

Karl-Heinz kennt die Schaltung schon, LED Kathode Vorwiderstände 270R.

[Manfred W. (Gast)]

Ok, danke Karl Heinz für die ausführliche Erklärung. Das hab ich 
verstanden.
Ich verwende jetzt mal einen Teiler von 64. Das ergibt dann einen Takt 
von 122 Hz.
Ich belasse das mal dabei. Flackern kann ich da mit meinem Auge nicht 
mehr erkennen.

jetzt hab ich noch eine Frage, ich möchte gerne das der Zähler bei den 
Segmenten mit führender Null zählt also wie bei einem Bandzählwerk.

0001
0002
  |
  |
0010
0011

Wie stelle ich es an das die Stellen von rechts nach links rücken?

[Karl H. (kbuchegg)]

Manfred W. schrieb:

> Wie stelle ich es an das die Stellen von rechts nach links rücken?

Da brauchst du überhaupt nichts rücken.
Die Print Funktion generiert doch ohnehin führende 0-en.

Also einfach einen Zähler als uint16_t Variable definieren und die 
erhöhen oder erniedrigen (je nachdem was der Zähler tun soll)

[Karl H. (kbuchegg)]

Übrigens (und da hab ich auch geschlafen)

Das hier

volatile uint8_t digits[3];

muss natürlich ein Array der Länge 4 sein

volatile uint8_t digits[4];

sind ja schliesslich 4 Anzeigen und dementsprechend auch 4 digits.

[Manfred W. (Gast)]

hm, dann stimmt die Verkabelung nicht?

Denn der zählt von links nach rechts.

Erstes Segment zählt bis 9 dann erhöht sich das zweite Segment. Wenn das 
zweite Segment über 9 kommt erhöht sich das dritte Segment. Also von 
links nach rechts.

Die Kathode des ersten Segmentes hängt an PB0
Das zweite an PB1 usw.

[Manfred W. (Gast)]

So sieht das aus: http://youtu.be/VPM_iuTrWUc

[holger (Gast)]

>Die Kathode des ersten Segmentes hängt an PB0
>Das zweite an PB1 usw.

Dann vertauscht die halt bis es passt.
Da musst du nicht mal die Software für ändern.
Ist das denn so schwer?

[Manfred W. (Gast)]

ja, hab ich jetzt eh. Passt schon.

[Manfred W. (Gast)]

Ich habe jetzt noch ein Problem.
Ich möchte in dem Programm jetzt noch zusätzlich eine Auswertung eines 
Drehgebers implementieren. Weil ich denke das die Funktionsweise eines 
mechanischen Zählwerkes entspricht. Anstelle des Drehgebers selbst 
möchte ich am Motor eine Scheibe montieren die dann 2 Lichtschranken 
bedient.

Die Auswertung des Drehgebersbeispiel: 
http://www.mikrocontroller.net/articles/Drehgeber
verwendet aber wieder ein anderes Timing wie mir scheint.
Wie implementiere ich das nun.

Ich hätte das mal so versucht:

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

#define SEVEN_SEGMENT_PORT    PORTD
#define SEVEN_SEGMENT_DDR    DDRD
#define ENCODER_A        (PINB & (1 << PB4))
#define ENCODER_B        (PINB & (1 << PB5))
#define TASTER          (1 << PB6)

                 // .gfedcba
uint8_t digitPattern[] =  {
                0b00111111,
                0b00000110,
                0b01011011,
                0b01001111,
                0b01100110,
                0b01101101,
                0b01111101,
                0b00000111,
                0b01111111,
                0b01101111,
              };

volatile uint8_t digits[4];

volatile int8_t enc_delta;
static int8_t last;

void encode_init( void )
{
  int8_t neu;

  neu = 0;
  if(ENCODER_A)
    neu = 3;
  if(ENCODER_B)
    neu ^= 1;
  last = neu;
  enc_delta = 0;

  TCCR0A = (1<<WGM01);
  OCR0A = (uint8_t)(F_CPU / 64.0 * 1e-3 - 0.5);
  TCCR0B = (1<<CS01 | 1<<CS00);
  TIMSK = (1<<OCIE0A);
}

void Wait()
{
  uint8_t i;
  for (i=0;i<10;i++)
  {
    _delay_ms(2);
  }
}

void Print(uint16_t num)
{
  uint8_t i=0;
  uint8_t j;

  if (num>9999) return;

  while (num)
  {
    digits[i]=num%10;
    i++;
    num=num/10;
  }
  for (j=i;j<4;j++) digits[j]=0;
}

ISR(TIMER0_OVF_vect)
{
  static uint8_t i=0;

  PORTB &= (0b11110000);
  if (i==3)
  {
    i=0;
  }
  else
  {
    i++;
  }
  SEVEN_SEGMENT_PORT = digitPattern[ digits[i] ]; 
  PORTB |= (1<<i);
}

ISR(TIMER0_COMPA_vect)
{
  int8_t neu, diff;
 
  neu = 0;
  if(ENCODER_A)
    neu = 3;
  if(ENCODER_B)
    neu ^= 1;
  diff = last - neu;
  if(diff & 1){
    last = neu;
    enc_delta += (diff & 2) - 1;
  }
}

int8_t encode_read1(void)
{
  int8_t val;
 
  cli();
  val = enc_delta;
  enc_delta = 0;
  sei();
  return val;
}

int main(void)
{
  int32_t val = 0;

  TCCR0B |= (1<<CS01) | (1<<CS00);
  TIMSK |= (1<<TOIE0);
  TCNT0=0;

  DDRB |= 0b00001111;
  PORTB = 0b01110001;

  SEVEN_SEGMENT_DDR = 0xFF;
  SEVEN_SEGMENT_PORT = 0x00;

  encode_init();
  sei();

  while(1)
  {
      val += encode_read1();
      Print(val);
  }
}

Aber das spiest sich ja.

[Uwe (de0508)]

Hi,

ich schreibe nur Timer 0 zwei mal initialisiert, weist Du welcher ISR 
noch angesprungen wird ?

[Manfred W. (Gast)]

Hallo Uwe,

TIMER0, ok. Aber welchen der beiden lasse ich dann weg?
Beim Drehgeber wird der bei jeder Drehbewegung initialisiert.

Welcher ISR außer den beiden?

[Uwe (de0508)]

Hallo Manfred,

welchen Atmel µC verwendest Du?

Dann schau mal ins Datenbatt unter TimerN/CounterN nach, und was steht 
da?

[Uwe (de0508)]

Manfred W. schrieb:
> Beim Drehgeber wird der bei jeder Drehbewegung initialisiert.

Wie soll ich das verstehen?

Ich kenne PaDas Drehencoder Code und kann ihn auch einsetzen, mir 
scheint , dass Dir noch C Grundlagen fehlen.

Also erst den gesamten Code verstehen und dann einbinden.

Ok?

[Manfred W. (Gast)]

Ähm, Blödsinn. Natürlich nicht bei jeder Drehbewegung.
encode_init() wird ja nur ein mal aufgerufen.

Es ist ein ATtiny2313

Ich hab das ganze jetzt mal zusammengefasst so wie es bei meinem 
Programm aufgerufen wird:

  TCCR0A = (1<<WGM01);
  OCR0A = (uint8_t)(F_CPU / 64.0 * 1e-3 - 0.5);
  TCCR0B = (1<<CS01 | 1<<CS00);
  TIMSK = (1<<OCIE0A);

  TCCR0B |= (1<<CS01) | (1<<CS00);
  TIMSK |= (1<<TOIE0);
  TCNT0=0;

TCCR0B ... kann ich einen schon mal kübeln.

Bei TIMSK addiert man da einfach den zweiten dazu?

[Manfred W. (Gast)]

Haa, es läuft wenn ich den
TCCR0A = (1<<WGM01); weglasse.

Also nur:

  OCR0A = (uint8_t)(F_CPU / 64.0 * 1e-3 - 0.5);
  TCCR0B = (1<<CS01 | 1<<CS00);
  TIMSK = (1<<OCIE0A | 1<<TOIE0);

Allerdings in zweier Schritten.

[Uwe (de0508)]

Hallo,

ich wollte Dich auf den zweiten Timer hinweisen.

Was kommt hierbei raus?

TCCR0B = (1<<CS01 | 1<<CS00);

Ich bin für heute raus.

[Manfred W. (Gast)]

64

Karl Heinz, kannst du mir noch einen Tipp geben wie ich den Punkt der 
Anzeige, also den dp da auch wieder in mein Programm bekomme?
Diese Auswertung ist ja beim Array flöten gegangen.

[Karl H. (kbuchegg)]

Manfred W. schrieb:
> 64
>
> Karl Heinz, kannst du mir noch einen Tipp geben wie ich den Punkt der
> Anzeige, also den dp da auch wieder in mein Programm bekomme?
> Diese Auswertung ist ja beim Array flöten gegangen.

Na ja.
Indem du ihn setzt bzw. bei der entsprechenden Stelle das Digit 
einschaltest, wenn du ihn brauchst.

Was soll ich dir da jetzt gross für einen Tip geben? Du wirst ja doch 
wohl ein einzelnes Bit an einem Port auf 1 setzen können, wenn es 1 
werden soll.

Wenn beim Multiplexen die 7Segment Anzeige mit der Nummer 0 drann ist, 
dann eben den Punkt noch mit dazu einschalten

....
  SEVEN_SEGMENT_PORT = digitPattern[ digits[i] ]; 
  if( i == 0 )
    SEVEN_SEGMENT_PORT |= 0x80;
....

oder

#define SEVEN_SEGMENT_PORT    PORTD
#define SEVEN_SEGMENT_DDR    DDRD

                 // .gfedcba
uint8_t digitPattern[] =  {
                0b00111111,
                0b00000110,
                0b01011011,
                0b01001111,
                0b01100110,
                0b01101101,
                0b01111101,
                0b00000111,
                0b01111111,
                0b01101111,
              };

#define DP_DIGIT  7    // der Dezimalpunkt ist am Bit 7 verkabelt

volatile uint8_t digits[4];


....
  SEVEN_SEGMENT_PORT = digitPattern[ digits[i] ]; 
  if( i == 0 )
    SEVEN_SEGMENT_PORT |= ( 1 << DP_DIGIT );
....

dann ist es ein wenig besser organisiert und das Bit, das den 
Dezimalpunkt steuert, findet sich im Code an der Stelle, in der auch der 
Aufbau der anderen Ziffern aus den Segmenten der Anzeige beschrieben 
ist.


(oder eben bei der Anzeige 3, je nachdem ob die Nummerierung der 
Anzeigen von links nach rechts oder von rechts nach links durchläuft).

[Manfred W. (Gast)]

Bit auf 1 setzen ist kein Problem.
Nur wie teil ich ihm mit das er dieses Bit nur auf dem 1 Segment setzen 
soll wenn ich zb. eine Taste drücke.

[Manfred W. (Gast)]

auf dem ersten Ziffernsegment meine ich.

[Karl H. (kbuchegg)]

Na komm.
Denk dir was aus!

Variablen sind schon erfunden. Ein 'if' ist schon erfunden. Vergleiche 
sind schon erfunden.

Ein wenig musst du auch selber was 'erfinden'. Ist ja schliesslich dein 
Projekt. Ganz im Gegenteil: Das 'sich etwas ausdenken' und nachsehen ob 
das funktioniert ist doch der ganze Spass an der Sache.

[Uwe (de0508)]

Guten Morgen Manfred,

Uwe S. schrieb:
> Hallo,
>
> ich wollte Dich auf den zweiten Timer hinweisen.
>
> Was kommt hierbei raus?
>
> TCCR0B = (1<<CS01 | 1<<CS00);

Die Clock Select Bit werden nicht für einen Vorteiler von 64 gesetzt - 
also FALSCH!

Der Ausdruck liefert die Zahl 2 also 0b10 und damit einen Vorteile von 8 
!

Wissen ist hier gefragt nicht raten !

Siehe:

http://de.wikibooks.org/wiki/C-Programmierung:_Liste_der_Operatoren_nach_Priorit%C3%A4t

[Karl H. (kbuchegg)]

Uwe S. schrieb:

>> Was kommt hierbei raus?
>>
>> TCCR0B = (1<<CS01 | 1<<CS00);
>
> Die Clock Select Bit werden nicht für einen Vorteiler von 64 gesetzt -
> also FALSCH!
>
> Der Ausdruck liefert die Zahl 2 also 0b10

fast. Es ergibt 3

Aber warum so kompliziert. Einfach im Datenblatt nachsehen. Es werden 
offensichtlich im Code die Bits CS01 und CS00 gesetzt. Im Datenblatt 
gibt es beim Timer 0 eine Tabelle, in der man mit den beiden Bits CS01 
bzw. CS00 nachsehen kann, welchem Vorteiler das entspricht. Den 
Zahlenwert, der sich aus den Bits ergibt, braucht man dazu nicht 
wirklich wissen.

[Uwe (de0508)]

Hallo Karl Heinz,

da fehlen noch Klammern - die sehen wir gerne nicht mehr - deshalb nur 
2.

Also eher so wird der Kompiler den Ausdruck verarbeiten:

TCCR0B = (1<< (CS01 | 1) <<CS00);

[Karl H. (kbuchegg)]

Uwe S. schrieb:
> Hallo Karl Heinz,
>
> da fehlen noch Klammern - die sehen wir gerne nicht mehr - deshalb nur
> 2.

?
<< hat eine wesentlich höhere Precedence als |
Die Klammern die dir fehlen sind ein optisches Gimmick aber rein 
technisch sind sie in diesem Ausdruck nicht notwendig. Der Ausdruck 
parst auch ohne Klammern genau so, wie er soll.
Ob das schlau ist, die Klammern wegzulassen, steht auf einem anderen 
Blatt. Notwendig sind sie hier aber konkret nicht.

>
> Also eher so wird der Kompiler den Ausdruck verarbeiten:
>

TCCR0B = (1<< (CS01 | 1) <<CS00);

Nope.
Das ist kompletter Quatsch.
Schau bitte mal in eine Operator Precedence Table hinein. Da gehts auch 
nicht um 'eher', sondern dafür gibt es exakte Regelungen.


Edit:
Hier ist eine
http://en.cppreference.com/w/c/language/operator_precedence
Operatoren, die weiter oben stehen, binden stärker.

[Manfred W. (Gast)]

Dann stimmt diese Tabelle hier nicht?

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR

CS00 -> 1
CS01 -> 1
= CPU-Takt / 64

[Karl H. (kbuchegg)]

Manfred W. schrieb:
> Dann stimmt diese Tabelle hier nicht?
>
> 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR
>
> CS00 -> 1
> CS01 -> 1
> = CPU-Takt / 64

Abgesehen davon, dass sie für den falschen µC-Typ ist, Zitat

Der 8-Bit Timer wird z.B bei AT90S2313

stimmt das schon.
Nur gewöhn dir an, dass deine Bibel das Datenblatt zu deinem Prozessor 
ist und nichts anderes! Egal, was du in einem Tutorial liest, du checkst 
es mit dem Datenblatt zu deinem Prozessortyp!

[Ingo S. (schicki)]

Hallo Manfred,

ich habe das mit einem ganz einfachen BCD-Treiber realisert.

http://www.schwabenplan.com/downloads/d01500.pdf

Die Treiber für 8051 und PIC hätte ich auch.

http://www.schwabenplan.com/downloads/MC-Lehrsystem_Katalog.pdf

Grüße
Ingo

[Manfred W. (Gast)]

Ist bei ATtiny2313 laut Datenblatt genau ident.
CS00 und CS01 auf 1 = clk/64

Also wieso 3?

[Karl H. (kbuchegg)]

Uh. bei dir muss man aber wirklich ganz unten anfangen.

8 Bit

Hier sind sie

 Bitnummer      7   6   5   4   3   2   1   0
              +---+---+---+---+---+---+---+---+
 0 oder 1     |   |   |   |   |   |   |   |   |
              +---+---+---+---+---+---+---+---+

welche Kombinationen der Bits mit 0-en oder 1-en gibt es und wie werden 
sie sinnvoll durchnummeriert

   00000000           0
   00000001           1
   00000010           2
   00000011           3
   00000100           4
   00000101           5
   00000110           6
   00000111           7
   00001000           8
   00001001           9
   00001010          10
   00001011          11
   00001100          12
   ....
   11111101         253
   11111110         254
   11111111         255

CS00 ist laut Datenblatt im Byte des Registers das Bit 0
CS01 ist laut Datenblatt im Byte des Registers das Bit 1

Betrachtet man also nur die beiden Bits, dann hat man 1 Byte (das mit 
dem Rest des Registers verodert wird), in dem das Bit 0 und das Bit 1 
gesetzt sind. Und das ist dezimal ausgedrückt welche Zahl (siehe 
Tabelle)?

[Manfred W. (Gast)]

Binär gerechnet schon klar Karl Heinz, aber Uwe meinte ja:

> TCCR0B = (1<<CS01 | 1<<CS00);

Die Clock Select Bit werden nicht für einen Vorteiler von 64 gesetzt -
also FALSCH!
Der Ausdruck liefert die Zahl 2 also 0b10 und damit einen Vorteile von 8

Das versteh ich jetzt nicht.
Wieso entspricht 2 (oder 3) in diesem Falle dann einen Vorteiler von 8?

[Karl H. (kbuchegg)]

Manfred W. schrieb:
> Binär gerechnet schon klar Karl Heinz, aber Uwe meinte ja:

Uwe hat sich geirrt.
Wie dir als C Kenner natürlich sofort aufgefallen ist :-)

[Karl H. (kbuchegg)]

Manfred W. schrieb:

> Wieso entspricht 2 (oder 3) in diesem Falle dann einen Vorteiler von 8?


Weil im Rechner alles einfach nur BIts sind.

Ob du   0000 0011
als 8 Bits auffasst, in denen das Bit 0 und das Bit 1 auf 1 gesetzt ist, 
oder ob du das als die Dezimalzahl 3 auffast eine reine Frage dessen 
ist, welche Sichtweise du haben willst. Dem COmputer ist das egal. Der 
sieht einfach nur 1 Byte in dem die beiden Bits gesetzt sind.

Und wenn du im Datenblatt nachsiehst, dann entspricht das (reduziert auf 
nur die Vorteiler Bits) einem Vorteiler von 64.

[Manfred W. (Gast)]

Ist denn die Schreibweise nun korrekt?

Mit Klammer, ohne, oder ganz anders?

TCCR0B = (1<<CS01 | 1<<CS00);
TCCR0B = (1<<CS01) | (1<<CS00);
TCCR0B = 1<<CS01^1<<CS00;

???