LGT8F328p - ein Nachbau vom ATMega328P oder sogar besser?

hört sich interessant an. Werde ich auch mal beim Ali bestellen und basteln.

Danke für den Hinweis zum Clone Jens!

Wieviele Stützpunkte aus der Sinus-LUT nimmst du für das 1MHz Beispiel? Ich sehe zwar eindeutig ein paar Abstufungen im 1-MHz Signal welche wohl die Punkte aus der Tabelle sind, kann aber wirklich nur schätzen.

64 Stützpunkte aus der LUT für eine Periode? Ich hätte auf viel weniger getippt, wenn ich das Bild vergrößert sehe. Habe mal ein paar mir(!) auffällige Stellen mit ROT markiert, wo ich gesagt hätte, ja hier nimmt er wieder einen Punkt, der Rest ist durch die Schaltung "interpoliert" und bei dem Minima GRÜN sprint er über den Minimalpunkt in der LUT weg.

Erstes abgebildete Minimum gut mit Stützpunkten getroffen! Zweite Minimum Stützpunkte vor dem LUT-Minimum und dahinter, deshalb ein "geclippter" Sinus, beim dritten Minimum noch etwas weiter danaben und dann, was nicht abgebildet wird, fängt er sich wieder bzw. springt dann im Maxima über den LUT-Max-Wert. Und so weiter und so weiter, was aber normal ist, wenn die Schrittweite nicht ganzzahlig durch die Anzahl der LUT-Werte teilbar ist.

Was ich mich allerdings Frage, der Timer kann mit 2xQuarzfrequenz takten, wie sieht es mit dem Rechenwerk aus, ist da auch ein Multiplier davor?

Bei 25 Hz: Alle 360 LUT-Werte (eine Periode) 25 mal die Sekunde = 360*25 = 9000 Hz, hast Du ja geschrieben. Also 9000x die ISR pro Sekunde, da bleibt viel Spielraum.

Bei 1 MHz: 64 LUT-Werte pro Periode, 1.000.000 mal die Sekunde = 64.000.000 Hz (64MHz), also wird die ISR 64 Mio mal pro Sekunde angesprungen. Wie arbeitet das Rechenwerk mit 32 MHz Takt denn jedesmal die ISRs ab?

64 Mio mal die Sekunde:

- Kontextwechsel (Register sichern) ,

- in die ISR springen, andere ISR Blockieren,

- LUT-Wert laden und in DAC Register schreiben,

- Inkrementieren zum nächsten LUT-Wert

- Prüfen auf Indexüberlauf

- andere ISR Freigeben

- Kontextwechel zurück (gespeichere Register wieder zurück schreiben)

und das auf einem 32 MHz getakteten Rechenwerk? Wenn jeder Schritt nur ein Takt braucht ist das doch schon zu viel, es müsste alles zusammen aber nur 0.5 Takte brauchen. Zauberrei oder habe ich was übersehen?

Oder meinest Du eher eine Schrittweite von 64 durch die 360 Grad LUT? Das wären dann nur 5,625 Stützpunkte, also fast 6, aber dafür sieht die Sinus nun wieder fast zu gut aus.

Wie gesagt, der Rest nach dem Komma sorgt sowieso für ein periodisches immer wiederkehrendes Überspringen der Min/Max-Werte der LUT, aber rechnerisch wird dann halt nur 5625000 mal pro Sekunde die ISR aufgerufen, wenn die Schrittweite 64 ist. Das wiederum ist für ein 32 MHz Rechenwerk nicht so sehr eine Zauberrei, auch wenn das Signal dann eher schei** ausieht.

Allerdings wenn der Controller schon für einen Sprung in die ISR, also bis zur ISR-execution 4 Takte benötigt (also noch nichtmal ein Return from Interrupt mitgerechnet, auch nicht das was eigentlich gemacht werden soll, schon gar nicht mit Arduino-Libs) bedeutet das, dass hier nur für den Sprung schon 22.500.000 Takte flöten gehen, bei 32.000.000 gesamt!

Aber 64 MHz ISR auf 32 MHz Rechenwerk?

Hallo Jens,

vielen Dank für diesen interessanten Tip! Ich werde dann mal ein paar bestellen!

Soo...gerade einige bestellt

Jens meint, alle 5,625 Grad ein Stützpunkt, also eine 64 Elemente lange Tabelle.

Dies sind dann die Sinuswerte um das Minimum herum:

In der Arduino-Referenz steht, daß die int()-Funktion den Datentyp wie in C konvertiert; also rundet sie ab. Daher haben wir dreimal hintereinander die 1 stehen, die - so vermute ich - für die Abplattung sorgt.

Nimmt man nur 48 statt 64 Stützpunkte, so ist die Abplattung weg:

Gruß, Frank

Ja Frank, genauso habe ich das auch aufgefasst, 64er LUT, jeder Step also 5,625 Grad. Nach seinen Oszibild für die 1 MHz hätte ich auf viel weniger Punkte geschätzt.

Wenn man die LUT wirklich als [0..63] aufbaut, bekommt man beim Zeigerumlauf auch immer den gleichen Phasenjitter, allerdings müssten dann die Minima auch immer gleich aussehen! Das erste Minima ist aber gut getroffen, dann scheint sich der Fehler zunächst nur zu addieren und wahrscheinlich später wieder zu minimieren bzw. aufs Maxima zu wechseln. Daher rate ich mal, wenn das keine Messfehler sind, im Quellcode ist immer noch die 360 Grad LUT drin und es wird nur in anderer Schrittweite drübergegangen, sodaß man um die "ungünstigen" Stellen indexmäßig schwebend ist. Das konnte, das Bild erklären.

Wenn Jens zusätzlich den Codeteil auch für die 1 MHz nimmt if(deg>359){deg=0;} müsste man eigentlich nach einer Periode immer einen größeren Phasensprung sehen, das ist aber nicht der Fall, also wird er das mit einer angepasst großen LUT machen, nur das erklärt wieder nicht die gleitende Veränderung des Extremas.

So oder so bleibt aber das Problem der Berechenbarkeit! Bisher konnte ich nur finden, daß man zwar den Timer mit 2xOszillatorfrequenz, also 64 MHz betreiben kann, das Rechenwerk aber direkt die 32 MHz bekommt und keine Vervielfachung/PLL davor ist, die einen höheren Takt ableitet, so wie das größere Controller haben.

Bei 64 Punkten/Signalperiode muss also bei 1 MHz auch jeder Timertick genutzt werden um durch die LUT zu schreiten, Wert auf DAC zu schreiben. Also 64 Mio mal ein Interrupt nach seinen oben gemachten Angaben. Bloß die Doku sagt zum Interrupt

making any interrupts available in the four system clock cycles
response. After four system clock cycles, the interrupt service routine enters the execution cycle.

Also 4 Takte zum reinspringen und nach dem Instruction Set des Prozessors kommen nochmal für den Rückkehrbefehl RETI 2 clock cycles hinzu. Wir sind also schon bei 6 Takten pro Interrupt und haben in der Interrupt Service Routine noch gar nichts gemacht.

6 cycles * 64 MHz = 384 Mio cycles/Sekunde, ein bisschen viel für ein 32 MHz getaktetes Rechenwerk. Es kommen ja noch pro Interrupt nach seinem Codevorbild mindestens je 1 Takt für SEI und CLI hinzu, dann Werte aus LUT holen und mit einer Arduinoimplementierung von analogWrite schreiben, Indexüberlauf prüfen. Das macht sicher nochmal mehr cylces nötig als eine direkte Assemblerimplementierung dieser Aufgabe. Aber es reicht ja rechnerisch schon nichtmal für rein in Interrupt/raus aus Interrupt.

Bei 48 Stützpunkten Frank, wären immer noch 288 MHz nötig nur für rein / raus aus dem Interrupt. Und selbst wenn Jens es so gemeint hat, wie ich oben im Fall 2, also in 64er Schritten durch eine 360er LUT, also nur 5,625 Stützpunkte pro Signalperiode sind es immer noch bei 1 MHz nur für Sprung in die Interrupt Service Routine und zurück 22.500.000 Takte die von 32.000.000 Takten abgezogen werden müssen. Wenn jetzt noch SEI und CLI dazukommen, dann die eigentliche Ausgabe... Das wird nichts auf einem 32 MHz core, wenn der ohne PLL direkt getaktet ist.

Also entweder ist da ein Rechenwerk aus Feenstaub drin, ein gefakter Prozessor der in Wirklichkeit ein STM32.... mit Taktvervielfältigung des Quarzes ist, oder ich weiß es nicht. Sowas wie ein dediziertes Rechenwerk nur für I/O wie diese PIO State Machines eines RP2040 gibt es ja auch nicht, DMA hat er auch nicht oder habe ich die falsche Dokus zum LGT8F328 erwischt?

Quote from pintel

Die 1 MHz sind ein Beispiel, ich würde es nicht machen, da der Prozessor damit an seine Grenzen stößt. Tatsächlich arbeitet der Timer mit doppelter Prozessorgeschwindigkeit, also 64 MHz und setzt 64 Punkte pro Periode. In wieweit er jeden Punkt richtig setzt oder ob er welche überspringt, wovon auszugehen ist, kann ich nicht sagen. Dass das Endergebnis nicht perfekt werden kann, ist ja logisch. Trotzdem sieht die Kurve für diese Umstände sehr gut aus, das ist der Kernpunkt. Die 25 Hz oder 1 kHz sind allerdings perfekt mit 360 Punkten pro Periode.

Ja die 25 Hz / 1 kHz sind sehr gut, aber das würde ein normaler ATmega328 wohl auch so hinbekommen, der Kernpunkt aber bei 1 MHz ist nicht die "hübsche" Sinuskurve, sondern es stößt der Prozessor eigentlich nicht an seine Grenzen, rechnerisch (nach den Dokus) hat er die Grenzen schon mehrfach überschritten und könnte das Signal so gar nicht unter diesen Randbedingen erzeugen!

Jens lade doch bitte mal dein 1 MHz Beispielcode als Projekt mit allen gemachten Prozessorsettings hoch, der die dieses Zauberwerk auf nach Herstellerdoku völlig ungeeigneter Hardware vollbringen soll! Dann kann das jeder der einen solchen Prozessor mal bestellt hat, auch auf seinem Modul selbst analysieren.

Ehrlich gesagt, sehe ich die angesprochenen Stellen nur im 1 MHz Sinus, nicht im 25 Hz Screenshot und auch nicht im letzten Bild. Das sind ja auch absolut unterschiedliche Rechen- und Auslastungssituationen bzw. im letzten Bild mit anderem Generator wie Du sagst, auch ein anderes Rechenwerk.

Ich denke das Oszi hat beim 1 MHz Sinus schon ganz gut die oben besprochenen Probleme wiedergegeben, weitere Screens die mit dem eigentlichen Problem der (Nicht-) Berechenbarkeit des Problems durch IRQ Überlastung des Rechenwerks auf dem genutzen System (also dem LGT8F328) einhergehen, bringen da nichts außer eine Ablenkung zur eigentlichen rechnerischen Aufklärung des "Wunders", was da auf dem Rechenwerk gesehen sein soll und schieben die Beträge dazu nur ins "off" des Threads. Es wird nur nebulöser, das mit dem 1 MHz Signal.

Du schreibst ja indirekt selbst irgendwie das du nicht weißt was da auf dem System vorgeht:

Quote

Wieviele tatsächlich ausgegeben, das weiß ich nicht.

Ich bin mal gespannt wie die Ergebnisse bei anderen LGT8F328-Käufern aussehen, dein Code und die Änderungen hast du ja beschrieben die zum dargestellten 1 MHz Sinus führten. Schauen wir mal was dabei rauskommt ...

Im Grunde dürfte doch der Prozessor bei IRQ-Überlast das so abarbeiten:

- Timer schiebt mit 64 MHz Unterbrecheranfragen rein (IRQ)

- Ein IRQ kommt durch/Sprung in die Interruptbehandlung: (4 cycles)

- Sperrung für andere IRQ (1 cycle)

- LUT_WERT holen, DAC setzen, Inkrementieren des LUT-Zeigers/Prüfung auf Überlauf (viele weitere cycles)

- Aufheben der Sperre für weitere IRQ ( 1 cycle)

- Rücksprung auf der Interruptbehandlung (2 cycles)

Während zwischen "IRQ kommt durch" und Rücksprung alles auf dem 32 MHz Core gerechnet wird, gibt es Timer-gesteuert mit 64 MHz viele weitere Unterbrecheranfragen, die aber ignoriert werden, weil die Sperre gesetzt ist. Es entsteht zwar ein Sinus über alle Punkte (das Inkrementieren des LUT-Zeigers geht ja immer nur in der Interruptbehandlung), der Sinus ist aber viel viel langsamger getaktet, als es erforderlich wäre für 1 MHz (64MHz/64 LUT-Punkte pro Periode), da die Interruptbehandlung nur bei 1. halben Timertakt also Systemtakt läuft und 2. viele Takte aus des gleichen Quartz benötigt um die Aufgabe zu erledigen (alles dürfte aber nur 0.5 Takte dauern).

Und das Wunder ist halt, wie kommt der nun viel langsamere Sinus doch zu einem 1 MHz aufs Oszi. Mal ganz davon abgesehen das nach einem IRQ und Sprung in die ISR schon wieder für 4 cycles, also bei doppeltem Timertakt 8 weitere IRQs zwischenhauen wollen und beim Rücksprung 4.

Gibt es dort eine rechentechnische Analyse, wie das 1 MHz Oszibild mit dem Code einer 64 Punkt LUT und den Datenblättern des LGT8F328 in Einklang zu bringen sind? Wenn du eine Erklärung hast, poste Sie doch für alle hier, damit wir Kreaturen und alle im Netz nicht mehr leiden müssen. Ehrlich, ich sehe im Moment NICHT wie es mit dem Rechenwerk gehen sollte.

Oder kommst Du schlicht nicht, wenn ich sage ich komme.

Sag niemals nie.

Ich habe hier einen LGT8F328P.
Dies sind Oszillogramme für 1 kHz mit Jens' Programm:

Beide mit 0,1 ms/Kästchen. Rechts erkennt man die Abplattung.

Für 1 MHz bräuchte ich Jens' Code. Ich gebe zu, ich traue dem Braten noch nicht so ganz .

Gruß, Frank

Offenbar gibt es Aussetzer und die Symmetrie passt nicht. Trotzdem akzeptabel für einen ersten Test.

Ja man könnte das DC-Offset in der LUT auf genau 127.5 setzen, dann stimmt die Aussteuerung genau auf 8 Bit, ungefähr so könnte man die Sinus-LUT mit 64 Punkten vorberechnen lassen.

#define LUT_SIZE 64
uint8_t sinus_lut[LUT_SIZE];

void generate_sinus_lut() {
    for (int i = 0; i < LUT_SIZE; i++) {
        sinus_lut[i] = (uint8_t)((sin((2 * PI * i) / LUT_SIZE) + 1) * 127.5);
    }
}

0 : 127
1 : 139
2 : 152
3 : 164
4 : 176
5 : 187
6 : 198
7 : 208
8 : 217
9 : 226
10 : 233
11 : 239
12 : 245
13 : 249
14 : 252
15 : 254
16 : 255
17 : 254
18 : 252
19 : 249
20 : 245
21 : 239
22 : 233
23 : 226
24 : 217
25 : 208
26 : 198
27 : 187
28 : 176
29 : 164
30 : 152
31 : 139
32 : 127
33 : 115
34 : 102
35 : 90
36 : 78
37 : 67
38 : 56
39 : 46
40 : 37
41 : 28
42 : 21
43 : 15
44 : 9
45 : 5
46 : 2
47 : 0
48 : 0
49 : 0
50 : 2
51 : 5
52 : 9
53 : 15
54 : 21
55 : 28
56 : 37
57 : 46
58 : 56
59 : 67
60 : 78
61 : 90
62 : 102
63 : 115

Für verschiedenen Frequenzen mit der 64er LUT könnte man die Timervorbelegungen zum Beispiel mit Arduino Web Timers durchspielen, der auch einen LGT8F329P unterstützt, man kann sich ja an Jens "Vorschlägen" orientieren, also Timer2

https://dbuezas.github.io/arduino-web-timers/#mcu=LGT8F328P&timer=2

Bei maximaler Timerfreq. hat man ja sowieso für OCR2A wenig Auswahl, aber was nützt es wenn der 32 MHz Core die ISR für so hohe Timerfrequenzen und damit IRQs nicht berechnen kann.

Für (viel) niedrigere Frequenzen findet man durch verschieben von OCR2A dann die passenden Settings bzw. es wird der setup-Code schon geschrieben, durchgetestet habe ich das für einen LGT8F329P freilich noch nicht.

Vielleicht hat ja noch jemand eine Idee bei der Durchsicht des Datenblatts, oder Jens meldet sich nochmal wo er das "Overdrivebit" für die MCU gefunden hat, das das so mit dem 1 MHz Sinus mit 64 Punkten klappt.