RP6 ArduIO Board - Software

Hi Besteller und Nutzer des RP6 ArduIO Boards von fabqu:

Zur aktuellen Stand der Hardware-Entwicklung gibt es hier noch diesen Thread von fabqu: I/O-, ADC- und DAC Erweiterung für RP6??? 3,3V und 5V!?

Hier wird es mal um die Software-Entwicklung gehen.
Wenn ihr wollt, könnt ihr schon mal in die RN-Wissen-Artikel gucken: Hardware, Software!
Für die Software gibt es schon einen Konfigurations-Header (nur für einen 1. Eindruck...).
Mehr folgt, wenn ... naja, erst sollte es schon die Hardware geben ... ;)

Wenn ihr zur Software aber schon Ideen/Vorschläge habt: Es ist noch früh genug! :)

P.S.:
Ich suche noch "Co-Programmer" für die Arduino-Seite. Mir schwebt da auch eine Arduino-Lib vor, mit der man das ArduIO Board normal als Arduino Shield (und nicht zwangsläufig auch mit RP6) nutzen kann.

Hi Dirk,

Zitat:

---

Zitat von Dirk

Wenn ihr zur Software aber schon Ideen/Vorschläge habt: Es ist noch früh genug! :)

---

also fange ich mal mit den ideen an :-) ...

Ich habe mir jetzt mal (viel zu spät, ich weiss) die "RP6Control_MultiIO_03_bumper.c" angeschaut, weil ich jetzt endlich den SRF02 einsetzen will. Recht komfortabel, was da in der lib drin steht und was man damit alles machen kann, sowas ähnliches wäre für den HC-SR04 ein traum! Einsetzbar für den HC beim einsatz auf der arduinoplatine oder m32, oder beides? Evtl. kombiniert mit dem signal-längen-messgerät welches per parameter für die verschiedenen signalmessungen (IR...US) auf verschidenen pins verwendbar wäre?

Durch die H-brücken auf der neuen platine rückt die möglichkeit alternativer antriebe für den RP6 in greifbare nähe :-) Es wäre phantastisch, liessen sich diese auf die gleiche komfortable art und weise steuern wie jetztigen :-) - move, rotage, jedes rad einzeln, dist und was es sonst der dige gibt...

ich hoffe ich bin hier nicht zu gierig - aber Du hast ja gefragt :-)

Oh je,

:Haue

Warum habe ich nur gefragt ...? :eek:

Was wolltest du dann denn noch freundlicherweise selbst programmieren? :p

Aber,- hier mal als Beispiel die geplanten Befehle für die H-Brücken (x = 1..2):
powerHBx(__DIR__,__DUTY__)
powerHBxSTOP()
powerHBxFWD(__DUTY__)
powerHBxBWD(__DUTY__)
powerHBxBRK()
powerHBxOFF()

Zitat:

---

move, rotage, jedes rad einzeln, dist und was es sonst der dige gibt...

---

"Rad", "dist" ??? :confused:
Ich muss mal fabqu fragen, ob ein bestimmter Antrieb Teil der Lieferung des ArduIO Boards ist ... ;)

Zitat:

---

Zitat von Dirk

Was wolltest du dann denn noch freundlicherweise selbst programmieren? :p

---

naja, die superlibs anwenden und fragen stellen...;-)

ich übertreibs jetzt mal ein bischen: meine tochter fährt auch auto, ob sich im motor die kurbelewelle dabei lins oder rechtsrum dreht ist ihr nicht so wichtig. Das trifft aber nur für meine tochter zu, ich bin da ganz anders, von mir hat sies also nicht :-)

Zitat:

---

Zitat von Dirk

"Rad", "dist" ??? :confused:
Ich muss mal fabqu fragen, ob ein bestimmter Antrieb Teil der Lieferung des ArduIO Boards ist ... ;)

---

aber Du weisst schon was ich meine :-)

Hey!#
Kleiner Dämpfer an dieser Stelle:
Nicht im "Packungsinhalt" ist ein Drehzahlsensor sowie ein Stromsensor ;) Daher wird das Auslesen von Umdrehungen etc nicht direkt möglich sein, müsste man sich eben selbst dazu basteln.

Grüße

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?

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 :)

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.

Hi TrainMen,

Zitat:

---

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().

Zitat:

---

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.

Zitat:

---

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.

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

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.

Ä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.

Hi Dirk,
mir war schon klar das die RP6_ArduIO.h in verschiedenen Verzeichnissen und somit getrennt RP6 / Ardiuno sind. Trotzdem ist es ein Dateiname mit verschiedenen Inhalten und das mag ich nicht. Kann ja jeder machen wie er will. Ich habe die Datei umbenannt.

Super, vielen Dank für die Beispiele. Jetzt fehlt nur noch die Hardware.

- - - Aktualisiert - - -

noch ein Problem. Doppelte Definition von PCA9685_set und PCA9685_init. Weil die stehen auch in der RP6Control_MultiIOLib.c
Ich habe die neue erst mal umbenannt in PCA9685_2_set und PCA9685_2_init.

Hi TrainMen,

Zitat:

---

Doppelte Definition von PCA9685_set und PCA9685_init.

---

Danke für den Hinweis!
Ich habe gerade im RN-Wissen auf V 1.1 upgedatet, damit die MultiIO gleichzeitig mit der ArduIO benutzt werden kann.
(Mann, was packst du alles auf deinen RP6? Wie hoch ist der schon?)

Hi HaWe,

Zitat:

---

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

---

Ja, ich gebe dir Recht, ich würde auch lieber die STDINT Datentypen nehmen, die Plattform-unabhängig sind.
Ich habe mich aber an die "Diktion" der bisherigen Arduino Uno Libs gehalten, die die Datentypen nach ANSI-C benutzen.

Wenn dich das stört: Die REPLACE Funktion der Editoren kann das ändern.
P.S.: Über das int8_t = char kann man sich streiten... (ich kenne keine Zeichencodes < 0, wohl aber > 127!) ;)

Zitat:

---

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.

---

Die geplante Lib wird ja Lese- und Schreibbefehle für die IO-Expander haben. Den Link zum Stöbern in den geplanten Funktionen der Arduino Uno Lib hatte ich ja schon am 27.11. gepostet.
Alternativ kann man natürlich Funktionen für "remotedigital/ remoteanalog-Read/Write" so nennen, wie man will, also z.B. auch "arduio_digitalread(pin)". Dazu brauchst du die zukünftige Lib nicht zu verändern, sondern definierst (#define ...) deine Wunschfunktionen als Macros.
Natürlich kannst du auch eine eigene Lib für das ArduIO Board schreiben: Diese Version wird nur ein erster Aufschlag sein, insb. für die, die nicht selbst an Libs basteln wollen.

Zitat:

---

Das mit der Echtzeitfähig auch für IRQs ist allerdings Hauptbedingung für meine persönlichen Anwendungsbereich, ...

---

Mit der "Echtzeitfähigkeit" von I2C-Bausteinen ist das so eine Sache. Die IO-Expander (PCA9535) auf der ArduIO haben für eine zügige Reaktion auf Wechsel des Input-Pegels einen IRQ-Ausgang, der auch auf dem ArduIO Board nutzbar ist. Man kann diesen IRQ-Pin dann z.B. an einen digitalen IO-Pin des Arduino legen und sofort auf Requests reagieren.
Nutzt man den Interrupt-Pin nicht, ist man allerdings auf die Abfragezeiten auf dem I2C-Bus angewiesen, die je nach Auslastung wechseln können.

So, Besteller des ArduIO Boards:

Im Software-Artikel sind jetzt beide Libraries mit ihren Test-Demos schon mal online:
--> AVR-GCC für M256, M32 und RP6v2: Guckst du hier!
--> Arduino Library für den Arduino UNO: Guckst du da!

Aber:
Ich konnte sie bis jetzt nur mit einem Prototypen testen!!!
Also:
Fehler sind garantiert noch drin!!! Bitte um Nachsicht und um Fehlermeldungen, sobald ihr eure Boards habt.

@Dirk,
gerade für die Arduino-Libs sind die neuen Standard-Datentypen wichtig, weil nämlich Sketch die Datentypen für AVR (Uno, Mega) anders behandelt als für ARM (Due, sicher auch Tre wenn er mal kommt).
byte ist gar kein C-Standardtyp,
8-bit char ist bei AVR signed char, bei ARM aber unsigned char
int ist bei AVR 16 bit, bei ARM 32 bit
long ist bei AVR 32 bit, bei ARM 64 bit
double ist bei AVR == float = 32 bit, bei ARM 64 bit

Am schlimmsten sind aber die 8-bit-Versionen, denn der unvermittelte, nicht angekündigte, verdeckte Compiler-Switch von signed zu unsigned bei völlig identischem Sourcecode im selben Editor/IDE führt zu katastrophalen Runtime-Fehlern auf ARM-Arduinos!

edit, Ergänzung:

Zitat:

---

Man kann diesen IRQ-Pin dann z.B. an einen digitalen IO-Pin des Arduino legen

---

ich hätte allerdings 16 Dpins, die auf IRQ reagieren müssen... :-/

Hi HaWe,

Zitat:

---

gerade für die Arduino-Libs sind die neuen Standard-Datentypen wichtig,...

---

Du rennst bei mir offene Türen ein.
Aber: (Fast) alle Examples und Standard-Libs der Arduino IDE verwenden die Standard-Datentypen (noch) NICHT, und daran habe ich mich orientiert.

Wenn du die Lib auf Standard-Datentypen ändern willst: REPLACE-Funktion deines Editors!
- byte --> uint8_t
- unsigned int --> uint16_t
- unsigned long --> uint32_t
Mehr Integer-Datentypen kommen in der Source (.cpp) und dem Header (.h) nicht vor. Also: Schnell gemacht.

Zitat:

---

edit, Ergänzung:
Dirk schrieb: "Man kann diesen IRQ-Pin dann z.B. an einen digitalen IO-Pin des Arduino legen."
ich hätte allerdings 16 Dpins, die auf IRQ reagieren müssen... :-/

---

Ja, das hilft dir nicht wirklich weiter ... :(