Hi, für mein aktuelles Projekt habe ich mir den ATtiny45 ausgesucht. Benutzen möchte ich das USI-Interface als I2C-Slave und den 16-bit Timer als Zeitgeber für meine Software-PWM Routine. Meine PWM routine funktioniert prima bis jetzt, ich kann 3 unabhängige Kanäle ausgeben. Nun weis ich nur nicht wie ich das USI Interface integrieren soll, da das auch einen Interrupt auslöst, der mir aber in die PWM-Routine pfuscht. Hat jemand von euch 'ne Idee oder eine generelle Software-Design-Routine für solche Fälle?
Gast
#352016
Wie wäre es wenn du global alle Interrupts sofort sperrst? Hat der AVR prioritäten? Und ist es nicht eigentlich so, dass der AVR einen Interrupt nach dem anderen abarbeitet?
Gast
#352017
PS.: Am schluss der ISR musst du natürlich wieder alle Interrupts freigeben.
Hi Schoasch, kleiner Tip: Sobald eine ISR abgearbeitet wird ist das Global Interrupt Enable Flag deaktiviert, somit können keine anderen Interrupts den Programmablauf unterbrechen. Es wird am Schluss mit dem Befehl RETI automatisch wieder gesetzt. Prioritäten kennt der AVR. Nur sind die nicht selbst definierbar. Stimmt, die Interrupts werden einer nach dem anderen abgearbeitet. Nur ist das leider mein Problem. Beide Routinen die ich brauche sind Zeitkritisch. Was soviel bedeutet das die eine Routine nicht die andere behindern/unterbrechen sollte. Im Falle der I2C-Routine währe das keine Problem, es würde im schlimmsten Fall einfach kein ACK vom Slave gesendet. Bei der PWM Routine sieht das im wahrsten Sinne des Wortes schon anders aus. Man würde ein Flackern bemerken (Nicht so schön, da ich ein RGB Modul entwickle und somit unterschiedliche Farben aufflackern ;-)). Ich suche eigentlich einen Algorythmus wie etwa ein RTOS, der mit Zeitkritischen Anwendungen "harmoniert".
Prioritäten hat der AVR leider nicht, also ist es am saubersten die SW-PWM den einzigen Interrupt sein zu lassen. Mach doch das I2C einfach ohne Interrupt in der Main-Loop. I2C ist ja überhaupt nicht zeitkritisch, da der Slave den SCL low strecken kann. Der Master merkt das und macht erst weiter, wenn er wieder high sieht. Schau Dir mal irgendeine I2C-Beschreibung an, da steht das drin. Peter
Gast
#352020
Wieso machst du die RGB-LED-Ansteuerung nicht mit einem Externen Bauteil? Philips hat da ja jetzt ein neues Bauteil herausgebracht. täusche ich mich jetzt.. oder gibts nicht ein Flag, dass gesetzt wird wenn eine übertragung fertig ist?! Also das du die Daten in den Buffer schreibst. wartest bis das Flag gesetzt/gelöscht wurde und du dann weiter machst. Also das du dein Hardware-I2C-Modul benutzt ohne einen Interrupt zu verwenden.. oder geht das bei den AVRs nicht? mfg Schoasch PS.: Ich kenn mich mit AVRs nicht aus.. besser gesagt hab ich mit denen noch nicht wirklich beschäftigt.. somit weis ich auch nicht wie die bei einem Interrupt reagiere.. sorry ;-)
Ich frage mich eher, von was für Zeiten wir hier sprechen. Bis das Auge irgendwas als "Flackern" erkennt, hat der AVR schon etwa 100.000 Befehle abgearbeitet. Daher kann ich nicht so recht glauben, dass eine PWM-Routine zeitkritisch sein sollte.
Gast
#352022
@Peter sicher hat ein AVR Interrupt Prios z.B. in der Reihenfolge . Reset · Externer Interrupt 0 · Externer Interrupt 1 · Timer/Counter 1 Capture Ereignis · Timer/Counter 1 Compare Match
@Daniel, probiers mal aus, Jitter sind sehr deutlich zu erkennen, wenn es dunkel ist. 254/256 und 255/256 Leuchtdauer fallen keinem auf, der Unterschied zwischen 1/256 und 2/256 dagegen sehr wohl. Ich habe mich mal gewundert, warum im Dunkeln eine LED beim Reset immer kurz aufblitzte. Der Grund war, daß ich erst den Pin auf Ausgang gesetzt hatte und danach auf High. Nach dem Vertauschen der beiden Befehle war das Aufblitzen weg. Man kann also selbst 1µs Leuchtdauer gut erkennen. Peter
@Vext, das Thema hatten wir schon 1000 mal. Was Atmel da fälschlich als Priorität bezeichnet, ist nur die Annahmereihenfolge bei gleichzeitigem Auftreten. Mit Prioritäten (Interrupt hoher Priorität unterbricht alle Interrupts niederer Priorität) hat das auch nicht das geringste zu tun. Ich hatte mal ne niedrige Prioritätsstufe in Software mit Hilfe eines Timerinterrupts gemacht, funktionierte sogar. Ist aber doch mehr ein dirty hack. Peter
Gast
#352025
Hi, danke für eure Antworten. Hab mir das Datenblatt des ATtiny45 nochmal genau durchgelesen, besonders den USI-Teil ;-). Scheint wirklich nicht so zeitkritisch zu sein wie ich gedacht hatte. Das Interface macht vieles von allein, insbesondere die "Wait States" in denen der Master auf eine Antwort warten muss. In der Zeit kann ich dann zuverlässig meine PWM-Routine abarbeiten und nachher die Daten abholen. Bevor ich mir aber den Kopf über eine "Interruptfreie" USI-Routine zerbreche, wollte ich fragen ob jemand nicht zufällig schon so ein Rad erfunden hat? Wieso das Rad jedesmal neu erfinden?
@Flo_K "Bevor ich mir aber den Kopf über eine "Interruptfreie" USI-Routine zerbreche" Du hast ne USI-Interruptroutine und weißt nicht, wie Du sie im Main aufrufen sollst ? Das ist jetzt aber nicht Dein Ernst ? Einfach aufs Interruptbit pollen, wenn gesetzt löschen und Handler aufrufen. Peter
Gast
#352027
@PeDa Doch ist mein ernst ;-). Meine Routine ist eigentlich nicht meine, hab sie hier im Forum gefunden und in meine Firmware integriert. Mit all den Funktionen die ich nicht unbeding benötige (lesen vom Slave,...). Die Vorgehensweise mit dem pollen ist mir schon klar, aber bevor ich mich hinsetze und programmiere und debugge wollte ich nur mal fragen ob jemand vielleicht schon ein Stückchen allgemeinen Quellcode hat dessen Funktion bereits sichergestellt ist (Der Mensch ist ja bekanntlich von natur aus faul).
"Die Vorgehensweise mit dem pollen ist mir schon klar, aber bevor ich mich hinsetze und programmiere" Programmieren oder Rad neu erfinden, kann man eine solche Lappalie doch nicht nennen. Wie gesagt, Du kannst jeden Interrupthandler auch im Main zyklisch aufrufen (pollen). Du mußt nur noch das Testen des Interruptflags dazu "programmieren". Peter
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.