Hallo Freunde der Microcontroller, ich bin gerade an einem Projekt in welchem ich einen SAMD21 einsetze. In diesem Projekt benötige ich einen Timerinterrupt der einen Interrupt im Takt von 160KHz auslöst. (Zweck Gepollte Manchesterdecodierung) Alles im Grunde kein Problem mit einem Arduino MoPro und Arduino Umgebung flux ausprobiert..läuft. Dann ein eigenes Board erstellen lassen auf dem der SAM mit dem internen Clock laufen soll. Diesen habe ich dann ohne die Arduino Bibliotheken mit Atmel Studio programmiert. Der Timer läuft auch im Interrupt nur ich erreiche die 160kHz nicht mehr, es gibt eine Schwelle die ich nicht überschreiten kann. (unter dieser Schwellenfrequenz entspricht alles den Erwartungen) Der Prescaler läuft auf 1 und auch der Compare Wert wird ins Compare Register übernommen. Nur wird der Interrupt mit einer niedriegeren Rate aufgerufen als es nach dem Compare Register sein müßte. Stelle ich den Prescaler auf 1/2 so gibt es auch hier eine Schwelle welche ich nicht überschreiten kann obwohl auch hier das Compare Register den richtigen Wert bekommt. Dasselbe mit Prescaler 1/4. Der einzige Unterschied zum MoPro ist ja der interne Takt. Hat irgendjemand eine Idee was das sein kann. Gibt es einen Errata Eintrag den ich nicht gefunden habe?
Gast
#5635328
Wie hoch ist denn nun dein Takt? 8Mhz? Wie hoch war dein Takt? 48Mhz? Welche Taktquelle verwendest du? Ohne Sourcecode ist das jedoch wieder mal Rätselraten. Hast du gar noch den Timer-Interrupt mit übermäßig viel Code vollgepackt? Etwa auch Delays? Ich hol mir die nächste Glaskugel, die hier ist kaputt :-(
Mein Prozessortakt ist 48MHz. Ich habe aber auch Spaßeshalber den Takt mal auf 1MHz runtergesetzt. Das selbe Phänomen. Nur mit eben 1/48 Frequenz. (Taktquelle interne 32kHz) Nein nein, in meinem Interrupt wird im Moment nur ein Port getoggelt. Wie gesagt auf dem MoPro mit Arduino Bibliothek gehts ja. Dieselbe Bibliothek habe ich auch schon ohne den ganzen Arduino Plunder in meinen Source Code eingebaut. Funzt auch nur eben bis zu dieser Grenze. Source Code habe ich hier auf dem Rechner nicht, den kann ich erst morgen einstellen. Ich hatte eben die Hoffung, dass jemand so etwas ähnliches schon hatte. Eventuell muss man etwas Besonderes bei dem internen Takt beachten? Kann es eventuell sein dass der Interruptcontroller, zu langsam läuft und so die auflaufenden Interrupt ab einer gewissen Frequenz nicht mehr mitbekommt?
Trotzdem könnte die Taktquelle die Ursache sein. Ohne Code kann man nur raten... Schau mal in Datenblatt -> Clock
Danke für die Antwort. Du weißt gar nicht wie oft ich den Abschnitt Clock und Timer im Datenblatt schon gelesen habe. Ich stell Morgen mal ein wie ich den internen Takt und die Timer konfiguriert habe. Irgendwo wird wahrscheinlich der Fehler liegen. Nur im Moment habe ich keine Idee mehr.
Hi Horst, Du hast uns relativ wenig Informationen zur Verfügung gestellt.... Über welche Frequenz kommst Du nicht rüber ? Wie stellst Du das fest ? Gehst Du mit dem Compare Wert runter und irgendwann erhöht sich die Frequenz der Interrupt nicht mehr ? Was sind die Werte, die Du einstellst ? Benutzt Du ASF ? Oder programmierst Du bare metal ? Oder stimmt nur Dein berechneter Compare-Wert nicht ? Wie hoch ist der denn ? Auf die Schnelle 3 Ideen: 1) Der Prozessor braucht zu viel Zeit in den ganzen Interrupts. Das wäre der Fall, wenn Du den Compare-Wert immer weiter erniedrigst, und die Frequenz bleibt "stehen". 2) Dein Clock-Distribution-System ist nicht i.O. z.B. der Timer läuft mit 48MHz aber Deine Main Clock mit 1MHz(was typischerweise zu dem Fehler unter 1 führt, weil angenommen wird, die Main Clock ist auch auf 48MHz) 3) Falls Dein Compare-Wert nur nicht passt: Der D21 hat keine 48MHz. Häufig werden die 48MHz über die internen 32kHz erzeugt. Der hat aber einen relativ großen Fehler. Die Clock läuft dann mit 47MHz oder auch 49MHz. Die 48MHz dann für den UART benutzen führt zu schicken Baudsratenfehlern… Für den UART dann besser die 8MHz Clock nehmen. Gruß N2
Kai P. schrieb: > Über welche Frequenz kommst Du nicht rüber ? Wie stellst Du das fest ? > Gehst Du mit dem Compare Wert runter und irgendwann erhöht sich die > Frequenz der Interrupt nicht mehr ? Was sind die Werte, die Du > einstellst ? Der Compare Wert stimmt bis zu einer bestimmten Frequenz dann erhöht sich die Frequenz nicht mehr obwohl der Compare Wert weiter erniedrigt wird. Ich stelle dies fest indem ich einen Port toggle und mir das Ergebnis auf einem Oska anschaue. > Benutzt Du ASF ? Oder programmierst Du bare metal ? Nein ich programiere an der Basis > Oder stimmt nur Dein berechneter Compare-Wert nicht ? Wie hoch ist der > denn ? Der berchnete Wert stimmt, wie gesagt bei höheren Frequenzen passt er. Mehr Details später.
Ich stelle mal den Source Code ein. Dies ist Code aus Beispielen von Microchip entsprechend geändert auf internen Oszi32k. Hier Clock Init:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | |
178 | |
179 | |
180 | |
181 | |
182 | |
183 | |
184 | |
185 | |
186 | |
187 | |
188 | |
189 | |
190 | |
191 | |
192 | |
193 | |
194 | |
195 | |
196 | |
197 | |
198 | |
199 | |
200 | |
201 | |
202 | |
203 | |
204 | |
205 | |
Hier Timer Init:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
Die Initialisierung vom Clock ist extrem kompliziert und schlecht im Datenblatt beschrieben. ICh habe in den Kommentaren für den Compare Wert die resultierenden Frequenzen angegeben. Das ist irgendwie nicht linear.
!! Ich habe nun die Fehler in der CLK Initialisierung gefunden!!! Hatte doch einiges vermurkst beim Umschreiben des Microchip Beispielcode auf internen Clock. Jetzt scheint es zu funktionieren. Allerdings ist mir aufgefallen dass der interne Clock absolut ja ziemlich daneben liegt. Wenn ich das vom Timer hochrechne läuft der jetzt mit 56MHz. Kann das sein? Auf jeden Fall Danke, die Antworten haben mich auf den richtigen Pfad gebracht.
Hi, Datenblatt 36.11.5: Wenn Du den ULP nutzt, kann das theoretisch vom Internen kommen: 38011*1500 ~ 57MHz Aber: Du nutzt das Ding sicher bei Raumtemperatur und 3V3, dann dürfen es maximal knapp 52MHz sein. Der normale Interne ist ein bissle besser. Da ich mich mit PLL nicht so gut auskenne, kann ich über den zusätzlichen Fehler, der über eine PLL reinkommt, leider nix sagen. Vom Prinzip her würde ich eine Erhöhung des Jitters erwarten aber keine weitere Frequenzverschiebung (da die Teiler ja ganzzahlig fest vorgegeben sind). Daher würde ich bei 56MHz versuchen, herauszufinden, woran das liegt. Gibt Dir den internen 32kHz Clock mal auf einem GPIO aus und messe erst mal diese Frequenz. Wenn die nach Spec ist, nochmal schauen, ob die Teiler der PLL alle wirklich richtig sind. Auch mal überlegen, ob der Messaufbau das Messgerät die Messmethode hinreichend genau sind. Kann der SAM schon "misshandelt" worden sein (ESD) ? Sich die Theorie einer PLL anschauen, ob dort noch Fehler entstehen können. Dann an Microchip wenden :-) Gruß N2
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.