Hallo zusammen! Ich bin gerade dabei den ADC und DAC eines XMega128A3 zum laufen zu bringen. Bisher klappt das auch schon ganz gut. Damit die Werte noch ein bisschen genauer werden, wollte ich zunächst den ADC kalibrieren. Dazu sollen laut Datenblatt im Controller Kalibrationswerte abgespeichert sein. Diese habe ich mit folgendem Code aus dem Internet ausgelesen und in das entsprechende Register geschrieben. void ADCA_Cal(void) { ADCA.CALL = LeseKalibrationsbyte(offsetof(NVM_PROD_SIGNATURES_t, ADCACAL0)); ADCA.CALH = LeseKalibrationsbyte(offsetof(NVM_PROD_SIGNATURES_t, ADCACAL1)); } int LeseKalibrationsbyte(int Index) { int result; NVM_CMD = NVM_CMD_READ_CALIB_ROW_gc; result = pgm_read_byte(Index); NVM_CMD = NVM_CMD_NO_OPERATION_gc; return(result); } Allerdings ändern sich dadurch die Werte des ADC nicht. Deshalb habe ich die Werte, die in CALL und CALH geschrieben werden, auf das angeschlossene LCD ausgegeben und beide waren 0. Kann das sein? Mir scheint das recht unwahrscheinlich oder habe ich irgendwas falsch gemacht? Vielen Danke! Fabian
Diese Woche sollte mein PDI-fähiger AVRISP MKII-Clone ankommen. Dann kann ich auf meinen ATxmega128A3U hoffentlich mal ordentlich zugreifen und dem was reinprügeln. Bin leider ziemlich ausgelastet, sodass sich das aber auch noch hinziehen kann.
Hallo Fabi, so funktioniert es bei mir(AVR-Studio 6.2)! #define ADCACAL0_offset 0x20 // zum Auslesen ADC Offset aus Flash #define ADCACAL1_offset 0x21 // dsgl // calibration_byte aus Flash ADCA.CALL=read_calibration_byte(PROD_SIGNATURES_START+ADCACAL0_offset); ADCA.CALH=read_calibration_byte(PROD_SIGNATURES_START+ADCACAL1_offset); uint8_t read_calibration_byte( uint8_t index ) { uint8_t result; /* Load the NVM Command register to read the calibration row. */ NVM_CMD = NVM_CMD_READ_CALIB_ROW_gc; result = pgm_read_byte(index); /* Clean up NVM Command register. */ NVM_CMD = NVM_CMD_NO_OPERATION_gc; return( result ); } Ergebnis: 0x44, 0x04 Gruß G.G
Cool, da ist schon eine hilfreiche Antwort. Habe jetzt zwei Stunden herumgefrickelt (anstatt OS X VMs mit Windows XP & Tools, Netbook mit Win7, ...) - der AVR ISP MKII-Clone will nicht.
1 | avrdude.exe: stk500v2_recv_mk2: error in USB receive |
2 | avrdude.exe: stk500v2_getsync(): timeout communicating with programmer |
3 | avrdude.exe: stk500v2_command(): failed miserably to execute command 0x11 |
4 | avrdude.exe: stk500v2_disable(): failed to leave programming mode |
5 | |
6 | avrdude.exe done. Thank you. |
Irgendwann entnervt aufgegeben und gegoogelt: Jo, hat einer in avrdude vergeigt. Aktualisiertes CrossPack-AVR gibt es nicht, mit der Brechstange über Brew avrdude 6.1 gezogen - selber Fehler. Für heute gebe ich auf.
Meine Demo fuer AVR Stick (Browserprogrammierbar - http://matrixstorm.com/avr/avrstick/#bideavr) funktioniert auch (Quellcode haengt an):
1 | XXXXXXXX@thinkrat ~ $ cd /media/1234-5678/ |
2 | XXXXXXXX@thinkrat /media/1234-5678 $ hexdump -C PRODSIGN.BIN |
3 | 00000000 0c 40 7c 09 40 5f ff 01 31 48 32 32 36 37 ff ff .@|.@_..1H2267..| |
4 | 00000010 0e ff 06 00 03 00 ff ff ff ff 7e f8 22 40 ff ff ..........~."@..| |
5 | 00000020 44 04 00 ff 44 04 00 ff ff ff ff ff ff ff ec 09 D...D...........| |
6 | 00000030 ff ff 0d 1a ff ff ff ff 67 67 67 ff ff ff ff |........ggg....| |
Minicom /dev/ttyACM0 gibt nach druecken einer Taste aus:
1 | alte Werte |
2 | ADCA.CALL=0x00 |
3 | ADCA.CALH=0x00 |
4 | |
5 | neue Werte |
6 | ADCA.CALL=0x44 |
7 | ADCA.CALH=0x04 |
matrixstorm schrieb: > Meine Demo fuer AVR Stick funktioniert auch (Quellcode haengt an) Offenbar gibt es aber ein Problem (oder Absicht?) mit dem MIME Type der Datei. Aus diesem Grund habe ich die HTML auch bei mir hochgeladen, damit Sie bequem aus dem Browser heraus benutzt werden kann: http://matrixstorm.com/tmp/example_mikrocontroller_337355_3709558.html Den "puren" C-Code hanege ich zudem an. (Dieser benoetigt aber externe Libs) MfG
Fabi schrieb: > Dazu sollen laut Datenblatt im Controller Kalibrationswerte > abgespeichert sein. Das behauptet Atmel seit Anbeginn der XMegas. Und schreibt doch seit Jahren die gleichen ziemlich sinnfreien Werte rein. Je nach Mondphase 0x0000, 0x0444, 0x0c0c, 0x00ff, oder war das 0xff00?. Egal, was hilft ist eine externe Kalibrierung unter Verzicht auf den Blödsinn aus der Signature Row.
Vielen Dank euch allen! @ Gerhard Gehlert: ich werde mir deinen Code mal etwas genauer anschauen. Vielleicht klappt es ja dann. Leider hat mein Laptop den Geist aufgegeben und das Programmieren muss deswegen pausieren. Aber der Beitrag von Mark 99 würde mein Problem ja unabhängig vom Code erklären: Mark 99 schrieb: > Fabi schrieb: > Dazu sollen laut Datenblatt im Controller Kalibrationswerte > abgespeichert sein. > > Das behauptet Atmel seit Anbeginn der XMegas. Und schreibt doch seit > Jahren die gleichen ziemlich sinnfreien Werte rein. Je nach Mondphase > 0x0000, 0x0444, 0x0c0c, 0x00ff, oder war das 0xff00?. Egal, was hilft > ist eine externe Kalibrierung unter Verzicht auf den Blödsinn aus der > Signature Row. Ich werde es mal versuchen, wenn ich an einen PC mit AVR Studio rankomme (ich verwende das 6.1) und melde dann meine Ergebnisse! Nochmals vielen Dank! Gruß Fabian
Fabi schrieb: > Je nach Mondphase >> 0x0000, 0x0444, 0x0c0c, 0x00ff, oder war das 0xff00?. Danke, und ich dachte schon ich hätte einen Programmfehler beim Auslesen, weil ich für beide ADCs nur 0x00FF erhalte.
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.