Ansteuern von Portbausteinen mit der NetDCU10?

Was heißt "Port" in diesem Zusammenhang? Einzelne Leitungen? Das wäre nämlich kein Problem, da jeweils 8 Leitungen zu einem logischen Port zusammengefasst sind. So können Sie also bis zu 8 Leitungen auf einmal lesen oder schreiben .

Sollte "Port" hingegen gleich eine Gruppe von Leitungen bedeuten, wäre zu überlegen, diese z.B. per I2C anzusteuern. Ansonsten würde sich auch der parallele FS-Bus für solche Aufgaben anbieten.

Mit freundlichen Grüßen,

H. Keller

OK, ich sehe mehrere Möglichkeiten:

1. FS-Bus
Der FS-Bus hat ja eine zusätzliche Leitung ADE. Mit dieser Leitung kann man signalisieren, ob es sich bei den acht Bits um Daten (ADE=0) oder eine Adresse (ADE=1) handelt. Basierend auf dieser Konvention gibt es von uns für den FS-Bus einen Software-Treiber, der über jeweils zwei Zyklen den Bus anspricht: 1. Zyklus Adresse (nur schreiben), 2. Zyklus Daten (lesen oder schreiben).

Auf diese Weise könnten Sie Ihren Portbausteinen jeweils eine Adresse zuteilen und sie so gezielt über das FS-Bus-Protokoll ansprechen. Wir bieten hierzu auch die "Gegenstelle" in Form eines PLDs an. Dieses nimmt die Adresse bei ADE=1 entgegen, speichert sie in einem internen Register und wenn dann der Datenzugriff (ADE=0) kommt, wird die Adresse gleichzeitig nach außen hin angelegt, während die Datenbits direkt von/zur NetDCU durchgeschaltet werden.

2. I2C-Bus
Eine komplett andere Lösung wäre die Nutzung des I2C-Busses. Hier gibt es z.B. mit dem PCA9554 und PCA9554A Portbausteine mit jeweils 16 Bit Breite, die bitweise auf Eingang oder Ausgang programmiert werden können. Bis zu 8 solche Bausteine von jeder Sorte können Sie problemlos am I2C anhängen und so bis zu 256 Leitungen realisieren. Das Setzen bzw. Auslesen der Daten erfolgt dann über den I2C-Bus sequenziell (mit bis zu 400kHz Datenrate). Der I2C-Treiber wäre auf der NetDCU10 vorhanden.

Konkret mit Ihren Daten:
40 Ausgangsleitungen, 24 Eingangsleitungen = 64 Leitungen = 4 Bausteine

Kommunikationsaufwand (je 9 Bits pro Byte)
Ausgangsport 16 Bit: 1 Byte Deviceadresse, 1 Byte Kommando, 2 Bytes Daten => 4 Bytes pro Zugriff
Ausgangsport 8 Bit: 1 Byte Deviceadresse, 1 Byte Kommando, 1 Byte Daten => 3 Bytes pro Zugriff
Eingangsport 16 Bit: 1 Byte Deviceadresse, 1 Byte Kommando, 1 Byte Deviceadresse, 2 Bytes Daten => 5 Bytes pro Zugriff
Eingangsport 8 Bit: 1 Byte Deviceadresse, 1 Byte Kommando, 1 Byte Deviceadresse, 1 Byte Daten => 4 Bytes pro Zugriff

Übertragungsrate Ausgänge: 2 Werte pro Sekunde
Übertragungsrate Eingänge: 100 Werte pro Sekunde

Ergibt folgende gesamte Übertragungsrate: (2*4*9 + 1*3*9)*2 + (1*5*9 + 1*4*9)*100 = 8298 Bits/s = 8,3kHz. Das geht also spielend mit I2C.

3. Rein GPIOs der NetDCU10
Bei dieser niedrigen Datenrate wäre ja zu überlegen, ob es nicht sogar ganz mit den GPIOs der NetDCU geht.

Beispiel 1:
8 Leitungen für Ausgänge plus 3 Leitungen Ausgangsadresse mit externem Adressdecoder (8 Kombinationsmöglichkeiten, davon 5 genutzt um 5*8=40 Leitungen anzusteuern)
8 Leitungen für Eingänge plus 2 Leitungen Eingangsadresse mit externem Adressdecoder (4 Kombinationsmöglichkeiten, davon 3 genutzt um 3*8=24 Leitungen anzusteuern)
Hierfür würden 21 GPIOs verwendet.

Beispiel 2:
10 Leitungen für Ausgänge, 6 Leitungen für Eingänge, dazu zusammen 2 Adressleitungen mit externem Adressdecoder (gekoppelt für Ein- und Ausgänge, 4 Kombinationsmöglichkeiten für 4*10 Ausgänge und 4*6 Eingänge) plus 1 Read/Write-Leitung
Hierfür würden 19 GPIOs verwendet.

Beispiel 3:
5 Leitungen für Ausgänge, 3 Leitungen für Eingänge, dazu zusammen 3 Leitungen Adresse mit externem Adressdecoder (gekoppelt für Ein- und Ausgänge, 8 Kombinationsmöglichkeiten für 5*8 Ausgänge und 3*8 Eingänge) plus 1 Read/Write-Leitung
Hierfür würden 12 GPIOs ausreichen.

Mit freundlichen Grüßen,

H. Keller