I/O-, ADC- und DAC Erweiterung für RP6??? 3,3V und 5V!?

Hi HaWe,

ich versuche das mal alles so genau wie möglich zu beantworten ;)
1.) Das Board hat Pinheader, welche kompatibel sind mit den üblichen Arduino-Layouts. Leider habe ich keinen Due oder Mega da, daher kann ich das nicht direkt beurteilen. Wenn du willst, prüfe ich das aber nach! Programmieren lässt sich das Board um das es hier geht gar nicht, alle Bausteine sind reine I2C-Komponenten.
2.) I2C geht auch mit 400kHz
3.) Kann ich wie gesagt (noch) nicht sagen
4.) Alle I2C-Adressen (zumindest jeweils A0 und A2) sind wählbar. Eine Liste der Adressen wird es demnächst geben, wenn Dirk mit seinen Softwarearbeiten fertig ist.
5.) Klar! 5V-Pegel oder 3,3V-Pegel-I2C sind vorhanden und auch auf Extrapins rausgeführt.
6.) Verfügbare 5V-PWM-Pins hat die ArduIO 16 Stück. Acht davon sind direkt auf Pins rausgeführt und können über Jumper weiter verwendet werden (etwa für LEDs). Acht sind auf MOSFETs (je vier auf n-, 4 auf p-Channels) gelegt, sind daher nicht direkt verwendbar (oder nur mit Lötarbeiten).
7.) reine Digi-IOs sind 48 vorhanden. 32 davon haben 5V-Pegel, 16 haben 3,3V-Pegel
8.) 12 ADC-Eingänge
9.) Drei DAC-Ausgänge
10.) Pullups an IOs sind nicht vorhanden. Es sind lediglich Pullups an den Int-Leitungen der drei IO-Expander vorhanden (Int-Leitungen der IO-Expander lassen sich jumperbar auf die drei Int-Leitungen des RP6-Systems legen) sowie zwei fest verlötete Pullups am 3,3V-I2C-Bus (notwendig für den Busbetrieb).
11.) Ja. Es wurden bei diesem Board durchgehende Arduino-Header verbaut, wie DIESE HIER. Pins sind nach unten gelegt, Buchsen nach oben.
12.) Ja. Siehe 11.)
13.) Wie gesagt, kann ich schlecht ausprobieren. Lässt sich aber sicher rausfinden ;)

Ich hoffe ich konnte helfen.
Grüße

hallo fabqu,
danke für die schnelle und ausführlich Antwort! Ist wirklich toll gelungen!

zu den Pullups (10): hier meinte ich die Pullups, die das Board benutzt zum Anschluss ans Arduino-TWI. Meist werden ja ca. 4k7 pullups verwendet. Wenn ich allerdings weitere i2c-Komponenten an denselben Bus anschließen will, könnte es sein, dass diese andere Pullups benötigen (im Extremfall 47k-82k) - gesetzt den Fall, dass die von dir verwendeten i2c-Komponenten das überhaupt vertragen. PCF8574 z.B. tun das durchaus, PCF8591 auch. Mein Steckenpferd ist aber u.a. auch das Anbinden von Lego-NXT-Sensoren, die auf Bitbanging I2c ausgelegt sind und oft nur mit 47k-82k Pullups funktionieren - die würde ich u.U. gern an denselben Bus mit dranhängen, an dem auch das Muxerboard hängt. Aber auch eine Pixy-Cam könnte ich mir gut zusätzlich vorstellen an diesem Bus zum Muxer, die dann aber wieder Standard-I2C mit Standard-Pullups braucht (hier sind, meine ich, allerdings bereits 4k7 Pullups fest eingebaut, man müsste dann andere, die zum Muxer-SDA/SCL führen, ggf. disablen können.

zu 6): Da ich mit den pwms durchweg DC-Encoder-Motoren antreibe, interessieren mich diese vorrangig als Enable-Pins für Motortreiber.
Mit Mosfets kenne ich mich nicht aus, ich verwende durchweg fertige Motortreiber-H-Brücken für 12-15V mit knapp 100W Dauerleistung. Denkst du, ich kann meine Motoren direkt an die Mosfets anschließen (vorwärts/rückwärts-Betrieb, ähnlich wie mit L293/L298) ?

Ansonsten bräuchte ich pro pwm-pin 4 weitere normale (in1/2 für die H-Brücken und je 2 für Encoder). Käme man insgesamt auf 12 Motoren (4-5 vom Arduino Due direkt, 7-8 vom Muxer-Board), wäre das ideal, dann könnte ich nämlich ein 2. Huckepack-Mega-Board als Motor-Multiplexer einsparen. Das würde allerdings bedeuten: 7-8 pwm-Muxer-Pins plus 28-32 normale Muxer-Digi-pins, was ja dann wohl locker ausreicht, auch schon ohne die Mosfets.
Trotzdem würde mich die Leistungsfähigkeit dieser Mosfets schon interessieren, wenn ich mir auch momentan noch gar kein spezielles Einsatzgebiet vorstellen kann (außer eben Motorantrieb).

zu 1.): Bleibt die Frage der Programmierbarkeit mit Sketch
- hier meinte ich aber: 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.

Ich hoffe, die Fragen sind nicht allzu speziell oder gar zu abwegig... :-/

Hi!
Also:
Pullups: auf der 3,3V-I2C-Seite sind tatsächlich 4k7-Pullups, auf der 5V-I2C-Seite momentan gar nichts, da hier 4k7-Pullups auf dem Mainboard des RP6-Systems liegen.
Andere oder zusätzliche Pullups sind aber gar kein Problem! Da ich alle Platinen selbst löte sind Extrawünsche machbar ;)

zu 6.) Ich würde dir NICHT empfehlen, mit den hier verwendeten MOSFETs Motoren zu betreiben. Möglich ist es, es sind auch "gute" Rücklaufdioden und ein passabler LC-Filter extra dafür da. Dennoch: 1. sind die MOSFETs eher für 20-40W (7-8V und 4-5A) ausgelegt, zweitens schafft der PWM-Baustein gerade mal 1000Hz. Das ist deutlich zu wenig für eine vernünftige Motoransteuerung... würde ich dir also abraten. Lieber ein vernünftiger Prozessor, der die Motoren ansteuert.

zu 1.) Die Bibliotheken, die Dirk vorbereitet, sind (denke ich) eher für den RP6 gedacht. Arduino-Libs müsste man sich dann daraus "copy-pasten" oder eben selbst erstellen. Dann sollte auch Sketch kein Problem mehr darstellen!

Über das Zeitkritische weiß ich leider auch zu wenig zu sagen! Ist sicherlich eine Frage der Software-Lösungen.
Ich habe schon gesehen, dass du im Anderen Post mit Dirk in Kontakt bist. Da ist er sicherlich der "sinnvollere" Ansprechpartner. In der Programmierung bin ich eher unterer Durchschnitt...

Grüße

Hi fabqu,

Zitat:

---

zu 1.) Die Bibliotheken, die Dirk vorbereitet, sind (denke ich) eher für den RP6 gedacht. Arduino-Libs müsste man sich dann daraus "copy-pasten" oder eben selbst erstellen. Dann sollte auch Sketch kein Problem mehr darstellen!

---

Eine Arduino Library für das ArduIO Board ist in Planung: HIER, zum "letzten Schliff" brauche ich die Hardware, dann kann's hoffentlich losgehen .... ;)

hi,
super - für mich persönlich hängt es dann "nur" an der Echtzeitfähigkeit für die 16 Encoder-Pins (über IRQ), denn die Motoren müssen ja vom Master-Arduino per PID control über die Encoder in Echtzeit gesteuert werden können: 4kHz mit 16 pins Bandbreite.

ABER -
wenn Ihr gerade dabei seid...
könnte man auf dem Board nicht evtl auch noch 256k-1MB permanten Speicher verbauen, ebenfalls über den i2c-Zugriff, der aber auch SEEEEEHR viele Schreibzyklen aushält (>> 10.000.000) ?
Vllt SD 4GB, class 10 oder so?
Mit einer lib, die in etwa die file-I/O-Funktionen von stdio.h hat (fopen, fread, fget, fgets, fscanf, fput, fputs, fprint, fprintf, fflush, fclose oder änhliches)

wenn man den Bus mit Highspeed-I2C (400kHz aufwärts) fährt, dann ist es sicher alles noch schnell genug (und hoffentlich für den zusätzlich angeschlossenen Rest am Bus nicht schon zu schnell...)

Ich habe da nämlich gerade ein ganz eklatantes Daten-Speicher-Problem mit dem Due. :-/

Hi!
Leider ist die Platine schon fertig! Ich löte gerade wie ein Weltmeister, um die alle fertig zu bekommen und an diejenigen, die welche bestellt hatten, rauszuschicken.
Ein SD-Steckplatz war leider nicht geplant, da das RP6-System sowas bereits besitzt. Aber soweit mir bekannt lässt sich mit dem Arduino genauso eine SD-Ansteuerung realisieren, dank SPI!?

Fertige, billige SD-Reader finden sich auf eBay etc.
Grüße

ja, stimmt ntl mit den SPI-Dingern. Wenn ich endlich mal ein TFT fände mit SD-SPI, die zusammen ausschließlich auf den ICSP-Headern funktionieren, wär ja auch alles gut.
Ist aber eh nur eine Nebensache gewesen.

Bleibt also nur die Frage nach der 250µs-Echtzeit-Sache.

Hi HaWe,

Zitat:

---

Bleibt also nur die Frage nach der 250µs-Echtzeit-Sache.

---

Heißt das, du must einzelne digitale Inputs alle 250µs (mit 4kHz) auswerten?

Das wird nur mühsam gelingen wegen des nicht so schnellen I2C-Bus Datentransfers (Default Bus Speed in der ArduIO-Lib 100 kHz, weil die PCF8591 nicht mehr können).
Wenn du auf den IRQ des IO-Expanders reagierst, könnte es vielleicht klappen, auf einen Pegelwechsel zeitnah zu reagieren, aber auch dann muss es ja noch einen Lesevorgang über I2C geben.

ALSO:
Die Auswertung von Dreh-Encodern ist eine No-Go-Aufgabe für einen I2C-IO-Expander!
Du solltest dazu immer einen IRQ-fähigen (oder ICP) Eingang des µCs nehmen!

Zitat:

---

Zitat von Dirk

Hi HaWe,

Heißt das, du must einzelne digitale Inputs alle 250µs (mit 4kHz) auswerten?
...
ALSO:
Die Auswertung von Dreh-Encodern ist eine No-Go-Aufgabe für einen I2C-IO-Expander!
Du solltest dazu immer einen IRQ-fähigen (oder ICP) Eingang des µCs nehmen!

---

ja, das stimmt mit den 250µs IRQ-Takt für die Drehencoder.
Bis jetzt mache ich es mit einem Huckepack-Arduino-Mega, der die Encoder selber on-board über eigene AVR-IRQs verwaltet samt "remote"-PID-Steuerung.
Was zwar in Echtzeit passiert, aber die direkte Kontrolle ist ntl dem Master entzogen.

Nur die lokalen Encoder mache ich ntl über lokale IRQ-Pins (in diesem Falle per DueTimer).

ps:
ich kann auf einem Due nur 6 Encoder-Motore verwalten, denn ich brauche pro Motor:
2 Encoder Pins,
3 H-Bridge-Pins pro Motor, davon 1 pwm-Pin, von dem jeder mit einem IRQ-Pin verschaltet ist

bestimmte Dpins von 2-13 (die einzigen, die auch pwm haben) sind aber bereits durch andere Geräte belegt
(z.B. der Encoder-Timer-IRQ-Pin selber, dann ein PS2 Keyboard mit einem eigenen IRQ-Pin, etc., etc., oder CS für SPI, oder durch einfache Taster (insg. 16) )

- ich brauche aber 12-14 Encoder-Motore, daher die notwendige Erweiterung, entweder per i2c-Mega-Slave oder eben per Muxer-Shield !

aber schade, dann bleibt doch nur die Mega-Huckepack-Methode...

Hi HaWe,

darf ich fragen, was du da für eine Hardware-Anwendung hast mit den vielen Encoder-Motoren, PS2 Keyboard und vielen Tastern?