Forum: Mikrocontroller und Digitale Elektronik Massive IO Porterweiterung - Stabilität des IO - mehrfaches SPI


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von J. W. (ontheway)


Lesenswert?

Hallo liebes Forum,

ich grübel gerade über etwas. Ich weiß, es gibt so viel über 
Porterweiterungen, aber dieses Thema ist vielleicht neu - und wenn 
nicht, seit nicht böse sondern gebt mir nen Link...

Nehmen wir an, ich bräuchte 128 Eingänge und 64 Ausgänge. Nun nehme ich 
einen Atmega32 oder Raspberry GPIO. Dahinter kaskadiere ich OUT mit (von 
mir aus 74HC595) und kaskadiere IN (vielleicht über 74HC165).

Stellen wir uns folgendes vor, nur zum Problem: Wir haben 64 Tasten und 
64 Lampen. Wenn ich eine oder mehrere Tasten berühre, dann gehen die 
entsprechenden Lampen an. Aber die gehen nur an, wenn gewisse Tasten 
zusammen gedrückt und andere nicht gedrückt sind, also: Logikcheck.
Ich möchte aber wissen, zum Beispiel, ob die Lampe überhaupt angehen 
konnte, weil OUT da war, also koppel ich zurück auf 64 IN, 
Sicherheitscheck.

Jetzt zum Algorithmus:
0. Systemzustand checken
1. Eingänge checken
2. Eingänge logisch bearbeiten
3. Ausgänge belegen
4. Ausgänge checken
5. zurück zu 0.

Dies erscheint mir sehr logisch vom Ablauf her. Aber wenn ich mir meine 
leider geringe Praxis anschaue, bin Neuling...
Mir grummelt da der Bauch, das kann nur schief gehen... von Zustand 2. 
bis 4. ist 1. unbeobachtet.
Nur so aus Spaß habe ich versucht, 2 Tasten zu kontrollieren, und 
dachte, juhu, mit Raspberry nutze ich den Interrupt. Aber das kann man 
ja wohl knicken bei sehr vielen IN OUT.

Zuerst: Wie würdet ihr dieses Problem in den Griff bekommen? Bevor...

... ich euch mit meiner Idee überfahre, die mir im wahrsten Sinne des 
Wortes logisch vorkommt... wie wäre es, wenn man alle "Tasteneingänge" 
mit einem logischen Baustein verbindet, der sich die "Tastendrücke" 
merkt, anstelle des direkten Kontaktes mit der z.B. 74HC165? Dann in 
Ablauf 0. werden die Dinger einfach resettet?

Danke für Eure Gedanken!

LG,
Jens

von Lurchi (Gast)


Lesenswert?

Für so etwas wie viele LEDs und Tasten kann man ggf. eine 
Matrixschaltung nutzen. Da kann man etwa über 3 mal 8 IO Ports 64 LED 
Schaltung und 64 Tasten einlesen.

So etwas wie Tasten ließt man in der Regel periodisch ein (z.B. im Timer 
Interrupt) - das gibt einem dann auch gleich die Entprellung.

von Sebastian S. (amateur)


Lesenswert?

Ich würde über die I²C-Schnittstelle gehen.
Es gibt Bausteine mit, soweit mir bekannt, bis zu 16 I/O-Ports.
Das ist relativ Komfortabel zu behandeln und kaskadierbar.

von J. W. (ontheway)


Lesenswert?

Danke aber nein, es geht um etwas wirklich großes. Ein System, was 
besteuert und gelesen wird. Das System als solches ist nicht relevant, 
es könnte sich um eine komplette Haussicherung handeln. Es geht um das 
Prinzip.

LG,
Jens

von J. W. (ontheway)


Lesenswert?

Sebastian S. schrieb:
> Ich würde über die I²C-Schnittstelle gehen.
> Es gibt Bausteine mit, soweit mir bekannt, bis zu 16 I/O-Ports.
> Das ist relativ Komfortabel zu behandeln und kaskadierbar.

Danke aber ich brauche viel viel mehr!

LG,
Jens

von Hannes (Gast)


Lesenswert?

Dann nimm kein Spielzeug sondern eine richtige Lösung. Es gibt genug 
MCUs mit 144 Pins.

von Sebastian S. (amateur)


Lesenswert?

> Danke aber ich brauche viel viel mehr!
Die Teile kann man wie bereits gesagt kaskadieren und wenn Dir 128 
Dingsbümser nicht reichen - der Bus ist relativ einfach gestrickt - 
verdopple ihn einfach (ein el. Schalter mit einer Richtung und einer mit 
zweien).

von Gerd E. (robberknight)


Lesenswert?

J. W. schrieb:
> Danke aber nein, es geht um etwas wirklich großes. Ein System, was
> besteuert und gelesen wird.

bei vielen IOs ist Matrixansteuerung absolut gängig, weil sehr 
effizient.

Erkläre genau warum das bei Dir nicht gehen soll.

von Tobias L. (murxwitz)


Lesenswert?

hört sich nach ner guten Anwendung für einen FPGA an. Und sollte sich 
auch gut als Anfängerprojekt eignen.
Einer in einem 144 Pin TQFP dürfte aber wohl zu klein sein und die mit 
mehr sind dann alle BGAs. Aber evtl findet sich ein passendes, fertiges 
Board, welches genügend Anschlüssen nach Außen geführt hat. Dann ist 
auch Spannungsversorgung etc. schon fertig und (sollte) funktionieren.
Natürlich kann man in einem 144 Pinner auch noch einfach eine 
Matrixansteuerung mit rein Implementieren.

: Bearbeitet durch User
von Possetitjel (Gast)


Lesenswert?

J. W. schrieb:

> 0. Systemzustand checken
> 1. Eingänge checken
> 2. Eingänge logisch bearbeiten
> 3. Ausgänge belegen
> 4. Ausgänge checken
> 5. zurück zu 0.
>
> Dies erscheint mir sehr logisch vom Ablauf her.

Sicher. SPS arbeiten so ähnlich.

Kann man natürlich so oft neu erfinden, wie man will.

von m. keller (Gast)


Lesenswert?

Wo genau ist denn jetzt das Problem?

Die Frequenz des seriellen Busses muss halt entsprechend hoch sein, 
damit du zuverlässig deine Tasten erkennen kannst.

Was meinst du mit "Out checken"? Willst du alle Ausgänge nochmals 
separat einlesen?

Also am einfachsten macht man das wirklich mit einem Controller der 
einfach ein paar mehr GPIOs hat (z.B. STM32F407 auf dem 
STM32F4Discovery, welcher schon 140 nutzbare IOs hat), dann musst du 
auch kein Grab an Schieberegister dranhängen. Ansonsten einfach schnell 
genug schieben, aber ich glaube ich hab dein Problem nicht verstanden

von J. W. (ontheway)


Lesenswert?

Gerd E. schrieb:
> J. W. schrieb:
>> Danke aber nein, es geht um etwas wirklich großes. Ein System, was
>> besteuert und gelesen wird.
>
> bei vielen IOs ist Matrixansteuerung absolut gängig, weil sehr
> effizient.
>
> Erkläre genau warum das bei Dir nicht gehen soll.

Nein, bitte umgekehrt: Wie kann ich den oben angegebenen Algorhitmus 
durchführen? Ich brauche 2n Eingänge, es können auch 256 sein, aber 
davon sind nur 128 "parallel" und müssen registriert werden, während 
diese dann logisch verarbeitet werden müssen, wonach die Outputs logisch 
geschaltet werden, wonach die Outputs geprüft werden...
Ich kenne mich da nicht aus, das ist für mich doch keine Matrix sondern 
völlig getrennte Vektoren: Input1, Output, Input2?

von Matthias K. (mkeller)


Lesenswert?

Was ist denn dein Problem?

Das ganze funktioniert doch ganz einfach:

Am Eingang 2^n mal schieben/takten bis alle deine Daten Eingänge gelesen 
sind.
Deine Logik ausführen und dann 2^m schieben und ausgeben. Das ganze 
sollte eben so schnell sein, dass du alle 20ms neue Daten hast damit 
deine Taster noch entprellen kannst...

Wenn du unbedingt einen definierten Zeitpunkt für das Erfassen der 
Eingänge haben möchtest nimmst du eben den 74HC597, welcher im Gegensatz 
zum 74HC165 D-FlipFlops an den Eingängen hat

: Bearbeitet durch User
von Georg (Gast)


Lesenswert?

J. W. schrieb:
> das ist für mich doch keine Matrix sondern
> völlig getrennte Vektoren: Input1, Output, Input2?

Was genau soll Input2 sein? Musst du die Ausgänge physikalisch 
zurücklesen über Eingänge, ob sie auch so geschaltet haben wie Output 
vorgibt?

Und was soll passieren, wenn das einmal nicht der Fall ist?

Georg

von Karl (Gast)


Lesenswert?

Matthias K. schrieb:
> Das ganze
> sollte eben so schnell sein, dass du alle 20ms neue Daten hast damit
> deine Taster noch entprellen kannst...

Es kann auch 200 ms sein, dann bekommt man das Prellen gar nicht mit. 
O.K. ganz eilige könnten sich beschweren, dass das ding nicht reagiert. 
Ein Schieberegister geht bis einige MHz, bei 128 bit und 20 ms kommt man 
auf 6,4 kHz das schaft ein AVR locker

von Peter D. (peda)


Lesenswert?

Man legt sich die Ports intern im RAM als Schattenregister an.
Und per DMA werden dann alle 10ms die Ausgänge rausgeschrieben und 
gleichzeitig die Eingänge eingelesen.
Die ganze Verarbeitungslogik erfolgt dann in den Schattenregistern.

von Axel S. (a-za-z0-9)


Lesenswert?

J. W. schrieb:
> Gerd E. schrieb:
>> J. W. schrieb:
>>> Danke aber nein, es geht um etwas wirklich großes. Ein System, was
>>> besteuert und gelesen wird.
>>
>> bei vielen IOs ist Matrixansteuerung absolut gängig, weil sehr
>> effizient.
>>
>> Erkläre genau warum das bei Dir nicht gehen soll.
>
> Nein, bitte umgekehrt: Wie kann ich den oben angegebenen Algorhitmus
> durchführen? Ich brauche 2n Eingänge, es können auch 256 sein, aber
> davon sind nur 128 "parallel" und müssen registriert werden, während
> diese dann logisch verarbeitet werden müssen, wonach die Outputs logisch
> geschaltet werden, wonach die Outputs geprüft werden...

Ja. Und?

> Ich kenne mich da nicht aus, das ist für mich doch keine Matrix sondern
> völlig getrennte Vektoren: Input1, Output, Input2?

Du vermischst hier die logische und die physikalische Ebene. Die 
Tasten deiner Tastatur sind z.B. auch als Matrix verschaltet. Trotzdem 
"sieht" der Tastaturcontroller die Tasten logisch als einen langen 
Vektor von Bits.

Auf der Programmseite wird sowas typischerweise dadurch gelöst, daß man 
die logischen Zustände in geeignete Datenstrukturen stopft (z.B. C 
structs) und Ein- und Ausgabe in Funktionen packt. Der logische Kern des 
Programms operiert ausschließlich auf den Datenstrukturen. Die 
Funktionen für Ein- und Ausgabe müssen natürlich auf die real vorhandene 
Hardware angepaßt werden.

Für eine Matrix-Tastatur würde die Eingabefunktion dann die Matrix 
einmal abscannen und den Zustand jeder einzelnen Taste in der 
entsprechenden Datenstruktur ablegen.

von J. W. (ontheway)


Lesenswert?

Possetitjel schrieb:

>> Dies erscheint mir sehr logisch vom Ablauf her.
>
> Sicher. SPS arbeiten so ähnlich.
>
> Kann man natürlich so oft neu erfinden, wie man will.

Ja, Du hast es, nur ist SPS nicht gerade billig und ich möchte halt 
gerne mit einem Raspberry arbeiten.

von J. W. (ontheway)


Lesenswert?

Matthias K. schrieb:
> Was ist denn dein Problem?
>
> Das ganze funktioniert doch ganz einfach:
>
> Am Eingang 2^n mal schieben/takten bis alle deine Daten Eingänge gelesen
> sind.
> Deine Logik ausführen und dann 2^m schieben und ausgeben. Das ganze
> sollte eben so schnell sein, dass du alle 20ms neue Daten hast damit
> deine Taster noch entprellen kannst...
>
> Wenn du unbedingt einen definierten Zeitpunkt für das Erfassen der
> Eingänge haben möchtest nimmst du eben den 74HC597, welcher im Gegensatz
> zum 74HC165 D-FlipFlops an den Eingängen hat
Ja, aber genau das verstehe ich nicht: Nehmen wir an, ich nehme einen 
74HC165, wenn ich die Eingänge prüfe, also parallel die Eingänge habe 
und nun seriell die Werte abarbeite, ist das dann beim 74HC165 der in 
genau diesem Moment der Abfrage vorliegende Spannungswert? Also muss ich 
softwaremäßig mehrmals abfragen um zu entprellen?
Wenn ich stattdessen den mir sehr sympathischen 597er nehme, dann habe 
ich die D-FlipFlops. Sehr symphatisch, weil - und ich habe halt keine 
Erfahrung - ich irgendwelche Tasten drücke, der 597er sich das merkt, 
und ich völlig entspannt in meiner Gänseblümchenwelt die Ports abfrage.

Also, nochmal, sorry für meine Anfängerfragen und wenn ich einige eurer 
Antworten nicht verstehe, aber: Ist das denn nun von Vorteil?
Wann schaltet der 597er? Wenn mal irgnendein winziges Signal auf IN 
liegt?
Oder ist das "automatische Entprellung"?

Ich suche fertige Platinen für den Raspberry Pi. Es gibt eine für serial 
in parallel out mit 595ern, ein Kumpel könnte die umlöten für serial out 
parallel in mit 597er. Kostet 9 Euro die Platine plus 4 * 597er, ein 
Witz.

Ich kümmer mich um die Programmierung und auch ich möchte das angeblich 
unmögliche Max-Max-Prinzip: Maximal preiswert, maximal einfach...

Danke und ich bitte um Geduld!

: Bearbeitet durch User
von Sascha (Gast)


Lesenswert?

J. W. schrieb:

> Ich kümmer mich um die Programmierung und auch ich möchte das angeblich
> unmögliche Max-Max-Prinzip: Maximal preiswert, maximal einfach...

"Das kannste schon so machen, aber dann wirds halt Scheisse"

von Peter D. (peda)


Lesenswert?

J. W. schrieb:
> Wann schaltet der 597er?

Für den Anwender ist der 597 völlig gleich mit dem 165.
Der einzige Unterschied, den 597 kann man schon neu laden, wärend er die 
Daten noch seriell rausschiebt. Beim 165 muß das Schieben beendet sein 
vor dem Laden. In der Praxis hat dieser Unterschied keinerlei 
Auswirkungen.

von J. W. (ontheway)


Lesenswert?

Peter D. schrieb:
> J. W. schrieb:
>> Wann schaltet der 597er?
>
> Für den Anwender ist der 597 völlig gleich mit dem 165.
> Der einzige Unterschied, den 597 kann man schon neu laden, wärend er die
> Daten noch seriell rausschiebt. Beim 165 muß das Schieben beendet sein
> vor dem Laden. In der Praxis hat dieser Unterschied keinerlei
> Auswirkungen.

Oh shit. Das ist ja ein Flipflop. Das heißt er wabbelt trotzdem zwischen 
den Zuständen, der ist ja bi-stabil, der rastet ja gar nicht ein auf 
"Taste gedrückt", richtig? Der rastet zwar ein aber das ist nichts 
anderes als ein Zwischenspeicher...

von J. W. (ontheway)


Lesenswert?

Aber wie wäre es mit einem Parallel In Serial Out der automatisch 
entprellt?
Also, gibt es einen günstigen Gänseblümchen 165er Ersatz, der bei 
"zappel" Schwankungen nicht schaltet, sondern erst bei stabilen 
Spannungen reagiert? Und zwar ein Schieberegister? Nur so aus Neugierde, 
ohne vorgeschaltete ICs oder Analogtechnik? Klar, jetzt kann das 
Argument kommen, Moment mal, was ist normal, das ist doch 
Definitionssache, aber ich meine einen miesen Taster. Schwierig zu 
definieren, klar....

von someone (Gast)


Lesenswert?

Dein Problem ist leider nicht gerade leicht verständlich formuliert.
Es wäre schön, wenn du dein Anliegen besser strukturierst und einen 
klareren Kontext gibst, wo du die Probleme bei der Umsetzung siehst.

Dir ist wahrscheinlich nicht klar, dass das Lesen der Eingänge und das 
Setzen der Ausgänge über SPI sehr schnell geht. Wenn sich in der 
kurzen Zeit zwischen dem Erfassen der Eingänge und dem Setzen der 
Ausgänge etwas ändert, wird das natürlich nicht sofort erfasst, sondern 
erst beim nächsten Zyklus. Das ist aber unwahrscheinlich, da das 
Auslesen und Setzen wirklich sehr schnell abläuft.

Von einer Matrixschaltung rate ich dir ab. Das macht man zwar so, aber 
du scheinst schon mit deutlich einfacheren Dingen Schwierigkeiten zu 
haben, da muss man die Sache nicht unnötig verkomplizieren.
Ein 8-Bit-Schieberegister kostet um die 30 cent, für die Ausgänge 
brauchst du 8 Stück, für die Eingänge brauchst du 16 Stück. Das sind 
7.20 Euro, das ist verschmerzbar. Natürlich kann man das auch für unter 
einen Euro hinkriegen, dann bist du aber damit beschäftigt, das Programm 
so anzupassen, dass auch alles richtig ausgelesen und gesetzt wird.
Falls möglich, nimm zwei SPI-Busse, einen für die Eingangs- und einen 
für die Ausgangsregister.
Dann kannst du beim Eingangsbus den Status einlesen und beim Ausgangsbus 
den Status rausschreiben, ohne dich um andere Dinge kümmern zu müssen.

von B. S. (bestucki)


Lesenswert?

Ich glaube, der TO weiss noch nicht, wie das mit der Matrix gemeint ist. 
Siehe:
https://upload.wikimedia.org/wikipedia/commons/0/0e/FunctionalCircuitDiagramOfKeyboardNumPadScanningProcedure.gif
Mit 16 IOs kannst du eine 8x8 Matrix aufbauen, mit der du ohne grossen 
Aufwand 256 Taster einlesen kannst (beliebig skalierbar).

Ich rate zu Schieberegistern. Die kosten zwar was, aber die Umsetzung 
ist dafür einfacher als bei einer Matrix. Einfach Bitstream rein/raus 
und fertig.

von J. W. (ontheway)


Lesenswert?

someone schrieb:
> Dein Problem ist leider nicht gerade leicht verständlich formuliert.
> Es wäre schön, wenn du dein Anliegen besser strukturierst und einen
> klareren Kontext gibst, wo du die Probleme bei der Umsetzung siehst.
>
Ich habe es absichtilich so abstrakt formuliert, damit keine 
Ideen-Spirale entsteht, wie dann wohl wann was belastet wird. Das System 
liefert mir Informationen. Ganz einfache Impulse. Ich habe den Verlauf 
doch dargestellt. Ich benutze doch gerade deshalb Abstraktion, damit 
klargestellt ist: Das System muss nichts anderes tun als Signale korrekt 
zu verwerten und auszugeben.

> Dir ist wahrscheinlich nicht klar, dass das Lesen der Eingänge und das
> Setzen der Ausgänge über SPI sehr schnell geht. Wenn sich in der
> kurzen Zeit zwischen dem Erfassen der Eingänge und dem Setzen der
> Ausgänge etwas ändert, wird das natürlich nicht sofort erfasst, sondern
> erst beim nächsten Zyklus. Das ist aber unwahrscheinlich, da das
> Auslesen und Setzen wirklich sehr schnell abläuft.
>
Da hast Du recht, das ist mir nicht klar. Aber ich will halt möglichst 
viel Sicherheit im System. Ich möchte halt Schrottsignale per hardware 
filtern, dann Sicherheit per Softwareentprellung, und dann kommt das 
Feedback der Komponenten. Das ist Standard bei SPS, auf die ein 
Kommentator hier verwies.

> Von einer Matrixschaltung rate ich dir ab. Das macht man zwar so, aber
> du scheinst schon mit deutlich einfacheren Dingen Schwierigkeiten zu
> haben, da muss man die Sache nicht unnötig verkomplizieren.

Ich weiß nicht, wie ich das interpretieren soll, aber scheinbar ist die 
Matrix ominös.

> Ein 8-Bit-Schieberegister kostet um die 30 cent, für die Ausgänge
> brauchst du 8 Stück, für die Eingänge brauchst du 16 Stück. Das sind
> 7.20 Euro, das ist verschmerzbar.
Ein Output-Board für den Rasperry-Pi kostet 9 Euro, 32 Pins 
kaskadierbar. Ich brauche eins für den Input.

von Oliver S. (oliverso)


Lesenswert?

J. W. schrieb:
> Ich möchte halt Schrottsignale per hardware
> filtern,

Dann bau dir 128 Hardwarefilter vor die 128 Eingänge, die das filtern, 
was du als Schrott definierst.

J. W. schrieb:
> dann Sicherheit per Softwareentprellung,

Dann schreib eine Softwareentprellung in deine Software.

J. W. schrieb:
> und dann kommt das
> Feedback der Komponenten.

Genau.

Um die schon mehrfach geäußerte Frage zu wiederholen:
Wo ist das Problem?

Und bevor du hier weiter an Problemen herumtheoretisierst, die es gar 
nicht gibt (und dafür die noch gar nicht kennst, die kommen werden), 
fang doch einfach an.

Denn
J. W. schrieb:
> bin Neuling...

ist ja nichts schlimmes, aber alleine durch theoretisieren ohne 
Hintergrund wird sich das nicht ändern.

Nimm dir deinen Raspi, häng zwei Tasten dran, eine Lampe, und die zurück 
an eine feedback-Eingang, und dann schreib einfach mal ein Programm, bei 
dem die Lampe nur angeht, wenn beide Tasten gerückt sind.

Oliver

von J. W. (ontheway)


Lesenswert?

Oliver S. schrieb:
> J. W. schrieb:
>
> Um die schon mehrfach geäußerte Frage zu wiederholen:
> Wo ist das Problem?
Es geht mir als Theoritker, hast Recht, darum, den Problemkreis quasi 
erst einmal zu sondieren, zu studieren.

> Und bevor du hier weiter an Problemen herumtheoretisierst, die es gar
> nicht gibt (und dafür die noch gar nicht kennst, die kommen werden),
> fang doch einfach an.

Ich bin halt Theoretiker, ja, aber das hat auch Vorteile, finde ich.

> Nimm dir deinen Raspi, häng zwei Tasten dran, eine Lampe, und die zurück
> an eine feedback-Eingang, und dann schreib einfach mal ein Programm, bei
> dem die Lampe nur angeht, wenn beide Tasten gerückt sind.
>

Wie definierst Du, das beide Tasten gleichzeitig gedrückt sind? Wenn du 
dich mit annähernd Lichtgeschwindigkeit an den Tasten vorbeibewegst... 
ach egal ;)

Alles gut, ich jammer schon früh genug.

von Karl (Gast)


Lesenswert?

J. W. schrieb:
> Ich habe es absichtilich so abstrakt formuliert, damit keine
> Ideen-Spirale entsteht, wie dann wohl wann was belastet wird. Das System
> liefert mir Informationen. Ganz einfache Impulse. Ich habe den Verlauf
> doch dargestellt. Ich benutze doch gerade deshalb Abstraktion, damit
> klargestellt ist: Das System muss nichts anderes tun als Signale korrekt
> zu verwerten und auszugeben.

Die Frage ist wie schnell und wie sauber sind die Impulse. Daraus ergibt 
sich, wie viel Aufwand man treiben muss. Werden die "Taster" durch 
Menschen gedrückt? Dann ist der RPI schnell genug, dass zu machen. 
Kommen die Signale mit deutlich höherer Frequenz geht es irgendwann 
nicht mehr. Du hast irgendwie noch nicht verstanden, wie schnell so eine 
Datenübertragung stattfindet. Du hast angst davor, dass wenn man seriel 
einließt das Signal sich schon geändert hat, bevor alle Daten gelesen 
wurden. Mit deinen Fingern kannst du aber gar nicht so schnell drücken, 
wie der RPI lesen kann.

Ob du wirklich einen Hardwarefilter bauen möchtest, solltest du nochmal 
überlegen. Auch ob es wirklich notwendig ist, die Ausgänge zu 
überwachen. Wenn du davon ausgehst, dass das sicherheitsrelevant ist, 
solltest du bei deinem Kenntnisstand die Finger davon lassen und eine 
SPS nehmen. Das ist noch ein bisschen mehr drin, als du denkst.

von Karl (Gast)


Lesenswert?

J. W. schrieb:
> Wie definierst Du, das beide Tasten gleichzeitig gedrückt sind? Wenn du
> dich mit annähernd Lichtgeschwindigkeit an den Tasten vorbeibewegst...
> ach egal ;)

Genau dass macht ein µC. Er guckt für einen Takt ob Spannung am Eingang 
anliegt (Strom vließt mit annähernd Lichtgeschwindigkeit) und schreibt 
das Ergebnis in ein Register. Damit kannst du dann weiterarbeiten.

von Oliver S. (oliverso)


Lesenswert?

J. W. schrieb:
> Wie definierst Du, das beide Tasten gleichzeitig gedrückt sind?

Ich? Gar nicht. Das ist dein Projekt, nur du kennst die Anforderungen, 
also wirst du das definieren müssen. Und die Definition dann in Software 
umsetzen. Das bringt dich unweigerlich zur nächsten Frage: Wann ist EINE 
Taste gedrückt ?

Sich vorab Gedanken zu machen ist prima. Aber selbstausgedachte Probleme 
zu lösen bringt dich nicht weiter. Fang lieber an, und löse die 
aufkommenden Probleme. Das ist bei deinem Kenntnisstand zielführender.

Oliver

von J. W. (ontheway)


Lesenswert?

Karl schrieb:
> Ob du wirklich einen Hardwarefilter bauen möchtest, solltest du nochmal
> überlegen. Auch ob es wirklich notwendig ist, die Ausgänge zu
> überwachen. Wenn du davon ausgehst, dass das sicherheitsrelevant ist,
> solltest du bei deinem Kenntnisstand die Finger davon lassen und eine
> SPS nehmen. Das ist noch ein bisschen mehr drin, als du denkst.

Danke für die Warnung, aber es geht mir doch gerade darum abzuschätzen, 
wie weit ich mit dem System kommen kann. Mit ziemlicher Sicherheit wird 
eine SPS eingebaut. Und nun? Ja, meine Kenntnisse sind nicht 
überwätigend, aber es geht um simple Logik. Diverse Bauteile werden ein 
"GO!" liefern oder ein "FAIL!". Ich prüfe gerade für mich, wie das zum 
Beispiel mit dem Rasp möglich ist. Ich habe doch, glaube ich, estra 
betont, dass das gerade die Basis für ein Experiment liefert. Das ist 
Theorie!

In der Erprobung werde ich schon noch genug jammern!


LG

von Karl (Gast)


Lesenswert?

Du hast immer noch nicht gesagt, wie schnell es den nun sein soll. Damit 
hat sich alles weitere erübrigt.

J. W. schrieb:
> Diverse Bauteile werden ein
> "GO!" liefern oder ein "FAIL!". Ich prüfe gerade für mich, wie das zum
> Beispiel mit dem Rasp möglich ist.

So lange niemand weis wie ein "GO!" oder "FAIL!" aussehen soll, wird dir 
auch keiner helfen können. Anstatt mit Bullshit-Bingo solltest du dich 
mal mit Fachwörtern beschäftigen. Das fängt schon beim Titel des Threads 
an.

"Massive IO Porterweiterung - Stabilität des IO"

Wenn es massiv werden soll, würde ich Blei empfehlen, dass ist ziemlich 
massiv. Wenn die Stabilität nicht ausreicht, kann man Stahl nehmen, der 
lässt sich aber nicht so gut Verarbeiten. Damit wäre deine Frage 
geklärt.

Für ein mikrocontroller.net Thread wurdest du ziemlich lange ziemlich 
nett behandelt.

von Peter D. (peda)


Lesenswert?

J. W. schrieb:
> Wenn ich eine oder mehrere Tasten berühre, dann gehen die
> entsprechenden Lampen an. Aber die gehen nur an, wenn gewisse Tasten
> zusammen gedrückt und andere nicht gedrückt sind

Das soll wohl heißen, Du hast ein Hardwareproblem.
Die SPI-Leitungen sind sehr störempfindlich, weil die HC-Logik sehr 
schnell ist (>20MHz). SPI-Leitungen sollte die Platine nicht verlassen 
und GND-Plane, Abblock-Cs sind Pflicht.
Falls SPI die Platine doch verlassen soll, dann differentiell (RS-485 
Transceiver).
Alles andere kann funktionieren, ist aber trotzdem Pfusch.

Ich hab schon mehrere SPI-Implementierungen hinter mir, die neueren 
laufen alle rock-solid.
Die ersten Versuche wollen wir lieber vergessen. Auch die Würg-Arounds 
mit RC-Gliedern und Schmitt-Trigger.

von someone (Gast)


Lesenswert?

Ich empfehle dir, dein Problem nochmal zu überdenken.

J. W. schrieb:
> someone schrieb:
>> Dein Problem ist leider nicht gerade leicht verständlich formuliert.
>> Es wäre schön, wenn du dein Anliegen besser strukturierst und einen
>> klareren Kontext gibst, wo du die Probleme bei der Umsetzung siehst.
>>
> Ich habe es absichtilich so abstrakt formuliert, damit keine
> Ideen-Spirale entsteht, wie dann wohl wann was belastet wird. Das System
> liefert mir Informationen. Ganz einfache Impulse. Ich habe den Verlauf
> doch dargestellt. Ich benutze doch gerade deshalb Abstraktion, damit
> klargestellt ist: Das System muss nichts anderes tun als Signale korrekt
> zu verwerten und auszugeben.

Abstraktion ist schön und gut, aber du musst dich mit der konkreten 
Sache gut genug auskennen, um sinnvoll abstrahieren zu können. Du 
denkst, dass du abstrahierst, leider gehen dabei bei dir wichtige 
Informationen verloren, die man zur Bewertung deines Problems und 
möglicher Lösungsansätze bräuchte.
Dass du darüberhinaus auch noch fest auf irgendeine Art der Lösung 
eingefahren bist, die du uns aber nicht verraten willst, macht die Sache 
nicht einfacher. Es ist kein Problem, wenn du dich nicht auskennst, aber 
dann sei bitte so gut und entscheide dich: Willst du vernünftige Hilfe 
bei Bauteilauswahl und Implementierung, so konkretisiere dein Problem. 
Willst du wissen, ob dein abstraktes Problem mit deiner Auswahl von 
Bauteilen funktioniert, teile uns die Bauteilauswahl und Verschaltung 
mit.

Du hast übrigens wichtige Daten zu den "ganz einfachen Impulsen" nicht 
genannt. Wie schnell, wie häufig, wie lang? Daran sieht man leider 
schon, dass du ziemlich wenig Ahnung hast. Das ist kein Problem und 
viele Leute helfen gerne, aber dann tu bitte nicht so, als hättest du 
das alles gar nicht nötig.

>> Dir ist wahrscheinlich nicht klar, dass das Lesen der Eingänge und das
>> Setzen der Ausgänge über SPI sehr schnell geht. Wenn sich in der
>> kurzen Zeit zwischen dem Erfassen der Eingänge und dem Setzen der
>> Ausgänge etwas ändert, wird das natürlich nicht sofort erfasst, sondern
>> erst beim nächsten Zyklus. Das ist aber unwahrscheinlich, da das
>> Auslesen und Setzen wirklich sehr schnell abläuft.
>>
> Da hast Du recht, das ist mir nicht klar. Aber ich will halt möglichst
> viel Sicherheit im System. Ich möchte halt Schrottsignale per hardware
> filtern, dann Sicherheit per Softwareentprellung, und dann kommt das
> Feedback der Komponenten. Das ist Standard bei SPS, auf die ein
> Kommentator hier verwies.

Was ist ein Schrottsignal? Was heißt Sicherheit im Kontext deiner 
Anwendung? Was sind die Fehlersituationen, die du abfangen willst? Und 
nein, "ich will, dass der Pin schaltet, wenn ich ihm das sage" ist keine 
sinnvolle Spezifikation.
Was passiert bei Ausfall einer Komponente? Was passiert bei 
Softwareabsturz? Herrschen für Einschalten andere Timing-Vorgaben als 
für Ausschalten?

>> Von einer Matrixschaltung rate ich dir ab. Das macht man zwar so, aber
>> du scheinst schon mit deutlich einfacheren Dingen Schwierigkeiten zu
>> haben, da muss man die Sache nicht unnötig verkomplizieren.
>
> Ich weiß nicht, wie ich das interpretieren soll, aber scheinbar ist die
> Matrix ominös.

Eine Matrix für Ein- und Ausgänge ist die offensichtliche Lösung. Sie 
ist kostengünstig, erweiterbar und bewährt. Leider benötigt man dafür 
etwas Hirnschmalz, um die Ansteuerung der Zeilen- und Spaltentreiber zu 
programmieren und nachher die Signalauswertung umzusetzen. Aufgrund 
deiner bisherigen Beiträge kann dir davon nur abgeraten werden, da du 
nicht den Eindruck machst, irgendeinen Teil des Projekts bereits 
durchdrungen zu haben: Weder bei Hardware noch bei Software habe ich das 
Gefühl, dass du genau weißt, was du tust. Daher empfehle ich die 
möglichst einfache Lösung, wenngleich diese teurer ist als notwendig.

>> Ein 8-Bit-Schieberegister kostet um die 30 cent, für die Ausgänge
>> brauchst du 8 Stück, für die Eingänge brauchst du 16 Stück. Das sind
>> 7.20 Euro, das ist verschmerzbar.
> Ein Output-Board für den Rasperry-Pi kostet 9 Euro, 32 Pins
> kaskadierbar. Ich brauche eins für den Input.

Ich dachte, du hast 128 Eingänge? Dann brauchst du halt 5 Stück und 
kannst dir nicht aussuchen, welche Komponenten darauf verbaut sind.

von Hans-Georg L. (h-g-l)


Lesenswert?

J. W. schrieb:
>
> Jetzt zum Algorithmus:
> 0. Systemzustand checken
> 1. Eingänge checken
> 2. Eingänge logisch bearbeiten
> 3. Ausgänge belegen
> 4. Ausgänge checken
> 5. zurück zu 0.
>
> Mir grummelt da der Bauch, das kann nur schief gehen... von Zustand 2.
> bis 4. ist 1. unbeobachtet.

Da musst du ein FPGA nehmen.
Mit einem MC funktioniert das nicht.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

J. W. schrieb:
> Zuerst: Wie würdet ihr dieses Problem in den Griff bekommen?
Ich kann da keinerlei "Problem" erkennen. Viele Eingänge mit vielen 
Ausgängen zu verknüpfen ist seit vielen Jahren ganz problemlos lösbar. 
Man nimmt eine SPS.

J. W. schrieb:
> Ich prüfe gerade für mich, wie das zum Beispiel mit dem Rasp möglich ist.
Es ist auch mit einem RPi sicher möglich, so eine SPS aufzubauen. Man 
muss sich nur ein wenig um das "Echtzeitverhalten" kümmern.

J. W. schrieb:
> Ja, aber genau das verstehe ich nicht: Nehmen wir an, ich nehme einen
> 74HC165, wenn ich die Eingänge prüfe, also parallel die Eingänge habe
> und nun seriell die Werte abarbeite, ist das dann beim 74HC165 der in
> genau diesem Moment der Abfrage vorliegende Spannungswert? Also muss ich
> softwaremäßig mehrmals abfragen um zu entprellen?
Du verknotest da mehrere Abstraktionsebenen und willst die alle "in 
einem Rutsch" erledigen. Das wird sicher schief gehen. Du brauchst einen 
anderen Ansatz, der dein "Monsterproblem" in kleinere Teilprobleme 
aufgliedert.
Und dann ist das erste davon: die Hardware. Wie bekommst du 
betriebssicher die Eingänge eingelesen?
Die nächste ist : die Signalkonditionierung. Das ist Entprellen, 
Entfernen von Glitches usw. Das passiert in der Software, denn die kann 
man leicht updaten.
Danach kommt: die Auswertung. Jetzt kannst du deine "logischen 
Verknüpfungen" mit den aufbereiteten und verlässlichen Signalen 
auswerten. Und das passiert am Einfachsten ohne Race-Conditions indem du 
(wie weltweit in zigmillionen SPSen) zyklisch erst alle Eingänge 
einliest und dann mit diesem statischen "Eingangsabbild" deine Logik 
ausführst und dann das Ergebnis auf die Ausgänge schreibst. Danach 
beginnt dieser Zyklus wieder von vorn.

Auf keinen Fall(!!!) solltest du im Verlauf des Programms direkt 
Eingänge abfragen. Bei manchen Geräten, die sich "ab und zu" seltsam 
verhalten, sehe ich solche Programmierfehler direkt vor mir...

: Bearbeitet durch Moderator
von bernhard (Gast)


Lesenswert?

Ich verweisse mal auf ein anderes Forum...

http://www.sps-forum.de/codesys-und-iec61131/68431-codesys-auf-dem-raspberry-pi-jetzt-verfuegbar.html

Wobei ich denke, der TO ist auch da etwas überfordert...

von Stefan ⛄ F. (stefanus)


Lesenswert?

> Ich möchte aber wissen, zum Beispiel, ob die Lampe überhaupt angehen
> konnte, weil OUT da war, also koppel ich zurück auf 64 IN,
> Sicherheitscheck.

Moment mal, da die Steuerung darüber entscheidet, wann die Lampen and 
bzw. aus gehen, kann sie zu jeder Zeit wissen, in welchem Status sich 
die Lampen-Ausgänge befinden (es sei denn, sie sind defekt).

> weil OUT da war

Was soll das heissen? Willst du die Existenz eines Anschlusses 
kontrollieren?

Unabhängig davon, kannst du relativ einfach hunderte I/O Anschlüsse mit 
Hilfe von Schieberegistern realisieren, oder über I2C Bus mit 
entsprechenden Chips. 8x PCF8574 + 8x PCF8574A ergibt 128 I/O Leitungen. 
Und mit Hilfe mehrerer I2C Busse (notfalls per Software emuliert) kannst 
du das beliebig vervielfachen.

Um die Stabilität mach Dir mal keine Sorgen. Wenn die Schaltung nicht 
zuverlässig funktioniert, ist siefehlerhaft. Auf korrekte Schaltungen 
kannst du dich 99,99999999% verlassen.

: Bearbeitet durch User
von J. W. (ontheway)


Lesenswert?

Lothar M. schrieb:
> J. W. schrieb:
>> Zuerst: Wie würdet ihr dieses Problem in den Griff bekommen?
> Ich kann da keinerlei "Problem" erkennen. Viele Eingänge mit vielen
> Ausgängen zu verknüpfen ist seit vielen Jahren ganz problemlos lösbar.
> Man nimmt eine SPS.
>
> J. W. schrieb:
>> Ich prüfe gerade für mich, wie das zum Beispiel mit dem Rasp möglich ist.
> Es ist auch mit einem RPi sicher möglich, so eine SPS aufzubauen. Man
> muss sich nur ein wenig um das "Echtzeitverhalten" kümmern.
>
> J. W. schrieb:
>>
> Du verknotest da mehrere Abstraktionsebenen und willst die alle "in
> einem Rutsch" erledigen. Das wird sicher schief gehen. Du brauchst einen
> anderen Ansatz, der dein "Monsterproblem" in kleinere Teilprobleme
> aufgliedert.
> Und dann ist das erste davon: die Hardware. Wie bekommst du
> betriebssicher die Eingänge eingelesen?
Exakt! Das ist aber nicht mein Problem, dafür wird gesorgt.
Ich bekomme ein sicheres "1" für okay und "0" für no-go.
> Die nächste ist : die Signalkonditionierung. Das ist Entprellen,
> Entfernen von Glitches usw. Das passiert in der Software, denn die kann
> man leicht updaten.
Das wird mich sicher noch beschäftigen, denn optimal hätte die Hardware 
natürlich keine Glitches usw.
> Danach kommt: die Auswertung. Jetzt kannst du deine "logischen
> Verknüpfungen" mit den aufbereiteten und verlässlichen Signalen
> auswerten. Und das passiert am Einfachsten ohne Race-Conditions indem du
> (wie weltweit in zigmillionen SPSen) zyklisch erst alle Eingänge
> einliest und dann mit diesem statischen "Eingangsabbild" deine Logik
> ausführst und dann das Ergebnis auf die Ausgänge schreibst. Danach
> beginnt dieser Zyklus wieder von vorn.
Exakt das möchte ich.
>
> Auf keinen Fall(!!!) solltest du im Verlauf des Programms direkt
> Eingänge abfragen. Bei manchen Geräten, die sich "ab und zu" seltsam
> verhalten, sehe ich solche Programmierfehler direkt vor mir...
Habe ich nicht vor, auf keinen Fall.

Entschuldigung für meine Unkenntnis, an alle, und danke für die Geduld. 
Du bringst es denke ich auf den Punkt. Wie es schon in anderen 
produktiven Beiträgen genannt wurde: Es ist im Prinzip die Logik einer 
SPS. Von der ich zwar auch nicht viel weiß, aber Fakt ist, dass 
ersichtlich dort extreme Zuverlässigkeit herrscht.

Da ich schon mehrmals dafür kritisiert wurde, dass ich nicht konkret 
genug bin: Es geht um die Ansteuerung eines Verstärkers, mit diversen 
Endstufen etc. Wenn zum Beispiel eine Endstufe hochgefahren wird 
(Röhrentechnik), dann bekomme ich erst GO nachdem die Endstufe 
betriebsbereit ist.
Wenn ein Bauteil ausfällt oder von miraus ein Temperaturmelder sagt, 
hier ist was im Argen!!, dann reagiert mein System.

Das ist aber ein elektronisches Ding, um das ich mich nicht kümmer. Es 
geht um kein Echtzeit-System, da habe ich mich ersichtlich falsch 
ausgedrückt. Mir geht es nur um viele Inputs und viele Outputs.

Gerne dazu weitere Kritik, aber was haltet ihr von Boards mit SPI und 
zum Beispiel 165 über Optokoppler am Input und dergleichen zum Beispiel 
über Relais im Output?
Die Schaltung, die mir vorschwebt, ist ja im Alghoritmus oben 
wiedergegeben, ich sehe da erst einmal kein technisches Problem, und die 
Abfrage kann auch gerne gemäß der Anwendung "recht lange" dauern, 
genaueres muss ich noch prüfen.. der Teufel steckt im Detail, wie 
immer...

Dennoch, eine grundsätzliche Frage: Einige favorisieren I2C, andere 
sagen SPI... gibt es da Erfahrungswerte in diesem Bereich, viele In- und 
Outputs? Mein möglicherweise falsches Grundgefühl sagt mir: Ich 
kaskadiere einfach mit SPI durch mehrere Bausteine, halt zum Beispiel 4 
16bit Input-Platinen... oder was ist nun der Vorteil von I2C?

Danke und sorry nochmal!

von Axel S. (a-za-z0-9)


Lesenswert?

J. W. schrieb:

> Da ich schon mehrmals dafür kritisiert wurde, dass ich nicht konkret
> genug bin: Es geht um die Ansteuerung eines Verstärkers, mit diversen
> Endstufen etc. Wenn zum Beispiel eine Endstufe hochgefahren wird
> (Röhrentechnik), dann bekomme ich erst GO nachdem die Endstufe
> betriebsbereit ist.
> Wenn ein Bauteil ausfällt oder von miraus ein Temperaturmelder sagt,
> hier ist was im Argen!!, dann reagiert mein System.

Aha. So ein Blödsinn

Was soll denn das für eine Monster-Installation sein, wo du zur 
Steuerung "eines Verstärkers" 128 Eingänge und 64 Ausgänge brauchst? 
Warum würde man Dinge wie die Notabschaltung bei Übertemperatur oder 
Gleichspannung am Ausgang überhaupt über eine zentrale Steuerung machen 
wollen? Das kann man doch alles (besser) autark machen und bestenfalls 
den Status an eine Zentrale melden.

> Gerne dazu weitere Kritik, aber was haltet ihr von Boards mit SPI und
> zum Beispiel 165 über Optokoppler am Input und dergleichen zum Beispiel
> über Relais im Output?

Vollkommen unsinnig. Potentialtrennung über Optokoppler und Relais macht 
man dann (und nur dann) wenn man es braucht. Andererseits schreibst du 
oben "Röhrentechnik". Deine Zielgruppe sind also anscheinend Leute mit 
wenig Ahnung aber desto mehr Geld. Und dann beruhigt es natürlich dein 
Gewissen, wenn du ihnen mit Optokopplern wenigstens eine gewissen 
Gegenwert lieferst.

> Die Schaltung, die mir vorschwebt, ist ja im Alghoritmus oben
> wiedergegeben

Abu Dscha'far Muhammad ibn Musa al-Chwarizmi würde sich im Grabe 
herumdrehen, wenn er lesen müßte daß du dein Geschwafel oben als 
"Algorithmus" bezeichnest.

> ... eine grundsätzliche Frage: Einige favorisieren I2C, andere
> sagen SPI... gibt es da Erfahrungswerte in diesem Bereich, viele In- und
> Outputs?

SPI ist tendenziell schneller und mit weniger Problemen ausbaubar (keine 
Beschränkung durch den Adreßraum). Aber in deinem Fall wäre beides 
Perlen vor die Säue geworfen.

von J. W. (ontheway)


Lesenswert?

Axel S. schrieb:
> J. W. schrieb:

>
> Aha. *So ein Blödsinn*

> Vollkommen unsinnig. Potentialtrennung über Optokoppler und Relais macht
> man dann (und nur dann) wenn man es braucht. Andererseits schreibst du
> oben "Röhrentechnik". Deine Zielgruppe sind also anscheinend Leute mit
> wenig Ahnung aber desto mehr Geld. Und dann beruhigt es natürlich dein
> Gewissen, wenn du ihnen mit Optokopplern wenigstens eine gewissen
> Gegenwert lieferst.
>

>
> SPI ist tendenziell schneller und mit weniger Problemen ausbaubar (keine
> Beschränkung durch den Adreßraum).
Danke!
> Aber in deinem Fall wäre beides
> Perlen vor die Säue geworfen.

Immerhin haben Sie in Ihrem Gepöbel eine brauchbare Information 
geäußert.
Genau wegen disem Ihrem peinlichen Gepöbel halte ich es lieber abstrakt, 
da ansonsten so wie bei Ihnen gleich Bewertungen erfolgen, die aber dem 
Ziel nicht dienlich sind.

Auf Ihre Perlen kann ich aber in Zukunft verzichten. Danke.

von someone (Gast)


Lesenswert?

Axel S. schrieb:
> Aha. So ein Blödsinn

Ich kann ja mittlerweile irgendwie schon verstehen, dass Leute ihre 
Probleme nicht vernünftig beschreiben wollen, wenn sofort nachdem sie es 
gemacht haben irgendeiner kommt und gleich das Problem niedermacht.
Es spielt keine Rolle, ob du es für sinnvoll findest, das Problem zu 
lösen oder nicht. Der Threadersteller will sich damit beschäftigen, 
dabei kannst du ihm entweder helfen oder es eben lassen.


Zum Problem an sich: Mir ist leider immer noch nicht so ganz klar, um 
was es nun geht. Schalten über Relais und Rückmeldung über Optokoppler 
ist sicher, aber natürlich auch sehr langsam. Relais schalten nicht 
besonders schnell. Außerdem ist die gesamte Beschaltung natürlich auch 
aufwendig, da du Spulentreiber etc. benötigst.
Als Sicherheitsmaßnahme würde ich eher zu Bauteilen raten, die von sich 
aus die Sicherheit herstellen und keine Softwarelösung benötigen. 
Software ist immer anfällig. Wenn Überhitzungsgefahr besteht, lieber 
zusätzlich noch eine Temperatursicherung einbauen als sich 100% auf die 
Software verlassen.

Zur Porterweiterung: I2C-Porterweiterungen sind langsamer, aber 
flexibler und brauchen nicht die Menge an Anschlüssen. Man kann sie 
einzeln adressieren und muss daher nicht immer alle auslesen.
Für deine Anwendung ist das aber ziemlich egal. Du willst ja immer alles 
auslesen und (potentiell) alles schalten.
Wie bereits erwähnt, empfehle ich dir Schieberegister für den Ausgang 
und Schieberegister für den Eingang, die dann kaskadiert werden. Dafür 
brauchst du keine überteuerte Platine mit Porterweiterungen, ein 
Schieberegister kostet um die 30 cent.
Du solltest in der Lage sein, die richtig anzuschließen, ansonsten rate 
ich dir davon ab, ein Projekt zu entwickeln, bei dem Dinge überwacht 
werden sollen, die bei fehlerhafter Überwachung zerstört werden können. 
Denn dann fehlt es einfach an Grundlagen, die später sehr problematisch 
werden können.

Die Schieberegister kannst du dann jeweils komplett auslesen bzw. die 
Ausgänge in einem Rutsch setzen und per Software in einzelne Variablen 
zerlegen, so wie du es brauchst.

von J. W. (ontheway)


Lesenswert?

someone schrieb:
> Axel S. schrieb:
>> Aha. So ein Blödsinn
>
> Ich kann ja mittlerweile irgendwie schon verstehen, dass Leute ihre
> Probleme nicht vernünftig beschreiben wollen, wenn sofort nachdem sie es
> gemacht haben irgendeiner kommt und gleich das Problem niedermacht.
> Es spielt keine Rolle, ob du es für sinnvoll findest, das Problem zu
> lösen oder nicht. Der Threadersteller will sich damit beschäftigen,
> dabei kannst du ihm entweder helfen oder es eben lassen.
>
>
> Zum Problem an sich: Mir ist leider immer noch nicht so ganz klar, um
> was es nun geht. Schalten über Relais und Rückmeldung über Optokoppler
> ist sicher, aber natürlich auch sehr langsam. Relais schalten nicht
> besonders schnell. Außerdem ist die gesamte Beschaltung natürlich auch
> aufwendig, da du Spulentreiber etc. benötigst.
Ersteinmal kein Problem.
> Als Sicherheitsmaßnahme würde ich eher zu Bauteilen raten, die von sich
> aus die Sicherheit herstellen und keine Softwarelösung benötigen.
> Software ist immer anfällig. Wenn Überhitzungsgefahr besteht, lieber
> zusätzlich noch eine Temperatursicherung einbauen als sich 100% auf die
> Software verlassen.
Natürlich gibt es interne Mechanismen, aber das ist nicht mein Job.
Ich brauche nur Rückmeldungen, die werde ich bekommen.
>
> Zur Porterweiterung: I2C-Porterweiterungen sind langsamer, aber
> flexibler und brauchen nicht die Menge an Anschlüssen. Man kann sie
> einzeln adressieren und muss daher nicht immer alle auslesen.
> Für deine Anwendung ist das aber ziemlich egal. Du willst ja immer alles
> auslesen und (potentiell) alles schalten.
Korrekt.
> Wie bereits erwähnt, empfehle ich dir Schieberegister für den Ausgang
> und Schieberegister für den Eingang, die dann kaskadiert werden. Dafür
> brauchst du keine überteuerte Platine mit Porterweiterungen, ein
> Schieberegister kostet um die 30 cent.
Hier mein Veto... ja eines kostet 30 Cent, ja und? Vorschlag...
> Du solltest in der Lage sein, die richtig anzuschließen, ansonsten rate
> ich dir davon ab, ein Projekt zu entwickeln, bei dem Dinge überwacht
> werden sollen, die bei fehlerhafter Überwachung zerstört werden können.
> Denn dann fehlt es einfach an Grundlagen, die später sehr problematisch
> werden können.
Also, das Risiko trage natürlich ich, aber wo ist das Problem mit einer 
"überteuerten Platine", das verstehe ich nicht. Für welchen Preis baust 
Du mir eine Platine mit zum Beispiel 16 Eingängen, Optokoppler, eigene 
Spannungsversorgung, kaskadierbar? Der Aufbau ist nicht so komplex, aber 
wozu soll ich das selber machen? Nenn mir Deinen Preis!

Wenn ich dafür 20 Euro oder so zahle, ist das so horrend? Lieferst Du 
billiger?
Es geht nicht um Massenproduktion, sondern darum, dass es fertig ist, 
zum probieren.
>
> Die Schieberegister kannst du dann jeweils komplett auslesen bzw. die
> Ausgänge in einem Rutsch setzen und per Software in einzelne Variablen
> zerlegen, so wie du es brauchst.

Ja genau, das will ich.
Und was kostet mich die Outputplatine bei Dir? Optokoppler und Relais?
Ich denke, Du weißt, was ich meine.
Aber danke!

PS: Gerade noch einmal diesen Beitrag lesend, ich meine das "Danke" als 
wirkliches danke. Ich meine nur, dass es doch wirklich Zeitverschwendung 
ist, eine Platine dergestalt selbst zu fummeln... wenn Du sowas aber 
machst, gerne, ich bin gespannt!

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

> Das wird mich sicher noch beschäftigen, denn optimal hätte die
> Hardware natürlich keine Glitches usw.

Ganz Recht. Finanziell lohnt es sich oft, die Hardware etwas einfacher 
zu gestalten und deren Mängel per Software auszugleichen.

von Peter D. (peda)


Lesenswert?

J. W. schrieb:
> Dennoch, eine grundsätzliche Frage: Einige favorisieren I2C, andere
> sagen SPI...

Innerhalb eines Gerätes ist das ziemlich egal, I2C ist teurer.
Zwischen Geräten würde ich CAN, RS-485 oder Ethernet nehmen.

J. W. schrieb:
> Wenn zum Beispiel eine Endstufe hochgefahren wird
> (Röhrentechnik), dann bekomme ich erst GO nachdem die Endstufe
> betriebsbereit ist.

Ich weiß ja nicht, wo und wie Du ein solches Signal abgreifen willst. 
Warum kann der Steuer-MC nicht einfach die Zeit abwarten?


Axel S. schrieb:
> Vollkommen unsinnig. Potentialtrennung über Optokoppler und Relais macht
> man dann (und nur dann) wenn man es braucht.

Na klar und die Leute, die SPS bauen, sind alles Idioten.
Gerade in größeren Geräten und Systemen kann man die Erdschleifen nur 
schwer beherrschen. Daher ist es bewährte Technik, Erdschleifen gar 
nicht erst entstehen zu lassen.
So ein Optokoppler ist doch kein Kostenpunkt. Ich habe viele 
Optokoppler, wo auf beiden Seiten quasi GND ist, aber eben von anderen 
Modulen herangeführt. Der Lohn ist eine bessere Störfestigkeit und 
Zuverlässigkeit.
Und besonders in NF-Anlagen möchte man auf keinen Fall digitales 
Gezwitscher im Hintergrund mithören.

von Axelr. (Gast)


Lesenswert?

Das rauscht und fiiept am Ende, trotzdem natürlich viel Erfolg.
Mach es einfach so, wie Du oben die vier Punkte angeführt hast. Du 
denkst im Moment einfach noch zu langsam. Du kannst Dir halt eben noch 
nicht vorstellen, wie schnell das im Inneren eigentlich abläuft.
Verstärker - hmm.
ich hatte bei Diener Beschreibung auf Modellbaueisenbahnanlage getippt.

( mich würde jetzt - völlig frei der Wertung - auch interssieren, wie 
sich die immense Anzahl IOs zusammensetzt )

Viel Spaß beim Projekt, nochmal viel Erfolg!

Axelr.
DG1RTO

von J. W. (ontheway)


Lesenswert?

Axelr. schrieb:
> Du kannst Dir halt eben noch
> nicht vorstellen, wie schnell das im Inneren eigentlich abläuft.
Ja, wie gesagt, mal schaun.
> ( mich würde jetzt - völlig frei der Wertung - auch interssieren, wie
> sich die immense Anzahl IOs zusammensetzt )
Nur soviel: Es geht um eine immense Anzahl von Röhren und Leistung, 
hiermmit verbunden, alleine durch die Röhren, üble Spannungen.
Es soll also mit Priorität kein Schaden an Leib und Leben entstehen, und 
sekundär, kein Schaden an den Bauteilen. Die Hauptaufgabe trägt die 
Hardware (zum Beispiel Schadensmeldung bis Selbstabschaltung). Die 
Software stößt Prozesse an, die kontrolliert werden. Treten Probleme 
auf, werden diese registriert und bewertet und danach gehandelt.

Im Prinzip eine Modelleisenbahn! ;-)

> Viel Spaß beim Projekt, nochmal viel Erfolg!

Danke Axel und ganz besonders auch an alle anderen positiv kritischen 
Kommentatoren (ganz besonders peda).
Ich werde schon noch früh genug rumheulen ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.