Timer Interrupt mit genau 10Hz. Welcher Timer? Preload?

Joachim B. schrieb:
> eben mit 8-bit nur indirekt !

Und was ist so schlimm dran, wenn auf einem µC irgendetwas mit 
Softwareunterstützung passiert?

p.s. Du plenkst

Studi schrieb:
> Nur jeden sechsten Interrupt zu verwenden scheidet ja aus, weil ich dann
> im Interrupt weniger Zeit habe, richtig?

Nein, das ist falsch. Im Prinzip hast Du endlos Zeit, bis diese vorbei 
ist.
Hier im Forum sind viele Beiträge, die sich genau mit diesem Thema 
beschäftigen. Es ist müßig, Alles zu wiederholen.

Danke schonmal für eure Antworten!

Weil jetzt hier oft der ctc Modus genannt wurde:
Was ist der Vorteil eines CTC Interrupts gegenüber einem overflow 
Interrupt bei dem der Timer vorgeladen wurde?


Karl Heinz schrieb:
> bei einem 8 Bit Timer der CTC kann (der Timer 0 vom Mega328 kann
> das)
> und 16Mhz müsste gehen:
>
> Vorteiler auf 64
> CTC Modus auf 250 Timerticks (OCR Wert also auf 249)
> In der ISR dann nur jeden 1000-ten Aufruf nehmen.

Dass das geht ist mir bewusst. Ich habe schon im Eingangspost gefragt, 
ob sowas möglich ist. Ich glaube nein, weil ich dann in der isr ja nur 
sehr wenig (1/100) Zeit habe.
Ist das so korrekt?

Karl Heinz schrieb:
> Wobei sich auch noch die Frage erhebt, was exakt unter 'genau' zu
> verstehen ist.
> Denn auch wenn auf dem Quarz 16Mhz draufsteht macht der nicht exakt
> 16000000.000000 Schwingungen in der Sekunde.

Ich sag mal zwischen 9.98 und 10.02Hz. Sollte locker machbar sein, oder?

Grüße!

m.n. schrieb:
> Studi schrieb:
>> Nur jeden sechsten Interrupt zu verwenden scheidet ja aus, weil ich dann
>> im Interrupt weniger Zeit habe, richtig?
>
> Nein, das ist falsch. Im Prinzip hast Du endlos Zeit, bis diese vorbei
> ist.

Jaja. Aber wenn der nächste Interrupt kommt, wird doch der vorherige 
"abgebrochen", weil ja dann der Counter um eins hochgezählt wird?!

Studi schrieb:
> Jaja. Aber wenn der nächste Interrupt kommt,

... ist der vorherige schon längst abgearbeitet, wenn man nicht gegen 
alle Regeln der "Programmierkunst" verstößt.

Joachim B. schrieb:
>> p.s. Du plenkst
> nö dito, der TO fragte nach 8-Bit Timer und als Antwort kommt bis 6xxx
> zählen, merkst du was ?

?
http://de.wikipedia.org/wiki/Plenk

Hi
Ich kenn dein Programm ja nicht, aber.. 16 MHz sind eine Taktzeit von 
62,5 ns. Im Datenblatt, da steht, wieviel Takte der Controller für die 
einzelnen Befehle braucht. Ich hab jetzt keine Lust, nachzusehen, aber 
angenommen, 2 Takte pro Befehl, das ist eine Befehlsverarbeitungszeit 
von 130 ns. Wenn du alle ms einen Interrupt hast, kannst du dazwischen 
locker 7000 Befehle abarbeiten. Wenn dein Programm nicht grad 
mathematische Kobeleien auflösen muss, dürftest du locker mit einem ms 
Interrupt und softwareprogrammierten Zeitflags alle Aufgaben ohne 
Probleme lösen.
Sicher, es gibt auch Programme mit langen Zykluszeiten, aber das sehe 
ich hier noch nicht.
Gruß oldmax

Joachim B. schrieb:
> Ich finde mit meinen alten Augen ein Leerzeichen vor ! oder ? besser
> erkennbar.

> Typografie hin oder her, nicht jede Regel -Plenk- ist sinnvoll.

Geht mir nicht anders - volle Zustimmung ;-)

Soo, ich melde mich auch mal wieder zu Wort!

Karl Heinz schrieb:
> Nur damit da mal die Relation siehst, wie schnell die Dinger eigentlich
> wirklich sind.

Mir ist klar, dass die Controller mit ihren 16MHz schon sehr schnell 
sind.
Allerdings habe ich gerne so viel Zeit wie möglich, da ich a) mit 
Gleitkommazahlen rechnen "muss" und b) meine Programmierung auch nicht 
die effizienteste sein dürfte.

Folgende Aufgaben müssen erledigt werden:
- Sensordaten via I2C einlesen
- Sensordaten verarbeiten (Offset rausrechnen, Filtern, Koordinatien 
verschieben/rotieren, evtl. speichern)
- Daten an den PC senden
- Daten auf einem Display ausgeben
- Eventuell noch auf Tasteneingaben warten

In der ISR möchte ich folgendes abarbeiten:
Sensordaten einlesen, dann verarbeiten und an den PC senden.

Aktualisierung des LCD passiert zwischen den Interrupts, die Framerate 
wird sich dann einstellen(wird sie das???).

=> Was meint ihr? Passt das Konzept so?


Thomas Eckmann schrieb:
> Dafür gibt es den CTC-Mode. Mit Prescaler 256 lässt du bis 6249 zählen,
> dann passt das genau.

Habe das jetzt mal probiert.
Timer1, Prescaler aber auf 64. So müsste doch die Auflösung höher sein 
und ich kann das mit dem Oszi genau kalibirieren. Bin jetzt bei 
10.001Hz. Passt sehr gut! Kann auch durch ändern von OCR1A auf 5Hz oder 
20Hz gehen. Auch gut!

Was mich aber stutzig macht:
in der iom328p.h ist der "TIMER1_COMPA_vect" Vektor Nummer 11.
Im Datenblatt zum 328 aber Vektor Nummer 12. (Seite 57).
Mit dem aus der iom328p.h funktionierts auf jeden Fall. Fehler im DB?

Grüße!

Rolf Magnus schrieb:
> Der wird jedoch beim Zeilenumbruch gerne vom Rest des Satzes abgerissen
> ! Und weil das irgendwie doof aussieht, gibt's diese Regel.
Full ACK, vor allem die zweite Zeile

Rolf Magnus schrieb:
> Der wird jedoch beim Zeilenumbruch gerne vom Rest des Satzes abgerissen
> ! Und weil das irgendwie doof aussieht, gibt's diese Regel.

Das ist doch wohl eher ein Problem des automatischen Zeilenumbruches.

Zwischen Zahlenwerten und Einheiten ist nach Norm sogar ein Leerzeichen 
vorgesehen und beide sollen nicht durch einen Zeilenumbruch getrennt 
werden. Trotzdem hackt der automatische Zeilenumbruch da gerne rein.

Text sollte lesbar sein.

Jörg Wunsch schrieb:
> ist auch seit geraumer Zeit ein Kraut gewachsen, das sich
> nichtumbrechendes Leerzeichen nennt

... und das gibt man hier im Forum wie ein?

F. Fo schrieb:
> Da ich das auch anfangs mal las, dass sie nicht genau sind, habe ich
> einige Quarze mal gemessen und alle waren genau 16MHz oder mein Ozi
> rundete das.

Dann musst du schon mal verraten, was "genau" genau heißt.

Beim gewöhnlichen Quartz für einen µC liegt die spezifizierte 
Genauigkeit irgendwo bei 30ppm, d.h. ein Quartz der bei 25°C irgendwo im 
Bereich 15.99952 ... 16.00048MHz schwingt, ist ok. Dazu kommt dann noch 
die Abweichung über den Arbeitstemperaturbereich, die dann noch mal 
ähnlich groß ist.

Und wie genau zeigt dein Oszi an und wie genau ist das kalibriert?

Oliver R. schrieb:
> F. Fo schrieb:
>> habe ich einige Quarze mal gemessen und alle waren genau 16MHz
>
> Dann laß diese Quarze doch mal eine Uhr steuern und sieh in drei Monaten
> nochmal nach. Dann versteht man warum es 2PPM Quarze und RTCs gibt.

Oh, das stimmt tatsächlich!
In einem halben Jahr ist meine Uhr um eine Stunde zu schnell gelaufen; 
die mußte ich jetzt zurückstellen ;-)

F. Fo schrieb:
> Da ich noch keine Uhr gebaut habe ... , ist mir auch noch
> keine Abweichung aufgefallen.

Nachmessen muss man schon vernünftig, um die Abweichung der Quarze zu 
sehen. Bauchgefühl versagt bei der Genauigkeit schnell.
Aber miss mal gegen ein 1pps-Signal vom GPS ...

Hi
Studi schrieb:
> Folgende Aufgaben müssen erledigt werden:
> - Sensordaten via I2C einlesen
> - Sensordaten verarbeiten (Offset rausrechnen, Filtern, Koordinatien
> verschieben/rotieren, evtl. speichern)
> - Daten an den PC senden
> - Daten auf einem Display ausgeben
> - Eventuell noch auf Tasteneingaben warten

Sensordaten einlesen, geht mit Pollen.
Sensordaten verarbeiten, wenn Änderung alt <> neu
Daten an PC senden ebenfalls wenn Änderung
Daten auf Display bei Änderung   ( so langsam wird's langweilig... )
Auf Tasteneingaben wartet kein Schwein, die pollt man. Na ja, es soll 
auch Systeme geben, da sind Tasteneingaben unbedingt mit einer ISR 
einzufangen... warum auch immer.
Da du in deinem Programm rechnest, nimmst du sicherlich eine 
Hochsprache. C oder BASCOM. Da kann ich mit Quälcode nicht aushelfen, 
aber mal so zum allgemeinen Verständnis: Warum so genaue Erfassung von 
Werten? Was steckt dahinter? Ist wirklich die Auflösung von Gleitpunkt 
erforderlich und werden die Werte durch die anschließenden 16Bit 
Auflösungen nicht wieder eingebügelt? Wie schnell müssen Änderungen 
erfasst werden?
Oftmals ist es gar nicht erforderlich, so wahnsinnig schnell und präzise 
zu sein. Das Prinzip einer guten Programmierung ist eben das Verteilen 
der Aufgaben, um eine ziemlich kurze Zykluszeit zu erhalten. So willst 
du 50 Werte aufarbeiten. Nun, bei kurzen Zyklen müssen nicht alle Werte 
in einer einzigen Schleife, sondern in 50 Schleifen jeweils einen Wert 
angefasst werden. Dann hast du auch kein Problem mit Eingaben von 
Tastern. Auch das Senden der Daten lässt eine Interruptroutine zu. So 
brauchst du nicht warten, bis ein Zeichen übertragen ist, das erledigt 
eine ISR, die sich dann das nächste Byte holt. Also, Zeit wird nicht nur 
von einer ISR verplempert oder von mathematischen Routinen, sondern auch 
von zuviel Erwartungen, ohne das ein Zwang dahinter steckt.
Gruß oldmax

oldmax schrieb:
> Sensordaten einlesen, geht mit Pollen.

Wehe, wenn er ein Pollen-Allergiker ist...
SCNR
;-)

Da hier oft gefordert wurde, was ich denn machen will:

Das ganze ist derzeit noch eine Konzeptstudie für mich selber. Ich 
möchte mit einem Gyroskop und Beschleunigungssensor ein 
"Inertialnavigationssystem" bauen. Erstmal ohne Zweck dahinter.

Ich möchte sehen, welcher Ansatz welches Ergebnis zur Folge hat und wie 
man das verbessern kann. Erster Ansatz ist die ganzen Beschleunigungen 
und Drehraten über die Zeit zu integrieren. Kommt mir bitte nicht mit 
Kalmanfilter, etc. das kommt später noch.

Dabei ist eine hohe Samplerate natürlich wichtig. Je schneller, desto 
besser.
Halbwegs gleichmäßig sollte das natürlich auch geschehen.
Auch denke ich, dass ich recht viel Rechenlast brauche, da ich ja die 
Drehraten und Beschleunigungen vom Körperfesten Koordinatensystem in das 
Weltfeste Koordinatensystem transformieren muss.

oldmax schrieb:
> Sensordaten einlesen, geht mit Pollen.

Nein, denke ich eben nicht. Siehe oben.

Ich kann aber die Sensordaten durch Pollen verarbeiten, sehe ich das 
richtig?

Die Daten vom Sensor werden im Array AccelGyro[6] gespeichert.

1

//Hauptschleife

2

while(1)

3

  {

4

5

    if (AccelDataAvl == 1)

6

    {

7

      AccelDataAvl = 0;

8

9

      for(int i = 0; i < 6; i++)

10

      {

11

        itoa(AccelGyro[i], buffer, 10);

12

        uart_puts(buffer);

13

        uart_puts("\n");

14

      }

15

    }

16

17

  }

18

19

//Interrupt Vektor

20

{

21

//Liest die Daten vom Sensor ein

22

  MPU6050_Update();

23

//Entfernt die Nullpunktverschiebug

24

  MPU6050_RemoveOffset();

25

26

  AccelDataAvl = 1;

27

}

Funktioniert aber so nicht.
Wird genau einmal ausgeführt, dann ist Schluss. Der Timer läuft aber, 
das sehe ich wenn ich in der ISR eine LED kurz ein- und wieder 
ausschalte.

Was mach ich falsch? Sollte eigentlich kein Ding sein, sowas zu machen 
;-)

Grüße!

OT: Was ich schade finde ist, dass hier mal wieder ein Thread mit 
unwichtigem, Offtopicem Müll (Diskussionen über Satzzeichen, Funktionen 
eines Webforums VS. Funktionen eines OS, Genauigkeit von Quarzen und 
deren Messbarkeit, ...) übernommen wird, das stört den Lesefluss extrem.
Dass sich die Moderation dabei beteiligt macht die Sache nicht besser.

Hi!

Jörg Wunsch schrieb:
> Nein, 0-basierte bzw. 1-basierte Zählweise.

Klingt logisch!

Jörg Wunsch schrieb:
> Klingt ja fast wie ein vergessenes volatile.

Klingt auch logisch! Läuft nun soweit, ich melde mich bei Fragen wieder 
;-)

F. Fo schrieb:
> Das willst du mit nem 328 machen?

Yessir! Zu wenig Dampf? Wollte den 328er hab ich halt mit der restlichen 
Hardware zu Hause.

Meinst du die Rechenpower reicht nicht? Ich werds probieren, wenns sein 
muss mit weniger Samplerate.

Eval Boards mit Infineon XMC4200 und STM32F0 liegen auch schon hier und 
warten auf das Testen, werde bei Gelegenheit mal evaluieren welches ich 
nehm.
Muss mich halt da komplett neu einarbeiten und wollte für erste 
Ergebnisse den Atmel nehmen. Den verwenden wir auch demnächst im 
Praktimum an der Uni, da weiss ich dann wahrscheinlich schon das meiste, 
aber was solls...

Danke schonmal, dass Ihr mir bis hier her geholfen habt und liebe Grüße!

F. Fo schrieb:
> Nein, die Rechenpower meinte ich noch nicht mal, obwohl ich glaube, dass
> es eng wird. Aber zumindest ein Dicovery Board hat einen
> Beschleunigungs- und Lagensensor schon drauf.
> Mit anderen Worten, da kannst du am Beispiel schon lernen, es ist
> kompakt und funktioniert auf jeden Fall.

Hmm, also das Discovery das ich habe, hat nur ein Gyroskop. Also nix 
Beschleunigungssensor.
Auch denke ich, dass der MPU6050 von Invensense besser ist, als die auf 
dem Discovery Board. Auf meinem Disco ist ein Beispielprogramm, wo man 
sieht, dass das Gyroskop stark driftet. Evtl. ist das nur eine Software 
Sache. Kann man bestimmt in den Griff bekommen, die Frage ist nur wie 
gut?!

Was genau meinst du mit Lagesensor?