Arduino Timerprobleme - suche programmierbaren Oszillator

Thomas G. schrieb:
> Programmierbare Oszillatoren finde ich bei Mouser oder ähnlichen Seiten
> nur für Frequenzen ab 100kHz.

Genau so. Und dann tust du den Ausgang noch durch 100.000 teilen 
(Nachteiler) und fertig ist die Laube.

Welcher Arduino?
UNO, oder Nano?

Dann:

Thomas G. schrieb:
> liefert mir der Arduino eine
> Frequenz von 10.989Hz für ca 1.365 Sekunden, woraufhin ein einzelner
> Puls mit 10.8695Hz folgt. Das ganze wiederholt sich zyklisch.
Arduino fügt Schaltmillis ein.
Ca alle 42ms


Thomas G. schrieb:
> Womit lässt sich
> mein Vorhaben realisieren?
Verwende doch besser Timer 1

Sofern Du einen Arduino verwendest, darfst Du den zumeist bestückten 
keramischen Resonator nicht verwenden, da er zu ungenau ist. Beim 
Arduino UNO beispielsweise kann man den Takt vom ATmega16U2 verwenden. 
Wie man dies umlötet findest Du hier unter Punkt "automatischer Abgleich 
..."
http://mino-elektronik.de/fmeter/fm_software.htm#bsp7

Genaue Zeiten - auch und gerade im unteren Frequenzbereich - mit einer 
Auflösung von 62,5 ns @ 16 MHz Takt kann man mit einem Timer erzeugen. 
Beispiel findest Du hier: 
http://mino-elektronik.de/Generator/takte_impulse.htm

Sieh es Dir einfach an. Es sind C-Programme, die man auch auf einem 
AVR8-Arduino laufen lassen kann.

Sofern die absoluten Zeiten im ppm-Bereich liegen müssen, kommst Du um 
einen stabileren Taktgeber nicht herum. Stichwort: TCXO.
Relative Zeiten kann man dadurch stabil halten, daß alle Oszillatoren 
vom gleichen Taktgeber betrieben werden und daher nicht gegeneinander 
driften können.

Klingt nach einem Fall für 4 Zustandsautomaten. Dort ist ein Beispiel 
mit Erklärungen für 3 blinkende Leuchtdioden:
http://stefanfrings.de/multithreading_arduino/index.html

Das kannst du selbstverständlich auf 4 erweitern. Wenn das auf Basis von 
millis() machst, kannst du die Blink-Intervalle natürlich auch nur im 
Raster von 1ms einstellen.

Klar könnte man auch 0,1ms oder gar 0,01ms Intervalle benutzen, was aber 
nichts daran ändert, dass man damit nicht jede beliebige Frequenz exakt 
erzeugen kann.

Für 37 Hz brauchst du z.B. 0,027027027ms pro Intervall wären, die Zahl 
hat zu viele Nachkommastellen. Das kriegst du mit keinem digitalen Timer 
hin. Und wenn doch, dann scheitert er an anderen Wunsch-Frequenzen.

Überdenke nochmal deine Anforderungen. Vermutlich verlangst du da mehr 
als nötig.

Mit cleveren Algorithmen kannst du zumindest näherungsweise an deine 
Wunsch-Werte heran kommen. Du musst nur dafür sorgen, dass die 
Abweichung sich nicht immer weiter auf-summiert. Denke an den 29. 
Februar. Der wird ab und zu eingefügt, um die Abweichung unseres 
Kalenders auszugleichen. Spontan fällt mir den Bresenham Algorithmus 
ein, mit dem man schräge Linien auf den Bildschirm zeichnet, die nicht 
exakt ins Pixelraster passen. Das gleiche Prinzip müsste man auch deine 
Zeiten anwenden können. Schau dir das mal an: 
https://de.wikipedia.org/wiki/Bresenham-Algorithmus

Stefan ⛄ F. schrieb:
> Für 37 Hz brauchst du z.B. 0,027027027ms pro Intervall wären, die Zahl
> hat zu viele Nachkommastellen.

Die Nachkommastellen kommen von Deinem Taschenrechner. Hier ist 
sinnvolles Runden hilfreich.

m.n. schrieb:
> Für 37 Hz brauchst du z.B. 0,027027027ms pro Intervall

Hoppla, es sind Sekunden, nicht ms. Die Zahl ist sogar periodisch, hat 
unendlich viele Nachkommastellen!

> Die Nachkommastellen kommen von Deinem Taschenrechner.
> Hier ist sinnvolles Runden hilfreich.

Würde ich auch tun, aber der TO will es exakt. Deswegen schrieb ich:

> Überdenke nochmal deine Anforderungen.
> Vermutlich verlangst du da mehr als nötig.

Mit einem anstaendigen Controller der ein paar Timer hat,
erledigt sich solch ein "Problem" quasi von selbst.
Ansonsten tut es auch ein wenig richtige Signalverarbeitung
um solche Signale zu erzeugen.

Aber wer nur den Buddelkasten spielt, kennt nichts anderes.

Stattdessen muessen externe Timer bemueht werden.
Da kann man doch nur lachen.

Stefan ⛄ F. schrieb:
> Würde ich auch tun, aber der TO will es exakt.

Exakt gibt es in der Physik nicht. Hinreichend genau ist angesagt.

NoArno schrieb:
> Da kann man doch nur lachen.

Ja, lach einen Anfänger nur aus. Dummer Mensch!

NoArno schrieb:
> Mit einem anstaendigen Controller der ein paar Timer hat,
> erledigt sich solch ein "Problem" quasi von selbst.

Leider ziemlich unkonkret, wie soll das dem TO helfen? Und wie machst du 
damit exakt 37 Hz?

> Ich sitze aktuell an einem Hobby Projekt, in dem ich möglichst
> genaue Frequenzen benötige.
Nicht schwafeln, sondern konkrete Angaben: wie genau.

> Diese sollen einstellbar sein. Mein Ziel ist es gerade, vier
> LEDs mit meinen voreingestellten Frequenzen blinken zu lassen.

Ich denke, das Problem ist eher die Erzeugung der Frequenzen mit 
delay().
Das ist nämlich sehr ungenau, eher im Promille-Bereich. TXCO ist der 
komplett falsche Weg, dort geht es um ppm, also um Faktor 1000 genauer.

Genauso programmierbare Oszillatoren.
Natürlich kann man das so machen, ist aber für dein "Hobbyprojekt" eher 
totaler Overkill, so wie ich das sehe.

Ich denke, dass die absolute Frequenz gar nicht so wichtig ist, sondern 
dass die 4 LEDs "synchron" bleiben. Und das geht am besten von einer 
Zeitbasis weg. Z.B. wie schon angedeutet mit dem Timer1.
Du errechnest on the fly, wann das nächste Event ist, lässt dann einen 
Interrupt generieren und schaltest den entsprechenden Ausgang. Dann 
überlegen, wann das nächste Event sein soll. Fertig.

Oder wenn es ein klein wenig jittern darf, ganz ohne Interrupt, einfach 
den Zähler periodisch abfragen und bei overflow einen Software-Zähler 
hochzählen.
Oder den Overflow-Interrupt die Überläufe zählen lassen für kleine 
Frequenzen.
Analog ist noch viel ungenauer (Temperaturabhängigkeit etc.)
Die Zeitbasis bei den Arduinos hängt vom Hersteller ab, manche verwenden 
Resonatoren, andere Quarze.

Thomas G. schrieb:
> Eine gute Idee die ich gerne testen würde, bei der ich leider nicht
> durchblicke wie ich den Timer 1 einstellen soll. Da verstehe ich nicht
> welchen prescaler ich auswählen soll oder was für TOP Werte zu verwenden
> sind.

Das kann man doch berechnen...
Oder?
Soweit mir bekannt, sind die Regeln im Datenblatt aufgeführt.

Thomas G. schrieb:
> die millis() Funktion läuft asynchron mit einer Ungenauigkeit von 100ppm

Nimm doch micros().

LG, Sebastian

Thomas G. schrieb:
> Wie funktioniert das beim Arduino? So würde ich näher an meine
> Wunsch-Frequenz kommen können.

Der Timer0 wird schon vom Arduno Framework belegt. Aber du kannst einen 
anderen Timer verwenden, der z.B. alle 0,1 ms einen Interrupt auslöst 
und dann in der ISR einen Counter hochzählen.

Aber da auch das wie gesagt nur eine halbe Lösung wäre, die auf keinen 
Fall die von dir geforderten exakten Frequenzen erzeugen könnte, erspare 
ich mir hier, dafür ein konkretes Beispiel zu schreiben. Wenn du es 
wirklich ernst meinst, wirst du selbst etwas finden. Mit ISR und der 
korrekten Nutzung von Variablen in diesem Kontext wirst du dich ohnehin 
beschäftigen müssen, sobald du über den Arduino Standard hinaus gehst.

Thomas G. schrieb:
> Andererseits versuche ich möglichst genau zu arbeiten.

Typischer Anfängerfehler. Man hat kaum Erfahrung, weniger Ahnung, will 
es aber so gut wie möglich machen, auf jeden Fall besser als die Profis. 
Jetzt fehlt nur noch, dass es insgesamt nicht mehr 20 Euro kosten darf.

Dabei kann ich dir nicht helfen.

Thomas G. schrieb:
> deshalb gehe ich
> laut anderer Internetseiten mal davon aus, dass es sich hierbei um einen
> Quarz handelt.

Ich behaupte, dass ein in Hochsprache (C++) programmierter µC der 
falsche Ansatz ist, eine stabile Frequenz ohne Jitter erzeugen zu 
wollen.

Ganz klassisch macht man das mit einer PLL und einen programmierbaren 
Teiler. Damit kann man exakte 1 Hz Schritte ohne jeden prinzipbedingten 
Fehler erzeugen, solange die Referenzfrequenz auch exakt ist.

Juri schrieb:
> Thomas G. schrieb:
>> Programmierbare Oszillatoren finde ich bei Mouser oder ähnlichen Seiten
>> nur für Frequenzen ab 100kHz.
>
> Genau so. Und dann tust du den Ausgang noch durch 100.000 teilen
> (Nachteiler) und fertig ist die Laube.

Bisher habe ich nur von irgendwelchen, halbseidenen Tricksereinen 
gelesen, die aller mehr oder weniger direkt in die Hose gehen.

Hol dir bei Mouser den programmierbaren Oszillator und schalte einen 
Nachteiler nach. Machst du diesen Nachteiler programmierbar, hast du ein 
sehr universelles Gerät. Ist sehr hohe Genaugkeit gefragt? 
Speise/synchronisiere deinen Oszillator aus einem TCXO oder OCXO.

Aber ich wiederhole mich...

Wenn ich ein genaues Timing brauche, dann nehme ich ein FPGA. Da kann 
ich im Mikrosekundenbereich (und kleiner) arbeiten. Die Timerbreite in 
Bits ist skalierbar. Es können mehrere Dutzend Timer laufen, die sich 
gegenseitig nicht stören. Und wenn eine CPU zufällig im Interrupt ist, 
funktioniert das Timing es immer noch.

Aber es muss ja immer ein Bastelarduino sein. Ich bastel mit denen auch, 
aber wenn ich verschärfte Anforderungen habe, muss ich andere Werzeuge 
benutzen.

PittyJ schrieb:
> Wenn ich ein genaues Timing brauche, dann nehme ich ein FPGA.

Beim Blinken einer LED kommt es selten auf genaues Timing (im Sinne von 
Jitter) an. Hier geht es wohl eher darum, dass die Phasenlage sich nicht 
verschiebt.
Vielleicht reicht schon eine einfache Software-DDS, die mit dem 
T0-Overflow getaktet wird und für jeden Output-Kanal einen eigenen 
Phasenakkumulator besitzt - hängt von den Anforderungen an die 
Frequenzen/Phasenlage ab.

>Ich sitze aktuell an einem Hobby Projekt, in dem ich möglichst genaue
>Frequenzen benötige.
> Dafür habe ich mich an mein Arduino gesetzt und ein Programm
>geschrieben, das fürs bloße Auge zu laufen scheint und in manchen Fällen
>die laufende Frequenz sichtbar verfälscht.

Wenn du mit bloßem Auge eine Ungenauigkeit siehst, dann liegt es mit 
Sicherheit nicht an der Zeitbasis des Arduino sondern an einem Fehler in 
deinem Programm.

"Möglichst" genau geht es, wenn eine Atomuhr nimmst. Oder du musst erst 
einmal "möglichst genau definieren".
Die nächst einfachere du ein GPS-Signal zur Synchronisation der 
Zeitbasis nimmst.
In absteigender Reihenfolge kannst du entweder
- ein Rubidiumnormal
- einen Ofen kontrollierten Oszillator
- oder einen Temperaturkompensierten Oszillator kaufen

Desweiteren gibt es nicht "den Arduino", sondern Haufenweise völlig 
unterschiedliche Hardware, auf der das Arduino Framework läuft.
Die Arduinos "Uno" und "Nano" haben einen Resonator, der für 
Frequenzmessungen mit mehr als 4 Stellen zu ungenau ist. Nimmst du aber 
einen PiPico mit Arduino-Framework, hat der einen sehr stabilen Quartz 
und die Systemfrequenz kann auf 150MHz hochgestellt werden, sodass auch 
noch kleine Zeitquantisierungen möglich sind.

chris_ schrieb:
> Wenn du mit bloßem Auge eine Ungenauigkeit siehst, dann liegt es mit
> Sicherheit nicht an der Zeitbasis des Arduino sondern an einem Fehler in
> deinem Programm.

sehe ich auch so.

@TO:
Wenn deine 4 LEDs in sync bleiben sollen dann mach einen Takt und leite 
davon die Takte der 4 LEDs ab. Das bleibt syncron auch wenn sich mal 
deine millis um eine 1ms verschieben würden.

Thomas G. schrieb:
> Wie genau arbeitet ein TCXO?

Das ist ein temperaturkompensierter Quarzoszillator, der über einen 
weiten Temperaturbereich eine auf ca. 1 ppm (je nach Typ) stabile 
Frequenz liefert.
Wie sich jetzt gezeigt hat, hat Deine Schaltung einen Quarzoszillator, 
wo man von einer Grundgenauigkeit von <= 50 ppm ausgehen kann.
Daraus folgt, daß er für Deine auf vier Stellen genaue Takterzeugung 
ohne weiteren Abgleich ausreichend ist.

Da Du einen ATmega328 verwendest, könntest Du die oben verlinkten 
AVR-Programmbeispiele damit laufen lassen. Pro erzeugte Frequenz braucht 
man einen OCRx-Ausgang, wovon der 328 insgesamt sechs Stück hat. Daß 
jeweils zwei an einem gemeinsamen Timer hängen, stört nicht. Insgesamt 
kann man damit also sechs unterschiedliche Blinkfrequenzen erzeugen - 
sehr genau und jitterfrei.

Man kann zwar die Arduino-IDE verwenden, sollte aber tunlichst setup() 
und loop() vermeiden, damit man alle Timer selbst benutzen kann.

Du brauchst also keinerlei andere oder zusätzliche Hardware, aber ein 
wenig Arbeit, um zu verstehen, wie die Timer mit ihren OXRx-Ausgängen 
arbeiten.

Bleibt noch die Frage, wie Du die unterschiedlichen Frequenzen 
einstellen willst.
Per Poti wäre zu ungenau. Per Tastatur oder per ser. Schnittstelle?

Peter D. schrieb:
> Das ist Wischiwaschi, damit kann keiner was anfangen.

Der TO hatte mittlerweile beschrieben, wie genau er es haben möchte.
Man  muß es nur lesen und verstehen wollen.

Peter D. schrieb:
> Für Blink-LEDs braucht es überhaupt keine Genauigkeit. Kein Mensch kann
> Fehler im ms-Bereich erkennen.

Der TO möchte es so haben, weil er etwas lernen will. Daß instabile 
Blinkschaltungen relativ schnell sichtbar in der Phasenlage 
auseinanderlaufen, ist kein Geheimnis. Das ist selbst dem TO als 
Programmieranfänger aufgefallen.
Daß Du das nicht brauchst, ist nicht relevant.

Peter D. schrieb:
> Wenn sie von einem gemeinsamen Basistakt erzeugt werden, aber schon.

Lies doch mal, was hier bereits geschrieben wurde.
Deine nutzlose Nörgelei bringt dem TO nichts.

m.n. schrieb:
> Stefan ⛄ F. schrieb:
>> Würde ich auch tun, aber der TO will es exakt.
>
> Exakt gibt es in der Physik nicht. Hinreichend genau ist angesagt.

Naja, Stefan ist weder Physiker noch Mathematiker. Also nicht 
übelnehmen.

So, zur Sache:
Wenn man irgendwelche möglichst präzisen Signale erzeugen will, die auch 
noch frei wählbar im Betrieb sein sollen, dann greift man der 
Einfachheit zuliebe zu einem kleinen DDS-Schaltkreis. Wenn man hingegen 
ohne zusätzliche Schaltung auskommen will, dann wären da µC-interne 
Timer die Wahl, aber das setzt zusätzliche Überlegungen voraus. Und da 
kommt zumindest das Rechnen mit echten Brüchen ins Spiel, womit auch 
Teilungsverhältnisse darstellbar sind, die bei Dezimaldarstellung zu 
nicht enden wollenden Nachkommastellen führen.

Sowas geht vom Prinzip her auch mit einem Arduino, aber man muß sich 
schon etwas mehr mit Rechnen und dem Verwenden von Timern befassen als 
nur millis() aufzurufen.

W.S.

Peter D. schrieb:
> Auseinander laufen können nur 4 unabhänge RC-Oszillatoren. Sobald man
> einen gemeinsamen Basistakt hat, sind alle Abläufe streng
> deterministisch.

Genau.
Schon deshalb kann ich das Problem des TO nicht nachvollziehen.
Und wenn er unabhängige Oszillatoren hat, auch welche vom Typ TCXO, dann 
werden die irgendwann merklich auseinandergelaufen sein.

Ich halte es für erwähnenswert, dass die loop Schleife keine while 
Schleife ist, wie man sich das als Anfänger vorstellt. Die Loop muss man 
sich so vorstellen:

while(1){
loop(); <--- hier wird dein Code ausgeführt
ArduinoKram(); <-- kostet Zeit
}

Auch digitalWrite() etc. benötigt unterschiedlich lange, was auch zu 
einer verschiebung führt.

Teste deinen code mal mit
- micros() anstatt millis()
- in einer while(1) Schleife anstatt in der loop()
- evtl. direkten Port Zugriff anstatt digitalWrite()

Die bessere Variante ist jedoch einen Timer zu verwenden und dann über 
direkten Port Zugriff die GPIOs schalten.

Thomas G. schrieb:
>> Kriegt man mit einer Toleranz von +/- 0,001 % hin. Genau genug? An eine
>> Kalibrierung kommt man wohl nicht vorbei.
>
> Das sollte genau genug sein.

Ganz doof gefragt: verfügst du überhaupt über die Messtechnik, um dein 
Ergebnis zu verifizieren?

Ansonsten ist selbst mit dem Uno noch eine Menge Luft nach oben, wie 
schon andere geschrieben haben.

> was da ganze
> überhaupt soll.

Das ist doch nun einfach.
Ein Caesium kontrollierter Arduinowurstblinker.
Braucht doch fast jeder (nicht).

Wenn es wenigstens ein Stroboskop waere...

> eine "Abweichung" von 0%.
ist, wie ich schon schrieb, mit einer PLL bezogen auf die
Referenzfrequenz leicht zu erreichen.
Das sollte sich vielleicht auch einmal in "FPGA-Kreisen" herumsprechen.
Das es auch ausserhalb eines FPGA eine oder mehrere PLLs geben kann.
Und nicht nur diese haesslichen DCMs.

Falk B. schrieb:
> Nö. Das sind einfache Zähler und Modulooperationen. DDS in Software.

Ach nö. Ein Zählerausgang liefert hi oder lo und damit nur das 
Vorzeichen, während ein DDS ein analoges Signal liefert und damit 
schlußendlich eine Stützstelle, die nach einem Tiefpaß den richtigen 
Signalverlauf (soweit technisch möglich) liefert. Du solltest dringend 
mal nachlesen, wie ein DDS funktioniert.

Und wenn man exakte Frequenzverhältnisse mit Timern haben will, dann 
kommt man nicht umhin, sich um Rechendinge zu kümmern wie gemeinsame 
Teiler von Integers usw. - sonst addieren sich die restlichen 
Phasenfehler und die Signale an den Ausgängen laufen langsam 
auseinander. Wenn einen das nicht schert, dann ist das Benutzen von 
Timern ohne weitere Berechnungen möglich. Sonst eben nicht.

W.S.

Lothar M. schrieb:
>> Ich habe auch nicht genörgelt, sondern nur gefragt, was da ganze
>> überhaupt soll.
> Auf die Antwort bin ich auch gespannt.

Das muß der TO überhaupt nicht beantworten. Er ist Anfänger und kann tun 
und lassen, was er will.

Er möchte Programmieren lernen und hat sich ein Ziel gesetzt. Das ist 
allemal besser, als irgendwelche, fertigen Entprellroutinen 
herunterzuladen und instinktlos einzusetzen.

Klassikradio schrieb:
> Ein Caesium kontrollierter Arduinowurstblinker.
> Braucht doch fast jeder (nicht).

Noch so ein namenloser Stinkstiefel, bei beim Wiederkäuen seines 
Frühstücks Schluckauf bekommen hat.

Klassikradio schrieb:
>> eine "Abweichung" von 0%.
> ist, wie ich schon schrieb, mit einer PLL bezogen auf die
> Referenzfrequenz leicht zu erreichen.

Naja, nicht 0%, sondern eher daß die restliche Frequenzabweichung im 
Phasenfehler untergeht. Aber 'leicht' ist was anderes. Es gibt durch den 
notwendigen Teiler immer ein Raster.

W.S.

Peter D. schrieb:
> Auseinander laufen können nur 4 unabhänge RC-Oszillatoren. Sobald man
> einen gemeinsamen Basistakt hat, sind alle Abläufe streng
> deterministisch.

Wieder mal eine sprachliche Ungenauigkeit. Meinst du langsame Änderungen 
in der Frequenz oder in der Phase? Und es sind nicht nur RC-Oszillatoren 
betroffen, sondern im Prinzip alle. Bloß das Ausmaß ist 
unterschiedlich.

So. Ich geb dir mal ein Beispiel zum Prinzip: ein Ausgang soll ein 
Signal mit 10 Hz ausgeben und ein anderer eines mit 50 Hz. Rein 
theoretisch sollten beide Signale gegeneinander nicht phasenmäßig 
auseinanderlaufen. Aber wenn bei einem die exakte Frequenz 10.0001 Hz 
ist und bei dem anderen die exakte Frequenz 49.9999 Hz, weil sich das 
eben aus den Integer-Teilerwerten ergibt, dann laufen die Signale 
langsam in der Phase auseinander - obwohl sie aus dem selben Takt 
generiert werden.

W.S.

> Er ist Anfänger und kann tun und lassen, was er will.

Dann soll er es auch lassen hier zu fragen.
Mein Fruehstueck habe ich uebrigens schon gut verdaut.

> daß die restliche Frequenzabweichung im
> Phasenfehler untergeht

Ist die PLL gelockt, gibt es keinen Frequenzfehler.
Nur einen fixen Versatz in der Phase. Hat das Schleifenfilter einen
I-Anteil, wird disee Phasenabweichung auf ein Minimum geregelt.

>  von W.S. (Gast)   30.05.2022 12:46
> Du solltest dringend mal nachlesen, wie ein DDS funktioniert.
Das weiß der Falk /sehr genau./

Hier ein präziser Einkanal-Frequenzgenerator z.B. für einen UNO oder 
Nano (so genau der 16bit-Timer halt geht):
Ursprünglich verwendete ich die timerOne-Library, die ist aber ungenau, 
da sie nur in Mikrosekunden rechnet, und das nicht einmal genau, da sie 
als Quarzfrequenz nur Mehrfache von 2 MHz "zulässt".

1

//      F_CPU is the frequency of MY arduino uno, change this number for YOUR board

2

//giving this as float forces a precise compile-time calculation of cycles in timerone.h.

3

#define F_CPU 15995000.0

4

//Otherwise calculation is based on frequencies in multiples of 2MHz

5

6

#define msg "enter frequency (mit Punkt statt Komma 0.119 - 4000000) : "

7

///#include <TimerOne.h>

8

void setup(){

9

  DDRB = 0x00;PORTB = 0xFF; //alle INPUT_PULLUP

10

  DDRC = 0x00;PORTC = 0xFF; //alle INPUT_PULLUP

11

  DDRD = 0x00;PORTD = 0xFF; //alle INPUT_PULLUP

12

  DDRB|=2; //OC1A COM1A1 PB1 output

13

  Serial.begin(9600);

14

  Serial.print(F("\nprecision frequency generator\n" msg));

15

///  Timer1.initialize();Timer1.pwm(9,512,round(F_CPU/16.0/51.0));

16

  TCCR1A=128;//COM1A1 COM1A0 Clear OC1A/OC1B on Compare Match (Set output to low level).

17

  TCCR1B=17; //WGM = 1000 (PWM, Phase and Frequency Correct)   clock source CS=001 (no prescaler)

18

  TCCR1C=0;ICR1=15623;OCR1A=7812; // frequency is 511.9055 duty=50%

19

  }

20

void loop(){float f;

21

  if(Serial.available()){

22

    f=Serial.parseFloat();if(f>0.11)if(f<=4100000.0){

23

      Serial.write(32);

24

      Serial.print(f);Serial.write(32);

25

      Serial.print(F_CPU/2/f);Serial.write(32);

26

      Serial.print(F_CPU/16/f);Serial.write(32);

27

//  auf Arduino Uno Anschluss 9 D9 PB1 U1/15 ausgeben

28

///   Timer1.pwm(9,512,round(F_CPU/16/f));

29

///   Serial.print(ICR1);Serial.write(32);

30

///   Serial.print(OCR1A);Serial.write(32);

31

      float //more precision than calculation with microseconds in pwm()

32

      p=        round(F_CPU/   2.0/f);

33

      if(p<65536){TCCR1B=17;ICR1=p;OCR1A=ICR1/2;}else{

34

        p=      round(F_CPU/  16.0/f);

35

        if(p<65536){TCCR1B=18;ICR1=p;OCR1A=ICR1/2;}else{

36

          p=    round(F_CPU/ 128.0/f);

37

          if(p<65536){TCCR1B=19;ICR1=p;OCR1A=ICR1/2;}else{

38

            p=  round(F_CPU/ 512.0/f);

39

            if(p<65536){TCCR1B=20;ICR1=p;OCR1A=ICR1/2;}else{

40

              p=round(F_CPU/2048.0/f);

41

              if(p<65536){TCCR1B=21;ICR1=p;OCR1A=ICR1/2;}else{

42

                Serial.print(F("Frequency too low"));}}}}}

43

      Serial.print(F(" TCCR1A="));Serial.print(TCCR1A);

44

      Serial.print(F(" TCCR1B="));Serial.print(TCCR1B);

45

      Serial.print(F(" TCCR1C="));Serial.print(TCCR1C);

46

      Serial.print(F( " ICR1 ="));Serial.print( ICR1 );

47

      Serial.print(F( " OCR1A="));Serial.print( OCR1A);

48

      if(TCCR1B==17)f=F_CPU/   2.0/ICR1;else //clkI/O/1 (No prescaling)

49

      if(TCCR1B==18)f=F_CPU/  16.0/ICR1;else //clkI/O/8 (From prescaler)

50

      if(TCCR1B==19)f=F_CPU/ 128.0/ICR1;else //clkI/O/64 (From prescaler)

51

      if(TCCR1B==20)f=F_CPU/ 512.0/ICR1;else //clkI/O/256 (From prescaler)

52

      if(TCCR1B==21)f=F_CPU/2048.0/ICR1;     //clkI/O/1024 (From prescaler)

53

      Serial.print(F("  frequency is "));

54

//    Serial.print(f);Serial.write(32);

55

      Serial.print(uint32_t(f));Serial.write(',');

56

      uint16_t frac=uint32_t(10000*f) % 10000;

57

      if(frac<1000)Serial.write(48);

58

      if(frac<100)Serial.write(48);

59

      if(frac<10)Serial.write(48);Serial.print(frac);Serial.write(10);

60

      Serial.print(F(msg));

61

      }else{Serial.print(F(" value out of range"));}

62

    }

63

  }

> Ja, "auf eine Referenzfrequenz". Und woher kommt die? Hat die auch eine
"Genauigkeit" von 0,0%?

Fuer ein mehrkanaliges Stroboskop kann die genaue Einhaltung
der Verhaeltnisse wichtiger sein, als ein absolut genauer Wert.
Wenn man sich z.B. Zahnraduebersetzungen ansehen will.
Zweifelhaft bleibt mir da nur, warum es gerade ganzzahlige
Vielfache von 1 sein muessen.

> Hach, flach.
Selber flach.

Der einzige eingermassen brauchbaren Vorschlag ist vom Peter.
Beitrag "Re: Arduino Timerprobleme - suche programmierbaren Oszillator"

Und natuerlich geht es nicht vernuenftig mit millis() und
Konsorten. Weil eben die Frequenz reziprok zur Zeit ist.

Lothar M. schrieb:
> Lernen heißt aber auch, nicht jeden Fehler selber zu machen, sondern
> auch mal auf andere zu hören.

Meinst Du die, die ihm sagen wollen, daß er doof und unfähig sei?

> Machen wir es mal so: du hilfst ihm und zeigst ihm den Weg, dass er
> seinen Wunsch erfüllen kann.

Oh, das hatte ich bereits getan. Oben sind Beispiele mit einem 8 Bit 
Timer (ATtiny25) und einem 16 Bit Timer (ATmega328) verlinkt. Letzteres 
nutzt beide Kanäle vom Timer1 und hat sogar eine .ino Endung.
Ich könnte ihm daraus auch ein fertiges Programm zusammenkopieren, was 
dann aber keinen Lerneffekt hätte.

Falls der TO die erzeugten Frequenzen mit einem Arduino (328) messen 
möchte, hätte ich auch einen Link: 
http://mino-elektronik.de/fmeter/fm_software.htm#bsp7
Alternativ natürlich auch mit STM32 oder RP2040 Pico-Board ;-)

Lothar M. schrieb:
> dann hast du bei 30Hz einen Jitter von 3%.

Na das ist heftig!
Für eine Stroboskope-Anwendung wohl ein wenig zu viel. Auch sind 50% 
Tastverhältnis wohl nicht so zündend. Das müßte auch noch einstellbar 
sein.

Mit der Arduino-Hardware bekommt man eine jitterfreie Auflösung von 62,5 
ns. Warum soll man darauf verzichten?

Klassikradio schrieb:

> Der einzige eingermassen brauchbaren Vorschlag ist vom Peter.
> Beitrag "Re: Arduino Timerprobleme - suche programmierbaren Oszillator"

Unsinn. Nicht der Vorschlag von Peter, sondern deine schwachsinnige 
Behauptung, dass es der einzige einigermaßen brauchbare Vorschlag wäre.

Denn hier im Thread, als vierte Antwort, wurde das Prinzip bereits 
erstmals erwähnt (wenn auch nur am Rande):

Beitrag "Re: Arduino Timerprobleme - suche programmierbaren Oszillator"

Ein weiteres Mal hier (sogar mit Link auf einen länglichen Thread zum 
prinzipiell gleichen Thema, incl. fertiger Lösung für einen Kanal):

Beitrag "Re: Arduino Timerprobleme - suche programmierbaren Oszillator"

Thomas G. schrieb:
> it der
> if (currentMillis - previousMillis >= interval) {
>     // save the last time you blinked the LED
>       previousMillis = currentMillis;
>
> Option driftet mein Intervall immer in gewissen abständen 1ms weg.
>
> Mit
> if (currentMillis - previousMillis >= interval) {
>     // save the last time you blinked the LED
>       previousMillis = previousMillis + interval;

Deckenleuchte schrieb:
> Ich halte es für erwähnenswert

Noch immer halte ich das für erwähnenswert!

Lothar M. schrieb:
> Ja, "auf eine Referenzfrequenz". Und woher kommt die? Hat die auch eine
> "Genauigkeit" von 0,0%?

Versuchen wir doch mal einen ernsthaften Überschlag: Wenn der Thomas 
irgend etwas per Stroboskop anschauen will, dann vermutlichst deshalb, 
weil es für's bloße Auge zu schnell, aber für stroboskopisches 
Betrachten (das Auge als Sampler...) noch nicht zu schnell ist. Also ich 
tippe mal auf so etwa 500..2000 rpm.

Das Stroboskop muß abstimmbar sein, weil man es für ein so einigermaßen 
stehendes Bild an die Bewegunng des Prüflings anpassen muß. Nehmen wir 
also mal irgendwas in der Mitte, also z.B. 1000 rpm. Wenn da das 
Stroboskop um 1% frequenzmäßig daneben liegt, dann dreht sich das 
virtuelle Bild mit 10 rpm, also 1x in 6 Sekunden.

Naja, ein stehendes Bild ist was anderes, aber 1 Umdrehung in 6 Sekunden 
kann man als Bastler noch aushalten. Ich denke mal, Abweichungen von 1% 
sind die obere Grenze des Zumutbaren. Und ob sich das Bild nun in 5 
Minuten einmal um sich selbst dreht, sollte egal sein, also wäre die 
untere Grenze so etwa im Bereich von 0.02 %. Genauer braucht's nicht zu 
sein.

Bei so etwa 1000 rpm liegt die Periode bei etwa 60 ms und ne Abweichung 
von 1% davon liegt bei 600 µs was damit die obere Grenze ist für die 
Ungenauigkeit.

Und besser als 12µs braucht man nicht zu sein.

So, da haben wir erstmal ne grobe Abschätzung.

Nochwas zum Verfahren: Wenn besagte LED's so eine Art Folgeblitz sein 
sollen, dann reicht es aus, wenn man sie mit einem gewissen zeitlichen 
Abstand von der ersten LED einschaltet. Vier separate Timer braucht es 
da überhaupt nicht. Insofern sind alle Überlegungen zum Davonlaufen von 
Phase usw. überflüssig.

W.S.

W.S. schrieb:

> Nochwas zum Verfahren: Wenn besagte LED's so eine Art Folgeblitz sein
> sollen, dann reicht es aus, wenn man sie mit einem gewissen zeitlichen
> Abstand von der ersten LED einschaltet. Vier separate Timer braucht es
> da überhaupt nicht. Insofern sind alle Überlegungen zum Davonlaufen von
> Phase usw. überflüssig.

So isses. Wie sich die Einlassungen des TO insgesamt so lesen, soll da 
wohl eigentlich ein Motor betrachtet werden und zwar ein Vierzylinder.

Wenn das so ist, sollte man sein Augenmerk eher darauf richten, die 
Messung mit dem Messobjekt zu synchronisieren, statt sie freilaufend zu 
realisieren. Dann gibt's erstmal kein "Fortlaufen" des Bilds. Der Rest 
sind dann keine vier Frequenzen, sondern eine in vier einstellbaren 
Phasenlagen.

Thomas G. schrieb:
> Ich suche eine Komponente, mit der ich stabile Frequenzen im Bereich von
> 1Hz bis 100Hz darstellen kann.

Thomas G. schrieb:
> Ich möchte Frequenzen bis 30Hz mit 2 Nachkommastellen wählen können.

Die Periodendauer der Signale sollten ganzzahlige Vielfache des 
Basistaktes sein. Sonst wird es schwierig.

m.n. schrieb:
> Man kann zwar die Arduino-IDE verwenden, sollte aber tunlichst setup()
> und loop() vermeiden, damit man alle Timer selbst benutzen kann.

Wieso soll man für vier LEDs mehr als zwei Timer benötigen?

Wolfgang schrieb:
> Wieso soll man für vier LEDs mehr als zwei Timer benötigen?

Das frage ich mich auch.
Ich denke, es ist alles gesagt. Man muß es nur lesen.

Hier das gewünschte Programm mit 4 Kanal-DDS:
4 Outputs auf PB5 .. PB2, auf PB1 zum Test die DDS-Frequenz 31250 Hz

Hänge mal einen Lautsprecher an PB5 (D13)...
chromatische Tonleiter 220 - 440 Hz

D12 - D10 ändern anfangs (nach jedem Durchlauf der Tonleiter) ihre 
Frequenz um -1,5, +1,5 und 2,0 Hz, just for fun, damit sich was ändert

Man müsste noch eine serielle Kommunikation dazuprogrammieren, um die
Frequenzen on the fly einstellen zu können.

1

//mikrocontroller.net/topic/537663

2

#define F_CPU 15995000.0

3

#define fre (F_CPU/2/256.0)

4

  //15995000/2/256=31240,234375

5

#define kon (4294967296/fre)

6

  //4294967296/31240,23=137481,935 DDS-Konstante für 1 Hz

7

union{uint32_t ul;uint8_t ub[4];} volatile t0,t1,t2,t3;

8

uint32_t t0add=round(1.234*kon),t1add=round(4.567*kon),

9

         t2add=round(16*kon),t3add=round(128*kon);

10

uint16_t cnt;

11

ISR(TIMER1_OVF_vect){

12

  t0.ul+=t0add;t1.ul+=t1add;t2.ul+=t2add;t3.ul+=t3add;}

13

int main(){

14

  DDRB = 32+16+8+4+2;PORTB = 0xFF;

15

//LEDpin 13 D13 PB5  D12 D11 D10 D9 output, D8 INPUT_PULLUP

16

  DDRC = 0x00;PORTC = 0xFF; //alle INPUT_PULLUP

17

  DDRD = 0x00;PORTD = 0xFF; //alle INPUT_PULLUP

18

  Serial.begin(9600);

19

  Serial.print(F("\n 4-channel precision frequency generator \n"));

20

  TCCR1A=128;

21

  //COM1A1 COM1A0 Clear OC1A/OC1B on Compare Match

22

  //(Set output to low level).

23

  TCCR1B=17;

24

  //WGM=1000 (Mode8:PWM, Phase and Frequency Correct)

25

  //clock source CS=001 (no prescaler)

26

  TCCR1C=0;ICR1=256;OCR1A=128;

27

  // frequency is 31250 duty=50%

28

  TIFR1=255;  //clear all by writing 1

29

  TIMSK1=_BV(TOIE1);

30

  //enable Timer1-Overflow-Interrupt  OCIE1B 2  OCIE1A 1  TOIE1 0

31

  sei();

32

  Serial.print( fre );Serial.write(32);

33

  Serial.print( kon );Serial.write(32);

34

  Serial.print(t3add);Serial.write(32);

35

  Serial.print(t2add);Serial.write(32);

36

  Serial.print(t1add);Serial.write(32);

37

  Serial.print(t0add);Serial.write(32);

38

  while(1){

39

    cli();if(t3.ub[3]&128)PORTB|=32;else PORTB&=~32;sei();

40

    cli();if(t2.ub[3]&128)PORTB|=16;else PORTB&=~16;sei();cnt++;

41

    cli();if(t1.ub[3]&128)PORTB|= 8;else PORTB&=~ 8;sei();

42

    cli();if(t0.ub[3]&128)PORTB|= 4;else PORTB&=~ 4;sei();

43

    if(cnt>65000){cnt=0;Serial.write('.');

44

//  t3add+=round(4.0*kon);if(t3add>round(128*kon)){

45

    t3add*=1.059463;if(t3add>round(440*kon)){

46

      t3add=round(220.0*kon);if(t2add>round(10.0*kon)){

47

        t2add-=round(1.5*kon);t1add+=round(1.5*kon);

48

        t0add+=round(2.0*kon);}}}

49

    } //while(1)

50

  } //main

Peter D. schrieb:
> Eine Sequenz sei(); cli(); ist wirkungslos, da nach dem SEI noch einen
> Befehl lang alle Interrupts gesperrt sind, ein CLI aber sofort greift.

"Again what learned" hätt' da Loddar g'sacht, gell ....

Einfach das Programm kopieren (Strg+C) und in die Arduino-IDE pasten 
(Strg+V).
Braucht kein Framework, also setup() und loop() sind überflüssig.
Strg+U und los geht's
CPU-Auslastung ist messbar mit
  DDRB = 32+16+8+4+2+1;PORTB = 0xFE;
und
ISR(TIMER1_OVF_vect){
  PINB=1;t0.ul+=t0add;t1.ul+=t1add;t2.ul+=t2add;t3.ul+=t3add;PINB=1;}
ergibt bei mir 1,1V am Anschluss 8, d.h. nur 22% Auslastung.
Man könnte mit der IRQ-Frequenz noch höher gehen.
Ich habe den Teiler testweise mit 256 (31250 Hz @ 16MHz) gemacht, d.h. 
man könnte auch einen 8-bit-Timer (Timer2) verwenden.

Die Frequenzauflösung ist jenseits von Gut und Böse: 7,27368 µHz
Der Frequenzbereich ebenfalls, 1kHz ist kein Problem, jittert aber schon 
merklich.
Wichtig ist, dass die 4 Kanäle phasenstarr miteinander verbunden sind.
Nebenbei, es ist schon interessant, welche Anwendung (4-Zylinder-Motor) 
hier ohne jeglichen Hintergrund vermutet wird.
Der Threadopener könnte ja mal etwas zur Anwendung sagen, vielleicht ist 
es ja auch ganz was anderes.

> Eine Sequenz sei(); cli(); ist wirkungslos,
Stimmt, daher habe ich den cnt++ dazwischen reingesetzt, nachdem ich 
mich am Anfang des Programmierens (als die cnt-Geschichte noch nicht 
dastand) wunderte, dass plötzlich gar nichts mehr ging.
Also kann man die CPU-Last und den Jitter noch um ein paar Promille 
reduzieren:

1

    cli();if(t3.ub[3]&128)PORTB|=32;else PORTB&=~32;

2

          if(t2.ub[3]&128)PORTB|=16;else PORTB&=~16;sei();cnt++;

3

    cli();if(t1.ub[3]&128)PORTB|= 8;else PORTB&=~ 8;

4

          if(t0.ub[3]&128)PORTB|= 4;else PORTB&=~ 4;sei();

5

    if(cnt>65000){cnt=0;Serial.write('.');

oder

1

    cli();if(t3.ub[3]&128)PORTB|=32;else PORTB&=~32;

2

          if(t2.ub[3]&128)PORTB|=16;else PORTB&=~16;

3

          if(t1.ub[3]&128)PORTB|= 8;else PORTB&=~ 8;

4

          if(t0.ub[3]&128)PORTB|= 4;else PORTB&=~ 4;sei();

5

    if(++cnt>65000){cnt=0;Serial.write('.');

Veit D. schrieb:
> sollte das nicht 16000000UL lauten?

Wer Quelltext-Kommentare lesen und verstehen kann ist klar im Vorteil.

// F_CPU is the frequency of MY arduino uno, change this number for YOUR 
board

Das liegt an der ... timerone-Lib (timerone.h). Die glaubt nämlich, wenn 
ich eine Quarzfrequenz geringfügig kleiner als 16MHz eingebe, der Quarz 
hätte 14MHz und berechnet dann alle Faktoren falsch.
Schuld ist diese Zeile:
const unsigned long cycles = (F_CPU / 2000000) * microseconds;

Fällt natürlich nicht auf, da so gut wie immer 16MHz verwendet wird.
Ich will aber wirklich die vorhandene Oszillator-Frequenz eingeben 
können, damit auch die richtige Frequenzen an den 4 Ausgängen 
herauskommen.

Daher hatte ich zuerst die Lib lokal geändert, hat auch funktioniert.
const unsigned long cycles = round(F_CPU / 2000000.0 * microseconds);

Dann kam mir aber die Idee, dass ich das Dilemma umgehen kann, wenn ich 
die Frequenz in Float (xx.0) angebe, die Lib gezwungen ist, alle 
Folgeberechnungen in Float und damit richtig (ohne Abschneiden der 
Nachkommastellen) zu berechnen.

Diese Berechnungen finden nicht auf dem UNO, sondern zur Compilezeit im 
PC statt, da es sich um Konstanten handelt.

Daher verwenden die späteren Versionen die Lib gar nicht mehr, auch weil 
über den Umweg, die Ticks über ganzzahlige Mikrosekunden zu berechen, 
Genauigkeit verloren geht.

Hat schon jemand das Programm getestet?
Insgesamt bin ich schon froh, soetwas in C programmieren zu können, auf 
der anderen Seite habe ich das Assembler-Listing angesehen und bin 
erschrocken, wie ineffektiv (teilweise!) der Compiler das übersetzt. Da 
kann ich jeden Asm-Fan (und c-hater ;-) verstehen. In der ISR werden 10 
Register (+Statusregister) auf dem Stack gesichert und dann wieder 
zurückgeholt, nur weil der Compiler zu doof ist, alle 4 Bytes der 
32-bit-Variablen mit einem Register zu addieren.  Oh oh.
So könnte man die ISR statt in 8µs leicht in unter 7µs erledigen.
Bei 32µs Zykluszeit eine Einsparung von 14%, die man besser in eine 
höhere Abtastrate stecken könnte.

Bei den heutigen Preisen von 32bit-Hardware sollte man sich eigentlich 
nicht mehr mit dem umständlichen 8bit-Kram abgeben. Aber er liegt 
überall herum...

Thomas G. schrieb:

> Die Spekulationen sind sehr interessant, aber einen Motor möchte ich
> hier nicht betreiben. Es bleibt ein normales Stroboskop, das die
> Frequenzen genauestens einhalten soll.

Kommt mir sehr komisch vor. Mir fällt nämlich keine Anwendung für ein 
solches Stroboskop ein.

> Vorhin habe ich noch kurz die Specs vom Arduino mit dem
> raspberry pi Pico verglichen - der ist dem Uno ja haushoch überlegen.

Ach echt?
16MHz vs. 125Mhz, 2kB RAM vs. 264kB RAM, 1x 8Bit-Core vs. 2x 32Bit-Core 
(+8 PIO-Statemachines & DMA-Fähigkeit).

Also wen da eine gewisse Überlegenheit überrascht... Tss...

> An
> sich müsste der Arduino mit seinen 16MHz doch trotzdem meinen
> Anforderungen gerecht werden oder bin ich da zu grün hinter den Ohren?

Ja und ja. Genau das ist das Problem: die Hardware des UNO könnte noch 
relativ problemlos leisten, was du willst. Du musst nur das 
Arduino-Geraffel weglassen und anfangen, Datenblätter zu lesen und 
richtig zu programmieren.

MisterX schrieb:

1

> if(t3.ub[3]&128)PORTB|=32;else PORTB&=~32;

2

> if(t2.ub[3]&128)PORTB|=16;else PORTB&=~16;

3

> if(t1.ub[3]&128)PORTB|= 8;else PORTB&=~ 8;

4

> if(t0.ub[3]&128)PORTB|= 4;else PORTB&=~ 4;

>
> ... auf der anderen Seite habe ich das Assembler-Listing angesehen
> und bin erschrocken, wie ineffektiv (teilweise!) der Compiler das
> übersetzt

Mach's halt so:

1

    PORTB = __builtin_avr_insert_bits(0xff7fffff, t3.ub[3],

2

            __builtin_avr_insert_bits(0xfff7ffff, t2.ub[3],

3

            __builtin_avr_insert_bits(0xffff7fff, t1.ub[3],

4

            __builtin_avr_insert_bits(0xfffff7ff, t0.ub[3], PORTB))));

Der dafür erzeugte Assemblercode:

1

        in r24,0x5

2

        lds r25,t0+3

3

        bst r25,7

4

        bld r24,2

5

        lds r25,t1+3

6

        bst r25,7

7

        bld r24,3

8

        lds r25,t2+3

9

        bst r25,7

10

        bld r24,4

11

        lds r25,t3+3

12

        bst r25,7

13

        bld r24,5

14

        out 0x5,r24

MisterX schrieb:> if(t3.ub[3]&128)PORTB|=32;else PORTB&=~32;
> if(t2.ub[3]&128)PORTB|=16;else PORTB&=~16;
> if(t1.ub[3]&128)PORTB|= 8;else PORTB&=~ 8;
> if(t0.ub[3]&128)PORTB|= 4;else PORTB&=~ 4;

Die Abfragenn können nie wahr werden, weil die "interessanten" Bits 
ausmaksiert werden.

>> An
>> sich müsste der Arduino mit seinen 16MHz doch trotzdem meinen
>> Anforderungen gerecht werden oder bin ich da zu grün hinter den Ohren?

c-hater schrieb:
>Ja und ja. Genau das ist das Problem: die Hardware des UNO könnte noch
>relativ problemlos leisten, was du willst. Du musst nur das
>Arduino-Geraffel weglassen und anfangen, Datenblätter zu lesen und
>richtig zu programmieren.

Nö, muss er nicht. Das hängt alles von der Fähgikeiten ab, mit C umgehen 
zu können. Ich vermute, dir fehlt da ein wenig die notwendige Erfahrung.

Gerd schrieb:

> Nö, muss er nicht. Das hängt alles von der Fähgikeiten ab, mit C umgehen
> zu können.

Na das ist ja mal spannend. Was kann C, was es möglich machen könnte, 
die Hardware für eine gegebene Anwendung optimal zu nutzen, ohne sie im 
Detail zu kennen?

Also, ich kenne diesen C-Dreck seit nunmehr 40 Jahren, aber eine 
derartige Fähigkeit ist mir in der gesamten Zeit NIEMALS aufgefallen.

Was mir allerdings nur zu oft aufgefallen ist: Wenn man C benutzt, hat 
man bei der optimalen Nutzung einer gegebenen Hardware immer wieder mit 
Restriktionen zu kämpfen, die es ohne C schlicht nicht gäbe.

c-hater schrieb:
> diesen C-Dreck

Die alte Leier, wir können es nicht mehr hören.

Wenn jemand diese Aufgabe nicht lösen kann, dann liegt es ganz sicher 
nicht an C. Wenn du das nur in Assembler hin bekommst, dann hast du 
ein ernsthaftes Problem.

Der einzige, der gegen C kämpft bist du. Alle anderen arbeiten damit, 
oder mit etwas anderem. Diese Spinnerei von dir wird von Monat zu Monat 
schlimmer.

Stefan ⛄ F. schrieb:

> Wenn jemand diese Aufgabe nicht lösen kann, dann liegt es ganz sicher
> nicht an C.

Im konkreten Fall nicht, da gebe ich dir vollkommen Recht.

Allerdings: ICH habe auch zu keinem Zeitpunkt behauptet, das hier C 
das Problem wäre... Wenn du auch nur LESEN könntest, wäre dir das 
klar. Aber: kannst du offensichtlich nicht. Nichtmal das...

c-hater schrieb:
> ICH habe auch zu keinem Zeitpunkt behauptet, das hier C
> das Problem wäre...

Du hättest Politiker werden sollen.

>  von foobar (Gast)  31.05.2022 18:33
VIELEN Dank, dass Du Dich da reingefuxt hast!
Hab es gleich implementiert. Funktioniert!
20 Bytes kürzer und schneller. Man muss nur die richtigen Tricks kennen.
Wie erzeugst Du das ASM-Listing?
ich mache es mit
"c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\bin\objdump.exe" 
-d -S genaueFreq.ino.elf  >genFre.lst
schaut aber nicht so schön aus wie Deines

Damit das elf-File erhalten bleibt, muss man in
C:\Users\xxx\AppData\Local\Arduino15\preferences.txt
einen Eintrag ähnlich save-temps ?? oder keep-temps ?? machen, müßte ich 
nachschauen.

So lernt jeder vom anderen.  Geben und nehmen.  Nur so funktioniert es.
Deshalb habe ich diesen Code entwickelt und veröffentlicht.

> von STK500-Besitzer (Gast)  31.05.2022 18:42
> Die Abfragenn können nie wahr werden, weil die "interessanten"
> Bits ausmaksiert werden.
?!?
Es gibt pro Zeile ein interessantes Bit, und das ist bit7 (MSB) des 
höchstwertigen Bytes byte3 des jeweiligen Phasenakkumulators t_.
(ich hätte ihn anderes benennen sollen, pa_ oder a_).
Und das wird nicht ausmaskiert, sondern ausgewertet.

> Wie erzeugst Du das ASM-Listing?

Einfach mit gcc -S:

1

  agcc -Os -S foo.c && less foo.s

Kannst auch noch ein -fverbose-asm dazupacken.

MisterX schrieb:
> So lernt jeder vom anderen.  Geben und nehmen.  Nur so funktioniert es.
> Deshalb habe ich diesen Code entwickelt und veröffentlicht.

Schön, daß Du es gemacht hast. Es ist aber auch eine "selektive" Lösung, 
da das Tastverhältnis nicht auf kurzen Blitz einstellbar ist. Das ist 
für ein Stroboskop unabdingbar.
Es wird auch dadurch nicht besser, daß einige Anwender durch 
Umdefinition der Anforderungen eine nachlässige Lösung als ausreichend 
anbieten.

Thomas G. schrieb:
> Vorhin habe ich noch kurz die Specs vom Arduino mit dem
> raspberry pi Pico verglichen - der ist dem Uno ja haushoch überlegen.

Als Anfänger solltest Du die Finger von dem Pico lassen, wenn Du schon 
Probleme mit einem AVR8 hast.

MisterX schrieb:
> Es gibt pro Zeile ein interessantes Bit, und das ist bit7 (MSB) des
> höchstwertigen Bytes byte3 des jeweiligen Phasenakkumulators t_.
> (ich hätte ihn anderes benennen sollen, pa_ oder a_).
> Und das wird nicht ausmaskiert, sondern ausgewertet.

Mein Fehler.
Aber: Leerzeichen, Tabulatoren und Absätze erhöhen die Lesbarkeit.
Ansonsten könnte man in diesem Fall auch statt einer if-Abfrage "?:" 
verwenden.

m.n. schrieb:
> Als Anfänger solltest Du die Finger von dem Pico lassen, wenn Du schon
> Probleme mit einem AVR8 hast.

Da stimme ich zu…

… außer wenn er (als ausgewiesener Anfänger) ein microPython drauf 
schiebt.
(Tastendruck, UF2 drag'n'drop, fertig)

Dann hätte er (ein wenig Python Grundwissen vorausgesetzt) das Programm 
schon lange fertig, ohne Interrupts, Assembler, usw.
Denn ein ganzer Sack voller PWM-Slices (8) stehen zur Verfügung, müssen 
nur einmal initialisiert werden, dann läuft das Ding ganz ohne CPU 
Interaktion. Rein in Hardware. Der CPU-Kern muss nichts tun. (Der andere 
auch nicht.)

Gut, ein Nachteil wäre das er nun nicht nur vier sondern acht 
unabhängige Kanäle hätte.
Ein weiterer Nachteil, das Board ist mit sub-4€ preiswerter als so 
ziemlich alle Arduino Boards.

Decisions, decisions…

Norbert schrieb:
> Denn ein ganzer Sack voller PWM-Slices (8) stehen zur Verfügung, müssen
> nur einmal initialisiert werden, dann läuft das Ding ganz ohne CPU
> Interaktion. Rein in Hardware.

Das sagt sich immer so leicht und jedesmal, wenn ich den konkreten Code 
dazu sehen will, wird gekniffen ;-)
Da die PWM-Kanäle doch recht bescheidene Funktion bieten, wäre meine 
Lösung die Verwendung der PIOs, wenn man hohe Auflösung und lange Zeiten 
braucht. Aber, um eine SM ein Signal erzeugen zu lassen, muß man sich 
zunächst damit auskennen und die passenden x-/y-Register wohl per DMA 
nachladen.
Das wäre eine kurze, saubere Lösung und - wie gesagt - ein Selbstläufer, 
aber nichts für einen Anfänger.

Solange hier aber Zittersignale mit 50% Tastverhältnis als DIE Lösung 
gehandelt werden, muß man nicht einmal Code für die AVR-Timer andenken.

m.n. schrieb:
> Norbert schrieb:
>> Denn ein ganzer Sack voller PWM-Slices (8) stehen zur Verfügung, müssen
>> nur einmal initialisiert werden, dann läuft das Ding ganz ohne CPU
>> Interaktion. Rein in Hardware.
>
> Das sagt sich immer so leicht und jedesmal, wenn ich den konkreten Code
> dazu sehen will, wird gekniffen ;-)
> Da die PWM-Kanäle doch recht bescheidene Funktion bieten, wäre meine
> Lösung die Verwendung der PIOs, wenn man hohe Auflösung und lange Zeiten
> braucht. Aber, um eine SM ein Signal erzeugen zu lassen, muß man sich
> zunächst damit auskennen und die passenden x-/y-Register wohl per DMA
> nachladen.
> Das wäre eine kurze, saubere Lösung und - wie gesagt - ein Selbstläufer,
> aber nichts für einen Anfänger.
>
> Solange hier aber Zittersignale mit 50% Tastverhältnis als DIE Lösung
> gehandelt werden, muß man nicht einmal Code für die AVR-Timer andenken.

Nö, das sagt sich nicht leicht, das iss so.

1

#!/usr/bin/python3

2

3

from machine import Pin, PWM, mem32, freq

4

5

freq(16_000_000)

6

7

LED = Pin(25)

8

pwm = PWM(LED)  # Pin 25 ist auf Channel 4 B          

9

pwm.freq(10)            

10

pwm.duty_u16(2**15)     

11

# Nu blinkt's schon

12

13

# Bis hier alles einfach, ab hier wird's schrecklich kompliziert.

14

# Man muss nämlich ins Datenblatt schauen

15

16

divint = 0      # 1…255 teilt durch 1…255  0 teilt durch 256  

17

divfrac = 0     # 0…15 für 0/16 … 15/16

18

mem32[PWM_BASE + CH4_DIV] = (divint<<4) + divfrac

19

20

topvalue = 62500  # für 1Hz

21

mem32[PWM_BASE + CH4_TOP] = topvalue-1  # -1 Datenblatt lesen!

22

23

ccvalue = topvalue // 2  # 1:1 Taktverhältnis

24

mem32[PWM_BASE + CH4_CC] = topvalue << 16  # LED ist auf Channel B

Das ist jetzt völlig ohne Jitter, aber manche Frequenzen sind nicht 
präzise zu erreichen. Im genannten Frequenzbereich 1…30Hz liegen wir 
teilweise mehrere 10µHz daneben.

Wenn man nun den divfrac hinzunimmt, dann gibt es 16-fach feinere 
Auflösung, aber dafür extrem geringen Jitter im ns Bereich.

Gern geschehen. ;-)

Ups, Zeile 24 muss natürlich ccvalue schreiben!

Stefan ⛄ F. schrieb:
> Der einzige, der gegen C kämpft bist du. Alle anderen arbeiten damit,
> oder mit etwas anderem. Diese Spinnerei von dir wird von Monat zu Monat
> schlimmer.

Also, polemisiere du mal nicht gar so sehr. Dabei kommt schlußendlich 
nur eines heraus: daß du außer C nix anderes kannst und deshalb gegen 
alle Leute wetterst, die auch andere Programmiersprachen können.

Mal zur Sachlage: sogenannte 'höhere' Programiersprachen sind dazu da, 
daß man sich damit auf Dinge konzentrieren kann, die keinen Bezug zur 
verwendeten Hardware haben. Zum Beispiel wie man eine 
Fouriertransformation macht oder wie man eine Datenbank auswertet. Dabei 
bleiben selbstverständlich viele Möglichkeiten ungenutzt, die die 
verwendete Hardware bietet. Eben deshalb gibt es an vielen Stellen 
bessere Lösungen für bestimmte Details, als so etwas in einer 'höheren' 
Programmiersprache formulieren zu wollen. Ich geb dir mal ein simples 
Beispiel anhand eines Details bei der FFT: versuche mal, einen 8 
bittigen Index zu spiegeln, also Bit 7 mit Bit 0 tauschen, dann Bit 6 
mit Bit 1 und so weiter, bis alle Bits getauscht sind. Und das in C. 
Sowas in Assembler ist vergleichsweise elegant und braucht nur wenige 
Maschinenbefehle. Siehste.

Und nochwas: Man kann C auch nutzen und zugleich sich darüber klar sein, 
daß diese Programmiersprache eben nicht das Weltbeste ist, sondern 
allenfalls das einzige, wofür man einen passablen Compiler kriegt. Man 
braucht also kein C-Fan zu sein.

W.S.

m.n. schrieb:
> … wäre meine
> Lösung die Verwendung der PIOs, wenn man hohe Auflösung und lange Zeiten
> braucht. Aber, um eine SM ein Signal erzeugen zu lassen, muß man sich
> zunächst damit auskennen und die passenden x-/y-Register wohl per DMA
> nachladen.

Geht auch super, aber DMA ist nicht nötig. Nur FIFO.

Sinngemäß:

1

   Hat FIFO neuen Wert?

2

   Ja: Ins Y-Register damit

3

4

   Y nach X transferieren

5

   Schleife: Runterzählen bis 0

6

   Pin toggeln

7

8

   Y nach X transferieren

9

   Schleife: Runterzählen bis 0

10

   Pin toggeln

11

   Zurück auf Start (keine 4000€ einziehen)

Aber ich gebe dir Recht, PIO Programmierung ist nichts für Beginner.

Neues Problem erkannt:
acht Mal PWM und acht Mal PIO. Alle völlig unabhängig.

Jetzt müssen wir schon 16 Pins ackern lassen wo doch nur vier gefragt 
waren. ;-)

Sebastian W. schrieb:
> Schick!

Danke!
Geht natürlich auch noch schöner:

1

#!/usr/bin/python3

2

3

from machine import Pin, PWM, mem32, freq

4

5

class AdvancedPWM:

6

7

    # S.550 - 4.5.3. List of Registers

8

    PWM_BASE        = 0x40050000    # the PWM registers

9

    PWM_CH          = [ch*0x14 for ch in range(8)]  # Offsets for each channel

10

    PWM_CSR         = 0x00          # Control and status register

11

    PWM_DIV         = 0x04          # INT(0…255) and FRAC(0…15) form a fixed-point fractional number.

12

    PWM_CTR         = 0x08          # Direct access to the PWM counter

13

    PWM_CC          = 0x0c          # Counter compare values

14

    PWM_TOP         = 0x10          # Counter wrap value

15

    PWM_EN          = 0xa0          # PWM Enable Register

16

17

    def __init__(self, pinnum):

18

        assert type(pinnum) == int and 0 <= pinnum <= 29

19

        self.pin = Pin(pinnum)

20

        self.channel, self.channelshift = divmod(divmod(pinnum,16)[1], 2)

21

        self.channelshift = int(self.channelshift * 16)

22

        self.regbase = self.PWM_BASE + self.PWM_CH[self.channel]

23

        self.pwm = PWM(self.pin)

24

        self.pwm.freq(10)

25

        self.pwm.duty_u16(0) # Aus

26

27

    def set_div(self, divint, divfrac=0):

28

        assert type(divint) == int and 0 <= divint <= 65535

29

        assert type(divfrac) == int and 0 <= divfrac <= 15

30

        mem32[self.regbase + self.PWM_DIV] = (divint<<4) + divfrac

31

32

    def set_top(self, top):

33

        assert type(top) == int and 0 <= top <= 65535

34

        mem32[self.regbase + self.PWM_TOP] = top-1  # -1 Datenblatt lesen!

35

36

    def set_cc(self, cc):

37

        assert type(cc) == int and 0 <= cc <= 65535

38

        mem32[self.regbase + self.PWM_CC] = cc << self.channelshift

39

40

41

freq(16_000_000)

42

43

PinNum = 25  # GPIO der LED auf dem Raspberry Pi pico board

44

advPwm = AdvancedPWM(PinNum)

45

advPwm.set_div(0)  # oder (0,0)

46

advPwm.set_top(62500)

47

advPwm.set_cc(62500 // 2)

Und man kann's beliebig erweitern, beste Einstellungen für gegebene 
Frequenz berechnen, Abweichung berechnen, usw.