Bei der Entwicklung der in
diesem Artikel beschriebenen Hardware des REDD-Komplexes wurden verschiedene Implementierungsoptionen berücksichtigt. PSoC wurde in Betracht gezogen, da es dafür eine fertige, relativ standardisierte, wenn auch de facto Version des USB-I2C-Adapters gibt. Leider war es aus den im
Artikel über DMA beschriebenen Gründen nicht möglich, etwas Schwieriges für diesen bestimmten Komplex auf der PSoC zu tun, und einfach ist wirtschaftlich nicht machbar. Es stellte sich als billiger heraus, Chips von FTDI zu nehmen. Während Experimente mit PSOC durchgeführt wurden, wurden interessante Details enthüllt, deren Veröffentlichung sinnvoll ist.
Kernerfahrung
Lassen Sie uns ein einfaches Projekt machen. Lassen Sie uns das Timing seiner Blöcke wie folgt konfigurieren:
Die PLL hat die niedrigstmögliche Frequenz ausgewählt (die Entwicklungsumgebung gibt nicht weniger). Der Bus wird von ihm getaktet. Dies geschieht absichtlich. Die Ergebnisse der Arbeit werden vom Oszilloskop gesteuert, und in den Kommentaren zu
diesem Artikel habe ich gezeigt, dass es besser ist, sich nicht der Obergrenze des Durchlassbereichs zu nähern, insbesondere wenn das Oszilloskop chinesisch ist: Die Fronten sind so überladen, dass bei den Messungen Fehler auftreten können. Es ist also besser, eine niedrigere Frequenz zu wählen. Das Minimum ist 24 MHz, und wir nehmen es.
Das Entwurfsschema ist trivial. Zwei Quellen von Taktimpulsen, die mit den Beinen des Chips verbunden sind.
Das Dokument AN60631 besagt, dass das System die Frequenzen von Clock_1- und Clock_2-Quellen von der Basis aus durch die Teiler leitet:
In unserem Projekt senden wir immer ein Signal mit einer Frequenz von 24 MHz an den Pin_1-Zweig und versuchen, ein Signal mit einer niedrigeren Frequenz an Pin_2 zu senden. Zunächst läuft alles vorhersehbar. Bei der gewünschten Frequenz von 23 bis 18 MHz erhalten wir eine erreichbare Frequenz von 24.
Durch Reduzieren der gewünschten Frequenz auf 17 MHz erhalten wir eine erreichbare 12. Alles ist logisch. Der Teiler ist nicht PLL. Die Divisionskonstante muss eine ganze Zahl sein. Ich habe nur dafür gesorgt, dass es keine Überraschungen gibt.
Stellen Sie die gewünschte Frequenz auf 12 MHz ein. Wir stellen ein Projekt zusammen (zum Schreiben ist kein Code erforderlich) und sehen uns das Ergebnis an.
Der gelbe Strahl ist die Grundfrequenz, der blaue ist geteilt. Wieder kein Haken. Was ist der Zweck des Artikels? Wir kommen gerade zum interessantesten. Was ist der nächste Teilungsfaktor? Die drei. Die nächste erreichbare Frequenz ist 24/3 = 8 MHz. Wir ändern die Projekteinstellungen, "blinken", schauen ...
Bitte lieben und bevorzugen Sie, auf einem blauen Strahl ist ein Taktsignal mit einem anderen Arbeitszyklus als 50% sichtbar. Erwartet ein einfacher Programmierer, dass eine Taktquelle ihm dies gibt? Kaum. Aber er hat es ausgestellt.
Division durch 4 ist vorhersehbar schön. Wir überprüfen die Division durch 5 (die gewünschte Frequenz beträgt 4,8 MHz):
Der Trend ist klar. Die PWM spielt eindeutig die Rolle eines Teilers. Je höher das ungerade Teilungsverhältnis ist, desto näher liegt der Arbeitszyklus an 50%, aber im Allgemeinen gibt es immer noch einige Diskrepanzen zwischen der positiven und der negativen Halbperiode. Wenn die Schaltung nur durch positive Fronten getaktet wird, ist dies nicht beängstigend. Wenn der Entwickler jedoch eine eigene Komponente erstellt, in der sowohl positive als auch negative Flanken des Taktsignals verwendet werden, sind Nuancen möglich, und manchmal gibt es schwebende Fehler.
Im Allgemeinen wird dieser Fall in TRM in Abbildung 14-12 mehr oder weniger beschrieben, sodass wiederum niemand etwas verbirgt:
Aber irgendetwas sagt mir, dass nur wenige Menschen dieses Muster studieren werden, bevor sie das entsprechende Bild auf dem Oszilloskop erfassen. Und er wird sie erst nach langen Versuchen erwischen, herauszufinden, warum das System abstürzt. Daher halte ich es für notwendig, vor dieser Funktion der Clock-Komponente von PSoC zu warnen.
Zusätzliche PSoC-Taktinformationen
Die Temperaturabhängigkeit der Frequenz des internen Generators
Es stellte sich irgendwie sehr kurz heraus. Lassen Sie uns ein weiteres Problem im Zusammenhang mit der Taktrate untersuchen. Es war einmal ein Projekt auf AtMega8. Um die Kosten des Systems zu senken, wurde die Uhr einem internen Generator entnommen. Das Projekt wurde am Stand getestet, aber danach stellte sich heraus, dass das Board erst dann funktioniert, wenn es in die Zielumgebung gelangt, nachdem es eingeschaltet wurde. Nach ein paar Minuten erwärmt sich alles, die Frequenz schwebt weg und die empfangenen seriellen Daten beginnen falsch zu decodieren. Und wenn Sie die Unterstände in diesem Modus einstellen, liegt alles vor dem Aufwärmen. In diesem Projekt wurde alles sicher entschieden: Die Daten befanden sich im Manchester-Code und waren selbstsynchronisierend. Ich habe die Synchronisation nicht vom Anfang des Pakets an durchgeführt, sondern von jedem Bit. Für die Zukunft habe ich jedoch gelernt, dass bei der Verwendung interner Generatoren in Steuerungen deren thermische Stabilität überprüft werden muss. Wir werden dies mit PSoC überprüfen, da sich auf dem vorhandenen Steckbrett kein Quarzresonator befindet und das System daher vom internen Oszillator im Controller getaktet wird. Der Controller selbst hat sich für meine Aufgaben noch nicht für mich erwärmt, kann jedoch durch Komponenten auf derselben Platine beheizt werden.
Bei einer Frequenz von 24 MHz sind die Fronten ziemlich gerundet, man kann einen Fehler machen. Nehmen wir für Experimente die erhaltene Frequenz f / 5.
Das sind übrigens nicht ganz 4,8, sondern 4,78 MHz. Kein Problem! Der Generator kann kalibriert werden! AN60631 sagt, dass im Allgemeinen ein 11-Bit-Register in den Ports IMO_TR0 und IMO_TR1 dafür verantwortlich ist. Die automatische Berechnung des optimalen Werts mit einem externen Referenzgenerator ist im Dokument CE219322 beschrieben. Ein Beispiel ist sogar diesem Dokument beigefügt. Da sich auf meinem Steckbrett jedoch kein separater Generator befindet, war es für mich zum Beispiel einfacher, den Wert empirisch auszuwählen und mich auf die Messwerte des Oszilloskops zu konzentrieren. Hinzufügen des folgenden Codes zur Funktion main () (Inkrementierungsschritt ist 0x20, da die unteren 5 Bits nicht verwendet werden):
volatile uint16_t* ptr = (uint16_t*) CYREG_IMO_TR0; ptr[0] += 20 * 0x20;
Ich habe ein ziemlich anständiges Ergebnis erzielt:
Wir halten das Brett auf dem Balkon, wo es heute ungefähr Null ist. Die Frequenz schwamm ein wenig ab, aber auf einem vorhandenen Oszilloskop ist es sogar schwierig zu messen. Eher mit dem Auge sichtbar (am Schnittpunkt des linken Cursors mit dem gelben Strahl).
Jetzt heizen wir das Board auf der Batterie. Auch auf dem Gerät sind Unterschiede nicht sichtbar.
In PSoC ist der Generator also ziemlich thermostabil. Wütende Abweichungen von der Häufigkeit, mit der das Arbeitssystem große Fehler macht, sollten von ihm nicht erwartet werden.
Die Abhängigkeit der Frequenz des internen Generators von der Versorgungsspannung
Ich habe diesen Artikel bereits geschrieben und ihn grob gelesen, da ein weiterer interessanter Faktor im Zusammenhang mit den Taktfrequenzen aufgetaucht ist. Bei einem Projekt ging die Frequenzmessung mit einem Fehler von etwa 2% einher, was für diese Aufgabe wesentlich ist. Darüber hinaus wurde die in UDB implementierte Logik korrekt implementiert. Es gab keine Fehler in der Logik. Als ich alles mit einem Oszilloskop kontrollierte, bemerkte ich, dass die Referenzfrequenz nur bei diesen 2% liegt.
Aber warum? Trotzdem war es wunderbar! Damals erinnerte ich mich an den Artikelentwurf. Die Abhängigkeit ist nicht nur von der Temperatur, sondern auch von der Versorgungsspannung. Und irgendwann habe ich es von 5 auf 3,3 Volt gesenkt. Kalibriert die Frequenz des Generators, ist der Fehler weg.
Danach bestand jedoch der Wunsch, Abhängigkeiten in der Dokumentation zu finden. Es stellt sich heraus, dass sie alle im DataSheet für einen bestimmten Chip aufgeführt sind. Hier ist die Temperaturabhängigkeit des Generatorfehlers
Mein Zeitplan ist blau. Im Allgemeinen stimmt alles mit den praktischen Ergebnissen überein. Und hier ist die Spannungsabhängigkeit:
Hier ist der erforderliche Zeitplan irgendwie rot. Bei zwei Prozent zieht er eindeutig nicht, aber eine lineare Zunahme des Fehlers ist offensichtlich.
Fazit
Wenn Sie die Standard-Clock-Komponente in PSoC Creator verwenden, sollten Sie darauf vorbereitet sein, dass das Tastverhältnis der dortigen Impulse nicht 50% beträgt. Dies ist wichtig, wenn das Projekt nicht nur Fronten, sondern auch Signalscheiben verwendet. Um diesen Effekt zu bekämpfen, sollten Sie die Grundfrequenz durch gerade Koeffizienten teilen.
Für Anwendungen, die empfindlich auf Frequenzfehler reagieren, wird empfohlen, die interne Uhr (IMO) nur mit einer stabilisierten Versorgungsspannung zu verwenden. Für jedes Produkt nach der Montage wird empfohlen, die Frequenz zu kalibrieren. Wenn eine instabilisierte Batterieleistung erwartet wird, ist es am besten, einen externen Quarzresonator zu verwenden.