RP6 ArduIO Board - Software

[inka]

hi fabqu,

vielleicht habe ich was missverstanden, aber frage:

die multi IO hat doch einen stromsensor?

und die drehgeber sind doch an den rädern (im getriebe bei RP6)? Braucht man da nicht nur die pulse zu zählen?

[fabqu]

Beides richtig
aber der rp6 kann das ja auch alles alleine? Mit dieser h-brücke wirst du wegen der beschränkten bandbreite von 1000Hz nichts besseres hinbekommen als der rp6 es kann. Und die arduIO bietet ja nur diese... Sie sind wirklich nur für ohmsche lasten empfohlen, für (kleinere) motoren zwar auch nutzbar aber ich glaube nicht, dass es spaß macht damit

[TrainMen]

Hallo,
ich habe mir mal heute die Software angeguckt. Erst einmal vielen Dank an Dirk.
In der RP6Control_ArduIO_03.c geht es ja um die Mosfet SP8M3. Für mich sieht es so aus als wenn sich jetzt Motoren mit 10% drehen sollen.
Will ich aber nicht. Ich will von den 8 Kanälen erst einmal 2 nutzen um meine Verbraucher zu schalten. Wie mach ich das ?

Ist es nicht etwas unglücklich gewählt 2x die RP6_ArduIO.h zu benennen ? Sie stehen zwar in verschiedenen Verzeichnissen trotzdem kann es ja zu verwechselungen kommen.

Nachtrag:
ich habe da schon einiges gefunden
enableHB und enablePPWM_G, wäre aber schön wenn man mich an die Hand nimmt und es mir mit einem konkreten Beispiel zeigt.

[Dirk]

Hi TrainMen,

In der RP6Control_ArduIO_03.c geht es ja um die Mosfet SP8M3. Für mich sieht es so aus als wenn sich jetzt Motoren mit 10% drehen sollen.
Will ich aber nicht. Ich will von den 8 Kanälen erst einmal 2 nutzen um meine Verbraucher zu schalten. Wie mach ich das ?

Dafür gibt es z.B. die Funktion setArduIOPowerPWMs().

Ist es nicht etwas unglücklich gewählt 2x die RP6_ArduIO.h zu benennen ? Sie stehen zwar in verschiedenen Verzeichnissen trotzdem kann es ja zu verwechselungen kommen.

Auf meinem PC ist das Arduino-Verzeichnis völlig getrennt von den RP6 Examples/Libraries. Das geht auch gar nicht anders! Dadurch kommt es nicht zu Verwechselungen.

ich habe da schon einiges gefunden
enableHB und enablePPWM_G, wäre aber schön wenn man mich an die Hand nimmt und es mir mit einem konkreten Beispiel zeigt.

Die Befehle im Bereich // ArduIO Status ermöglichen es, die jeweiligen (Schreib-)Funktionen der Lib zu sperren.
Du brauchst sie normalerweise nicht, weil alle Schreibfunktionen standardmäßig EINgeschaltet sind. AUSNAHME: Alle H-Brücken-Befehle sind standardmäßig AUSgeschaltet, weil ihre Benutzung bei falscher Beschaltung die Platine zerstören kann.
Beispiele:
setArduIOPowerPWMs(0b00001010); ==> Schaltet Power PWM 2 und 4 EIN und alle anderen AUS.
dimArduIOPowerPWM(1, DUTY_50); ==> Setzt Power PWM 1 auf eine PWM von 50%
setArduIOPowerPWM2(1); ==> Schaltet Power PWM 2 EIN.

[HaWe]

auch wenn es jetzt ein Doppel-Post ist...

Bleibt die Frage der Programmierbarkeit mit Sketch
- hier meine ich...:
wie man die neuen Ports über die Programmierung des Arduino anspricht. Ideal wäre es, wenn die "remote"-Muxerpins mit Nummern angesprochen werden könnten z.B. ab 100 oder 128 aufwärts), die sich dann im Arduino-Sketch-Programm genauso verwalten lassen wir die lokalen Arduino-Pins.
Also z.B.:

uint8_t ISRab |= (digitalRead(2) << 1) | digitalRead(3); // liest die lokalen Dpins 2 und 3 für einen Motorencoder
// während
uint8_t ISRab |= (digitalRead(102) << 1) | digitalRead(103) // die 2. und 3. Dpins auf dem Muxer-Board liest.

Wie das ganze über I2C ausgeführt wird, müsste dann ein Wrap um eine I2C-Funktion leisten können.
Da das ganze zeitkritisch ist, müssten alle 24 DPins für Encoder (4 lokal, 8 auf dem Board) mindestens alle 250-500µs über IRQs (IRQ1 per DueTimer) ausgelesen werden können.

Denkst du, das Board bzw. der i2c-Bus für die ganzen Pins ist dazu schnell genug? Es sind zwar nur 4kHz für die Encoder-Pins. aber der ganze Rest an Daten hängt ja auch noch dran.

ps,
auch für alle übrigen pins wäre so eine remote-zu-lokal-Transcodierung ideal: alle lokalen inputs nummeriert wie gehabt, aber die auf dem Board ("remote") genau wie die lokalen zu handhaben - nur über eine Art Offset für das Muxer-Board.
lokal: pinMode(A0, OUTPUT); digitalWrite(A0, HIGH); int x=analogRead(A0);
Muxer: pinMode(A100, OUTPUT); digitalWrite(A100, HIGH); int x=analogRead(A100);


edit:
Möglicherweise über eine Routine (Endlos-loop als eigener Task per DueTimer.h und Scheduler.h), die einfach nur alle Werte zwischen Mux-Board unf Arduino so schnell wie möglich hin- und her schaufelt, und dann alle Mux-Sensor-Werte in globalen Variablen abspeichert (die dann ähnlichwie die lokalen gepollt werden können):
So ähnlich, wie ich es hier zwischen NXT und Mega gemacht habe, nur eben schneller, in Echtzeit:
http://www.mindstormsforum.de/viewto...&t=8302#p65015

[Dirk]

Hi HaWe,

schau mal da rein.
Da gibt es schon den Header der zukünftigen Arduino Lib für das ArduIO Board.
Du kannst an den (geplanten) Funktionsdeklarationen schon erkennen, wie die Portpins abgefragt oder als Ausgänge angesprochen werden sollen.

Bis zur fertigen Lib braucht es noch etwas Zeit.

[HaWe]

Änderungswunsch:
gerade für den Due ist es wichtig, die alten Variablen-Typen durch eindeutig definierte neue zu ersetzen:
also bitte
uint8_t statt byte
und
int8_t stat char !

Ansonsten vllt doch eine überarbeitete API wie ich sie beschrieben habe für remote-zu-lokal ...?
Oder man schreibt für jeden existierenden digital/analog-Read- oder Write-befehl ein entsprechendes Pendant als remotedigital/ remoteanalog-Read/Write.

Macht die Sache 100000x einfacher!

edit: Das mit der Echtzeitfähig auch für IRQs ist allerdings Hauptbedingung für meine persönlichen Anwendungsbereich, denn es müssen die Encoder jederzeit fehlerfrei gelesen werden können, z.B. für ständig laufende exakte PID-Steuerungen und sonstige 1°-genaue Encoder-Messungen im 4kHz-Takt.