Hi liebe Leute, ich möchte SPI mehrfach nutzen. Ich möchte mehrere 595 schalten aber auch eventuell mit diesem Kontroller über SPI andere Aufgaben erledigen. Nach einigem nachforschen bin in noch nicht ganz schlau geworden über OUTPUT ENABLE aktiv low und Master Reset aktiv low. Mein Bauchgefühl sagt mir folgendes: Ich setzte OE auf High, wenn anders kommuniziert werden soll. Wenn das Register aktiv werden soll, nach Schreibevorgang, dann wieder auf Low. Ich hatte mal irgendwo gelesen, das man auch den Reset Low halten kann, das halte ich für gewagt, denn ich will auf jeden Fall vermeiden, dass die Ausgänge sich verändern bis ich das will! Was meint ihr? Bastlergrüße, Jens
J. W. schrieb: > Hi liebe Leute, > > ich möchte SPI mehrfach nutzen. Ich möchte mehrere 595 schalten aber > auch eventuell mit diesem Kontroller über SPI andere Aufgaben erledigen. > Nach einigem nachforschen bin in noch nicht ganz schlau geworden über > OUTPUT ENABLE aktiv low und Master Reset aktiv low. Die bringen dir nichts. Mit Output Enable kannst du lediglich die Ausgabe der 595 an ihre Ausgänge unterdrücken. Aber die 595 würden nach wie vor, alles was du per SPI raustaktest übernehmen. Setzt du OE danach wieder, dann kommt dann eben die Ausgabe etwas zeitverzögert. Master Reset ist einfach nur das 0-setzen der kompletten Schieberegister. Was du brauchst ist ein abklemmen der Taktleitungen. Zb mit einem Und- Gatter, welches auf einen zusätlzichen Pin am µC führt. Nur dann wenn du an diesem Pin eine 1 ausgibst, können die Takte bis zum 595 durchkommen und der 595 übernimmt Daten. Du bräuchtest 2 Und-Gatter, eines für den Schiebetakt und eines für den Latch-Takt. Du kannst aber beide vom selben Output-Pin des µC ansteuern. Hängen mehrere Geräte/IC an ein und demselben Bus und kann das Protokoll hier keine Auflösung des angesprochenen Geräts/IC leisten (wie zb bei SPI), dann muss jedes Gerät/IC einen Eingang haben, den man gemeinhin 'Chip Select' nennt. Nur dann wenn der Chip Select einen bestimmten Pegel hat (0 oder 1 je nachdem), nur dann fühlt sich das Gerät/IC angesprochen und übernimmt die Daten. Die 595 haben leider keinen Enable Eingang der als Chip Select fungieren könnte. Aber wir wissen, dass man am Dateneingang mit den Bits nur so rumfuchteln kann, wie man will. Solange sich an den Takteingängen nichts tut, übernimmt der 595 auch keine Daten. Also kann man sich einen Enable bauen, indem man einfach die Pulse auf den Taktleitungen unterdrückt, wenn ein zusätzlicher Eingang nicht richtig gesetzt ist.
Okay, danke Karl-Heinz, aber ich muss nochmal doof nachfragen: Wenn OE nicht mehr da ist, kann es mir dann nicht wurscht sein, was geschrieben wird, solange ich danach dafür sorge, dass die gewünschte Information geschrieben wird, und ich danach OE aktiviere? Oder ist das unsicher? Oder, extrem fatal, das gilt es tunlichst zu vermeiden in meinem Fall, ich will paar Relais anschalten: Gibt es einen "Flankenwechsel", also ist mal kurz alles off und wieder on? Danke! Liebe Grüße, Jens
J. W. schrieb: > Okay, danke Karl-Heinz, aber ich muss nochmal doof nachfragen: Wenn OE > nicht mehr da ist, Wenn OE nicht mehr da ist, dann gehen die Ausgangstreiber des 595 in einen Tri-State Zustand. Auf Deutsch: Wenn du zb LED drann hängen, dann gehen die alle aus. Und das willst du ja wohl in den seltensten Fällen haben, dass irgendwelche an die 595 angeschlossene Hardware 'verrückt' spielt, nur weil du gerade ein anderes SPI Gerät ansprichts und daher dem 595 die Ausgänge abdrehst.
Alles klar, Karl-Heinz, danke, super! Dann schaue ich mir jetzt die UND-Gatter an!
Output enable false bedeutet tristate. Kannst du dir das erlauben? Was macht die Peripherie zu dieser zeit?
Was du natürlich machen kannst: Du kannst alles nur über den STCP (RCLK) abhandeln. Solange der 595 keinen Puls am STCP sieht kannst du durch die Schiebekette Bits durchjagen wie es dir gefällt. Erst mit einem Puls an STCP erscheint die Belegung der Schiebekette an den Ausgängen. Das würde auch gehen.
Karl Heinz Buchegger schrieb: > > Was du brauchst ist ein abklemmen der Taktleitungen. Zb mit einem Und- > Gatter, welches auf einen zusätlzichen Pin am µC führt. Nur dann wenn du > an diesem Pin eine 1 ausgibst, können die Takte bis zum 595 durchkommen > und der 595 übernimmt Daten. Du bräuchtest 2 Und-Gatter, eines für den > Schiebetakt und eines für den Latch-Takt. Du kannst aber beide vom > selben Output-Pin des µC ansteuern. > Nochmal gefragt von einem Elekronik-Anfänger: Hast Du einen Tipp für so einen Baustein? Danke!
Hi! Falls du Ahnung von VHDL hast, könntest du dir auch deinen eigenen Chip auf einem CPLD machen. Ein MAX von Altera (die alten 5V Modelle, im 0.8mm QFP) kostet vielleicht 1,5€. Die eignen sich ideal als Port-Expander und solche serial-in parallel-out Sachen sind wirklich ganz kleine und einfache Designs. Dann brauchst du auch nur einen einzigen IC dafür.
Klingt spannend, aber ich schaue mir mal den MOS 4085 an
Du brauchst nichts zusätzliches. Das RCLK ist quasi das /SS des 595. Die 595-er kann man alle kaskadieren. Ansonsten braucht jeder SPI-Slave sein eigenes /SS (Slave Select) vom Master.
Peter Dannegger schrieb: > Du brauchst nichts zusätzliches. > Das RCLK ist quasi das /SS des 595. > Die 595-er kann man alle kaskadieren. > Ansonsten braucht jeder SPI-Slave sein eigenes /SS (Slave Select) vom > Master. Hi Peter, bedeutet das aber, dass durch das RCLK, welches als /SS dient, automatisch der 595 nicht beschrieben wird, sprich, der Baustein überhaupt nichts mitbekommt von jedwelcher Kommunikation über die Eingänge? Die Idee von Karl-Heinz ist ja, so könnte ich das umsetzen, dass ich UND-Gatter an RCLK koppel, dann ist sozusagen die absolute Ruhe am Eingang des 595. Die Idee finde ich eigentlich ganz symphatisch, weil ansonsten wohl, sehe ich das richtig, per Software garantiert sein muss, dass niemals ein versehentliches RCLK für Chaos sorgt. Klar möchte ich das eh vermeiden, aber ich möchte möglichst sicher arbeiten. Ist das nicht eine Zusatzsicherung für die Ausgangspins? Danke, Jens
oh man, totaler Quatsch, was ich gerade geschrieben habe, oder? Ich möchte ja die Eingänge des 595 beschreiben, bevor ich auf RCLK auf High gehe! Das heißt, ich bräuchte einen Extra-Eingang am 595 den ich UND-koppel, stimmts? Jens
J. W. schrieb: > Die Idee finde ich eigentlich ganz symphatisch, weil > ansonsten wohl, sehe ich das richtig, per Software garantiert sein muss, > dass niemals ein versehentliches RCLK für Chaos sorgt. Trau dir einfach zu, daß du das mit deinem Programm hinkriegst. J. W. schrieb: > Ist das nicht eine Zusatzsicherung für die Ausgangspins? Geht für mich ein bisschen in Richtung Paranoia. Wenn es sich per Software lösen lässt, würde ich da keine weitere Hardware zusätzlich einbauen. Aber muss jeder selber wissen. mfg.
Wenn Du schon I²C in Betrieb hast, oder in Betrieb nehmen willst, so kannst Du ja auch einen Port/Baustein, an Stelle der 595 nehmen. Dann geht's auch ohne Verrenkungen. Und wesentlich komfortabler, da Du an Einzelbits/-ports rumfummeln kannst, ohne immer alles neu auszugeben.
amateur schrieb: > Dann > geht's auch ohne Verrenkungen. Und wesentlich komfortabler, da Du an > Einzelbits/-ports rumfummeln kannst, ohne immer alles neu auszugeben. Was denn für Verrenkungen? Dafür schreibt man einmal eine Funktion, die Variable, die die Ausgänge der 595er repräsentieren, von einem Timer getriggert, zyklisch ausgibt. Die Bits werden dann genauso wie bei echten Ports in die Variable geschrieben. Um den Rest kümmert sich die Funktion. mfg.
Bei der seriellen Ausgabe musst Du immer alle neu Durchschubsen, auch wenn sich nur ein Bit ändert. Mit System kannst Du ein einzelnes Bit bestimmen. Und was auch, außer in optischen Systemen, störend ist, in der Zwischenzeit musst du die Ausgänge abschalten. Darüber hinaus mag nicht jeder Eingang den Z-Zustand.
> Trau dir einfach zu, daß du das mit deinem Programm hinkriegst. > Klar, aber in Sicherheit hatte ich mal ein Dokument von Siemens gesehen, eigentlich ganz klar, Prioritäten, falls das System als solches funktioniert: Höchste Stufe: Hardware kann versagen. Es muss gesichert sein, dass ein Ausfall von Hardwarekomponenten keine katastrophalen Auswirkungen auf das Gesamtsystem hat. Fehlfunktionen müssen gemeldet werden an die Softwareebene. Mittlere Stufe: Software kann versagen. Die Software muss die Hardware kontrollieren, aber ein Versagen darf nicht dazu führen, dass die Hardware in einen problematischen Zustand gerät. Niedriegste Stufe: Der Mensch. Der Mensch kann in der Bedienung der Software versagen. Fehlbedienung darf nicht in der Softwareebene für Versagen sorgen. >> J. W. schrieb: >> Ist das nicht eine Zusatzsicherung für die Ausgangspins? > Geht für mich ein bisschen in Richtung Paranoia. Wenn es sich per > Software lösen lässt, würde ich da keine weitere Hardware zusätzlich > einbauen. Aber muss jeder selber wissen. Siehe oben. Du hast natürlich vollkommen recht, wenn Du 100 Leuchtdioden an einem Weihnachtsbaum blinken lässt, ist das wurscht. Aber falls ich fette Schütze oder Relais anschließe, dann grummelt es mir im Bauch. Magst recht haben, aber ich denke, ich würde auf Nummer sicher gehen. Denn bei der Idee mit den UND-Gliedern hat man eine Sicherheitsstufe mehr, schaden kann es nicht. LG Jens
amateur schrieb: > Bei der seriellen Ausgabe musst Du immer alle neu Durchschubsen, auch > wenn sich nur ein Bit ändert. Ich muss gar nichts. Das macht der Controller. Wie gesagt: Eine Funktion. amateur schrieb: > Und was auch, außer in optischen Systemen, störend ist, in > der Zwischenzeit musst du die Ausgänge abschalten. Darüber hinaus mag > nicht jeder Eingang den Z-Zustand. Du weisst wohl nicht wie 595er funktioniert. J. W. schrieb: > Aber falls ich > fette Schütze oder Relais anschließe, dann grummelt es mir im Bauch. Wo willst du da die Grenze ziehen? Dann must du ein komplett redundantes System aufbauen. Denn sowohl der Controller als auch die "Sicherungslogik" können in die Knie gehen, weil sich beim Netzteil eine Diode verabschiedet hat. mfg.
J. W. schrieb: > Denn bei der Idee mit den UND-Gliedern hat man eine Sicherheitsstufe > mehr, schaden kann es nicht. Doch, kann es. Du hast ein weiteres aktives Bauteil hinzugefügt - und das kann kauptt gehen oder sich sonstwie unerwartet verhalten. Wenn Du tatsächlich so große Sorgen bezüglich "unerwartetem Verhalten an RCLK" hast, dann würde ich lieber noch zwei zusätzliche Pins spendieren und Software-SPI (Bit-Banging) machen, dann hast Du die Ansteuerung der Relais viel besser vom restlichen Zeugs auf SPI entkoppelt. Sind die restlichen Teile der Relais- und Schützansteuerung auch schon entsprechend robust? Hast Du Pull-Downs für RCLK vorgesehen während der Controllerausgang im Tri-State ist, etc.? Gruß, Bernd
J. W. schrieb: > Die Idee finde ich eigentlich ganz symphatisch, weil > ansonsten wohl, sehe ich das richtig, per Software garantiert sein muss, > dass niemals ein versehentliches RCLK für Chaos sorgt. Die Idee ist Quatsch. Wenn Du der Meinung bist, daß Du den RCLK-Pin nicht richtig programmieren kannst, warum solltest Du dann die anderen Pins richtig programmieren können? Es ist völlig wurscht, welchen Pin Du falsch ansteuerst, ob RCLK, SRCLK oder SER.
amateur schrieb: > Und wesentlich komfortabler, da Du an > Einzelbits/-ports rumfummeln kannst, ohne immer alles neu auszugeben. ??? Das mußt Du mal erklären. Bei I2C ist der Aufwand sogar noch höher, da Du erst die Adresse senden mußt. Bei SPI schiebst Du 8 Bit rein und gut. Bei I2C (PCF8574) mußt Du aber 18 Bits schieben und Du kannst Die auch nicht kaskadieren. Bei max 16 IO-Expander ist Schluß.
@Peter Wenn 16 IO-Expander nicht ausreichen, ist an anderer Stelle etwas in die Hose gegangen. Ich erinnere mich irgendwo mal Port-Expander gesehen zu haben die 16 Bit breit sind, allerdings nicht von Phillips, NXP oder wie die jetzt heißen. Die von Dir erwähnten 18 Bits reichen aber aus, um jedes beliebige der 128 Bits persönlich zu begrüßen.
Peter Dannegger schrieb: > amateur schrieb: >> Und wesentlich komfortabler, da Du an >> Einzelbits/-ports rumfummeln kannst, ohne immer alles neu auszugeben. > > ??? > Das mußt Du mal erklären. Hallo zusammen, ich versuche mal Verständnis zu stiften: <verständnis stiften> Die Gefahr, die einige hier sehen ist, dass bei gemeinsamer Nutzung der Controller-SPI-Pins zwischen den 595 und anderen SPI-Teilnehmern die erste Stufe der 595 ("vordere" FFs) mangels nSS-Pin immer neu beschrieben werden. Das ist eigentlich nicht gewünscht - aber auch ohne zusätzliche Hardware wie das vorgeschlagene AND-Gatter nicht zu vermeiden, da der 595 eben kein richtiger SPI-Baustein ist, sondern "nur" ein Schieberegister. Die Befürchtung von ontheway ist nun, dass ein (aus welchem Grunde auch immer verursachtes) unbeabsichtigtes Aktivieren von RCLK an den 595 den Datenmüll, den sich die 595 durch einen vorherigen SPI-Transfer für einen anderen SPI-Baustein eingefangen haben 1:1 an die Ausgänge weitergeben und die dort angeschlossenen Relais dann Unheil anrichten könnten. Bevor der RCLK-Pin aktiviert werden kann, müssen die FFs also erst wieder neu geladen werden - und das bezeichnet amateur als "alles immer neu ausgeben". </verständnis stiften> Das "alles immer neu ausgeben" ist aber wie Peter schreibt ein Denkfehler, denn am RCLK-Pin erzeugt man ohnehin nur dann eine positive Flanke, wenn die Ausgänge der 595 anders gesetzt werden sollen - und in diesem Fall muß die Kette der 595 sowieso zwingend neu geladen werden. Wenn man den RCLK-Pin (vor lauter Paranoia) immer wieder neu setzen will, dann müsste man tatsächlich immer wieder neu laden - aber das sollte man dann sowieso tun, denn wenn man den Ausgängen schon nicht vertraut, sollte man den Eingangsstufen auch nicht vertrauen und lieber neu laden. Ist aber wie schon geschrieben unbegründete Paranoia. Die technisch und ökonomisch sinnvollste Lösung ist, die 595 einfach 1:1 an SCLK und MOSI zu hängen und einen PortPin für RCLK vorzusehen. Dieser PortPin sollte sicherheitshalber mit einem Pull-Down versehen werden, damit im Reset des Controllers und nach Power-On definierte Bediungungen vorliegen. Dann noch ein paar Gedanken in die Beschaltung von SRCLR und OE investieren, damit beim Init und beim Programmieren des Controllers alles geordnet abläuft und gut. Gruß, Bernd
Bernd O. schrieb: > Dieser > PortPin sollte sicherheitshalber mit einem Pull-Down versehen werden Dieser Pulldown bewirkt dann genau 0,nix. Der Einschaltzustand einfacher Logik-ICs ist nämlich nicht definiert. Blöderweise wirkt der Resetpin auch nur auf das unwichtige Schieberegister, nicht aber auf das bestimmende Ausgangsregister. Die einzige Lösung ist daher, den /OE per Pullup zu deaktivieren, bis der MC gültige Daten eingeschrieben hat. Und die Ausgänge sind solange mit Pullup/Pulldown auf nichtaktiv zu ziehen.
Problem, wenn das Und-Gatter aktiviert wird und der Clk-Anschl (am Und-Gatter) steht zum Zeitpunkt auf 1, wird in diesem Moment am '595 Clk ausgelöst! Weil man norm.weise Änderungen bei Clk=1 macht, wäre ein OR-Gate besser. Zur Deaktivierung schickt der uC da 1 hin, solange ist OR-Gate-OUT (und somit Clk am '595) noch auf 1, also 'ungefährlich'. Zur Aktivierung schickt der uC 0 ans OR-Gate, in dem Moment ist OR-Gate-OUT norm.weise noch 1, weil Clk am OR-Gate noch mit 1 anliegt. Erst wenn nun (nach einiger Zeit) Clk (am OR-Gate) 0-1 schaltet wird das 0-1 weiter an den '595-Clk geschickt.
J. W. schrieb: > Hi liebe Leute, > > ich möchte SPI mehrfach nutzen. Ich möchte mehrere 595 schalten aber > auch eventuell mit diesem Kontroller über SPI andere Aufgaben erledigen. > Nach einigem nachforschen bin in noch nicht ganz schlau geworden über > OUTPUT ENABLE aktiv low und Master Reset aktiv low. Mein Bauchgefühl > sagt mir folgendes: Ich setzte OE auf High, wenn anders kommuniziert > werden soll. Wenn das Register aktiv werden soll, nach Schreibevorgang, > dann wieder auf Low. Ich hatte mal irgendwo gelesen, das man auch den > Reset Low halten kann, das halte ich für gewagt, denn ich will auf jeden > Fall vermeiden, dass die Ausgänge sich verändern bis ich das will! Was > meint ihr? > Das OE-Signal bringt dich nicht weiter. Der 595 (sn74xxx595a) hat zwei Clock-Signale. SRCLK für das Schieberegister und RCLK für die Ausgangsspeicher. Du taktest die Daten die du willst per SER+SRCLK in das Schieberegister und wenn du dann RCLK einmal taktest wird der Zustand aus dem Register in den Ausgang geschickt. Wenn RCLK wieder '1' ist, kannst du weiter schieben, und der Ausgang ändert sich nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.