8 bit -> 256 TTLs

[constantin]

Hallo,
wie kann ich aus 8 bit -> 256 TTL-Signale machen ? Gibt's dazu auch Literatur ?

gruß

Consti

[john]

Ja, dafür gibts fertige Adressdekoder. Jedoch ist 4 Bit zu 16 Ausgänge das größte, was mir in einem Gehäuse bekannt ist. Brauchst du echt 256 Ausgänge?

[constantin]

Hallo,
ja, es sollten schon 256 Kanäle sein. Aber aus 4 bit -> 16 TTL . Dann nehme ich halt 2 von den ICs . Schließlich macht 16^2 = 256 . Vielleicht sollte ich auch erst mal mein Problem schildern : Ich habe ein C-Control von Conrad. Mit der möchte ich möglichst viele Sachen schalten. Und da ich 8 Digi-Ausgänge habe ( die anderen 8 werden ja so viel ich weiß für's LCD benutzt ), wollte ich aus einem 8 bit Signal von der CC 256 Kanäle Schalten. Oder ich würde mit einem eigenen Protokoll arbeiten. Davon habe ich aber null Ahnung . Also fand ich die Ausgabe über 8 bit am einfachsten.

[ralf-k]

Hi!

Aber für 256 Ausgange brauchst du aber mehr als 2 dieser IC´s
Ein IC hat 16 Ausgänge also wären das dann 16 IC´s.
Es sei denn, du willst es als Matrix schalten.
aber dann brauchst du 256 Transistoren, und ich weis nicht. Ich hätte keine Lust die alle ein zu löten

Gruß Ralf

[john]

Dir ist aber schon klar, daß du beim Wandeln von 8 Bit auf 256 Ausgänge die Möglichkeit verlierst, zwei Ausgänge gleichzeitig zu schalten, oder?

Porterweiterungen für den C-COntrol gibts wie Sand am Meer. Die meisten Lösungen setzen auf seriellen Schieberegistern an. Sehr elegant geht das auch mit I2C Bus - hier gibt es fertige ICS, die sich gut kaskadieren lassen!

Gruß

John

[constantin]

Hallo,
ja schon klar, dass ich dann keine 2 Kanäle gleichzeitig schalten kann. Was ist der I2C Bus ? Gibt's zur C-Control nicht auch Bücher die auch so etwas ansprechen ?

gruß

Const

[floh]

der I2C (I-Quadrat-C) Bus ist eine Schnittstelle um auf einer Printplatte verschiedene IC's zu verbinden ohne, dass alles in einem Kabelsalat endet. Es werden zwei Leitungen benötigt (ausser der Masse) und zwar eine Takt- und eine Datenleitung. Wenn ich mich nicht irre ist beim CControl der Speicherchip so an den Controller angeschlossen. Die Leitungen sind auch herausgeführt und es können weitere Bausteine angeschlossen werden. Wie man diese programmiert, weiss ich aber nicht. Irgendwo in irgend einer Elektronik Zeitschrift habe ich aber mal ein Beispiel gesehen, es funktioniert also!

[random]

Hi,

mit dem Atmel AVR ist dies leicht zu Programmieren. Der hat I2C bereits mit drin, kann man auf zwei beliebige Portpins legen.
Weiterhin findet man da Sachen wie
- I2C
- 8 Analogwandler - Eingänge
- RS232
- insgesamt 4 x 8Bit
- Im System programmierbar
- usw.

Ein schickes Teil, ich spiel da selbst mit herum.
Bestell Dir mal bei Reichelt folgenden Baustein:

PCF8574

Ich hab mir ein kleines System zum Experimentieren aufgebaut. Ein Display 20x4 und 8 Tasten werden hier über I2C mit dem PCF bedient, so dass dafür lediglich zwei Leitungen erforderlich sind (gegenüber 2 Ports zu je 8Bit)

Gruß,
thorsten

Block Diagramm:
<img src="http://www.semiconductors.philips.com/p ... MBD980.gif" alt="" />

Datasheet von Phillips

Kurzbeschreibung:

The PCF8574 is a silicon CMOS circuit. It provides general purpose remote I/O expansion for most microcontroller families via the two-line bidirectional bus (I²C).
The device consists of an 8-bit quasi-bidirectional port and an I²C-bus interface. The PCF8574 has a low current consumption and includes latched outputs with high current drive capability for directly driving LEDs. It also possesses an interrupt line (INT) which can be connected to the interrupt logic of the microcontroller. By sending an interrupt signal on this line, the remote I/O can inform the microcontroller if there is incoming data on its ports without having to communicate via the I²C-bus. This means that the PCF8574 can remain a simple slave device.

The PCF8574 and PCF8574A versions differ only in their slave address.


Features Operating supply voltage 2.5 to 6 V
Low standby current consumption of 10 µA maximum
I²C to parallel port expander
Open-drain interrupt output
8-bit remote I/O port for the I²C-bus
Compatible with most microcontrollers
Latched outputs with high current drive capability for directly driving LEDs
Address by 3 hardware address pins for use of up to 8 devices (up to 16 with PCF8574A)
DIP16, or space-saving SO16 or SSOP20 packages.

[constantin]

Hallo,
also erstmal vielen Dank für die zahlreichen Antworten. Mittlerweile habe ich mich mit dem I2C-Bus etwas auseinandergesetzt. Ich muss zugeben, dass das ein hammer Teil ist, mit dem sich so einiges erleichtert. Allerdings eignet er sich aus folgenden Gründen nicht für mein Vorhaben ( min. 200 TTLs ) :
1.: Die Adressierung erfolgt in 7 bit : Folglich habe ich nur 128 Adressen die ich ansteuern kann. Ok, ich kann an jeder Adresse fast beliebig viele Ports (nicht direkt) anschließen, allerdings wird dass dann wieder ein Kabelsalat.
2.: Die Adresse der fertigen ICs im Handel haben ja schon eine eigne Adresse teilweise einprogrammiert. Somit bleibt für mich im Bestfall vielleicht die Möglichkeit 9 gleiche Bausteine an den Bus anzuschließen.

Der I2C Bus wurde ja entwickelt, um verschiedene Bausteine an einen Bus anzuschließen. Für meine Aufgabe stelle ich allerdings nicht so hohe/komplexe Ansprüche : nochmal konkret : mit einem Controller sollte das Datensignal über möglichst wenig Leitungen zu den sog. Empfängern gesendet werden. Dieser sollte Adressierbar sein ( ähnlich wie bei DMX 512 ). Zudem sind alle Empfänger an die gleiche Datenleitung angeschlossen. Ich habe mir das so vorgestellt : der Controller sendet die Adresse -> der Empfänger "vergleicht" die gesendete Adresse mit seiner voreingestellten . Wenn die Adressen übereinstimmen muss dann nur noch am Empfänger ein Relais schalten ( was dann wohl der geringste Aufwand währe ). Sonst müssen keine weiteren Daten übertragen werden . Nur der Befehl an,aus und wer ( Adresse des Empfängers ) müssen gesendet werden. Bei dieser Schaltung ( empfängerseitig ) sind im Gegensatz zu dem I2C-Bus immer die gleichen Bauteile vorgesehen. "Theoretisch" will ich 250 Empfänger bauen, die ich alle an eine Dtenleitung hänge und jeweils mit dem Controller ansteuere. Natürlich ist das nur der Extremfall. Also, hat da jemand ne Idee ?

gruß
const

<small>[ 28. Juni 2002, 17:33: Beitrag editiert von: const ]</small>

[jan]

Klar, dazu hab ich eine Idee. Sieh dir mal die Encoder/Decoder ICs HT12E und HT12D von Holtek an (www.holtek.com); ich glaube, die könnten dir weiterhelfen.

[constantin]

Hallo Jan,
vielen Dank für deine Antwort. Das Teil ist wirklich interessant. Da ich so ein ähnliches Teil von ELV hab ( HT615/600 ) denke ich mal, dass die ähnlich aufgebaut sind. Du hast das wahrscheinlich so gemeint: jeder Empfänger erhält seinen eigenen "Eingangscode" . Es gibt dann einen Sender, der praktisch immer sendet, aber seinen Sendecode entsprechend ändert. Und der Empfänger kann mit dem eigentlichen Datensignal in den meisten Fällen nix anfangen. Nur wenn der Sender im gleichen Code sendet, wie der am Empfänger eingestellt wurde, schaltet der Decoder. ABER : Ich möchte aber auch zwei Kanäle gleichzeitig ansprechen. Brauch ich dafür dann wohl zwei Sender, aber aknn ich die auf die gleiche Datenleitung legen ?

Fragen über Fragen ...

consti

[floh]

ich glaube du versuchst das Rad neu zu erfinden. Mach doch etwas auf Basis von DMX 512 dann bist du gleich auch kompatibel!

Was hältst du von dem da: http://www.theaterzentrum.at/technix/de ... index_html oder GOOGLE mal etwas herum

[constantin]

Hallo,
DMX ist schon Klasse, keine Frage. Es gab da aber für mich einige Gründe, nicht DMX zu benutzten:
- Da ich viele Empfänger benötige, wird's mit den DMX Empfängern recht teuer.
- DMX 512 kann , wie der Name schon sagt bis zu 512 Adressen ansprechen. Aber das ist ja nicht das einzigste, was DMX kann. Lichter dimmen usw. . Das muss ja auch alles mitgesendet werden und bedeutet mehr Aufwand = teuer . In meinem Fall muss ich ja nur an und aus schalten. Mehr nicht. Das Protokoll, dass die Encoder/Decoder leisten müssen ( Vorschlag v. Jan ) ist erheblich kleiner. Kurz gesgt, DMX kann so viel Zeugs, was ich nicht brauch.Auf Kompatibilität lege ich zudem keinen großen Wert.

Gruß

consti

<small>[ 02. Juli 2002, 13:50: Beitrag editiert von: const ]</small>

[john]

@const: Was um Himmels willen willst du damit eigentlich Steuern? Vielleicht ergeben sich ja aus der Anwendung ganz andere Möglichkeiten.
Ich wollte z.B. früher mal einen Haufen LEDs ansteuern und war froh, als ich vom Multiplexen erfuhr

John

[jan]

Ich würde den Sender nicht permanent senden lassen, sondern nur bei Bedarf, also in etwa so: Adresse anlegen, Daten anlegen und dann mit dem TE Signal senden. Eventuell das VT Signal des Empfängers als Empfangsbestätigung zurückleiten; wenn man nur ein Schaltsignal braucht kann man auch auf die Daten verzichten und VT zum Toggeln benutzen. Zwei Empfänger gleichzeitig schalten geht nur, wenn sie die gleiche Adresse haben. Mit zwei Sendern gleichzeitig auf eine Leitung gehen ist nicht möglich - auch nicht bei DMX oder sonstigen seriellen Bussystemen. Natürlich hat man mit DMX den Vorteil der Kompatibilität und die Gewähr ein erprobtes System zu benutzen. Aber man muss natürlich einen höheren Aufwand und höhere Kosten in Kauf nehmen. Ich weiss nicht, ob es fertige DMX-512 ICs gibt, ansonsten benötigt man das Know-How und die Entwicklungstools um das Protokoll in einem µC zu implementieren (und möglichst ohne Fehler). Und natürlich muss man auch die RS-485 Schnittstelle als Hardwarellayer verwenden; das kann man übrigens auch mit den Holtek-ICs machen, ist nicht schlecht für die Störsicherheit.

[lightfreak]

Hallo,

[KLUGSCHEISSERMODUS]
also mit zwei oder gar mehr Sendern auf einen seriellen Bus zu gehen ist schon lange möglich (z.B. Ethernet / Token-Ring / CAN-Bus) man muß nur möglichkeiten für collision-detection oder -avoidance haben. DMX 512 in einem µC ist überhaupt kein Problem. Das Protokoll ist völlig offengelegt und easy going auf nem '51er oder AVR zu implementiern.
[/KLUGSCHEISSERMODUS]

Gruß

Simon

[floh]

Da geb ich doch noch meinen Senf dazu:
Senderecht:
In einem Bussystem muss gewährleistet sein, dass nur ein Gerät auf einmal Daten sendet.

Dies kann dadurch geschehen, dass ein Gerät als Master (engl. master=Meister) und alle anderen Geräte als Slave (engl. slave=Sklave) konfiguriert ist. Der Master bestimmt wer senden darf. Dazu ist es notwendig, dass er jedes Gerät, das Daten senden kann, nach Bedarf bzw. zyklisch abfragt.

Eine andere Möglichkeit ist die Weitergabe eines Tokens (engl. token=das Zeichen; hier: Sendeberechtigung). Jedes Gerät hat so die Möglichkeit anstehende Daten zu senden, wenn es im Besitz des Tokens ist. Es ist dabei unerlässlich, dass erkannt wird wenn der Token fehlt (z.B. das Gerät, das den Token gerade erhalten hat stürzt vor der Weitergabe ab) oder wenn aus irgend einem Grund mehrere Token unterwegs sind.

Die dritte Art ist das CSMA/CD Verfahren (z.b. bei Ethernet). Die Abkürzung aus dem englischen bedeutet „Carrier Sense Multiple Access with Collision Detection“ (Verfahren mit Abfrage des Signalträgers bei mehrfachem Zugriff mit Kollisionserkennung). Ein sendewilliger Teilnehmer hört in das Datennetz hinein und wartet bis die Leitung frei ist. Sobald kein anderes Gerät sendet, sendet er für einige Millisekunden. Sollte im selben Augenblick ein anderes Gerät auch senden, so wird das erkannt und alle Geräte stellen den Sendebetrieb ein. Danach warten sie eine kurze Zeit, die von einem Zufallsgenerator bestimmt wird und versuchen erneut ihre Daten loszuwerden. Da jedes Gerät einen eigenen Zufallsgenerator besitzt, hat es im Durchschnitt dieselben Sendechancen.

[jan]

Hab mir schon gedacht, dass meine Äusserung "Zwei Sender gleichzeitig geht nicht" zu einem Aufschrei der Empörung führen würde und das jemand mit CAN oder Ethernet kommt. Aber was floh dazu geschrieben hat ist ja zutreffend und bedarf keiner weiteren Worte mehr. Was die Implementierung irgendwelcher Protokolle auf µCs angeht: Klar ist das einfach - wenn man's kann und die technischen Möglichkeiten besitzt. Für jemanden der sowas noch nie gemacht hat ist das auf keinen Fall "easy going" - aber es kann sich ja lohnen mal damit anzufangen.

[lightfreak]

Hi,

mit einigem Suchen kann man im Netz auch schon einiges an Quelltexten für DMX finden. Ist wirklich nicht schwer (vorausgesetzt, man hat sich schon mal ein bischen mit µC's auseinandergesetzt).

Gruß

Simon