Hallo, vor 2 Jahren habe ich bereits schon einmal diese Frage gestellt und es gab eigentlich keine befriedigende Lösung dazu. Beitrag "Bits im Timer-Register durch Präprozessor / Compiler ausrechnen" Mir ist klar das es jede Menge Szenarien gibt wo man wirklich eine sehr spezielle Kombination verschiedener Funktionen erreichen möchte, und daher eine "manuelle" Konfiguration der Register erforderlich ist. Allerdings gibt es auch sehr viele Standardfälle, wo einfach nur ein sich wiederholender Interrupt erzeugt werden soll. Ich finde es äußerst lästig hier jedes Mal erneut die Spezifikationen zu wälzen und die Bits manuell zusammenzuschrauben. Scheinbar gibt es dafür bis heute keine einfache Lösung wie z.B. für die Fuse-Bits: http://www.engbedded.com/fusecalc/ Ich finde es erstaunlich wieviele Leute scheinbar gerne und endlos in den Datenblättern schmökern. Ist dies wirklich die dauerhafte ultimative Lösung?
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.
Also ein AVRCubeMX ;-) Wüsste ich jetzt auch keins.
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 ...
Ich habe es noch nicht zum laufen bekommen, aber vielleicht ist das ein Ansatz: http://sourceforge.net/projects/avrcoder/
Wenn ich es von seiner Seite aufrufe funktioniert es: http://www.jarkonkotisivu.org/AVRcoder/ nur localhost hat Probleme. Liegt aber bei mir nicht an php denn anderes läuft korrekt.
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.
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?
Karsten M. schrieb: > Allerdings gibt es auch sehr viele Standardfälle, wo einfach nur ein > sich wiederholender Interrupt erzeugt werden soll. > > Ich finde es äußerst lästig hier jedes Mal erneut die Spezifikationen zu > wälzen und die Bits manuell zusammenzuschrauben. Dann schreib Dir Deine Standardfälle doch auf einen Zettel an die Pinwand (Verzechnis mit sinnvoller Baumstruktur) Karsten M. schrieb: > Macht es wirklich Spaß so ein Macro-Hickel-Hackel zu verfassen? > (Mir leider nicht.) 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. wendelsberg
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?
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. Karsten M. schrieb: > In jedem Fall sehe ich hier die "Hauptarbeit" wenn man von einem > Microcontroller auf einen anderen bei der Programmierung und Benutzung > schwenkt. Von einem AVR auf einen anderen? Die drei Zeilen? wendelsberg
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.
Karsten M. schrieb: > Es reicht doch in dem Datenblatt bei Bedarf die Spezialfälle > nachzuschlagen. Welches Kriterium entscheidet, ob es ein Spezialfall ist? Karsten M. 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. Karsten M. schrieb: > Du findest es angenehmer hier durch das Datenblatt zu ackern? Angenehmer nicht, aber weniger anfaellig fuer "versteckte" Fehler. Karsten M. schrieb: > Wenn du z.B. statt einem ATMega32 einen ATMega128 verwendest? Da ist es ja nicht mit der Anpassung der Inits getan. wendelsberg
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!
Karsten M. schrieb: >> Welches Kriterium entscheidet, ob es ein Spezialfall ist? > > 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. Der Aufwand, die paar Bits in dem Falle nachzuschlagen, ist fuer mich wesentlich ueberschaubarer, als diese Abhaengigkeiten fehlerfrei zu beschreiben. wendelsberg
Angehängte Dateien:
Moin, @ Karsten bei dir läuft der AVRcoder local? Ich habe eben wieder eingeschaltet und da sieht es so aus wie im Bild. Muss wohl doch ein Problem bei meinem php oder apache sein.
Angehängte Dateien:
-
Shot260.jpg
89 KB
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? :-)
Karsten M. schrieb: > Vielleicht liegt es daran das ich mit Linux arbeite? :-) glaube ich nicht.... .... ich auch :-)
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.
@ Karsten danke für die phpinfo. Meine Version ist die 5.5.9 Ubuntu. Leider gibt es sehr viele Unterschiede in den Infos. Das muss ich mir heute Abend genauer ansehen. Muss auch die log Files checken. Auf den ersten Blick sieht es so aus als ob ein Steuerzeichen falsch interpretiert wird.
Karsten M. schrieb: >> 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. 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. wendelsberg
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: > muss jemand > sauber und fehlerfrei erfassen und programmieren. Ist leider wahr. Sinnvoll eigentlich nur vom Hersteller machbar.
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. ;-)
Es wurde ja schon einmal versucht die Atmel Welt zu verändern. Ich sage nur: avrtools.no
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.
Karsten M. schrieb: > Einen Großteil der Abhängigkeiten Ja, natuerlich. Aber wie immer in der Softwarewelt: Die ersten 90% der Funktionalitaet machen 10% Arbeit, die restlichen 10% machen 90% der Arbeit aus. Und wenn man dann noch solche Sachen (z.B. beim Atmega128): Restrictions in ATmega103 Compatibility Mode Note that in Atmel® AVR® ATmega103 compatibility mode, only one 16-bit Timer/Counter is available (Timer/Counter1). Also note that in ATmega103 compatibility mode, the Timer/Counter1 has two Compare Registers (Compare A and Compare B) only. abbilden will, wird es sehr schnell sehr unuebersichtlich, was fuer mich wieder zur Grundhaltung > Der Aufwand, die paar Bits in dem Falle nachzuschlagen, ist fuer mich > wesentlich ueberschaubarer, als diese Abhaengigkeiten fehlerfrei zu > beschreiben. fuehrt. wendelsberg
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 ...
Angehängte Dateien:
-
AVR-DB.png
46 KB
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.