Das wuerde ja eine Schaltung implizieren, die es erlaubt einander auschliessende Special Modes doch abwechselnd nutzen zu koennen.
Da hätte ich aber ein Beispiel: es gibt A/D-Wandler am SPI die bei gesetzten Chipselect und keinem SCK auf der MISO-Leitung signalisieren ab ihr Wandelzyklus abgeschlossen ist. Da das vom SPI-Standard abweicht wird es vom IOW nicht unterstützt, kann aber leicht durch disabeln vom SPI-Mode mit normale IO abgefragt werden.
Außerdem sind da noch die beiden Leitungen DRDY und /SS die man nicht umbedingt am SPI braucht, die aber blockert sind sind solange SPI enabled ist.
Da muss ich mir noch ein paar Gedanken machen wie das mit Pinbelegung und Pinfreigabe funktionieren soll.
Die Implikation ist das ein Special-Mode-Teilgeraet seine Pins erst beim Anschalten reserviert und beim Abschalten freigibt. Das wiederum bedeutet das unabhaengig davon ob das IO-Pins-Teilgeraet die Special-Mode-Pins reserviert hat oder nicht das Special-Mode-Teilgeraet vorhanden ist. Es laesst sich dann aber nicht aktivieren solange seine Pins vom IO-Pins-Teilgeraet reserviert sind. Das koennte sich aber mit einem "Aktivierbar"-Flag in der Device-Info erschlagen lassen.
Das IO-Pins-Teilgeraet braucht noch eine Reservierungsfunktion fuer Pins. Bei den Special-Mode-Teilgeraeten ist das ja implizit.
Jede Pin-Reservierung resultiert in einem ConfigChange-Event. Die Applikation des ausloesenden Teilgeraets wird dabei bevorzugt.
Auf diese Weise laesst sich dann der von Mike D genannte Fall handhaben.
IIC-Teilgeraet und IO-Pins-Teilgeraet reservieren abwechselnd die IIC-Pins.
So jetzt schmeisst mir die Einwaende an den Kopf :-)
Also diese nochmalige Zerlegung des IO-Pin-Gerätes in weitere Teilgeräte halte ich für ... na sagen wir mal, nicht so gelungen!
Jetzt denken wir mal an die Hardware-Hersteller!
Nehmen wir mal an ich habe mit viel Zeit und Geld ein Produkt entwickelt, das die nur IO-Pins auf Port 1 und IIC braucht.
Was mach ich jetzt in meiner Software wenn das IO-Pin Teilgerät per Callback vorbeikommt?
Belege ich nur die Pins auf Port 1 und stelle alle anderen IO-Pins an die Straße, damit sich irgendeine andere Applikation die der Kunde auch noch installiert hat, diese Pins unter den Nagel reißt? Sicher nicht!
Das gleiche gilt dann für alle SpecialMode-Teilgeräte an meinem Gerät. Auch die werde ich brav alle nacheinander einsammeln.
Und erst wenn ich wirklich alle Teilgeräte beisammen habe, kommt die Meldung : Das Geräte ist betriebsbereit und kann nun verwendet werden!
Auf keinen Fall werde ich irgendwas an meinem Gerät einer fremden PimpYourWarrior-Software überlassen.
Also folgendes muß möglich sein:
1. Durch Belegung aller Teilgeräte erhalte ich einen exklusiven Zugriff auf den IOWarrior.
2. Egal welche Konfiguration ich ab diesem Moment einstelle: kein anderes Programm hat Zugriff auf das Gerät bis ich es wieder freigebe.
Wenn die neue Library das nicht leisten kann ist sie lediglich für Hardware-Bastler mit eigenem Lötkolben brauchbar.
Das geht doch. Das Programm greift sich IO-Pins-Teilgeraet und IIC-Teilgeraet. Beim IO-Pins-Teilgeraet werden alle Pins bis auf die IIC-Pins belegt und das IIC-Teilgeraet wird aktiviert. Damit ist der ganze IO-Warrior sicher vor anderen Applikationen.
Es geht hier um solche Geraete wie das c't Maeusekino (http://www.includ.de). Dort wird der IIC, LCD und RC5 benutzt. Da kann man sich aber fuer zwei Benutzungsarten entscheiden. Alles in einem Programm oder RC5 in einem eigenen.
Das wichtigste an diesem Design ist alle Optionen fuer die Benutzung offenzuhalten und die Benutzung eines IO-Warriors durch mehrere Programme ist nun mal sinnvoll.
Robert Marquardt wrote:Das geht doch. Das Programm greift sich IO-Pins-Teilgeraet und IIC-Teilgeraet. Beim IO-Pins-Teilgeraet werden alle Pins bis auf die IIC-Pins belegt und das IIC-Teilgeraet wird aktiviert.
Das war Punkt 1.
Punkt 2, ich ändere in meiner Applikation die Konfiguration der IO-Pins (das SPI-Problem von oben z.B.), dann will ich aber auch sicher sein das mir kein anderes Programm an dieser Stelle einen IO-Pin klauen kann!
Ich möchte doch nicht nach jeder Änderung der Konfiguration testen müssen ob mein Gerät noch betriebsbereit ist.
Wenn das SPI-Teilgeraet deaktiviert wird (es ist dann ja immer noch belegt), dann geht der ConfigChange zuerst an das von der Applikation belegte IO-Pins-Teilgeraet, das sich die freigewordenen Pins nun greifen kann.
Bei der Rueckschaltung geht der DeviceChange zuerst an das SPI-Teilgeraet der Applikation das sich nun postwendend aktiviert und damit die Pins wieder reserviert.
Duch die Bevorzugung der in der gleichen Applikation benutzten Teilgeraete kann man daher die Pins immer reserviert halten.
Letztlich ist aber ein so komplizierter Fall recht unwahrscheinlich.
Sind die Pins nicht verdrahtet, so ist es auch egal ob ein anderes Programm sie benutzt oder nicht.
man hat schon lange nix mehr von der API 2.0 gehört. Als realistisches Ziel war ja mal Ende April anvisiert worden. Nu ist ja schon Juni. Ist das Projekt gestorben, auf Eis gelegt oder einfach noch nicht reif genug.
Gibt es vielleicht einen neuen Richttermin?