Guten Abend,
ich versuche gerade, den Timer0 des ATmega809 dazu zu bekommen, dass er
einen Interrupt erzeugt, wenn der Wert im CMP0-Register erreicht ist:
/* Set Clock source to 20MHz internal oscillator */
29
CLKCTRL.MCLKCTRLA=CLKCTRL_CLKSEL_OSC20M_gc;
30
/* Disable prescaler */
31
CLKCTRL.MCLKCTRLB&=~(1<<CLKCTRL_PEN_bp);
32
33
/* Enable interrupts globally */
34
sei();
35
36
PORTF.DIR|=(1<<PIN0_bp);
37
}
38
39
intmain(void)
40
{
41
initCPU();
42
initTimer0();
43
while(1)
44
{
45
46
}
47
}
Allerdings passiert beim debuggen gar nichts (d.h. die Interrupt-Routine
wird nicht erreicht). Das CNT-Register erhöht sich aber ständig, d.h.
laufen würde der Timer im Prinzip.
Hat da jemand eine Idee, was noch fehlt?
S. Landolt schrieb:> Wie sieht das Assembler-Listing aus?
Hab ich angehängt
Johann L. schrieb:> Wie sind denn die Einträge in der Vektortabelle? 2 Bytes oder 4 Bytes?
Ich weiß mit der Frage nicht so recht was anzufangen. Hilft die
angehängte Datei .map-Datei?
Hab jetzt mal testweise an .asm Projekt erstellt und deinen Code
reinkopiert:
1
puti: Unknown instruction or macro
2
CPU_CCP: Unknown instruction or macro
3
syntax error, unexpected ";" (Zeile "20 MHz/1:")
Braucht man da vielleicht ein Headerfile?
Edit: Hab mal im Instruction Set Summary nachgeschaut und da steht kein
"PUTI" als Instruktion bzw. Suche über das gesamte Dokumente liefert
keine Ergebnisse. Bist du dir sicher, dass das der Code ist den du bei
dir ausgeführt hast?
Warning offset 0x4000 in .cseg is beyond end of memory at 0x1fff TestASM main.asm 57
3
Error Relative branch out of reach TestASM main.asm 58
4
Warning offset 0x4002 in .cseg is beyond end of memory at 0x1fff TestASM main.asm 60
5
Warning offset 0x4012 in .cseg is beyond end of memory at 0x1fff TestASM main.asm 60
6
Warning end of .cseg at 0x4046 is beyond end of memory at 0x1fff TestASM main.asm 84
7
Error Relative branch out of reach TestASM main.asm 84
S. Landolt schrieb:> fehlt da im 'void initCPU()' nicht die Freigabe per> CPU.CCP?
Das stimmt - vielen Dank! Hab ich nachgetragen, funktioniert aber
trotzdem nicht:
S. Landolt schrieb:> Also gut, einfach mal die beiden "$2000" durch "0" ersetzen und schauen,> was passiert.
Dann kompiliert es zwar aber funktioniert trotzdem nicht (durch den Code
steppen im Debug-Modus funktioniert aber also scheinbar denkt der
Assembler schon mit und mapped den gesamten Code an die passende
Stelle?).
Kann das auch an meiner Schaltung liegen? Aber eigentlich nicht, der Pin
wackelt einwandfrei wenn ich das Togglen in die while-Schleife
verschiebe.
Ansonsten frage ich mich noch ob ich vielleicht irgendwie ausversehen
eine Fuse gesetzt hab die einen Timer deaktiviert?
Oder muss man erst die Peripherie mit dem Clock versorgen so wie bei den
STM32ern? Irgendwas aktivieren?
> Dann kompiliert es zwar aber funktioniert trotzdem nicht.
Auch nach Aus-Ein-Schalten nicht?
> ... Fuse ...
Nicht, dass ich wüsste; bin aber kein Spezialist für die megaAVR®
0-series.
Und da mir sonst nichts mehr einfällt, darf ich mich verabschieden.
Wünsche einen frohen 4. Advent.
Wobei ich mich frage, weshalb in der ATmega-Großfamilie überhaupt noch
Controller mit 8 KiB Flash entwickelt, produziert und gekauft werden -
und der verantwortliche Ingenieur ist ja auch prompt darauf
reingefallen.
Hallo,
naja, Druckfehler in Datenblättern können immer wieder passieren, falls
da überhaupt ein Fehler ist, weil die ja kompatibel zueinander sind und
alle Register in der neuen Serie grundlegend aufgeräumt bzw.
vernünftig(er) strukturiert wurden.
Wegen 8KiB. Meinste nicht das es immer kleine und große µC geben wird?
Habe nochmal in die iomX809.h geschaut, 4809 mit 809 verglichen.
Für beide gilt:
define MAPPED_PROGMEM_START (0x4000)
Würde sagen wollen, dass haut schon alles hin.
Fröhliche Weihnachten und frohes Programmieren ... :-)
Ich bezog mich auf die Vektortabelle des ATmega809, s. Zitat im Link von
Max M.:
"This chip has a silicon bug, incorrect size of interrupt vectors. See
discussion here: https://www.avrfreaks.net/forum/...";
Zugegeben, könnte man vielleicht entfernt auch als "Druckfehler im
Datenblatt" interpretieren, aber ich weiß nicht ...
S. Landolt schrieb:> Ich bezog mich auf die Vektortabelle des ATmega809, s. Zitat im Link von> Max M.:>> "This chip has a silicon bug, incorrect size of interrupt vectors. See> discussion here: https://www.avrfreaks.net/forum/...";>> Zugegeben, könnte man vielleicht entfernt auch als "Druckfehler im> Datenblatt" interpretieren, aber ich weiß nicht ...
avr-gcc behandelt ATmega808/809 wie andere 8KiB-Devices auch, d.h. nimmt
an, dass es kein CALL/JMP gibt. Laut Datenblatt gibt es diese
Instruktionen zwar, aber sie sind 1) Resourcenverschwendung und 2)
bestimmt die avr-libc daraus die Größe der Einträge in .vectors.
Was aber etwas irritiert ist, dass die eingesetzte Toolchain mit 100%
Wahrscheinlichkeit ohne nativen ATmega808/809-Support kommt, und der
Support stattdessen per Device-Packs vom Hersteller erfolgt. Und wenn
der noch nichtmal weiß, wie seine Devices eigenen funktionieren, und
noch nicht 1× ein Programm für diese Devices übersetzt und hat laufen
lassen, dann spricht das nicht wirklich für Qualität.
Und wie sieht's für ATtiny807/806/804? Haben die auch 4-Byte Vektoren?
Hallo,
ist das ein Doppelposting vom TO? Hier und dort im Forum?
Bei genauer Betrachtung wurde das mit dem vermuteten Siliziumbug demnach
widerlegt. Hätte ich mir auch nicht vorstellen können, jedenfalls nicht
im fertig entwickelten Produkt.
Der TO hat den Timer einfach falsch programmiert.
Sein Mainclock hätte so auch nicht funktioniert.
Im Normalmode muss das PER/PERBUF Register als TOP verwendet werden.
Im Frequencymode muss das CMPn/CMPnBUF Register als TOP verwendet
werden.
Dann funktioniert die CMP ISR.
Die Serie ist noch neu, muss man sich sachte vortasten. Der Schreibstil
im Manual ist auch anders was man bis jetzt gewohnt war. :-)
Vielen dank für eure Antworten.
Ich habe mich ursprünglich für den ATmega809 entschieden (bzw. allgemein
für die neue AVR-Reihe), weil ich auf einfacher zu bedienende Hardware
gehofft hatte.
Nachdem ich ursprünglich die IAR Kickstart-Version verwenden wollte
(Code-größenbeschränkt auf 4Kbyte), aber IAR so derbe Bugs in der 7.20.1
drinn hat, dass der Atmel-ICE nicht funktioniert (Bugfixes gibts
natürlich nur für zahlende Kunden), bin ich nun doch auf Atmel Studio
umgeschwenkt.
Hab dann aber einen ganzen Tag gebraucht um einen Timer zum laufen zu
bekommen nur um herauszufinden, dass der Hersteller keinen Peil von
seinen eigenen Produkten hat.
Im Nachhinein kann ich mir aus dem Datenblatt auch nicht wirklich
herleiten, dass ich den Timer im Frequenzmodus laufen lassen muss.
Für dieses sehr simple Programm belegt der avr-gcc nun fast unverschämte
300byte Flash (das Assembler-Programm von Landolt braucht knapp 60byte).
So schnell fass ich keinen AVR / Microchip mehr an, das gibts doch
nicht.
> Der TO hat den Timer einfach falsch programmiert.
Das verstehe ich nicht: für PER gilt doch "Reset: 0xFFFF" laut
Datenblatt, und im vorliegenden Programm ist der Wert von CMP0
unerheblich, er wird auf jeden Fall durchlaufen und damit sollte die LED
blinken.
> Bei genauer Betrachtung wurde das mit dem vermuteten> Siliziumbug demnach widerlegt.
Ich muss zugeben, dass ich nicht alles auf avrfreaks gelesen habe,
aber:
in einem alten ATmega_DPF steht in iom809.h:
#define _VECTOR_SIZE 2 /* Size of individual vector. */
wie es sich für einen 8 KiB-Controller gehören würde, jetzt lese ich
dort:
#define _VECTOR_SIZE 4 /* Size of individual vector. */
Hallo,
@ Landolt:
geht ja auch, wenn man es richtig programmiert. Beim TO gehts ja
mittlerweile auch. Womit ich weniger klar komme ist wenn der TO die
Schuld jetzt auf den Hersteller schiebt. Man muss sich in jeden neuen µC
einarbeiten. Dabei ist jeder 8Bitter noch leicht(er) überschaubar. Die
neue AVR Serie hat neue Timer mit mehr Möglichkeiten und aufgeräumten
Registern. Das man das nicht alles gleich aus dem ff beherrscht ist
klar.
C++ und Assembler kann man nun auch nicht direkt vergleichen.
Das unten reduzierte benötigt bei mir 268Byte Flash und 0 Byte RAM.
1
voidTCA0_init(void)
2
{
3
// TCA0.SINGLE.PERBUF default 0xFFFF ... 2,38Hz
4
TCA0.SINGLE.CNT=0;
5
6
TCA0.SINGLE.CTRLB=TCA_SINGLE_WGMODE_NORMAL_gc;// Normal Mode
@ Johann:
Hab in die Header geschaut.
Bei den ATtinys (804) beginnt der Flash ab 0x4000
und
#define _VECTOR_SIZE 2 /* Size of individual vector. */
#define _VECTORS_SIZE (31 * _VECTOR_SIZE)
bei den ATmegas (4809) beginnt der Flash ab 0x8000
und
#define _VECTOR_SIZE 4 /* Size of individual vector. */
#define _VECTORS_SIZE (40 * _VECTOR_SIZE)
Wenn es beim TO jetzt funktioniert, bedeutet das für mich das alles
andere auch i.O. ist.
... ich muss erstmal Geschenke verpacken ...
> Womit ich weniger klar komme ist wenn der TO die> Schuld jetzt auf den Hersteller schiebt.
Tja, Veit D., da sind wir nun mal unterschiedlicher Meinung. Die
Vektorgröße des ATmega809 passt nicht zu allem Bisherigen - entweder ein
Fehler im Chip oder in der alten iom809.h, so oder so: Schuld von
Microchip/Atmel.
Soll uns beiden aber die Vorfreude auf geruhsame Feier- und Ferientage
in keiner Weise vermiesen!
Veit D. schrieb:> C++ und Assembler kann man nun auch nicht direkt vergleichen.
Ist ja auch C und kein C++. Und ein 6x so großes Binary - da muss
irgendwas schief laufen. Vor allem, da das alles nur Befehle sind, die
Werte in ein Register schreiben.
Veit D. schrieb:> Womit ich weniger klar komme ist wenn der TO die> Schuld jetzt auf den Hersteller schiebt.
Wenn die Lösung ist, dass ich die Definitionsdateien der Controller neu
herunterladen muss (obwohl ich mein Atmel-Studio vor 5 Tagen neu
installiert habe), dann schiebe ich schon die Schuld auf den Hersteller
(wie gesagt, ich hab keine Zeile Code geändert, nur heruntergeladen ->
installiert -> Laptop neu gestartet -> neu kompiliert -> funktioniert).
Bevor ich die neue Definitionsdateien nicht heruntergeladen und
installiert hatte, war das Programm seltsamerweise "nur" 200Byte groß.
S. Landolt schrieb:> Soll uns beiden aber die Vorfreude auf geruhsame Feier- und Ferientage> in keiner Weise vermiesen!
+1
Veit D. schrieb:> @ Johann:> Hab in die Header geschaut.> Bei den ATtinys (804) beginnt der Flash ab 0x4000> und> #define _VECTOR_SIZE 2 /* Size of individual vector. */> #define _VECTORS_SIZE (31 * _VECTOR_SIZE)
Dateien sind geduldig. Was zählt ist, was die Hardware macht. Gibt's
dazu belastbare aussagen?
> bei den ATmegas (4809) beginnt der Flash ab 0x8000> und> #define _VECTOR_SIZE 4 /* Size of individual vector. */
Wie zu erwarten bei > 8KiB Flash.
>Ist ja auch C und kein C++. Und ein 6x so großes Binary - da muss>irgendwas schief laufen. Vor allem, da das alles nur Befehle sind, die>Werte in ein Register schreiben.
Weil der gcc nicht smart genug ist, es bei kurzen snippets mit einem
Assemblerprogrammierer aufzunehmen? Wie soll er auch. Für diese ISR
braucht er Register (hat so eine RISC-Architektur an sich). Nun hat der
gcc dummerweise als Altlast R0+R1 verwendet. Wohl erst später kam der
mul-Befehl, welcher R0+R1 als output hat. Schade, so müssen R0+R1
jedesmal gesichert werden; in der ISR könnte ja ein mul-Befehl
auftauchen. Dummerweise ist R1 zum NULL-Register gemacht worden.
Deswegen das XOR. R2 als tmp und R3 als NULL und R0+R1 einfach nicht
betrachtet, könnte der Interrupt unter avr-gcc schneller laufen. Habe
schon gcc-Programme für den AVR gesehen, wo z.B. R7 überhaupt nicht
verwendet wurde.
Hallo,
@ Max:
Deinen aktuellen Frust kann ich jetzt nachvollziehen. In paar Wochen
siehst du das bestimmt anders. Die IDE etc. ist auch nur Software die
gepflegt werden muss. Fehler wurden korrigiert. Microchip hat seinen Job
gemacht. Ich sehe das eher positiv.
@ Johann:
ich habe keinen ATtiny der neuen Serie zur Verfügung. Ich möchte mich
ganz auf die ATmegas konzentrieren, sonst liegt bei mir zu viel µC Müll
rum. :-)
@ S. Landolt:
> Soll uns beiden aber die Vorfreude auf geruhsame Feier- und Ferientage> in keiner Weise vermiesen!
Volle Zustimmung! +1 :-)
Wir lassen uns von alledem nicht unterkriegen.
neuer PIC Freund schrieb im Beitrag #6082716:
> Für diese ISR braucht er Register (hat so eine RISC-Architektur an> sich). Nun hat der gcc dummerweise als Altlast R0+R1 verwendet.> Wohl erst später kam der mul-Befehl, welcher R0+R1 als output hat.> Schade, so müssen R0+R1 jedesmal gesichert werden;
Das ist bei allen unterstützten GCC-Versionen nicht mehr der Fall. Für
den Code von
Veit D. schrieb:
1
>ISR(TCA0_CMP0_vect)
2
>{
3
>PORTF.OUTTGL=PIN5_bm;
4
>TCA0.SINGLE.INTFLAGS=TCA_SINGLE_CMP0_bm;
5
>}
erzeugen alle aktuellen Versionen, wenn Optimierung aktiviert ist (außer
mit -Og):
1
00000102 <__vector_9>:
2
102: 8f 93 push r24
3
104: 80 e2 ldi r24, 0x20 ; 32
4
106: 80 93 a7 04 sts 0x04A7, r24 ; 0x8004a7
5
10a: 80 e1 ldi r24, 0x10 ; 16
6
10c: 80 93 0b 0a sts 0x0A0B, r24 ; 0x800a0b
7
110: 8f 91 pop r24
8
112: 18 95 reti
Warum der Hardwarehersteller keinen aktuellen Compiler verteilt,
entzieht sich meiner Kenntnis.
Dass der Code so groß ist, liegt jedoch an der Vector-Tabelle des
Startup-Codes: allein die nimmt beim ATmega4809 160 Bytes ein.
Johann L. schrieb:> Warum der Hardwarehersteller keinen aktuellen Compiler verteilt,> entzieht sich meiner Kenntnis.
Ich habe nur eine Vermutung. Wenn sie nur Assembler und C Bsp. in ihre
Manuals drucken, kommen sie mit ihrer 5.4.0 Toolchain noch lange hin.
Wer nur in C++11 programmiert hat damit auch kein Problem. Wer neuer
möchte muss sich leider kümmern. Du kennst ja den Aufwand am Besten der
notwendig ist die Toolchain für aktuellen C++ Compiler auf dem laufenden
zu halten. Das wollen die sich bestimmt sparen, obwohl das genau der
Punkt wäre wo sie dich/euch unterstützen müßten. Ist das bei anderen
Hersteller IDEs besser? Ich weiß nicht wie die zukünftige Pflege der
Microship MPLAP X IDE aussehen wird. Irgendwann wird AS7 bestimmt nicht
mehr supportet. Zwei IDEs pflegen ist derzeit wohl deren Luxus.
Veit D. schrieb:> Irgendwann wird AS7 bestimmt nicht> mehr supportet.
Das hat aber mit der Version des avr-gcc nichts zu tun.
MPLABX benutzt ja (für AVR) denselben Compiler.
Ich denke eher, das sind die Nachwehen des Kulturkampfes nach der
Übernahme.
Wenn man den ganzen Tag herumläuft mit der Message "Now we'll do it the
Microchip way", dann ist Input von außen und Zusammenarbeit mit Externen
das letzte, was man sucht...
PR81268 ist der GCC-Teil des Optimierens von ISR Pro- und Epilogen; die
Änderung beinhaltet auch eine Anpassung der specs-Generierung so dass
obige Spec enthalten ist.
Problem gibt es dann, wenn man einen neuen Compiler mit einem alten,
inkompatiblen Spec-File ohne obige Spec verwendet.
Idealerweiese sind die Specs-Dateien unabhängig von der Compilerversion,
aber die Tools entwickeln sich eben weiter. Und die Specs, die der
Compiler mitbringt, sind so gestaltet, dass sie kompatibel zu älteren
Versionen sind.
> Wenn ich mich recht erinnere, ist das in den device-packs von MicroChip> nicht drin.
Thread beobachten
Seitenaufteilung abschalten