RP6 ArduIO Board - Software

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

[TrainMen]

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.

[Dirk]

Hi TrainMen,

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

[Dirk]

Hi HaWe,

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

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.

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.

[Dirk]

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.

[HaWe]

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

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... :-/

[Dirk]

Hi HaWe,

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.

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