ADC Messung mit dem Attiny 841

Heiner schrieb:
> Leider konnte ich verstehen was ADCW ist.

Ich nehme an du hast es nicht verstanden.

Aber ein Blick ins Datenblatt (16.13.3) lässt die Vermutung
aufkommen dass es sich um eine Kombination von ADCL und ADCH
handelt.

Das bestätigt dann auch ein Blick in die Datei iotn841.h

Ben B. schrieb:
> Für 8 Bit kann man das Alignment in ADCL/ADCH entsprechend einstellen

Siehe 16.13.5 im Datenblatt.

ADCSRB – ADC Control and Status Register B

Wenn ich das in 16.13.5 richtig verstanden habe besteht ADCW bei 10 Bit 
aus ADCH und ADCL. Wenn ich nur 8 Bit brauche wird in Register ADCSRB 
das Bit ADLAR auf 1 gsetzt.
Habe ich das richtig verstanden?

Heiner schrieb:
> Wenn ich nur 8 Bit brauche wird in Register ADCSRB
> das Bit ADLAR auf 1 gsetzt.

Ja, und nur ADCH auslesen (8 bittig!)... da die unteren 2 Bit
nicht zu auswerten sind.

Warum willst du nur 8 Bit?

Um es einmal zu verstehen und arbeite an einer übertragung mit I2C. 
Wollte mir nicht gleich die 10 Bit antun.
Kannst du mir ein paar Tips geben wenn ich 10 Bit per I2C übertragen 
will?

Heiner schrieb:
> Kannst du mir ein paar Tips geben wenn ich 10 Bit per I2C übertragen
> will?

Klar:
Sende 16Bit

Heiner schrieb:
> Kannst du mir ein paar Tips geben wenn ich 10 Bit per I2C übertragen
> will?

Man überträgt einfach zweimal 8 Bit (ein 10 Bit ADC Wert wird
in einer 16 Bit Variable gespeichert, siehe Return-Wert ADCW)
da du 10 bit über I2C nicht einfach übertragen kannst.

Da liegt auch das Problem. Eine 16 Bit übertragung mit I2C habe ich noch 
nie gemacht. Kennst du ein Beispiel dazu?

Heiner schrieb:
> Eine 16 Bit übertragung mit I2C habe ich noch nie gemacht.

Dann zeig mal deine 8 Bit Übertragung.

Habe bisher die übertragung der Tastenzustände am Attiny 841 vom Slave 
zum Master und zurück hinbekommen. Paralle habe ich den Komparator und 
ADC am ATI 841 geschafft. Da der Ati 841 beim Bus sehr anders ist, kann 
ich meine bisherigen Programm mit dem Atmega 128 nicht nutzen. Da werde 
ich wohl erst einiges machen müssen.

Heiner schrieb:
> Eine 16 Bit übertragung mit I2C habe ich noch
> nie gemacht.

Wer es verstanden hat 1 Byte zu senden, kann auch ein zweites 
übertragen.
Und wenn das nichts wird, dann liegen die Probleme ganz woanders.

Heiner schrieb:

> Habe bisher die übertragung der Tastenzustände am Attiny 841 vom Slave
> zum Master und zurück hinbekommen. Paralle habe ich den Komparator und
> ADC am ATI 841 geschafft. Da der Ati 841 beim Bus sehr anders ist, kann
> ich meine bisherigen Programm mit dem Atmega 128 nicht nutzen.

Nicht der Bus ist anders, nur die Hardware. Und deren Funktionsprinzip 
ist sehr ähnlich, wenn man mal gedanklich auf Slave beschränkt und die 
Smart-Features des 441/841-TWI-Slave aussen vor läßt, also nicht 
aktiviert.

Unter diesen Randbedingungen kann man gut geschriebenen Slave-Code für 
die normale Mega-TWI-Einheit praktisch ohne jegliche strukturelle 
Änderungen für den TWI-Slave der 441/841 übernehmen. Man muß nur etliche 
symbolische Konstanten singemäß anpassen.

Setzt natürlich voraus, dass man den Sinn verstanden hat, was bei selbst 
geschriebenem Code vorausgesetzt werden kann. Nur bei C&P-Code muss man 
erst verstehen lernen, was der eigentlich tut...

Ich glaube der Heiner verarscht uns.

Stefan ⛄ F. schrieb:
> Ich glaube der Heiner verarscht uns.

Daher wollte ich auch erst mal sehen was er selbst gemacht hat.

weiter weg schrieb:
> Dann zeig mal deine 8 Bit Übertragung.

Aber die ganzen übereifrigen, unausgelasteten Technik-Freaks haben
solch massive Scheuklappen dass sie das nicht erkennen können.

Ich möchte euch auf keinen Fall verarschen. Um den Attiny 841 zu 
verstehen gehe ich jeden Anwendungsfall nach Datenblatt durch. Dazu 
übersetze ich mir den Inhalt, lese die Register genau und vergleiche es 
mit den Programmen die ich bisher habe. Hatte euch ja schon öfters um 
Rat gefragt und viele Infos dazu bekommen.
Mein Code für den Attiny841 als Slave zum I2C Bus:

1

void I2C_init(void)

2

  {

3

  TWSA = I2C_SLAVE_ADDRESS;          // TWI Adressregister

4

  TWSD = 0xFF;                // Datenregister

5

  TWSCRA = (1<<TWEN)|(1<<TWSHE)|(1<<TWASIE)|(1<<TWSIE)|(1<<TWDIE);      

6

  // Register A, TWEN-Schnittstelle Aktivieren, TWSHE-Haltezeit aktivieren, TWASIE-Adressenunterbrechung aktivieren, 

7

  // TWSIE-Stop Unterbrechung aktivieren, TWDIE-Datenunterbrechung aktivieren 

8

    TWSCRB = (1<<TWAA)|(1<<TWCMD1)|(0<<TWCMD0);  // Register B, TWI Bestätigungsaktion, TWI Befehl

9

  sei();      // Interrups einschalten

10

  }

Und ISR dazu:

1

ISR( TWI_SLAVE_vect )

2

  {

3

    uint8_t status = TWSSRA & 0xC0;      // Register A

4

  if (status & I2C_DATA_INTERRUPT)

5

  // Daten wurden vom Master empfangen oder werden angefordert

6

    {

7

      if (TWSSRA & (1 << TWDIR))          // Master fordert Daten vom Slave an

8

      {

9

      TWSD = tx_buff;

10

      TWSCRB = (uint8_t) ((1<<TWCMD1)|(1<<TWCMD0));

11

      }

12

    else       // Master sendet Daten zum Slave

13

      {

14

      TWSCRB |= (uint8_t) ((1<<TWCMD1)|(1<<TWCMD0));

15

      command = TWSD;

16

      }

17

    }

18

  else if (status & I2C_ADDRESS_STOP_MATCH)

19

    {

20

    if (TWSSRA & I2C_BUS_COLLISION)

21

      {

22

      TWSCRB = (uint8_t) (1<<TWCMD1);

23

      }

24

    else

25

      {

26

      if (TWSSRA & (1<<TWAS))

27

        {

28

        // ACK

29

        TWSCRB = (uint8_t) ((1<<TWCMD1)|(1<<TWCMD0));

30

        }

31

      else

32

        {

33

        // Stop Condition

34

        TWSCRB = (uint8_t) (1<<TWCMD1);

35

        }

36

      }

37

    }

38

  }

Damit kann ich bereits Daten zum Master übertragen.
Sicher geht es besser.
Heiner

Sorry vergessen zu sagen, senden und empfang klappt damit.

Noch mal zur ADC.

Heiner schrieb:
> Wenn ich das in 16.13.5 richtig verstanden habe besteht ADCW bei 10 Bit
> aus ADCH und ADCL. Wenn ich nur 8 Bit brauche wird in Register ADCSRB
> das Bit ADLAR auf 1 gsetzt.
> Habe ich das richtig verstanden?

Habe jetzt ADCSRB |=(1<<ADLAR) auf 1 gesetzt. Habe dann die Spannung 
zwischen 0 und 5V verändert. Klappt aber nicht damit nur 8 Bit zu 
nutzen.
Mit welchem Bit kann ich von 10 Bit auf 8 Bit umschalten?

Heiner schrieb:

> Habe jetzt ADCSRB |=(1<<ADLAR) auf 1 gesetzt. Habe dann die Spannung
> zwischen 0 und 5V verändert. Klappt aber nicht damit nur 8 Bit zu
> nutzen.

Doch das klappt schon. Wenn man verstanden hat, was da passiert.

> Mit welchem Bit kann ich von 10 Bit auf 8 Bit umschalten?

Garnicht. Wenn du nur 8 Bit des Ergebnisses haben willst, benutzt du 
auch einfach nur acht Bit davon.

ADLAR dient nur dazu, die relevanten 8Bit der Wandlungsergebnisses in 
einem 8Bit-Register bereitzustellen und erspart so, zwei Register 
auszulesen und das Ergebnis erst passend zu hinschieben zu müssen.

Sprich: statt ADCW (2x 8 Bit) liest du nur ADCH aus. Da stehen deine 8 
Bit schon vollkommen passend drinne. Die zwei wegzuwerfenden Bits stehen 
in ADCL. Da du sie sowieso wegwerfen willst, brauchst du es erst 
garnicht auslesen.

Heiner schrieb:
> Klappt aber nicht damit nur 8 Bit zu nutzen.
> Mit welchem Bit kann ich von 10 Bit auf 8 Bit umschalten?

Ich habe es dir doch beschrieben wie es funktioniert.
Was bitte ist an meinem Satz nicht zu verstehen?
Du schaffst es nicht deine Lesefunktion so abzuändern damit
es wie von mir beschrieben arbeitet?

weiter weg schrieb:
> Ja, und nur ADCH auslesen (8 bittig!)... da die unteren 2 Bit
> nicht zu auswerten sind.

Wenn du das nicht willst/kannst dann unterstelle ich dir Trollerei
oder vollständige Überforderung. Im zweiten Fall empfehle ich dir
ein anderes Hobby wie z.B. Wandern oder Stricken/Häkeln.

weiter weg schrieb:
> Im zweiten Fall empfehle ich dir
> ein anderes Hobby wie z.B. Wandern oder Stricken/Häkeln.

Mach Dich einfach weg. Ganz weit weg. Mach Dich RAUS!!

Warun wird hier einem sofort ein Troll zu sein untergeschoben?
Die Fragen die ich stelle sind von grossen Intresse für mich.
Ist das der Umgang von euch sogenannten Fachleuten mit Anfänger oder 
macht ihr nur Stimmung oder blöde Anmache.
Zurüchk zum Thema.
Habe es jetzt so hinbekommen.

1

ADCSRB |=(1<<ADLAR);        // bei 8 Bit links

2

  while (ADCSRA & (1<<ADSC))

3

    {                  // auf Abschluss der Konvertierung warten

4

    }

5

  //return ADCW;            // ADC auslesen und zurückgeben bei 16 Bit

6

  return ADCH;            // 8 Bit mit ADLAR=1

Damit läuft 8 Bit und ich kann mit den Auskommentierten Zeilen auf 16 
Bit umstellen.
Bleibt noch das Problem mit der übertragung von 16 Bit mit dem Bus.

Heiner schrieb:

> Bleibt noch das Problem mit der übertragung von 16 Bit mit dem Bus.

Du meinst, es bleibt das Problem, dass dir da noch niemand eine fertige 
Lösung geliefert hat, richtig?

Wie wäre es mal mit tatsächlich selber programmieren? Alles Nötige an 
Hinweisen hast du im Laufe dieses Threads bereits bekommen.

Mehr geht nicht, das wäre Auftragsarbeit, dafür musst du mit Kohle rüber 
kommen.

Heiner schrieb:
> Bleibt noch das Problem mit der übertragung von 16 Bit mit dem Bus.

Das wirkt wirklich äusserst dümmlich oder trollig. Bleibt keine
andere Schlussfolgerung.

Hier hattest du bereits den Hinweis:

Arduino Fanboy D. schrieb:
> Wer es verstanden hat 1 Byte zu senden, kann auch ein zweites
> übertragen.

Nicht schon wieder das mit dem Troll. Versuche einfach es zu verstehen.
Hatte weiter oben bereits den Code für den Attiny 841 und den I2C bus 
angegeben. Da er anders ist z.B. als bei einem Slave (kein Prozessor) 
mit 16 Bit sieht die übertragung anders aus. Leider habe ich im Netz 
keine Info dazu gefunden.Vielleicht gehen ein paar Brocken zu meinem 
Verständnis.

Heiner schrieb:

> mit 16 Bit sieht die übertragung anders aus.

Nur ganz unwesentlich.

> Leider habe ich im Netz
> keine Info dazu gefunden.Vielleicht gehen ein paar Brocken zu meinem
> Verständnis.

Mein Gott. Verstehe einfach, wie I2C funktioniert und benutze es. Das 
hat doch rein garnix mit der AVR8-Architektur im Allgemeinen oder dem 
TWI-Slave der ATiny441/841 im Besonderen zu schaffen.

Man muss einfach nur verstehen, wie der Bus funktioniert und den 
vorhandenen Code entsprechend nutzen. Wenn man ein Byte korrekt senden 
kann, zwei aber nicht, beweist das genau eine Sache: Man benutzt Code, 
den man nicht verstanden hat. Und die einzige logische Erklärung dafür 
ist:

Weil man wohl einfach zu FAUL war, zu lernen, wie der Bus 
funktioniert...

c-hater schrieb:
> Weil man wohl einfach zu FAUL war, zu lernen, wie der Bus
> funktioniert...

Ein Troll hat immer noch ein "gutes" Argument in der Hinterhand.

Heiner schrieb:
> Hatte weiter oben bereits den Code für den Attiny 841 und den I2C bus
> angegeben.

Das hast du nicht!
Die Initialisierung, ja.
Die ISR auch.

Aber die (read/Write) API zur Software hast du geheim gehalten.

Also:
Nur ein untestbares Fragment gezeigt.
Exakt den Bereich, an dem es hakt, geheim gehalten.

Habe nichts geheim gehalten. Noch mal das komplette Programm. Mehr habe 
ich dazu nicht und es geht damit.

1

#include "main.h"            // CPU 16MHz

2

#include <avr/interrupt.h>        // dient zur Behandlung der Interrupts

3

#include <avr/io.h>            // Integer-Definitionen

4

5

#define I2C_SLAVE_ADDRESS       0x52  // Slave Adresse 0x52

6

#define I2C_DATA_INTERRUPT      0x80  // 0x80

7

#define I2C_BUS_COLLISION       0x08  // 0x08

8

#define I2C_ADDRESS_STOP_MATCH  0x40  // 0x40

9

10

volatile uint8_t command;

11

volatile uint8_t tx_buf[2];  // 4

12

volatile uint8_t tx_buff = 11;  // 4

13

volatile uint8_t tx_buf_index = 0;

14

15

// Funktionsprototypen

16

void I2C_init(void);

17

18

void I2C_init(void)

19

  {

20

  TWSA = I2C_SLAVE_ADDRESS;          // TWI Adressregister

21

  TWSD = 0xFF;                // Datenregister

22

  TWSCRA = (1<<TWEN)|(1<<TWSHE)|(1<<TWASIE)|(1<<TWSIE)|(1<<TWDIE);      

23

  // Register A, TWEN-Schnittstelle Aktivieren, TWSHE-Haltezeit aktivieren, TWASIE-Adressenunterbrechung aktivieren, 

24

  // TWSIE-Stop Unterbrechung aktivieren, TWDIE-Datenunterbrechung aktivieren 

25

    TWSCRB = (1<<TWAA)|(1<<TWCMD1)|(0<<TWCMD0);  // Register B, TWI Bestätigungsaktion, TWI Befehl

26

  sei();      // Interrups einschalten

27

  }

28

29

ISR( TWI_SLAVE_vect )

30

  {

31

    uint8_t status = TWSSRA & 0xC0;      // Register A

32

  if (status & I2C_DATA_INTERRUPT)

33

  // Daten wurden vom Master empfangen oder werden angefordert

34

    {

35

      if (TWSSRA & (1 << TWDIR))          // Master fordert Daten vom Slave an

36

      {

37

      TWSD = tx_buff;

38

      TWSCRB = (uint8_t) ((1<<TWCMD1)|(1<<TWCMD0));

39

      }

40

    else       // Master sendet Daten zum Slave

41

      {

42

      TWSCRB |= (uint8_t) ((1<<TWCMD1)|(1<<TWCMD0));

43

      command = TWSD;

44

      }

45

    }

46

  else if (status & I2C_ADDRESS_STOP_MATCH)

47

    {

48

    if (TWSSRA & I2C_BUS_COLLISION)

49

      {

50

      TWSCRB = (uint8_t) (1<<TWCMD1);

51

      }

52

    else

53

      {

54

      if (TWSSRA & (1<<TWAS))

55

        {

56

        // ACK

57

        TWSCRB = (uint8_t) ((1<<TWCMD1)|(1<<TWCMD0));

58

        }

59

      else

60

        {

61

        // Stop Condition

62

        TWSCRB = (uint8_t) (1<<TWCMD1);

63

        }

64

      }

65

    }

66

  }

67

68

int main(void)

69

  {  

70

  DDRA=0b00000011;      // Port A auf Ausgang schalten

71

  PORTA=0b00000011;      // Port A auf aus 

72

  DDRB=0b00000011;      // Port A auf Ausgang schalten

73

  PORTB=0b00000011;      // Port A auf aus  

74

  I2C_init();

75

  while(1)

76

    {

77

    if (command != 42)       // Taster T2 PD0

78

     {              // Wenn T1 gedrückt...

79

       PORTA &=~(1<<PINA1);    // LED 2 ein  

80

     }

81

     else

82

    {              // wenn nicht

83

       PORTA |=(1<<PINA1);    // LED 2 ein ??

84

    }  

85

     if (command != 43)       // Taster T2 PD0

86

    {              // Wenn T1 gedrückt...

87

      PORTA &=~(1<<PINA0);    // LED 2 ein

88

    }

89

     else

90

    {              // wenn nicht  

91

      PORTA |=(1<<PINA0);    // LED 2 ein ??

92

    }   

93

94

    {

95

96

      {

97

98

    // ========>> TASTENEINGABEN T3

99

    if (!(PINA & (1<<PINA7)) )  // Taster T 3

100

      {              // Wenn T3 gedrückt...

101

      tx_buff = 5;  // 4

102

      }

103

104

    // ========>> TASTENEINGABEN T2

105

    if (!(PINB & (1<<PINB2)) )  // Taster T 3

106

      {              // Wenn T3 gedrückt...

107

      tx_buff = 3;  // 4

108

      }    

109

      }

110

    }

111

112

    }

113

  }

Das einzige was fehlt ist die main. Da steht nur drin das CPU 10MHz 
sind.
LG Heiner

Soll 16MHz sein

Danke für die Info

Matthias S. schrieb:
> In deiner ADC Routine könnte zum füllen dann stehen
> tx_buff[0] = ADCH;
> tx_buff[1] = ADCL;

Bei 16 Bit verwende ich ADCW und das besteht aus ADCH und ADCL.
Wenn ich nur 8 Bit verwende, nutze ich ADCH und ADLAR=1.
Dann brauche ich im Master nur aus denn 2 x 8 Bit wieder 16 Bit machen.
Das gefällt mir.

Heiner schrieb:
> if (TWSSRA & (1 << TWDIR))          // Master fordert Daten vom Slave an
>       {
>       TWSD = tx_buff;
>       TWSCRB = (uint8_t) ((1<<TWCMD1)|(1<<TWCMD0));
>       }

Meinst du diese Stelle?

Das Programm des Slave beim I2C Bus bzw. ISR empfinde ich als relativ 
gross und kompliziert. Da ich noch nicht beim Bus angekommen bin, ergibt 
sich eine Frage für mich.
Gibt es ein weniger Aufwändiges Programm für den Slave beim Attiny 441?

Habe mir die Stellen angesehen. Bin dazu geteilter Meinung. Habe z.B. 
Angaben wie asm und nop gefunden. Dachte eigentlich das sowas lange raus 
ist.

Donnerwetter!

Du bist wirklich ein Crack!
Weißt Du, wofür “nop” oder “Sam” benötigt wird? Ich bezweifle das, und 
mit “Copy & Paste” kommst du nicht weit

SCNR

Hannes

Mist!

Muss natürlich “asm” heißen nicht “Sam” - sche** Autokorrektur

Hannes schrieb:
> Mist!
>
> Muss natürlich “asm” heißen nicht “Sam” - sche** Autokorrektur

Ja, die Autokorrektur macht schöne Sachen. Mir hat sie mal ein Auto von 
MAN auf Scania korrigiert. Da konnte ich dann 2 Tonnen mehr laden.

Veit D. schrieb:
> Wofür \n\t hinter nop dienen soll kann ich nicht erklären.
> new line und Tabulator? Wer kann den Grund dafür zusammen mit nop
> erklären?

Wenn man sich den ASM Zwischencode anzeigen lässt, steht das schön 
untereinander, statt in einer Zeile gequetscht

Veit D. schrieb:
> Wofür \n\t hinter nop dienen soll kann ich nicht erklären.

Zeilenumbruch und Tabulator.
In Assembler muss hinter jedem Befehl ein Zeilenumbruch kommen und die 
Befehle sind üblicherweise mit Tabulator ein gerückt. Das spielt erst 
eine Rolle, wenn du mehrere asm befehle hintereinander schreibst und 
dann den Quelltext als Assembler-Listing ausgibt. Der sieht dann schöner 
aus.

Veit D. schrieb:
> Im disassamblierten Code kann ich das
> nicht herauslesen. Da finde ich nur
Da lassen sich die \n und \t auch nicht mehr finden.

Der C Compiler baut ASM Zwischencode(auf Wunsch), da siehst du es.
Der C++ Compiler tut das nicht.

Du scheinst es nicht zu glauben. Ich will keinen ärgern, über den Tisch 
ziehen oder ähnliches damit machen. Mein Ziel ist es einfach den Attiny 
441 (841) zu verstehen und anzuwenden. Mir gefällt einfach die 
Baugrösse, klein relativ wenige Pins und viele Anwendungen. Leider 
scheint meine Freude an dem IC nur von wenigen geteilt zu werden. Man 
findet im Netz wenige Beispiel dazu. Ja es stimmt, verwende teilweise 
vorhandenen Code aus dem Netz. Das sind dann aber Sachen um die Funktion 
zu verstehen oder einfach mal anschauen wie es andere machen. Wenn ich 
dann das Datenblatt dazunehme komme ich mit den Funktione weit aus 
besser klar. Da die Anwendung aber auf mein Brett bezogen sind, muss ich 
alles umbauen oder halt neu machen.
Soweit ist das klar. Sehen wir mal was es so für den I2C Bus gibt. Ein 
Programm geht ja, ist aber wahrscheinlich einfacher möglich.
LG Heiner

Mit Arduino wärst du längst fertig.

@Stefan

Das wage ich zu bezweifeln. Auch wenn Arduino Libraries bietet, mit 
denen man Funktionen “zusammenklimpern” kann, muss man dennoch wissen, 
wie es geht 😉.

Außerdem hat Veit D. schon mit den links brauchbare Hinweise gegeben- 
wenn man aber nicht versteht sie anzuwenden…

Stefan ⛄ F. schrieb:
> Mit Arduino wärst du längst fertig.

Das ist schon möglich.
Kann ich den die ganzen Sachen verwenden wenn ich nicht mit einem 
Arduino arbeite?
Habe bisher alles in C gemacht ohne die ganzen Sachen von Arduino.
Alle notwendigen Sachen für den I2C Bus beim Attiny 841 sollen im 
Datenblatt stehen. Mag sein, leider schwer für mich zu verstehen. Habe 
angefangen die Register anzuschauen und wenn möglich zu verstehen. Ist 
leider für mich sehr schwer. Kann mir jemand dabei helfen es zu 
verstehen?

Gibt es einen Attiny oder anderen IC der die gleiche I2C Schnitstelle 
wie der Attiny 441/841 verwendet?

Hallo Heiner

Ich dachte, Du hättest den I2C Bus vom Attiny 841 schon funktionsfähig 
bzw. schon Daten per I2C ausgetauscht?

Hallo Heiner

Ist Dein Problem der I2C des Attiny 841 oder die ADC Messung (lt 
Betreff)?

Die ADC mit 8 und 16 Bit geht ohne Probleme.
Möchte jetzt einfach weitermachen und den ADC Wert auf einem Display mit 
dem Bus darstellen. Dazu möchte ich einen Atmega 128 als Master 
verwenden und ein Display ansteuern. Die Ansteuerung mit dem Atmega 
funktioniert bereits korrekt.
Soll ich lieber etwas neues aufmachen?

Hannes schrieb:
> Ich dachte, Du hättest den I2C Bus vom Attiny 841 schon funktionsfähig
> bzw. schon Daten per I2C ausgetauscht?

Ja das stimmt, habe bereits Daten ausgetauscht. Leider ist das Programmm 
für den Slave etwas gross geraten. Deshalb mein Versuch es etwas kleiner 
und damit übersichtliches zu machen. Habe das Datenblatt dazu genommen, 
komme leider nur sehr schwer damit zurecht. Das funktionierende Beispiel 
für den slave kann ich kaum nachvollziehen.

Hallo Heiner

Habe ich das korrekt verstanden:
Du willst mit dem Attiny 841 per ADC Werte einlesen (8 Bit), diese per 
I2C an den Atmega 128 schicken und die Werte per Display (das direkt 
ohne I2C am Atmega 128 angeschlossen ist) anzeigen.
Stimmt meine Zusammenfassung?

Wobei der Attiny 841 der I2C Slave ist und der Atmega 128 der I2C Master 
ist - korrekt

Heiner schrieb:
> Kann ich den die ganzen Sachen verwenden wenn ich nicht mit einem
> Arduino arbeite?

Ja schon, weitgehend. Voraussetzung ist, dass Arduino diesen 
Mikrocontroller unterstützt. Offenbar gibt es für den ATtiny841 ein 
passendes Plugin (Core).

> Alle notwendigen Sachen für den I2C Bus beim Attiny 841 sollen im
> Datenblatt stehen. Mag sein, leider schwer für mich zu verstehen.

Ja das ist so. Die I²C Schnittstelle ist komplizierter als die meisten 
anderen, weil sie nicht nur einfach nur Daten rein/raus schiebt sondern 
ein komplettes Protokoll implementiert.

In Arduino ist der Teil bereits fertig. Diesen Anzuwenden ist fast so 
einfach, wie printf().

> Kann mir jemand dabei helfen es zu verstehen?

Fange mal mit eine Beschreibung des Protokolls an:
https://howtomechatronics.com/tutorials/arduino/how-i2c-communication-works-and-how-to-use-it-with-arduino/

Erstmal musst du verstehen, welche Signale der Bus in welcher 
Reihenfolge überträgt und welche Zustände es gibt. Denn diese spiegeln 
sich in den Registern wieder.

Lies auch die I²C Spezifikation, das Dokument ist uralt aber sehr gut:
https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Hannes schrieb:
> Du willst mit dem Attiny 841 per ADC Werte einlesen (8 Bit), diese per
> I2C an den Atmega 128 schicken und die Werte per Display (das direkt
> ohne I2C am Atmega 128 angeschlossen ist) anzeigen.

Stimmt nicht ganz. Der Attiny 841 soll per I2C an den Atmega 128 
angeschlossen werden. Auch das Display wird per I2C angeschlossen z.B. 
mit PCF8574. Verwende teilweise verschiedene Displays. Das Display und 
Verbindung mit verschiedenen Slaves funktioniert korrekt.

Stefan ⛄ F. schrieb:
> Ja das ist so. Die I²C Schnittstelle ist komplizierter als die meisten
> anderen, weil sie nicht nur einfach nur Daten rein/raus schiebt sondern
> ein komplettes Protokoll implementiert.

Da gebe ich dir sofort Recht.
Mit diesem Protokoll gibt es den Attiny 441/841. Gibt es da noch andere 
Typen mit dem gleichen Protokoll.
LG Heiner

Heiner schrieb:
> Mit diesem Protokoll gibt es den Attiny 441/841. Gibt es da noch andere
> Typen mit dem gleichen Protokoll.
Die Frage verstehe ich nicht

I2C ist ein Protokoll!
Das Protokoll besteht aus einer Hardware Vereinbarung und einem 
logischen Regelwerk.

Ich sage mal: ALLE µC können I2C.
Ein paar Tinys bieten dafür den USI Block
Andere Mega, nutzen spezialisierte TWI Einheiten.
Und per Software geht auch immer, wenn sonst nix geht.

Also:
Protokolle hat man nicht, sondern man implementiert sie.

Ist klar geworden, wo der Fehler in der Frage liegt?

Vom Hersteller dieser Attiny werden noch andere Typen produziert. Gibt 
es andere Typen die die gleiche Hardware haben? Bei denen man auch mit 
der gleichen Software arbeiten kann?
Beispiel:
Es gibt Attiny die haben kein I2C. Da kann man per Software etwas 
machen.
Es gibt Attiny die haben I2C Bus ohne eigenes Protokoll.
Gibt es andere Attinys die das gleiche Protokoll verwenden?
Kurz gesagt, gibt es noch andere Typen deren Software auf dem Attiny 441 
anwenden oder vergleichen kann?

Hallo Heiner

Hast Du hier schon mal geschaut 
Beitrag "ATtiny841 I2C Slave Beispiel"

Hallo Cyblord

Schön wenn es bei Dir funktioniert 👍.

Wenn Du aber nicht helfen willst, kannst Du Dir den Beitrag sparen

SCNR

Verwende selber diesen Controller in einigen Anwendungen. Da ich ein 
Anfänger bin erarbeite ich mir die Anwendungen. Schaue dazu ins 
Datenblatt und gehe die verschiedenen Möglichkeiten durch. Weiter oben 
habe ich nach ADC gefragt. Das funktioniert jetzt ohne Probleme. Kann es 
Anwenden und Nutzen. Bin dan zur nächsten Stufe gegangen und das ist für 
mich I2C, die übertragung der Daten vom Slave zum Master und Anzeige auf 
einem Display. Bei anderen Controller habe ich das relativ einfach 
hinbekommen. Leider ist das Beispiel für einen funktionierenden Slave 
sehr gross und für mich in einigen Sachen nicht verständlich. Deshalb 
einfach die Frage nach Hilfe dabei.

Hannes schrieb:
> Hast Du hier schon mal geschaut
> Beitrag "ATtiny841 I2C Slave Beispiel"

Ja, diesen Beitrag kenne ich. Er ist auch Grundlage für meinen Slave. 
Mein Programm funktioniert damit, noch ein paar Anpassungen und es geht.
Was ich daran nicht verstehe ist die ISR. Die ist doch so gross.
Geht das nicht auch kleiner?

Wenn’s funktioniert ist es doch 👍

Kleiner machen geht immer, ob’s DANN noch funktioniert 🤔

Warum willst Du die ISR denn kleiner haben?

Hallo Hannes
Es geht haupsächlich darum es zu verstehen.
Habe jetzt im Netz gesucht und noch einiges gefunden.
Einfache Frage dazu:
Warum braucht der Attiny 441
- void Timer0_init(void)
- ISR(TIMER0_COMPA_vect)
- ISR(TWI_SLAVE_vect)

Da ich den Attiny 441(841) in verschiedenen Schaltungen verwenden 
möchte, kann es dazu führen 16 Bit oder 8 Bit oder mehrfache 8 Bit (z.B. 
2 oder 4 x ADC) oder (schnelle) Schalterstelleungen zu übertragen. Das 
nutze ich z.B. um eine Tasterentprellung zu machen. Dadurch kann man 
Tasten verschieden nutzen. Oder einen Enkoder als universeller Eingabe 
zu verwenden oder ein Joystick.
Teilweise sind Teile da von schon lauffähig, andere warten noch auf das 
Programm.
LG Heiner

Heiner schrieb:
> Mit diesem Protokoll gibt es den Attiny 441/841. Gibt es da noch andere
> Typen mit dem gleichen Protokoll.

Alle Mikrocontroller mit I²C (bzw. TWI), also eigentlich fast alle außer 
ein paar wenige Ausnahmen die nur USI haben. Die sind noch schwieriger 
zu programmieren.

Heiner schrieb:
> Vom Hersteller dieser Attiny werden noch andere Typen produziert. Gibt
> es andere Typen die die gleiche Hardware haben? Bei denen man auch mit
> der gleichen Software arbeiten kann?

Was soll denn diese Frage? Andere Typen mit gleicher hardware wirst du 
genau so wenig programmieren können. Bleibe mal lieber auf dem Weg zur 
Problemlösung.

@Stefan

+1 😉

Es scheitert daran, daß manche AVR
- Kein I²C interface haben
- andere kein USI Interface besitzen
- wieder andere keins von Beiden und mittels Software selbst eines 
gebastelt werden muss

- Unverständliche Software mit unverständlichen Bibliotheken aus aller 
Herren Länder verwurstelt werden muß.

-> Schmeiß den Dreck aus dem Konntrolle und installiere Bascom. Damit 
geht es am Einfachsten und es gibt jeweils ein Beispielprogramm in der 
Hilfe.

Veit D. schrieb:
> Schau mal
> ob du damit was anfangen kannst.
> http://www.peterfleury.epizy.com/avr-software.html#libs

Die Datein und Programme von Peter verwende ich bereits. Besonders für 
I2C und das Display. Seine Programme sind auch Grundlage bei anderen 
Sachen von mir.
Leider ist der Attiny 441 mit seinem I2C Bus anders als die anderen. 
Nach Quellen im Netz haben die es total anders gemacht. Mit den anderen 
Programmen die auf den slaves laufen geht es nicht. Teilweise sind die 
Register anders.
Da muss ich mich weiter durchkämpfen.
LG Heiner

Stefan ⛄ F. schrieb:
> Was soll denn diese Frage? Andere Typen mit gleicher hardware wirst du
> genau so wenig programmieren können. Bleibe mal lieber auf dem Weg zur
> Problemlösung.

Habe gehofft einen anderen IC zu finden mit der gleichen Hardware, wo es 
vielleicht besser passende Software.

Egonwalter M. schrieb:
> Und wenn Du GENAU erklärst, was Deine Zielsetzung ist - z.B "mit dem
> ATiny 841 ADC Werte (8Bit) einlesen, mittels I2C an den Master
> (ATMega128) übertragen und diese Werte mittels I2C an ein LCD schicken
> zwecks Anzeige der 8-Bit ADC Werte" - eine klar umrissene
> Aufgabenstellung...

Du hast es bereits gesagt. Genauso will ich es machen. Die gesamte 
vorhanden Software steht bereits oben drin. ADC funktioniert dank eurer 
Hilfe. Jetzt bleibt noch die Werte zum Master zuschicken und dann 
anzuzeigen

Ja das stimmt genau. Das Programm funktioniert korrekt. Was ich noch 
machen muss, die Anpassung an 8 oder 16 Bit und die passende übertragung 
dazu.
Was mich bei diesem Programm verunsicht ist die Grösse. Dadurch ist es 
für mich sehr unübersichtlich und kompliziert. Programme bei anderen 
slaves sind übersichtlicher und damit besser zu verstehen.
Deshalb auch die Frage dazu, geht es nicht kürzer bzw. einfacher.

Egonwalter M. schrieb:
> Hallo Heiner

Beim grundgütigen Egonwalter sollte man sich erst mal seinen
ureigensten Thread reinziehen bevor man darüber urteilt ob
er hier kompetente Hilfestellung geben kann oder nicht.

Beitrag "Arduino UNO USART Daten fehlen"

Heiner schrieb:

> Was mich bei diesem Programm verunsicht ist die Grösse. Dadurch ist es
> für mich sehr unübersichtlich und kompliziert. Programme bei anderen
> slaves sind übersichtlicher und damit besser zu verstehen.

Wohl kaum. Das Programm ist (noch nicht einmal ganz) komplex genug, um 
das Protokoll abbilden zu können. Es gibt nunmal für einen I2C-slave so 
und so viele mögliche Stati und wenn man einen vollwertigen Slave 
implementieren will, muss man die halt auch alle unterstützen, also im 
Programm behandeln.

Einsparungen können sich nur dann ergeben, wenn man auf Teile der 
Möglichkeiten des Protokolls verzichtet, z.B. halt auf die Möglichkeit, 
mehr als ein Payload-Byte pro Transaktion zwischen Master und Slave zu 
bewegen. Und/oder gar auf die Möglichkeit, überhaupt Payload in eine der 
beiden Richtungen zu transferieren. Am allermeisten spart man 
allerdings, wenn man überhaupt keinen Transport von Payload vorsieht. 
Und du wirst lachen: selbst dafür gibt es denkbare Anwendungen.

Dein Problem ist offensichtlich: du kennst das I2C-Protokoll nicht und 
scheinst auch nicht gewillt zu sein, zu lernen, wie es funktioniert. 
Dann hat man NATÜRLICH erhebliche Probleme, zu verstehen, wie ein 
Programm funktioniert, welches dieses Protokoll implementiert. 
Insbesondere dann, wenn es das Protokoll vollständig implementiert, denn 
dann erreicht es naturgemäß den größten Umfang.

Könnte es seindas es hier Unterschiede im Protokoll gibt. Man kann ja 
Daten von einem Slave lesen, z.B. PCF8574 oder einem Attiny oder halt 
einen anderen Prozessor. Beim PCF8574 ist die Sache ja relativ einfach, 
ist Hardware mässig alles vorhanden. Die Software kommt in den Master. 
Der Master liest die Daten aus dem Slave aus oder schreibt neue rein. 
Weiter oben steht ein Hinweis auf das Protokoll. Das habe ich 
durchgelesen, ist unterteilt in verschiedene Bereiche, wie Adresse, 
Register und Daten.
Bei dem Attiny ist das was anderes für mich. Es gibt fertige 
Bibliotheken dazu, da wurde jtronic genannt. Die kenne ich, sind aber 
nur für bestimmte Typen brauchbar. Das passt alles nicht zum Attiny841. 
Vergessen wir mal den Umfang. Bin dabei zu lesen. Da werde ich nichts 
dran änder und alles so lassen wie es ist.
LG Heiner

Heiner schrieb:

> Könnte es seindas es hier Unterschiede im Protokoll gibt.

Nein, das I2C-Protokoll ist immer das gleiche. Aber man kann es auf 
unterschiedliche Art nutzen. Das ist dann ein übergeordnetes Protokoll. 
Es entsteht ein Protokollstack.

Ganz genau dieselbe Soße wie z.B. im Netzwerkbereich. Da gibt es MAC, 
darauf setzt z.B. IP auf, darauf wiederum z.B. TCP, darauf wiederum z.B. 
HTTP usw. usf.

In deinem Anwendungsfall ist es halt einfach so, dass du das 
übergeordnete Protokoll komplett frei definieren kannst, da du sowohl 
master als auch slave selber implementierst.
Es gibt keinen verpflichtenden Standard dafür. Das einzige, was es 
sicherstellen muss, ist die standardgerechte Nutzung des I2C-Protokolls, 
was es als Transport-Protokoll benutzt.
Im µC-Bereich verschmelzen aber diese beiden Layer aus Effizienzgründen 
oft, d.h.: man implementiert auf dem I2C-Layer nur das, was man für das 
übergeordnete Protokoll tatsächlich benötigt.

> PCF8574

Wenn du einen Slave bauen willst, der mit dem Anwendungsprotokoll dieses 
Teils kompatibel ist, dann musst du das halt einfach tun. Nur ist es 
wohl nicht sonderlich sinnvoll. 8Bit-digital-IO (konfigurierbar) vs. 
16bit-analog-out (nicht konfigurierbar)? Nur ein Idiot würde versuchen, 
das kompatibel zu machen. Passt einfach nicht.

Vergiß' die Wichsvorlagen, lerne Denken.

Sorry und Danke für deine Hilfe

Rainer V. schrieb:

> So weit waren wir am 12.06....und für mich ist der TO seitdem keinen
> Schritt weiter gekommen. Sorry...glaube kaum, dass das noch was wird.

Sehe ich auch so. Es sei denn, irgendwer erbarmt sich und liefert eine 
fertige Wichsvorlage.

So, wie's aussieht, ist genau das, was der TO erreichen will. Er selber 
ist offensichtlich unfähig, auch nur die Konzepte zu verstehen. Und 
lernen mag er wohl auch nicht.

Staube über deinen Pessimismus. Es kommt so richtig negativ rüber.
Zu deiner Info. Das Programm funktioniert ohne Probleme. Kann es als 8 
bit oder 10 Bit nutzen. Kann verschiedene Werte angeben. Habe 
verschiedne Stufen drin. Habe das Programm für mich vollkommen 
auskommentiert mit den Angaben im Datenblatt versehen. Die Einstellungen 
die DB angegeben werden sind soweit klar. Teste noch Einstellungen mit 
der Verstärkung, Differenzeingang und anderes. Da bin ich aber auch der 
Hardware dran. Ansonsten habe ich angefangen die Werte per I2C am Bus zu 
übertragen und Anzuzeigen.
Nach Anfang sieht das nicht mehr aus.

c-hater schrieb:
> und liefert eine
> fertige Wichsvorlage.

Auch das ist schon geschehen!
Veith sprach mehrfach vom "Spencer Arduino Core für Tinys"
https://github.com/SpenceKonde/ATTinyCore

OK, das ist C++ (zu einem großen Teil), aber das winzige Detail fällt 
hier wohl nicht ins Gewicht.

Heiner schrieb:

> Staube über deinen Pessimismus. Es kommt so richtig negativ rüber.

Entspricht meinem Gefühl beim Schreiben. Das WAR sehr negativ.

> Zu deiner Info. Das Programm funktioniert ohne Probleme.

Wenn das so ist: Warum sind deine beiden Threads noch nicht mit "Lösung 
gefunden" und "Lösung sieht soundso aus" beendet?

Das wäre ja die logische Konsequenz, wenn stimmt, was du hier 
behauptest...

Das würde ich sehr gern machen, doch wo stelle ich das ein?

Zum ADC hatte ich gesagt es funktioniert und da der Titel nicht das 
aussagt was ich wissen möchte, kommt ein anderer Thread.
Warum müssen alle so agressiv sein. Ich Frage weil ich es nicht weis. Es 
kommen Hinweise, mal kleine oder mal grosse dazu. Ich will es nicht 
geschenkt haben, aber ein Hinweise oder Infos über was falsches sind 
sehr Hilfreich.
Leider bleibt mir der Inhalt der Datenblätter teilweise, auch mit 
übersetzung, sehr verschlossen.
Ein paar freundliche Worte oder ein kleiner Anstoss wirken Wunder und 
ist alle mal besser als seine Wut über das Wissen der anderen 
auszudrücken.
Geh ruhig Biertrinke und beruhige dich. Geniesse das schöne Wetter und 
lass uns gemeinsam anstossen.

Heiner schrieb:
> aber ein Hinweise oder Infos über was falsches sind
> sehr Hilfreich.

Hmm ....
Ich würde richtige Hinweise als hilfreicher erachten, als falsche, oder 
Hinweise auf falsches.

Heiner schrieb:
> Leider bleibt mir der Inhalt der Datenblätter teilweise, auch mit
> übersetzung, sehr verschlossen.
Das ist natürlich eine schwierige Situation.
Welche "wir" auch nicht ändern können.

Denn es gilt ja der Grundsatz:
> Selber lesen, macht selber schlau.

Arduino Fanboy D. schrieb:
> OK, das ist C++ (zu einem großen Teil), aber das winzige Detail fällt
> hier wohl nicht ins Gewicht.

Er will sich ja "nicht verzetteln" und lieber "bei C bleiben".

Stefan ⛄ F. schrieb:

> Er will sich ja "nicht verzetteln" und lieber "bei C bleiben".

Das ist so ziemlich die einzige vernünftige Entscheidung, die er 
getroffen hat. Das muss man ihm zu Gute halten.

C ist schon schwierig genug, aber C++ ist ein absoluter Moloch, den 
selbst die Schöpfer und Entwickler der Sprache kaum noch im vollen 
Umfang überblicken.

Bezüglich der normalen Programmierer ist es aber ziemlich dieselbe Soße, 
kaum einer beherrscht die selbst gewählte Sprache wirklich im vollen 
Umfang. Übrigens auch du nicht und auch der Fanboy nicht.

c-hater schrieb:
> C ist schon schwierig genug, aber C++ ist ein absoluter Moloch, den
> selbst die Schöpfer und Entwickler der Sprache kaum noch im vollen
> Umfang überblicken.
>
> Bezüglich der normalen Programmierer ist es aber ziemlich dieselbe Soße,
> kaum einer beherrscht die selbst gewählte Sprache wirklich im vollen
> Umfang. Übrigens auch du nicht und auch der Fanboy nicht.

Da muss ich dir ausnahmsweise mal zustimmen.

Ergänzend: Es ist OK und praktikabel, eine Programmiersprache nur 
teilweise zu verwenden. Problematisch wird das erst, wenn man auf 
fremden Code stößt, den man deswegen nicht versteht.

Das vollständige Verstehen von beliebigem fremden Code ist allerdings 
eher etwas für die alten Hasen mit viel Berufserfahrung. C++ macht es da 
einem besonders schwer, dicht gefolgt von Java. Diese voll zu 
durchblicken sollte man nicht von Anfängern erwarten, das wäre gemein.

Es hat schon seinen guten Grund, warum immer wieder Programmiersprachen 
erdacht werden, die einfach und dennoch ausreichend seien sollen. Wir 
werden in 30 Jahren sehen, ob das jemandem mit Erfolg gelungen ist. 
Vielversprechende Ansätze sind zu sehen, z.B.: Python und Go. Die sind 
aber noch zu jung, um sie final zu bewerten, finde ich.

Assembler glänzt mit Einfachheit und der Gewissheit, dass man damit 
wirklich ohne Einschränkung alles machen kann - irgendwie. Doch der 
Sprache fehlt es am Mitteln zur übersichtlichen Gestaltung großer 
Programme, der Unterstützung von Teamarbeit und statische Code-Analysen 
zur Vermeidung von Fehlern.

Mit Assembler programmieren ist, als ob ich dich mit Spitzhacke, Schwert 
und Feuerzeug bewaffnet vor einen Berg stelle und dir sage: Baue mir ein 
Hotel - du hast 10 Monate Zeit.

Ist das machbar: Zweifellos! Will das jemand so machen? 
Unwahrscheinlich, es sei denn derjenige nennt sich c-hater.

Egonwalter M. schrieb:
> Nur jemand mit übersteigertem Selbstbewusstsein wird für sich in
> Anspruch nehmen (wollen), dass er die selbst gewählte Sprache wirklich
> in vollem Umfang beherrscht.

Oder jemand, der nur die primitivste Sprache akzeptiert, weil er sie 
tatsächlich vollständig beherrschen kann.

Meinen Pelikan Füller kann ich vollständig beherrschen, aber ich kann 
damit keine Enzyklopädie in angemessener Zeit und Qualität erstellen.

c-hater schrieb:
> Stefan ⛄ F. schrieb:
>
>> Er will sich ja "nicht verzetteln" und lieber "bei C bleiben".
>
> Das ist so ziemlich die einzige vernünftige Entscheidung, die er
> getroffen hat. Das muss man ihm zu Gute halten.
>
> C ist schon schwierig genug, aber C++ ist ein absoluter Moloch, den
> selbst die Schöpfer und Entwickler der Sprache kaum noch im vollen
> Umfang überblicken.
>
> Bezüglich der normalen Programmierer ist es aber ziemlich dieselbe Soße,
> kaum einer beherrscht die selbst gewählte Sprache wirklich im vollen
> Umfang. Übrigens auch du nicht und auch der Fanboy nicht.

Da ist er wieder der c-hater, und noch mehr C++ Hasser....

Meine Ansage lautet:
Wenn zur Wahl steht C oder C++ zu lernen, dann ist ganz klar C++ zu 
bevorzugen.


Von den Gründen möchte ich hier mal nur 2 aufführen.

- Pointer vs. Referenzen.
Man kann viel mehr Mist mit Pointern bauen, als mit Referenzen.

- Array Index Überschreitungen
Ein Tipp oder logischer Fehler, bei der Indexberechnung in for 
Schleifen, führt ganz fix ins Versagen.
Der RangeBasedForLoop vermeidet dieses.

Diesen Zugewinn in den Wind zu schlagen, nur weil an anderer Stelle 
evtl. eine Überforderung auftreten könnte ist dumm.

Damit ist die Entscheidung des TO dumm, weil ohne Fachkenntnis getroffen 
und die Zustimmung des c-hassers sicherlich aus dem gleichen Grund 
genauso dumm.

Dem TO, kann ich verzeihen da er es nicht besser weiß.
Aber der C-hater, der könnte es wissen, aber er hat wenn er C++ hört, 
sofort so viel Schaum vorm Mund, dass es ihn blind macht.

Arduino Fanboy D. schrieb:
> Diesen Zugewinn in den Wind zu schlagen, nur weil an anderer Stelle
> evtl. eine Überforderung auftreten könnte ist dumm.

Das ist nur dumm, wenn man davon ausgeht, irgendwann mal Fehler zu 
machen. Der c-hater weiß aber, dass er so etwas nicht nötig hat, weil er 
keine Fehler macht. Zumindest scheint er das zu glauben. Wir kennen ja 
seine entsprechenden Vorträge.

Egonwalter M. schrieb:


> Ich kann auch kein C++, verwahre mich aber schärfstens dagegen, dass
> irgendjemand meine Entscheidung als "dumm" bezeichnet.
>
> Noch herrscht das Recht auf freie Entscheidung, und die ist zu
> respektieren.

Aber doch nicht hier! Schreibe hier mal beiläufig, daß Du z.B. mit 
Bascom alle Deine Aufgaben erledigst. Binnen 5 Minuten liegst Du als 
blank genagtes Skelett da.

Der Mensch beginnt hier erst mit der Benutzung von C.

Punkt 1:
Egonwalter M. schrieb:
> Noch herrscht das Recht auf freie Entscheidung, und die ist zu
> respektieren.

Da hast du wahr!
Natürlich darfst du eigene Entscheidungen treffen!
Wie könnte ich dir das verwehren?

Allerdings darf ich auch eine Meinung dazu haben, wie "schlau" diese 
Entscheidung ist.

Und jetzt zu Punkt 2:
Natürlich darfst du dich auch so weit mit deinen Entscheidungen 
identifiziere, so dass eine Kritik an dieser Entscheidung, also eine 
Wertung dieser Entscheidung, dich beleidigt.
Das wäre allerdings schade, wenn du das konsequent so hältst....

Noch mal, ganz klar:
Es liegt nicht in meinem Interesse dich zu beleidigen.
Deine Entscheidung hatte ich eher für falsch, als richtig.

Wie versprochen der ganze Code zur ADC Messung am Attiny 841. Habe die 
Variante drin mit 8 Bit und 10 Bit. Die Anzeige erfolgt durch 3 x LED. 
Beim drehen des Poti werden die LEDs nach einander eingeschaltet. Beim 
zurückdrehen gehen sie wieder aus.

1

#define F_CPU 16000000UL              // Angabe der Frequenz, wichtig für die Zeit

2

#include <util/delay.h>                // Einbindung Datei Pause

3

#include <avr/io.h>                  // Einbindung Datei Ausgänge

4

#include <avr/interrupt.h>

5

6

void init_ADC()

7

  {

8

  ADMUXB &=~((1<<REFS2)|(1<<REFS1)|(1<<REFS0));  // Register ADMUXB

9

  // REF-Auswahl Referenzspannung, auf Vcc(5V)

10

  ADCSRA |=((1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0));  // Register ADCSRA

11

  // ADPS - Teilungsfaktor 16MHz/128=125kHz

12

  ADCSRA |= (1<<ADEN);              // ADC aktivieren

13

  ADCSRA |= (1<<ADSC);              // eine ADC-Wandlung "single conversion"

14

  while (ADCSRA & (1<<ADSC))

15

    {                        // auf Abschluss der Konvertierung warten

16

    }

17

  }

18

19

uint16_t ADC_Read()            // ADC Einzelmessung

20

  {

21

  ADMUXA |=(1<<MUX1);          // Register ADMUXA

22

  // MUX - Auswahl welcher Eingang - 000010 - ADC2

23

  ADCSRA |= (1<<ADSC);              // Register ADCSRA

24

  // ADSC - Start Konvertierung "single conversion"

25

  ADCSRB |=(1<<ADLAR);        // bei 8 Bit links

26

  while (ADCSRA & (1<<ADSC))

27

    {                  // auf Abschluss der Konvertierung warten

28

    }

29

  //return ADCW;            // ADC auslesen und zurückgeben bei 10 Bit ohne Adlar

30

  return ADCH;            // ADC auslesen und mit 8 Bit zurück mit ADLAR=1

31

  }

32

33

int main(void)

34

  {

35

  DDRA=0b00101001;          // Port A auf Ausgang schalten

36

  PORTA=0b00101001;          // Port A auf aus

37

  uint8_t adcval;            // 16 Bit mit ADCW

38

  init_ADC();

39

  while(1)

40

      {

41

    adcval = ADC_Read();

42

    if(adcval>=58)           // bei 8 Bit und 10 Bit

43

      {

44

45

      PORTA &=~(1<<PINA5);    // LED2 ein

46

      }

47

    else

48

      {

49

      PORTA |=(1<<PINA5);      // aus

50

      }

51

    if(adcval>128)           // bei 8 Bit, bei 10 Bit 600

52

      {

53

      PORTA &=~(1<<PINA0);    // LED3 ein

54

      }

55

    else

56

      {

57

      PORTA |=(1<<PINA0);      // aus

58

      }

59

    if(adcval>228)           // bei 8 Bit, bei 10 Bit 950

60

      {

61

      PORTA &=~(1<<PINA3);    // LED4 ein

62

      }

63

    else

64

      {

65

      PORTA |=(1<<PINA3);      // aus

66

      }  

67

    }    // while

68

  }      // main

Die 10 Bit habe ich auskommentieret. Programm läuft ohne Probleme bei 
mir.
Wünsche viel Spass damit. Danke an Alle und entschuldigung für die 
vielen blöden Fragen.
LG Heiner

Ja das stimmt. In dem DB steckt aber noch mehr. Das ist mein erstes 
Programm dazu. Erweiterungen jederzeit möglich. Besonders bei der 
eigentlichen Messung und übertragung. Da werde ich noch einiges machen 
dazu.

Im DB stehen die Register drin und die Anwendung dazu. Fange immer mit 
einem leichten Programm an und nehme dann in dem nächsten Programm 
weitere Sachen dazu. Lieber erst ein kleines und leichtes Programm zum 
laufen bekommen als gleich mit dem schwersten anfangen.

Egonwalter M. schrieb:
> Wenn Du es weißt, warum machst Du es dann nicht (mehrmals den ADC Wert
> einlesen und den ersten verwerfen) in Deinem hier vorgestellten
> Programm?

Das habe ich in einem Versuch bereits drin. Da in dem ersten Programm 
die Auswertung nur durch das ein- und ausschalten von LEDs erfolgt ist 
das noch nicht notwendig.

Heiner schrieb:
> DDRA=0b00101001;          // Port A auf Ausgang schalten
> PORTA=0b00101001;         // Port A auf aus

> uint8_t adcval;           // 16 Bit mit ADCW

> if(adcval>=58)            // bei 8 Bit und 10 Bit

Die Kommentare stiften mehr Verwirrung als zu helfen.

Arbeite nochmal an der Positionierung der Klammern. Ich empfehle, Tabs 
durch 4 Leerzeichen zu ersetzen, das kannst du in deinem Editor bestimmt 
einstellen.

> PORTA &=~(1<<PINA5);    // LED2 ein

Dies würde ich in eine Funktion verschieben, die LED2_ein() heißt. 
Dadurch wird der Code besser lesbar. Und keine Sorge, er wird dadurch 
nicht größer oder langsamer.

Egonwalter M. schrieb:
> Sollte man eine ADC Messung nicht mehrmals nacheinander machen und die
> erste Messung verwerfen

Nur wenn die Quelle zu hochohmig ist und man mehr als 8 Bit nutzen will. 
Das macht man nicht für den ADC, sondern um Zeit für die äußere 
Schaltung zu gewinnen.

Rainer V. schrieb:
> Das ist kein Vorschlag (aus dem Netz...) das steht in den diversen
> Applikationen!

Wo denn?

Hier schonmal nicht:
http://ww1.microchip.com/downloads/en/Appnotes/AN2538-ADC-of-megaAVR-in-SingleEnded-Mode-00002538A.pdf
http://ww1.microchip.com/downloads/en/AppNotes/00002535A.pdf

Hatte es so verstanden:
Da die erste Wandlung nicht korrekt, sollte man sie verwerfen. Bei ( Bit 
streiten sich die Leute. Manche sagen: ist auf jeden Fall besser und die 
letzten Stellen wackeln nicht so stark. Andere sagen: Bei 8 Bit ist es 
nicht unbedingt notwendig.
In diesem Programm ist es relativ egal da das Auslesen mehrfach erfolgt 
und die Anzeige mit LEDs erfolgt. Dabei ist keine grosse Genauigkeit 
gefordert.

Stefan ⛄ F. schrieb:
> Die Kommentare stiften mehr Verwirrung als zu helfen.
>
> Arbeite nochmal an der Positionierung der Klammern. Ich empfehle, Tabs
> durch 4 Leerzeichen zu ersetzen, das kannst du in deinem Editor bestimmt
> einstellen.
>
>> PORTA &=~(1<<PINA5);    // LED2 ein

Danke für den Hinweis. Diese Kommentare sind eigentlich nur für mich, 
das ich nicht vergesse die richtigen Stellen zu ändern.
Verwende auch Funktionen, doch bei diesem Programm geht es erst mal um 
das Verständnis. Werde es aber auf jeden Fall machen.
LG Heiner

Heiner schrieb:
> Da die erste Wandlung nicht korrekt, sollte man sie verwerfen.

Im Datenblatt steht genau drin, wie viele Takte der ADC zur 
Initialisierung benötigt und wann sich das Umschalten des Multiplexers 
auswirkt. Wenn man diese Takte abwartet, dann misst der ADC von Anfang 
an korrekt.

Warten kann man auf unterschiedliche Art - auch indem man den ADC 
Messungen macht und verwirft. Aber das macht man, um Zeit zu schinden, 
nicht um irgend etwas einschwingen zu lassen. Der ADC muss sich nicht 
einschwingen.

Egonwalter M. schrieb:
> Wenn ich weiß, dass es nicht korrekt ist und es trotzdem ignoriere …

Stimmt!
Man kann auch Wartezeiten, ohne Sinn und Verstand, einstreuen und wenn 
das dann kritisiert wird, sauer von dannen ziehen.

Rainer V. schrieb:
> ..und das habe ich mir
> sicher so nicht ausgedacht.
Aber offensichtlich nicht verstanden!
Und darum falsch gemerkt und den Irrtum weiter verbreitet.

Die Umschaltung der Referenz, z.B. von Vcc zu Intern, benötigt Zeit.
Je größer der Kondensator an ARef, desto länger.

Auch ein (zu) hoher ADC Takt, klarer, zu kurze S&H Umladezeit, zu hohe 
Eingangsimpedanz können eine zweite Messung nötig machen.
Aber das ist nicht in Stein gemeißelt und hier sehe ich auch keine 
Anzeichen dafür.

Auch Multiplexerumschaltungen im FreeRunningMode erfordern das Verwerfen 
von Werten.
Aber das ist wieder ein anderes Thema....

Du siehst....
Verallgemeinern gilt nicht.

Arduino Fanboy D. schrieb:

> Die Umschaltung der Referenz, z.B. von Vcc zu Intern, benötigt Zeit.
> Je größer der Kondensator an ARef, desto länger.

Richtig.

> Auch ein (zu) hoher ADC Takt, klarer, zu kurze S&H Umladezeit, zu hohe
> Eingangsimpedanz können eine zweite Messung nötig machen.

Ebenfalls richtig.

> Auch Multiplexerumschaltungen im FreeRunningMode erfordern das Verwerfen
> von Werten.

Das ist falsch. Das ist höchstens dann zutreffend, wenn man das 
Zeitverhalten seines Codes nicht im Griff hat.

Das Umschalten des Multiplexers wirkt sich auf die nächste Messung aus, 
nicht auf die gerade laufende Messung. Das ist des Pudels Kern, so steht 
das auch im Datenblatt.

Für die Art, wie der TO hier den ADC nutzt, ist dieses Detail 
irrelevant.

Stefan ⛄ F. schrieb:

> Das Umschalten des Multiplexers wirkt sich auf die nächste Messung aus,
> nicht auf die gerade laufende Messung. Das ist des Pudels Kern, so steht
> das auch im Datenblatt.

So ist es, aber trotzdem nur die halbe Wahrheit.

Im FreeRunning-Mode gibt es nämlich die Möglichkeit für Quirks, wenn man 
den Multiplexer in der ADC-ISR umschaltet. Da kann es nämlich passieren, 
dass die neue Multiplexer-Konfiguration noch für den gerade laufenden 
(durch FreeRun automatisch gestarteten) ADC-Zyklus wirksam wird, nämlich 
dann, wenn die ISR wenig Overhead hat und auch gerade nicht durch eine 
konkurrierende ISR verzögert wurde.

OK: Bei in C geschriebenen ISRs ist es relativ unwahrscheinlich, dass 
das passiert, aber eben nicht unmöglich. In Asm hingegen ist das ein 
absolut relevantes Thema, welches man natürlich entsprechend 
berücksichtigen muss.

Und übrigens, ohne Quirks: Die Multiplexer-Konfiguration, wird im 
nächsten Zyklus gültig, d.h.: das daraus resultierende Ergebnis ist erst 
das ÜBERNÄCHSTE.