Hi! Ich will mit einem ATMega 328P 10mal pro Sekunde einen Timer Interrupt auslösen um so regelmäßig Daten einzulesen. Ich hab ja zwei Timer zur Verfügung: 8bit und 16bit. Soweit ich das richtig verstanden habe, kann das mit dem 8bit Timer bei 16MHz auch bei größtem Prescaler (1024) garnicht funktionieren(?): 16MHz/(1024*2^8) = 61 Interrupts pro Sekunde. Nur jeden sechsten Interrupt zu verwenden scheidet ja aus, weil ich dann im Interrupt weniger Zeit habe, richtig? Ausserdem kackt die Genauigkeit ab. Also verwende ich den 16bit Timer mit Prescaler 64: 16MHz/(64*2^16) = 3,8 Interrupts pro Sekunde. Dies ist zwar zu langsam, sollte aber mit einem Preload von 40536 genau passen: 16MHz/(64(2^16-40536)) = 10 Interrupts pro Sekunde. Stimmt das alles so? Ich habe das Vorladen eines Timers noch nie gemacht, ich werde mir diesbezüglich mal das Datenblatt ansehen. Was noch wichtig wäre, ist dass der Jiter der Zeitabstände zwischen den Interrupts möglichst klein ist. Aber das ist ja gegeben, oder? Jetzt ist meine Frage folgende: Kann man das nicht doch auch mit dem 8bit Timer lösen? Wäre mir eigentlich lieber, da das einfach einfacher ist. ;-) Evtl. braucht man den 16bit Timer ja auch für was anderes... Grüße!
Studi schrieb: > Stimmt das alles so? Ich habe das Vorladen eines Timers noch nie > gemacht, Dann fang da auch gar nicht erst mit an. Dafür gibt es den CTC-Mode. Mit Prescaler 256 lässt du bis 6249 zählen, dann passt das genau. mfg.
Studi schrieb: > Jetzt ist meine Frage folgende: Kann man das nicht doch auch mit dem > 8bit Timer lösen? Wäre mir eigentlich lieber, da das einfach einfacher > ist. ;-) Thomas Eckmann schrieb: > Mit Prescaler 256 lässt du bis 6249 zählen, wie passt das mit 8-Bit Timer ?
Joachim B. schrieb: > wie passt das mit 8-Bit Timer ? Das ist natürlich mit 16 Bit. 8-Bit Timer geht nur mit Softwareunterstützung. mfg.
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.
Thomas Eckmann schrieb: > Das ist natürlich mit 16 Bit. 8-Bit Timer geht nur mit > Softwareunterstützung. eben mit 8-bit nur indirekt !
1 | ISR(COMPA_VECT) |
2 | {
|
3 | if(teiler) |
4 | teiler--; |
5 | else
|
6 | {
|
7 | teiler=TEILER; count++; |
8 | }
|
9 | }
|
:
Bearbeitet durch User
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.
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.
@ Karl Heinz (kbuchegg) (Moderator) >Wobei sich auch noch die Frage erhebt, was exakt unter 'genau' zu >verstehen ist. Sicher, aber man kann es ohne Problem so genau machen, dass nur noch der Fehler vom Quarz übrig bleibt.
@ Studi (Gast) >> 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", NEIN! >weil ja dann der Counter um eins hochgezählt wird?! Wieviel Jahre soll das Hochzählen einer Variablen bei dir dauern? Siehe Interrupt!
@ Studi (Gast) >Was ist der Vorteil eines CTC Interrupts gegenüber einem overflow >Interrupt bei dem der Timer vorgeladen wurde? CTC funktioniert OHNE jeglichen CPU-Eingriff auch bei vollem Zählertakt! Der Trick mit dem Vorladen ist aus der Jungsteinzeit und funktioniert nur dann, wenn der Zähler mit einem ausreichend großen Vorteiler (Prescaler) arbeitet, damit die CPU beim Interrupt genug Zeit hat, den Zähler neu vorzuladen, OHNE dass Zähltakte verloren gehen!
Mike schrieb: > Und was ist so schlimm dran, wenn auf einem µC irgendetwas mit > Softwareunterstützung passiert? nichts, ich nutze es ja > p.s. Du plenkst nö dito, der TO fragte nach 8-Bit Timer und als Antwort kommt bis 6xxx zählen, merkst du was ?
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
OK habe ich falsch verstanden. Ich finde mit meinen alten Augen ein Leerzeichen vor ! oder ? besser erkennbar. Ich habe noch kein UHD 30" Monitor, sorry Typografie hin oder her, nicht jede Regel -Plenk- ist sinnvoll. Ein <SPACE> kann es lesbarer machen und darum gehts doch ? oder
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
Studi schrieb: >> 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? Auch wenn es Oldmax schon von der anderen Seite herum aufgezogen hat: Mal ein bischen rechnen. Vorteiler von 64 bedeutet, dass 64 CPU Takte vergehen, bis der Timer um 1 hochzählt. Dieses Hochzählen macht der Timer 250 mal, bis es zum 'Überlauf' kommt. Wieviele CPU Takte sind das daher? Das sind 64*250 gleich 16-tausend CPU Takte. Pro Befehl braucht die CPU im Schnitt (kommt auf die exakten Befehle an, aber so überschlagsmässig) ca. 1.5 Takte. D.h. von einem derartigen Überlauf zum nächsten (der alle 16000 Takte passiert) arbeitet die CPU über den Daumen gepeilt 16000 / 1.5 gleich 10666 Befehle ab. Für das Laden eines Wertes aus einer Variablen, die 16 Bit Variable um 1 erhöhen und mit einem Grenzwert von 1000 vergleichen würde ich mal über den Daumen vielleicht 8 bis 10 Befehle ansetzen oder in Takten ausgedrückt vielleicht 15. Von mir aus sollen es 20 sein. Du hast 16000 Takte Zeit, bis der nächste Overflow kommt! Das ist noch nicht einmal annähernd knapp! Nur damit da mal die Relation siehst, wie schnell die Dinger eigentlich wirklich sind.
:
Bearbeitet durch User
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!
Studi 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. Um das nochmal anders zu rechnen: Wenn du 20 Taktzyklen brauchst und 16000 Taktzyklen Zeit hast, ergibt das eine Auslastung von 0,125%. Erst wenn der Rest mehr als 99,875% braucht, bekommst du ein Problem. Das hast du dann aber sowieso... > 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. Das alles in der ISR? Üblicherweise macht man das eher außerhalb. Joachim B. schrieb: > Ein <SPACE> kann es lesbarer machen und darum gehts doch ? oder Der wird jedoch beim Zeilenumbruch gerne vom Rest des Satzes abgerissen ! Und weil das irgendwie doof aussieht, gibt's diese Regel.
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
So etwas wie mehr 1 Byte an Daten einlesen oder auszugeben macht man besser nicht in einem Interrupt. Besonders das Einlesen hat oft keine definierte Zeit, und das Programm kann im Interrupt hängen bleiben. Der Timer interrupt könnte das Einlesen anstoßen, so dass ab dann im TWI Interrupt die Daten eingelesen werden, ggf. auch am Ende verarbeitet werden und dann die Ausgabe angestoßen wird. Die findet dann auch eher Byte für Byte in einem anderen Interrupt (z.B. UART) statt.
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.
Mike schrieb: > Text sollte lesbar sein. Richtig, und deshalb gehört vor ein Satzzeichen kein Leerraum. Seit ewigen Zeiten übrigens, das hat nichts mit Computern zu tun. Schnapp dir ein Buch deiner Wahl und schau rein: vor Punkt oder Komma steht kein Leerraum, nur danach. (Gegen den automatischen Umbruch zwischen Maßzahl und Maßeinheit ist auch seit geraumer Zeit ein Kraut gewachsen, das sich nichtumbrechendes Leerzeichen nennt, aber das ist 'ne andere Baustelle.)
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?
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. 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. Aber zum eigentlichen Problem mit dem Zähler. Letztlich ist es doch gleich, ob 8 oder 16 Bit, aber auch welcher Vorteiler (gut, nicht ganz, so ein krummer Wert wäre schon schlecht), denn in der ISR kann er sich das doch so zurecht schreiben, dass erst an der gewünschten Stelle was passiert.
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?
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.
:
Bearbeitet durch User
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 ;-)
Vermutlich, ich weiß es gerade nicht, werden auch weniger Stellen hintern Komma angezeigt und somit habe ich sicher nur die gerundeten Werte gesehen. Ist schon ca. 2 Jahre her und eigentlich auch heute egal. Hatte mich nur mal so am Rande interessiert. Da ich noch keine Uhr gebaut habe (habe ich auch nicht vor), nichts wirklich zeitkritisch bei mir bisher war, ist mir auch noch keine Abweichung aufgefallen.
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 ...
Mike schrieb: >> ist auch seit geraumer Zeit ein Kraut gewachsen, das sich >> nichtumbrechendes Leerzeichen nennt > > ... und das gibt man hier im Forum wie ein? Seit wann sind Eingabemethoden eine Funktion eines Webforums? Sowas sollte dein OS bereitstellen.
Studi schrieb: > 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? > Nein, das ist nicht gut soviel in der ISR zu tun. ISRs sollten so kurz wie nur möglich sein, alles was man asynchron tun kann sollte man auch in der "Hauptschleife" tun. Ansonsten läuft man in diverse Probleme wegen: ISR müssten sich gegenseitig unterbrechen (das sollte man besser nicht machen) oder eine ISR verhindert/verzögert einen anderen Int (schlecht). Sobald man dorthin kommt wird es ziemlich unschön und kompliziert. Deshalb: ISRs kurz und "Arbeit" in der Hauptschleife verrichten. Üblicherweise würdest Du die I2C-Daten dort einlesen, idealerweise Byte-weise mit Hardware-Unterstützung des uC und einem Puffer. Siehe: http://www.mikrocontroller.net/articles/AVR_TWI Damit läuft die I2C-Übertragung einfach im Hintergrund. Wenn dann Daten bereitstehen (eine bestimmte Menge Zeichen empfangen, auf die Du wartest) setzt Du Dir in der ISR ein Flag (byte-Variante auf 1 für "true"), z.B. "sensorDataReady", was weiss ich. Dieses Flag wird in der Hauptschleife abgefragt und dann entsprechend die Daten verarbeitet. Dort hast Du dann alle Zeit der Welt und die ISRs können munter weiter tickern ohne sich gegenseitig zu blockieren.
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: > sondern auch > von zuviel Erwartungen, ohne das ein Zwang dahinter steckt. Das ist wohl wahr. Liest man hier doch sehr oft. Wenn der Thread Starter dann endlich mal sagt was er machen will, relativieren sich oft die gehobenen Ansprüche.
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.
Studi schrieb: > 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? Nein, 0-basierte bzw. 1-basierte Zählweise. Studi schrieb: > Was mach ich falsch? Klingt ja fast wie ein vergessenes volatile. Aber dafür zeigst du uns wohl zu wenig deines Codes (bzw. nicht die wichtigen Stellen).
Studi schrieb: > as 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. Das willst du mit nem 328 machen? Ich propagiere ja nie die ST Boards und nehme den kleinsten µC, wenn es geht, aber hier würde ich doch mal so ein Dicovery Board anraten, Da ist das alles schon drauf und die kosten nix.
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!
Studi schrieb: > Meinst du die Rechenpower reicht nicht? Ich werds probieren, wenns sein > muss mit weniger Samplerate. 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.
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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.