PWM mit IO16

Ich würde gerne RGB-LED's mit dem IO16 Bricklet ansteuern. Um die Farben einzustellen benötige ich jedoch PWM Signale.

Nun die Frage:

Ist das System schnell genug um ein 100 Hz PWM Signal mit 8-Bit Auflösung zu erzeugen?

( d.h. max. 256 Zustandsänderungen in 10ms)

Oder anders gefragt: Wie oft kann "set_port_configuration" in 10ms aufgerufen werden?

Ich habe mir auch schon das Servo-Brick angeschaut. Allerdings brauche ich mindestens 12, später 24 PWM Signale und das wird mir mit Servo-Bricks zu teuer.

Das geht mit der IO16 leider definitiv nicht. Auf der IO16 ist ja ein I2C Port Expander drauf, d.h. jeder Befehl muss erst per I2C übertragen werden. Damit sind solche Frequenzen leider nicht zu erreichen.

Mit der IO4 sollte eine Änderung pro ms möglich sein (mehr ist mit USB nicht drin). Das reicht aber auch nicht für 256 Zustandsänderungen in 10ms.

wenn hier USB der größte Flaschenhalz ist währe es gut die MasterBrick firmware um die fähigkeit zu erweitern die IOBricklets automatisch mit einer forgegebenen Frequenz anzusteuern. z.B. sage ich meinen MasterBrick

IO4 Port 0 output high;
wait 1ms;
IO4 Port 0 output low;
wait 1ms;
repeat -1; # immer weiter dammmit bis ich anweisungsausführung stopp sage...

und der macht das dann fröhlich ohne das noch daten über den USB-Bus fließen müssen bis ich stopp sage.

andersherum wäre es klasse wenn man automatisch vorgegebene Schemen erkennen und melden lassen könnte für die die pooling abfrage (von usb nicht von der high level api(usb unterstützt nur pooling wenn ich mich nicht irre))

define signal(01, 1000, array(1,0,0,0,1,1,0); #signalidetifikationsnummer (int), grundtackt mHz (int) (hier 1kHz), Array der Abfolge (bolean)
listen signals IO4 Port 0;

und er mir dann über USB nur zurück geben würde "Signal 01 beginnt" und "Signal 01 endet" oder so ähnlich...

eine andere Möglichkeit wäre auch die Signale zu cachen und dann wenn der usb bus frei ist zu übertragen.

würde die USB Schnittstelle um einiges entlasten.

nur ein paar Vorschläge für in weiter ferne liegende Erweiterungen der Brickfirmware und der API die einige Projekte dadurch realisierbar machbar werden ließen die jetzt wegen der geringen Abtastrate noch nicht möglich sind..

gruß

Das ist schwierig umzusetzen. Per USB kann ich mit maximal 1000 Nachrichten pro Sekunde rechnen und das System ist entsprechend darauf aufgebaut.

Zum Beispiel ruft unser interner Scheduler pro Bricklet Plugin nur 1x pro ms eine Task auf, wir können also auch nur 1x pro ms eine Zustandsänderung haben.

Auf den meisten Bricks sind für sowas auch keine PWM oder Timer Counter Hardware Einheiten mehr über.

Du musst bedenken das so ein Master Brick ja auch noch mit x Stack Teilnehmern und x Extension Slave Teilnehmern gleichzeitig sprechen können muss. Und die Treiber Bricks (Servo/Stepper/DC). Müssen ihre jeweilige Motoren steuern und Beschleunigungen/Debeschleunigungen etc. Berechnen.

eine andere Möglichkeit wäre auch die Signale zu cachen und dann wenn der usb bus frei ist zu übertragen.

Das tut brickd bereits.