Timer Initialisierung für den avr-gcc komfortabel ermitteln

Schon sehr schön.
Der AVRCalc läuft aber leider nicht mehr in einem aktuellen Linux.

Mit der Problemstellung meine ich aber eine spezifische Lösung für 
verschiedene AVR-Mikrocontroller.
Es geht auch darum einen einfacheren Überblick zu bekommen welche Timer 
mit welchen Möglichkeiten bei einem AVR zur Verfügung stehen.
Hier gibt es ja sehr viele Unterschiede hinsichtlich PWM, CTC, etc.

Konkret meine ich hiermit eine Datenbank aus der die Informationen zu 
einem AVR übersichtlich ermittelt werden können.
Wenn die Informationen in einer relationalen Datenbank abgelegt sind, 
sollte es auch möglich sein die passenden Bits automatisch 
zusammenzusetzen.

Als Basis könnten erst einmal die XML-Dateien aus dem AVR-Studio 
genommen werden.
Z.B. ATmega8A.xml

1

<module caption="" name="TIMER_COUNTER_1">

2

      <register-group caption="" name="TIMER_COUNTER_1">

3

        <register caption="Timer/Counter Interrupt Mask Register" name="TIMSK" offset="0x59" size="1">

4

          <bitfield caption="Timer/Counter1 Input Capture Interrupt Enable" mask="0x20" name="TICIE1"/>

5

          <bitfield caption="Timer/Counter1 Output CompareA Match Interrupt Enable" mask="0x10" name="OCIE1A"/>

6

          <bitfield caption="Timer/Counter1 Output CompareB Match Interrupt Enable" mask="0x08" name="OCIE1B"/>

7

          <bitfield caption="Timer/Counter1 Overflow Interrupt Enable" mask="0x04" name="TOIE1"/>

8

        </register>

9

        <register caption="Timer/Counter Interrupt Flag register" name="TIFR" offset="0x58" size="1" ocd-rw="R">

10

          <bitfield caption="Input Capture Flag 1" mask="0x20" name="ICF1"/>

11

          <bitfield caption="Output Compare Flag 1A" mask="0x10" name="OCF1A"/>

12

          <bitfield caption="Output Compare Flag 1B" mask="0x08" name="OCF1B"/>

13

          <bitfield caption="Timer/Counter1 Overflow Flag" mask="0x04" name="TOV1"/>

14

        </register>

15

        <register caption="Timer/Counter1 Control Register A" name="TCCR1A" offset="0x4F" size="1">

16

          <bitfield caption="Compare Output Mode 1A, bits" mask="0xC0" name="COM1A"/>

17

          <bitfield caption="Compare Output Mode 1B, bits" mask="0x30" name="COM1B"/>

18

          <bitfield caption="Force Output Compare 1A" mask="0x08" name="FOC1A"/>

19

          <bitfield caption="Force Output Compare 1B" mask="0x04" name="FOC1B"/>

20

          <bitfield caption="Waveform Generation Mode" mask="0x03" name="WGM1"/>

21

        </register>

22

        <register caption="Timer/Counter1 Control Register B" name="TCCR1B" offset="0x4E" size="1">

23

          <bitfield caption="Input Capture 1 Noise Canceler" mask="0x80" name="ICNC1"/>

24

          <bitfield caption="Input Capture 1 Edge Select" mask="0x40" name="ICES1"/>

25

          <bitfield caption="Waveform Generation Mode" mask="0x18" name="WGM1" lsb="2"/>

26

          <bitfield caption="Prescaler source of Timer/Counter 1" mask="0x07" name="CS1" values="CLK_SEL_3BIT_EXT"/>

27

        </register>

28

        <register caption="Timer/Counter1  Bytes" name="TCNT1" offset="0x4C" size="2" mask="0xFFFF"/>

29

        <register caption="Timer/Counter1 Output Compare Register  Bytes" name="OCR1A" offset="0x4A" size="2"

30

mask="0xFFFF"/>

31

        <register caption="Timer/Counter1 Output Compare Register  Bytes" name="OCR1B" offset="0x48" size="2"

32

mask="0xFFFF"/>

33

        <register caption="Timer/Counter1 Input Capture Register  Bytes" name="ICR1" offset="0x46" size="2" mask="0xFFFF"/>

Die Informationen sind bzgl. der Timer leider nicht ganz vollständig.
Dafür sind aus den Dateien viele andere Eigenschaften zu einem AVR 
extrahierbar.

hp-freund schrieb:
> Also ein AVRCubeMX ;-)
>
> Wüsste ich jetzt auch keins.

Ich sage Mal so - ohne allgemeines Interesse und Mitarbeit lohnt es sich 
nicht so eine Datenbank aufzubauen.

Daher meine Frage ganz am Anfang ...

Marc T. schrieb:
> Ich schreibe mir die Berechnungen der Timerladewerte immer als Macros in
> das Programm und gut ist.

Timerladewerte?

Sowas hat man vor 10 Jahren beim AT90S1200 gemacht.

Ich denke, dass es Karsten eher um sowas geht wie: „Ich habe einen
ATmega88, einen CPU-Takt von 8 MHz, und möchte den Timer im
PWM-Modus mit mindestens 500 Hz und 16 Bit Auflösung fahren.  Welche
Konfigurationsbits müssen in welchem Register gesetzt werden?“

Der AVRcoder ist wirklich schön gemacht.
Er läuft auch ohne Probleme auf einem Webserver (über IP adressiert).

Aber er ist natürlich nur auf ein paar Controller beschränkt.
Kein Wunder, denn der Autor hat sich hier viel Arbeit gemacht und alle 
Abhängigkeiten in den Code gepackt. Bsp. Timer-Mode:

1

// COMPARE OUTPUT MODE OC1A(PD5)

2

   if ($_SESSION["com1a"]=='2') {$_TCCR1A=$_TCCR1A+64;} //TOGGLE

3

     if ($_SESSION["com1a"]=='3') {$_TCCR1A=$_TCCR1A+128;} //CLEAR

4

     if ($_SESSION["com1a"]=='4') {$_TCCR1A=$_TCCR1A+192;} //SET

5

// COMPARE OUTPUT MODE OC1B(PD4)

6

   if ($_SESSION["com1b"]=='2') {$_TCCR1A=$_TCCR1A+16;} //TOGGLE

7

     if ($_SESSION["com1b"]=='3') {$_TCCR1A=$_TCCR1A+32;} //CLEAR

8

     if ($_SESSION["com1b"]=='4') {$_TCCR1A=$_TCCR1A+48;} //SET

9

// TCCR1B bittien asetus

10

   if ($_SESSION["icnc1"]) {$_TCCR1B=$_TCCR1B+128;} //NOISE CANCELER ON/OFF

11

   if ($_SESSION["ices1"]=='up') {$_TCCR1B=$_TCCR1B+64;} //SET IF POSITIVE/RISING EDGE

12

// CLOCK SELECT BITS [CS12] [CS11] [CS10]

13

           if ($_SESSION["cs1"]=='2') {$_TCCR1B=$_TCCR1B+1;}

14

           if ($_SESSION["cs1"]=='3') {$_TCCR1B=$_TCCR1B+2;}

15

           if ($_SESSION["cs1"]=='4') {$_TCCR1B=$_TCCR1B+3;}

16

           if ($_SESSION["cs1"]=='5') {$_TCCR1B=$_TCCR1B+4;}

17

           if ($_SESSION["cs1"]=='6') {$_TCCR1B=$_TCCR1B+5;}

18

           if ($_SESSION["cs1"]=='7') {$_TCCR1B=$_TCCR1B+6;}

19

           if ($_SESSION["cs1"]=='8') {$_TCCR1B=$_TCCR1B+7;}

Das zusammensetzen der Bits könnte auch generisch erfolgen, indem die 
notwendigen Informationen aus einer Datenbank geholt werden.
Das sieht man gerade hier beim ADC deutlich, weil es eine sehr 
systematische Angelegenheit ist:

1

 $ADCSRA=0;

2

      if($_SESSION["ADEN"]){$ADCSRA=$ADCSRA+128;}    //

3

      if($_SESSION["ADSC"]){$ADCSRA=$ADCSRA+64;}     //

4

      if($_SESSION["adate"]){$ADCSRA=$ADCSRA+32;}      //

5

      if($_SESSION["adif"]){$ADCSRA=$ADCSRA+16;}     //

6

      if($_SESSION["ADIE"]){$ADCSRA=$ADCSRA+8;}      //

7

      if($_SESSION["adps2"]){$ADCSRA=$ADCSRA+4;}       //

8

      if($_SESSION["adps1"]){$ADCSRA=$ADCSRA+2;}      //

9

      if($_SESSION["adps0"]){$ADCSRA=$ADCSRA+1;}      //

10

11

  $ACSR=0;

12

      if($_SESSION["ACD"]){$ACSR=$ACSR+128;}    //

13

      if($_SESSION["ACBG"]){$ACSR=$ACSR+64;}     //

14

      if($_SESSION["ACO"]){$ACSR=$ACSR+32;}      //

15

      if($_SESSION["ACI"]){$ACSR=$ACSR+16;}     //

16

      if($_SESSION["ACIE"]){$ACSR=$ACSR+8;}      //

17

      if($_SESSION["ACIC"]){$ACSR=$ACSR+4;}       //

18

      if($_SESSION["ACIS1"]){$ACSR=$ACSR+2;}      //

19

      if($_SESSION["ACIS0"]){$ACSR=$ACSR+1;}      //

Marc T. schrieb:
> Hallo Leute,
>
> ich wundere mich wirklich, warum man bei so einem einfachen Thema: Timer
> nach einem Konfig.tool fragt.
>
> Ich schreibe mir die Berechnungen der Timerladewerte immer als Macros in
> das Programm und gut ist.

Genau das verstehe ich nicht.
Es ist für Dich und die meisten anderen scheinbar absolut 
selbstverständlich "es zu schreiben und gut ist".
Macht es wirklich Spaß so ein Macro-Hickel-Hackel zu verfassen?
(Mir leider nicht.)

Sind die Header-Dateien für die AVR auch überflüssig?
Oder ist es schön und angenehm das man hier die Register-Zuordnungen 
nicht selber verfassen muss?

Wenn schon einmal jemand Macros für die Timer verfasst hat - warum 
können die dann nicht zur Verfügung gestellt und gesammelt werden, wie 
die Header-Dateien für die Register auch?

Gibt es ein ungeschriebenes Gesetz das hier jeder das Rad selber 
erfinden muss?

Jörg W. schrieb:

> Ich denke, dass es Karsten eher um sowas geht wie: „Ich habe einen
> ATmega88, einen CPU-Takt von 8 MHz, und möchte den Timer im
> PWM-Modus mit mindestens 500 Hz und 16 Bit Auflösung fahren.  Welche
> Konfigurationsbits müssen in welchem Register gesetzt werden?“

Ja - es geht mir um eine komfortable automatische Konfiguration, bei der 
ich einfach nur sage was ich eingestellt haben möchte.
So wie es vor 2 Jahren in dem Macro realisiert wurde:
https://www.mikrocontroller.net/attachment/highlight/201074

Es reicht dann im Hauptprogramm einfach folgende Definition:

1

// Timer ====================================================

2

#define TIMER_1_ON 1

3

// #define TIMER_1_MODESELECT 1

4

#define T1_FREQUENCE 1UL   // 1 Hz

Das schreiben bzw. anpassen eines solchen Macros empfinde ich als sehr 
aufwendig und unkomfortabel.

Darüber hinaus würde eine umfassendere Datenbank auch eine einfache 
Auskunft über die Möglichkeiten eines bestimmten AVR-Mikrocontrollers 
erlauben.
Dies ist natürlich eher ein schönes Beiwerk als notwendig.

In jedem Fall sehe ich hier die "Hauptarbeit" wenn man von einem 
Microcontroller auf einen anderen bei der Programmierung und Benutzung 
schwenkt.

wendelsberg schrieb:
> Dann schreib Dir Deine Standardfälle doch auf einen Zettel an die
> Pinwand (Verzechnis mit sinnvoller Baumstruktur)

Man könnte auch Schiefertafeln nehmen - die halten bekanntlich noch 
länger. ;-)
Im Ernst - warum nicht ein zeitgemässes Werkzeug wie eine Datenbank 
verwenden?

> Karsten M. schrieb:
> Wenn Du einmal tagelang nach "unerklaerlichen" Effekten gesucht hast und
> diese dann in einer solchen Standardfallinitialisierung versteckt
> gefunden hast, dann laesst Du anschliessend die Finger davon.

Es wird ja generell keiner davon abgehalten es anders zu tun.
Selbst ich sehe kein Problem darin in Spezialfällen hier Hand an das 
Bitwerk zu legen.

Aber ehrlich gesagt sehe ich trotzdem keine Notwendigkeit darin die Bits 
für z.B. TCCR1A und TCCR1B manuell rauszusuchen und zusammenzusetzen.
Es reicht doch in dem Datenblatt bei Bedarf die Spezialfälle 
nachzuschlagen.

Wenn es um die Fuse-Bits geht verwende ich eigentlich immer den 
Fusecalc.
Mich würde interessieren ob dieser von Euch auch links liegen gelassen 
wird?

wendelsberg schrieb:
> Von einem AVR auf einen anderen?
> Die drei Zeilen?

3 Zeilen?
Wenn Du z.B. statt einem ATMega32 einen ATMega128 verwendest?

Das Problem geht schon damit los das Du Register für Register 
vergleichen musst ob sich hier etwas geändert hat.
Dann ist interessant was z.B. welcher Timer kann und wofür man ihn 
einsetzen kann.
Mit so etwas kann man viele Stunden verbringen.

Ich fände es deutlich angenehmer wenn man z.B. direkt sehen könnte 
wieviele Timer es gibt und was ein Timer für Modi bereit stellt.

Du findest es angenehmer hier durch das Datenblatt zu ackern?

Karsten M. schrieb:
> Wenn Du z.B. statt einem ATMega32 einen ATMega128 verwendest?

Die stammen ja zumindest noch aus einer Generation, die sind wirklich
ziemlich gleich.  Wesentlicher Unterschied ist, dass bei ATmega16/32
der Timer 2 für Async-Betrieb vorgesehen ist (was ihm neben dem
AS2-Bit noch ein paar zusätzliche Prescaler-Einstellungen bringt),
während es bei ATmega128 Timer 0 ist.

Etwas größer sind die Unterschiede auf die nächste AVR-Generation,
also ATmega1281, ATmega644, ATmega88.  Diese sind in sich dann aber
wieder ähnlich bis gleich.  Schließlich hat man ja auch bei Atmel
die Hardwareblöcke nicht jedesmal neu entworfen.

wendelsberg schrieb:
>> Wenn es um die Fuse-Bits geht verwende ich eigentlich immer den
>> Fusecalc.
>> Mich würde interessieren ob dieser von Euch auch links liegen gelassen
>> wird?
>
> Ich nutze den nicht.

Ich auch nicht.  Bei sowas sensiblem, was man noch dazu nur einmal
pro Projekt machen muss, verlass ich mich lieber drauf, jedes Bit
verstanden zu haben. ;-)

Jörg W. schrieb:
> Die stammen ja zumindest noch aus einer Generation, die sind wirklich
> ziemlich gleich.  Wesentlicher Unterschied ist, ...

Danke für die Erläuterungen.
Es ist allerdings nicht einfach solche Informationen zu finden wenn man 
diese sucht.

Diese Informationen dann faktisch in Code umzusetzen ist noch einmal 
deutlich schwieriger.


Der AVRcoder wurde immerhin schon 944 Mal heruntergeladen und wer weiss 
wie oft Online benutzt.
https://sourceforge.net/projects/avrcoder/files/AVRcoder_1.0.first_public_GNU.tar.gz/stats/timeline?dates=2010-01-20+to+2015-11-26

Das Interesse kann also doch nicht ganz so gering sein ...

wendelsberg schrieb:
> Welches Kriterium entscheidet, ob es ein Spezialfall ist?

Z.B. wenn ich einen Timer nicht nur für einen wiederkehrenden Interrupt 
verwende.

Ich zumindest verwende Timer meistens jedoch entweder als Zeitgeber oder 
zur Erzeugung als PWM.
Das sind für mich Standard-Fälle.

wendelsberg schrieb:
> Ich nutze den nicht.
>
> Angenehmer nicht, aber weniger anfaellig fuer "versteckte" Fehler.

Dann stehst Du einfach mehr auf Handarbeit. :-)


Selbstverständlich muss man sich bei einer anderen Controller-Familie 
schon mit den Details auseinandersetzen.
Deshalb muss ich mich aber dennoch nicht zwingend hinsetzen und die Bits 
für die Register selber zusammenschrauben?

Zur Zeit muss ich es schon!

hp-freund schrieb:
> @ Karsten
>
> bei dir läuft der AVRcoder local?

Ich habe den AVRcoder auf meinem Webserver von einem anderen PC 
aufgerufen.
Es funktioniert aber auch auf dem Server direkt mit localhost.

Vielleicht liegt es daran das ich mit Linux arbeite? :-)

wendelsberg schrieb:
> Karsten M. schrieb:
>> Z.B. wenn ich einen Timer nicht nur für einen wiederkehrenden Interrupt
>> verwende.
>
> Das meinte ich nicht.
> Was genau sind die (maschinell zu verarbeitenden) Abhaengigkeiten?
> Bei der sauberen Formulierung dieser wirst Du Dir schon einen abbrechen.

Ich glaube ich kann Dir nicht ganz folgen.

Wie gesagt finde ich es schon hilfreich z.B. wie beim AVRCoder einfach 
nur auswählen zu können was ich haben möchte.
Da gibt es dann auch z.b. eine Dropbox für den "operating mode" und 
"OC1A".
Daraus werden dann die dazugehörigen Registerwerte ermittelt.

Das nenne ich komfortabel!
Die Auswahllisten (Dropbox) selber zeigen schon was möglich ist.

hp-freund schrieb:
> glaube ich nicht....
>
> .... ich auch :-)

Hmmm - gute Frage.
Dann schaue in meine PHP-Konfiguration.
Vielleicht siehst Du dort etwas?

Evtl. ist das PHP zu "neu".
Da gibt es leider immer mehr Probleme mit älteren Applikationen.

hp-freund schrieb:

> Muss auch die log Files checken.

Ja - aus Sicherheitsgründen werden PHP-Fehler ausgeblendet.
Sie stehen aber im Apache-Log drinn.

wendelsberg schrieb:
> Das ist der Idealzustand, aber die Abhaengigkeiten dahinter muss jemand
> sauber und fehlerfrei erfassen und programmieren. Das macht sich nicht
> von selbst. Und da beisst sich die Katze wieder.

Nein - solche Abhängigkeiten lassen sich noch in einer Datenbank 
abbilden.
Einen Großteil der Abhängigkeiten lassen sich im Vorfeld aus den 
XML-Dateien gewinnen.
So eine Datenbank könnte ich kreieren.

Ich bin jedoch leider kein Web-Programmierer, so daß noch eine 
Oberfläche dazu fehlt.
Der AVR-Coder wäre hier eine gute Grundlage.
Für viele Zwecke würde auch schon ein Perl-Skript reichen, welches die 
notwendigen Informationen extrahiert.
Dieses könnte dann in ein makefile eingebunden werden.

Damit die Arbeit überschaubar bleibt müssen fehlende "Feinheiten" jedoch 
für viele AVR nachgearbeitet werden.
Z.B. fehlen die WGM-Bits in den XML-Dateien.

1

        <register caption="Timer/Counter1 Control Register A" name="TCCR1A" offset="0x4F" size="1">

2

          <bitfield caption="Compare Output Mode 1A, bits" mask="0xC0" name="COM1A"/>

3

          <bitfield caption="Compare Output Mode 1B, bits" mask="0x30" name="COM1B"/>

Man kann diese fehlenden Informationen jedoch daran erkennen das hier 
mehrere Bits in der Bitmaske (mask) gesetzt sind.


Auf jeden Fall müssen auch andere User zuarbeiten, sonst ist es in der 
Tat einfach zu viel Arbeit, die eigentlich von Atmel geleistet werden 
sollte.
Die bekommen dies aber scheinbar nicht vernünftig hin. ;-)

Scheint auch schon geplatzt zu sein. ;-)
Gibt es nur noch im Museum.
http://web.archive.org/web/20150118102335/http://avrtools.no/Main.asp?page=2

So eine graphische Oberfläche halte ich nun wieder definitiv für 
übertrieben.
Mam muss einen Microcontroller auch nicht mit UML programmieren können.

wendelsberg schrieb:
> Und wenn man dann noch solche Sachen (z.B. beim Atmega128):
> _Restrictions in ATmega103 Compatibility Mode_
>
> abbilden will, wird es sehr schnell sehr unuebersichtlich, was fuer mich
> wieder zur Grundhaltung fuehrt.

Meine Antwort:

Wer einen ATMega128 als ATMega102 verwenden will, der soll hierfür eine 
getrennte zusätzliche Konfiguration ATMega128-102 erstellen.

Und Deine Grundhaltung ist der Sache hier nicht förderlich! :-))
Zumindest verfehlt diese das Thema dieses Threads. ;-)
Aber schön wenn Du mitdenkst ...

Ich hab das ganz pragmatisch gelöst, ohne noch viel mehr zusätzlichen 
Firlefanz als unbedingt nötig dranbauen zu müssen.

Wichtig war mir daß ich z.B. die WGM-Bits und andere Bits einfach so dem 
Datenblatt erntnehmen kann wie sie dort aufgelistet sind und 
übersichtlich hinschreiben kann, exakt in der Form und Reihenfolge wie 
sie dort beschrieben sind und das eigentliche Aufteilen und 
Zusammenfummeln der Bits an die entsprechenden Stellen der verschiedenen 
Register vom Preprozessor erledigen lassen kann.

Aber viel mehr als das was ich da unten geschrieben habe wäre 
wahrscheinlich schon wieder Overkill, weiter würde ich also gar nicht 
gehen.

1

/*

2

 * timer.h

3

 *

4

 *  Created on: 18.07.2015

5

 *      Author: bernd

6

 */

7

8

#ifndef TIMER_H_

9

#define TIMER_H_

10

11

#include <avr/io.h>

12

13

14

/**

15

 * Erst mal einigen wir uns auf ein

16

 * paar grundlegende Definitionen

17

 */

18

19

#define COM_DISCONNECTED                    0b00

20

#define COM_TOGGLE_ON_MATCH                 0b01

21

#define COM_CLEAR_ON_MATCH                  0b10

22

#define COM_SET_ON_MATCH                    0b11

23

24

#define WGM_NORMAL_FFFF                     0

25

#define WGM_PWM_PHASE_CORRECT_00FF          1

26

#define WGM_PWM_PHASE_CORRECT_01FF          2

27

#define WGM_PWM_PHASE_CORRECT_03FF          3

28

#define WGM_CTC_OCR1A                       4

29

#define WGM_FAST_PWM_00FF                   5

30

#define WGM_FAST_PWM_01FF                   6

31

#define WGM_FAST_PWM_03FF                   7

32

#define WGM_PWM_PHASE_FREQ_CORRECT_ICR1     8

33

#define WGM_PWM_PHASE_FREQ_CORRECT_OCR1A    9

34

#define WGM_PWM_PHASE_CORRECT_ICR1          10

35

#define WGM_PWM_PHASE_CORRECT_OCR1A         11

36

#define WGM_CTC_ICR1                        12

37

#define WGM_RESERVED                        13

38

#define WGM_FAST_PWM_ICR1                   14

39

#define WGM_FAST_PWM_OCR1A                  15

40

41

#define CS_STOPPED                          0b000

42

#define CS_DIV_1                            0b001

43

#define CS_DIV_8                            0b010

44

#define CS_DIV_64                           0b011

45

#define CS_DIV_256                          0b100

46

#define CS_DIV_1024                         0b101

47

#define CS_EXT_T1_FALLING                   0b110

48

#define CS_EXT_T1_RISING                    0b111

49

50

51

/**

52

 * OK, nachdem das nun gesagt ist 

53

 * kanns jetzt los gehen

54

 */

55

56

#define USE_TIMER1

57

58

#define COM1A_BITS      COM_DISCONNECTED

59

#define OCR1A_VAL       70

60

61

#define COM1B_BITS      COM_DISCONNECTED

62

#define OCR1B_VAL       0

63

64

#define WGM1_BITS       WGM_CTC_OCR1A

65

#define CS1_BITS        CS_DIV_1

66

67

#define ICR1_VAL        0

68

69

#define ICIE1_BIT       0

70

#define OCIE1A_BIT      0

71

#define OCIE1B_BIT      0

72

#define TOIE1_BIT       0

73

74

#define ICNC1_BIT       0

75

#define ICES1_BIT       0

76

77

78

static inline void timer_init() {

79

#ifdef USE_TIMER1

80

    OCR1A = OCR1A_VAL;

81

    OCR1B = OCR1B_VAL;

82

    ICR1 = ICR1_VAL;

83

    TIMSK1 = (ICIE1_BIT << 5) | (OCIE1B_BIT << 2) | (OCIE1A_BIT << 1) | (TOIE1_BIT);

84

    TCCR1A = (COM1A_BITS << 6) | (COM1A_BITS << 4) | (WGM1_BITS & 0b0011);

85

    TCCR1B = (ICNC1_BIT << 7) | (ICES1_BIT << 6) | ((WGM1_BITS & 0b1100) << 1) | (CS1_BITS);

86

#endif

87

}

88

89

#endif /* TIMER_H_ */

Danke für die Anregung!

Bernd K. schrieb:
> Ich hab das ganz pragmatisch gelöst, ohne noch viel mehr zusätzlichen
> Firlefanz als unbedingt nötig dranbauen zu müssen.

Jetzt müssten wir das nur noch für alle Controller haben und dieses 
Thema hätte sich schon im Prinzip erledigt.

Eine Datenbank bzw. visuelle Oberfläche wäre dann schön aber nicht 
notwendig.

> Aber viel mehr als das was ich da unten geschrieben habe wäre
> wahrscheinlich schon wieder Overkill, weiter würde ich also gar nicht
> gehen.

Wahrscheinlich könnte man aus den Informationen in den XML-Files einen 
Teil solcher Dateien automatisch erstellen.
Das wäre immerhin schon einmal ein Plan B.

Karsten M. schrieb:
> Wer einen ATMega128 als ATMega102 verwenden will

Ich würde demjenigen auch gegen Portoerstattung meine beiden seit
Jahren in der Kiste verstaubenden ATmega103 überlassen. ;-)  (Porto
wäre in diesem Falle wohl eine Postkarte.)

Ich habe jetzt erst einmal eine Anfrage an Atmel geschickt.

Es muss zuvor geklärt werden ob die Informationen einem Copyright 
unterliegen und ob die nicht vielleicht sogar schon eine Datenbank haben 
und die netterweise rausrücken.
Zumindest macht es keinen Sinn etwas zu tun wenn die ihren Daumen auf 
den Informationen halten.

Ich habe mir die XML-Dateien Mal etwas genauer angeschaut.
Zumindest innerhalb einer Prozessorfamilie scheint die Struktur soweit 
identisch zu sein. Das sollte dann ganz gut funktionieren.
Die ATXmega haben leider schon wieder einen anderen Aufbau.
Der müsste dann etwas anders angegangen werden.

Ich schaue Mal wie es weitergeht ...

Die Dateien als Ganzes haben ein Copyright, aber es ist OK, wenn du
dir daraus die benötigten Informationen entnimmst.  Hatten wir anno
dunnemals schon geklärt für AVRDUDE und avr-libc.  Also durch ein
XSLT oder was auch immer das rausziehen, was du willst.  Auch
Abspeichern als XML ist dann in Ordnung, nur die 1:1-Weitergabe
unterliegt den Bedingungen des Atmel Studio (die meines Wissens
besagen, dass du den Klumpen nur im Ganze weitergeben darfst).

Ja - das habe ich mir bereits schon gedacht.
Aber nachfragen kann ja nicht schaden.
Vor allem falls die doch noch mit besseren Informationen dienen können, 
was ich nicht glaube.

Ich denke ich werde die Tage Mal mit Perl und XML::Parser ein paar 
Versuche unternehmen.
Das Teil wollte ich schon immer Mal ausprobieren und dies ist ein guter 
Anlass dazu.
Vielleicht funktioniert das ja ganz gut.

Karsten M. schrieb:
> Aber nachfragen kann ja nicht schaden.

Doch: es könnte sein, dass der Frontend-Inder keinen Bock hat, sich
intensiv um eine fundiertere Aussage zu kümmern, da er danach bezahlt
wird, dein Ticket möglichst schnell abzuarbeiten.  Dann versichert er
sich bei seinem Chef, dass es OK ist, dein Ansinnen abzulehnen, dem
wieder ist das völlig schnuppe, und damit hättest du plötzlich eine
neue Aussage auf dem Tisch …

Das könnte natürlich passieren.
Leider kann ich meine Anfrage nicht zurückziehen.

Ich könnte in diesem Fall allerdings immer noch weitere Rückfragen 
starten, die dazu führen das die ganze Sache nach Arbeit riecht. Dann 
ist es wiederum einfacher nach Rückversicherung die Sache doch einfach 
durchzuwinken.

wendelsberg schrieb:
> Naja, das ist eben wie so oft in der SW-Welt.
> Diejenigen, die soetwas schreiben koennten, sehen keine Notwendigkeit.
> Diejenigen die soetwas haben wollen, koennen es nicht schreiben und
> wollen auch niemanden dafuer bezahlen.
>
> Da beisst sich die Katze in den Schwanz.

Die Katze nutzt evtl. nun eines Ihrer vielen Leben und durchbricht den 
Teufelskreis. :-)

Ich habe Jarkko, den Autor von AVRcoder kontaktiert.
Er hatte bereits schon die gleiche Idee und Interesse den AVRcoder zu 
erweitern.
Wir überlegen uns nun gemeinsam eine Lösung - wahrscheinlich mit so 
einer Datenbank und schicken Web-Oberfläche ...

Frohes Neues Jahr!

Es war insgesamt eine ganze Menge Arbeit aber die Datenbank ist nun 
geschaffen und verfügbar. :-)
Jarkko arbeitet bereits an einer Web-Oberfläche.
Für Testzwecke existiert auch schon eine API die Daten im JSON-Format 
zur Verfügung stellt.

Als Ergebnis stelle ich Euch eine Übersicht über alle AVR's in der 
Datenbank in Form einer Libreoffice-Tabelle zur Verfügung.

Die Datenbank beinhaltet alle verwertbaren Informationen aus den 
XML-Dateien von AVR-Studio 7.0 (inklusive aller Fehler).
Dies beinhaltet z.B. die Adressen für die Register und die Fuse-Bits.

Jetzt müssen weitere Überlegungen für die Verwertung der Inhalte 
stattfinden.
Wer hier etwas ernsthaft beisteuern möchte, möge sich bitte bei mir 
melden.

Da das Interesse hier bislang sehr gering war, habe ich eine weitere 
Diskussion bei Arduino gestartet:
http://forum.arduino.cc/index.php?topic=365378