...oder in anderen Worten "Was könnte ich übersehen haben " (in den Migration Notes) Moin erstmal, Ich hätte da eine sehr allgemeine Migrations- und Kompilerfrage, die ich am konkreten Bsp. des ADCs hinterfragen möchte (Glaskugel an ;) Ich bin von einem Atmega16 hergekommen und wollte noch einige "komplexe" Selbsttests mit auf den Chip schreiben. Dafür reichte der Speicher nicht aus. Ergo bin ich zum zum Atmega644P gewechselt. (Gab ja auch noch JTag gratis) Nun kompiliere ich bereits seit 2 Jahren für den Kunden immer 2 Versionen. 1x die Full und 1x etwas abgespeckt die kompacktere (ohne Selbtest), die noch auf den Atmega16 passt. Die Hauptfunktion der Platine ist eine (sehr langsame) Temperatursteuerung. Zwischen ADC und Sensor liegt nur ein 1%iger RC-Filter und es wird über 16 Werte der Mittelwert gebildet. (Da der Sensor nicht ganz linear ist, aber nur an 2 punkten exakt sein muss, wird eine Korrekturlinie vom Kunden "eingepegelt"; Abweichung an A und B) Meine Defaults für A und B lauten 0,4(bei 50 soll) und 1,2(bei 90 soll) Grad. Diese Defaults liegen im EEPROM. Nun hat der Kunde das Phänomen (ich kann ihm leider beim Flashen nicht immer auf die Finger schauen), dass er den B Wert beim Atmega644 bis auf 3,4 schrauben muss, damit es passt. Nach meinem Wissen kann der ADC des Nachfolgers (gleiches Board) doch nicht so viel vom Vorgänger abweichen, oder doch? Ich hatte schon die Vermutung, dass der Kunde die *.eep Datei von den beiden Versionen (Code identisch hex vielleicht nicht) durcheinander würfelt. Aber dann sollten ja an allen anderen Variablen aus dem EEPROM auch nur Mumpits raus kommen? In meiner IDE setze ich lediglich die FLAGs zum setzten des JTAGs für die beiden Kompilate. Habt ihr hier noch einen Rat? Oder mal ganz blöd gefragt, sollte die elf (hex+eep) des einen (sofern nicht zu groß) auch auf dem anderen laufen? Ich dachte ich fahre sicherer mit diesen 2 Kompilaten.
Ich frage mich: -wie bekommst du mit einem einfachen Temperaturregler 16k knackevoll? -falls tatsächlich voll: warum nicht auf den Mega32 wechseln? Der ist bis auf die Speichergrössen identisch zum Mega16.
D a v i d K. schrieb: > Ich bin von einem Atmega16 hergekommen und wollte noch einige "komplexe" > Selbsttests mit auf den Chip schreiben. Dafür reichte der Speicher nicht > aus. Was sind denn das für Monster-Selbsttests? D a v i d K. schrieb: > Meine Defaults für A und B lauten 0,4(bei 50 soll) und 1,2(bei 90 soll) > Grad. Da keiner die unbekannte Rechnung mit A und B kennt, kann man dazu nichts sagen. Der ADC-Code ist ja auch unbekannt. Die ADC-Funktionen wurden vom ATmega16 zum ATmega164 etwas erweitert. Preislich sollten die neueren Typen sogar günstiger sein.
D a v i d K. schrieb: > dass er den B Wert beim Atmega644 bis auf 3,4 schrauben muss, damit es > passt. Und den "A Wert" fast auf 1? > Nach meinem Wissen kann der ADC des Nachfolgers (gleiches Board) doch > nicht so viel vom Vorgänger abweichen, oder doch? Man müsste möglicherweise mal mit 'm Messgerät messen... > sollte die elf (hex+eep) des einen (sofern > nicht zu groß) auch auf dem anderen laufen? Nein, warum? Da sind ja einige Register ganz woanders und heißen auch anders und haben andere Funktionen. Das Dokument "AVR505: Migration between ATmega16/32 and ATmega164P/324P/644P" aka "Microchip doc8001.pdf" hast du dir schon mal angeschaut?
:
Bearbeitet durch Moderator
D a v i d K. schrieb: > sollte die elf (hex+eep) des einen (sofern nicht zu groß) auch auf dem > anderen laufen? Nein. D a v i d K. schrieb: > Nach meinem Wissen kann der ADC des Nachfolgers (gleiches Board) doch > nicht so viel vom Vorgänger abweichen Na ja, der ATmega16 hat eine 2.54V Referenz, der ATmega644 eine 1.1V Referenz. Aber kein Mensch weiss bei deiner oberflächlichen Beschreibung, ob du die überhaupt benutzt
D a v i d K. schrieb: > Nach meinem Wissen kann der ADC des Nachfolgers (gleiches Board) doch > nicht so viel vom Vorgänger abweichen, oder doch? Welche Referenz verwendest du für den ADC und von welchen ADC Messwerten (im Bereich 0-1023) reden wir? Deine Werte 0,4 und 1,2 und 3,4 sind offenbar das Ergebnis einer Umrechnung. Je nach Formel könnte schon eine minimale Abweichung der Referenzspannung zu diesen Unterschieden führen. D a v i d K. schrieb: > Oder mal ganz blöd gefragt, sollte die elf (hex+eep) des einen (sofern > nicht zu groß) auch auf dem anderen laufen? Wahrscheinlich nicht. Die Befehlssätze und Register sind nicht ganz identisch.
Ich baue selbst viele Temperaturregler fuer allerlei Anwendungen. Der Code selbst war nie gross. Man kann den Speicher mit allerlei Filefanz fuellen. Ich verwendete standardmaessig den Mega32, seit 10 Jahren den Mega644, weil ich oft 2 Schnittstellen brauche. Ich verwende allerdings immer einen externen ADC, den AD7799, und die Berechnungen laufen in Longint. Damit kann ich NTC, Dioden, PT1000 oder NTC messen. Auf keinen Fall float verwenden, das bringt nichts.
Warum testest du deine Kompilate nicht mal bei dir im Labor? Das ist ja nun kein Hexenwerk.
D a v i d K. schrieb: > Ich bin von einem Atmega16 hergekommen und wollte noch einige "komplexe" > Selbsttests mit auf den Chip schreiben. Dafür reichte der Speicher nicht > aus. > Ergo bin ich zum zum Atmega644P gewechselt. Das ist nicht wirklich "ergo". Dazwischen gäbe es nämlich noch den Mega32, der gegenüber dem Mega644P den relativen Vorteil hat, dass er wirklich in jeder Hinsicht vollständig kompatibel zum Mega16 ist, nur halt doppelt soviel Flash hat. > (Gab ja auch noch JTag > gratis) JTAG haben die allesamt. Also: völlig unwichtig bezüglich deines Themas. > Die Hauptfunktion der Platine ist eine (sehr langsame) > Temperatursteuerung. > Zwischen ADC und Sensor liegt nur ein 1%iger RC-Filter und es wird über > 16 Werte der Mittelwert gebildet. (Da der Sensor nicht ganz linear ist, > aber nur an 2 punkten exakt sein muss, wird eine Korrekturlinie vom > Kunden "eingepegelt"; Abweichung an A und B) Also, das hört sich für mich generell erstmal nicht so an, als ob man dafür einen Mega16, Mega32 oder gar Mega644P brauchen würde... Sehr wahrscheinlich hast du hier ein delikates Detail vergessen zu erwähnen. Z.B. die Pinzahl, die für ein "GUI" nötig ist... > Nun hat der Kunde das Phänomen (ich kann ihm leider beim Flashen nicht > immer auf die Finger schauen), dass er den B Wert beim Atmega644 bis auf > 3,4 schrauben muss, damit es passt. > > Nach meinem Wissen kann der ADC des Nachfolgers (gleiches Board) doch > nicht so viel vom Vorgänger abweichen, oder doch? Keine Ahnung. Man kann in jede MCU mit jeder beliebigen Peripherie beliebigen Stuss einprogrammieren. Das zumindest ist völlig sicher.
MaWin schrieb: > D a v i d K. schrieb: >> sollte die elf (hex+eep) des einen (sofern nicht zu groß) auch auf dem >> anderen laufen? > > Nein. > > D a v i d K. schrieb: >> Nach meinem Wissen kann der ADC des Nachfolgers (gleiches Board) doch >> nicht so viel vom Vorgänger abweichen > > Na ja, der ATmega16 hat eine 2.54V Referenz, der ATmega644 eine 1.1V > Referenz. Ich verwende eine externe: https://www.reichelt.de/spannungsreferenz-fest-2-5-v-so-8-lm-385-d2-5-p39827.html Aber der Hinweis ist gut, denn vielleicht hab ich im Code nicht das richtige Register gesetzt, so dass doch die intere (bei beiden) verwendet wird. Sollte ja schnell rauszufinden, sein. Nachgesehen: ADMUX wird von mir nie mit den Bits für REFS0 und REFS0 beschrieben. Somit sollten diese defaultmäßig beide gelöscht sein und laut Tabelle die externe Referenz nutzen. Täusche ich mich da? (Ansonsten schreibe ich nur "5" und "7" für die beiden Channels rein, die ich verwende.
:
Bearbeitet durch User
JTAG ist bei den AVR oft unbrauchbar, da auf anderen benoetigten Pins liegend. Man sollte nicht Kunden irgendwelche files laden lassen und dann noch dafuer zustaendig sein wollen...
Pandur S. schrieb: > JTAG ist bei den AVR oft unbrauchbar, da auf anderen benoetigten Pins > liegend. Du bist ein Vollpfosten. Du hast es geschafft, das mit einem einzigen Satz vollkommen klar zu machen. Herzlichen Glückwunsch zu dieser Leistung.
Bitte 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.