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
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 ...
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:
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:
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
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.
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.
@ 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
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">
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. ;-)
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.
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