Hallo Leute,
ich hab ein Problem in einer Anwendung, wo sich 1Wire und V-USB in die
Quere kommen. 1Wire blockiert Interrupts für sein nötiges Timing. Das
führt dann dazu, dass manchmal USB-Anfragen vom PC kommend übersehen
werden (Vermutung).
Ich habe mir folgenden Lösungsansatz überlegt: cli/sei bei 1Wire
entfernen. Dafür muss der USB-Interrupt ein globales "Interrupt
detected" Flag setzen. 1Wire fragt dieses Flag ab und startet seine
letzte Aktion ggf. neu.
Da ich mich nicht zuviel in den Untiefen von V-USB bewegen will, würde
ich gerne den INT0 verbiegen auf eine Funktion, die das detected-Flag
setzt und dann erst zur USB-Interruptroutine weiter springt.
Was hält ihr von dieser Idee? Geht das vielleicht auch einfacher und ich
seh den Wald vor lauter Bäumen nicht?
Falls das so sinnvoll ist - ich bewege mich noch halbwegs in
"normalem" C-Code. Dieser Ansatz birgt für mich noch recht viel Voodoo
und ich komme nicht recht weiter. Ersuche um Anregungen.
Was ich schon probiert habe:
void (* int0_isr)(void);
uint16_t *int0_addr;
void int0_proceed(void){
int0_isr();
}
void INT0_detection_init(void){
int0_addr = 0x0002;
int0_isr = *int0_addr;
*int0_addr = &int0_proceed;
}
Aber an 0x0002 steht ja nicht nur die Adresse, sondern auch der Sprung
drinnen, aber da geht es schon in Richtung Assembler und da bin ich noch
ziemlich unbedarft... Und vielleicht ist es ja auch komplett der falsche
Ansatz.
@Peter Z. (peterz1972) >ich hab ein Problem in einer Anwendung, wo sich 1Wire und V-USB in die >Quere kommen. 1Wire blockiert Interrupts für sein nötiges Timing. Das >führt dann dazu, dass manchmal USB-Anfragen vom PC kommend übersehen >werden (Vermutung). Nimm den UART für Onewire, dann braucht man keine Interruptsperre. Beitrag "Re: Onewire + DS18x20 Library"
> Nimm den UART für Onewire, dann braucht man keine Interruptsperre.
Hm... Interessant. Braucht aber zusätzliche Hardware. Ich will mit
diesem Projekt nicht mehr zurück in die Bastelstube. Eine SW-Lösung wäre
mir lieber.
Peter Z. schrieb: > Eine SW-Lösung wäre > mir lieber. Gibts aber nicht. Du hast Dir einen ungeeigneten µC ausgesucht. Bei µC mit Hardware-USB ist der USB Teil lange nicht so zeitkritisch wie bei VUSB, wo in Software die Pins zu sehr exakten Zeitpunkten geändert oder ausgelesen werden müssen. Daher auch die Interrupt Sperre.
Jim M. schrieb: > Peter Z. schrieb: >> Eine SW-Lösung wäre >> mir lieber. > > Gibts aber nicht. Du hast Dir einen ungeeigneten µC ausgesucht. > > Bei µC mit Hardware-USB ist der USB Teil lange nicht so zeitkritisch wie > bei VUSB, wo in Software die Pins zu sehr exakten Zeitpunkten geändert > oder ausgelesen werden müssen. Daher auch die Interrupt Sperre. Gibts nicht gibts nicht. Mittels eines Interrupt verbiegenden Hook müsste es gehen, siehe oben. Dazu fehlt mir aber das Know-How und ich hoffe auf die Unterstützung des Forums. Derzeit baue ich eine andere Alternative mittels Timer, der mitläuft und anhand dem man erkennen kann, ob ein Interrupt drein gefahren ist. Aber natürlich lässt sich mit besserer Hardware vieles besser lösen. Das war aber nicht die Intention meiner Frage.
Gast
#4849777
>führt dann dazu, dass manchmal USB-Anfragen vom PC kommend übersehen >werden (Vermutung). Wie kommst du zu dieser Vermutung? Und selbst wenn wird der PC wohl eine Antwort erwarten. Wenn er sie nicht bekommt fragt er halt noch mal. Das dürfte ziemlich Banane sein ob der 1Wire 2s später gelesen wird. >Was hält ihr von dieser Idee? Nichts.
Gast
#4850238
holger schrieb: > Wenn er sie nicht bekommt > fragt er halt noch mal. So funktioniert USB nicht. Nach den Spezifikationen muss der Client antworten. Und wenn es nur ein nak ist. Kann sein, dass der host-stack entsprechend Fehlertolerant ist, aber das bleibt Pfusch. Du wirst nicht drum herumkommen, die von vusb in Assembler geschriebene isr zu erweitern. Das einfachste wäre es wohl ein Register mit sbi\cbi zu setzen. Informationen über Assembler gibts im avr-tutorial. So schwer ist das nicht. Assembler ist deutlich einfacher als c. Wenn dein uC gpior-Register besitzt, würden sich diese anbieten.