SPI für langsame Takte

[Dietmar P. (dietmar2)]

Hallo,

für eine Schaltung Abfrage von Leitungszuständen und Anzeige über LED's 
suchen ich Bauteile für langsame Takte.

Die Leitungen sind wenn geschlossen auf low oder wenn offen über einen 
pullup-Widerstand auf high. Die Anzeige soll direkt über LED's 
("Spar"-LED mit 2 mA) permanent erfolgen. Zustand der LED: Leitung offen 
LED leuchtet, Leitung geschlossen LED aus.
Zwischen dem Ende der Leitungen und der LED-Anzeige besteht eine 
räumliche Entfernung von ca. 1,5 m, überbrückt mit einer Telefonleitung 
(4-paarig).

Habe mich bereits intensiv mit den Bauteilen für SPI 74HC165 und 74HC595 
beschäftigt. Diese sind nicht geeignet für größere Entfernungen und 
eingentlich nur für die gleiche Platine gedacht. Ferner ist der Takt für 
meine Anwendung zu hoch.

Gibt es Bauteile die so etwas auch können und mit der Entfernung, sowie 
mit einem Takt von 500 Hz bis 2 kHz arbeiten können?

Danke für Eure Hilfe!

Gruß

[Jo Kurt (Gast)]

>Ferner ist der Takt für meine Anwendung zu hoch.

Welcher Takt? Sowohl 74HC165 und 74HC595 arbeiten mit Taktfrequenz ab 
DC, das dürfte doch wohl langsam genug sein? Die von dir genannten 
Bauteile haben keinen eigenen Takt, den musst du schon selber mit 
geeigneter Schaltung erzeugen.

Im übrigen sind das keine SPI-Bauteile, das sind nackte Schieberegister. 
Wenn du eine Datenübertragung parallel-seriell-parallel machen willst, 
brauchst du schon ein paar Bauteile zusätzlich.


Die 1,5m sollten mit geschirmter Leitung kein Problem sein.

[Dietmar P. (dietmar2)]

Da war ich etwas unvollständig!

Ja sicher brauche ich eine Steuerung, die übernimmt ein Atmega32. Dieser 
hat ja die entsprechenden Anschlüsse auf Port B (SCK, MOSI, MISO, SS).

Nur habe ich nach Durchsicht der Datenblätter Atmega und 74HC165 / 
74HC595 angenommen, dass der Takt bei einer Frequenz des Atmega von 1 
MHz viel zu hoch wird.

Wenn die 74HC165 und 74HC595 auch mit einer niedrigen Takt gesteuert 
werden können, so könnte ich ja die entsprechenden Impulse im Atmega per 
C-Programm selber erzeugen.
Ist das richtig?

[Wolfgang (Gast)]

Dietmar P. schrieb:
> Ist das richtig?
Ja.
Falls du Sorgen mit Sauberkeit der Signale hast, kannst du auch 
RS422-Treiber o.ä. dazwischen schalten. Wenn du nicht in völlig 
gestörter Umgebung bist, sollte das aber nicht nötig sein.

[Jo Kurt (Gast)]

>dass der Takt bei einer Frequenz des Atmega von 1 MHz viel zu hoch wird.

Die Schieberegister arbeiten locker bis 30 MHz. So schnell kann ein 
normaler ATMEGA den SPI gar nicht takten.

[Dietmar P. (dietmar2)]

Danke Euch für die Infos.

@ Wolfgang:

Mir genügt ein Takte mit ca. 500 Hz.
Nachdem es da mit den den 74HCxx scheinbar keine Probleme gibt, werde 
ich es mit den selbst gesteuerten Signalen probieren.
Den RS422 werde ich wohl besser gleich einbauen.

@ Jo Kurt:

Habe aber gelesen, dass bei diesen hohen Frequenzen und einer längeren 
Leitung es zu Störungen im ASgnalverlauf kommen kann, weil die Leitung 
die Eingang-Impedanzehn der Bautele verändert.

[Bernd R. (Firma: Promaxx.net) (bigwumpus)]

Du kannst gerne mit 500Hz Takt arbeiten, aber wenn Störungen auf den 
langen Leitungen einstreuen (Leuchtstofflampe einschalten), dann kann 
der schnelle empfindliche Baustein alles möglich machen...

Lange Leitungen sind nichts für SPI oder I2C  !!!!

[Wolfgang (Gast)]

Bernd Rüter schrieb:
> Lange Leitungen sind nichts für SPI oder I2C  !!!!

Darum SPI über RS422 Treiber. Wenn's ganz ernst wird, kann man damit 
sogar über Lichtleiter gehen. I2C ist da wegen der bidirektionalen 
Datenleitung unhandlicher.

[Dietmar P. (dietmar2)]

Nochmals Danke für die weiterhgehenden Informationen.

@Wolfgang:

Wegen der Einstreuung von Störungen will ich ja mit dem Takt runter.
Bei meiner jetzigen Lösung mit Mux/Demux-Bausteinen (Dateianhang) habe 
ich das Problem bei einem Takt von 2 kHz. Eine Auswertung der 
Leitungsinformationen im Atmega bringt kein sauberes Ergebnis. Ein 
weiterer Nachteil ist die aufwändige Steuerung der LED mit dem 
Halte-Elko. Deshalb kam ich auf die 74HCxx-Bauteile.

Ich würde jeweils einen RS422 (AM26LS31CN - Reichelt) auf die "Sender-" 
und "Empfänger"-Platine setzen und die Signale (SCK, MOSI, MISO, SS im 
µC per C-Prog.) über die Treiber versuchen möglichst störsicher zu 
machen.

So ok?

[Peter D. (peda)]

Warum so kompliziert?

Nimm doch auf beiden Seiten einen MC.
Dann brauchst Du nur einen IC und eine Leitung.

Z.B. der ATmega162 hat 35 IOs.
An den einen hängst Du bis zu 34 Taster ran und überträgst per UART 
(5Byte).
Der andere empfängt und schaltet bis zu 34 LEDs an.
Dazu nur noch ein bischen Software (<100 Byte), fertig.


Peter

[Peter D. (peda)]

Hier mal ein Beispiel für den Sender:

                        // Target: ATmega162
#include <avr/io.h>


#define F_CPU           1e6             // 1MHz
#define BAUD            1200
#define BAUDDIVIDER     (uint16_t)(F_CPU / BAUD / 16 - 0.5)


void uputchar( uint8_t c )
{
  UCSR0A = UCSR0A;                      // clear interrupt flag
  UDR0 = c;
  while( (UCSR0A & 1<<TXC0) == 0 );
}


int main()
{
  UBRR0H = BAUDDIVIDER >> 8;
  UBRR0L = BAUDDIVIDER;                         // set baud rate
  UCSR0B = 1<<TXEN0 | 1<<UCSZ02;                // Tx only, 9bit
  UCSR0C = 1<<URSEL0 | 1<<UCSZ01 | 1<<UCSZ00;   // 9bit

  for(;;){
    UCSR0B |= 1<<TXB80;                 // 1 = first byte
    uputchar( PINA );
    UCSR0B &= ~(1<<TXB80);              // 0 = next bytes
    uputchar( PINB );
    uputchar( PINC );
    uputchar( PIND );
    uputchar( PINE );
  }
}

Das Protokoll ist ganz einfach, das erste Byte wird durch 9.Bit = 1 
gekennzeichnet.
Ohne Startup-Code ist das Programm 54 Byte groß.


Peter

[Dietmar P. (dietmar2)]

@ Peter:

Danke für die Alternative, muss ich mal näher einsteigen.

Meinen Atmega32 kann ich ja trotzdem für die Auswertung der Leitungen 
hinsichtlich eines Alarms und für die Steuerung der LCD-Anzeige 
verwenden.

[Peter D. (peda)]

Dietmar P. schrieb:
> Meinen Atmega32 kann ich ja trotzdem für die Auswertung der Leitungen
> hinsichtlich eines Alarms und für die Steuerung der LCD-Anzeige
> verwenden.

Ist durch die UART ja auch ganz einfach.
Bei Verwendung der UART sollten beide MC einen Quarz benutzen.

Wenn Du die 32 LEDs als 4*8 Matrix im Timerinterrupt multiplext, kann er 
auch die LEDs mit ansteuern.


Peter

[Dietmar P. (dietmar2)]

Hi Peter

Der Standardstatus ist Leitung geschlossen, LED = aus.

Mein Gedanke ist, dass ich die Ausgänge am Atmega16 ("Empfänger"), z.B. 
PB0-7 usw. auf low setze (LED aus), wenn die Leitung geschlossen ist und 
wenn die Leitung offen ist dann den Ausgang auf high LED = an setzte.
Damit könnte ich ein Flimmern der LED vermeiden.

Wäre das auch ein Weg?

Gruß
Dietmar

[Peter D. (peda)]

Dietmar P. schrieb:
> Damit könnte ich ein Flimmern der LED vermeiden.

Mit der UART flimmert nichts. Jedes Byte bleibt bis zum nächsten 
Telegramm gültig.


Peter

[Dietmar P. (dietmar2)]

ok, danke.

Dietmar

[Dietmar P. (dietmar2)]

@ Wolfgang:

Nach einigen Tests habe ich letztlich die Schaltung doch mit 74HC165 und 
74HC595 realisiert (@Peter: Passte so am Besten in die bereits 
vorhandene Umgebung).

Da der Treiber RS422 relativ viel Strom zieht habe ich 74HC00 verwendet. 
Am Ende der Übertragungsleitung in beide Richtungen (CLK und Parallel 
shift bzw. MISO) wird das Signal damit doppelt invertiert und ist recht 
sauber und stabil.

Gruß

[MCUA (Gast)]

>Wegen der Einstreuung von Störungen will ich ja mit dem Takt runter.
Bringt nichts.
Massgebend ist die max Geschwindigkeit der Bausteine (ca 30MHz), nicht 
die von deinem vorgegebenem Takt. Da musst Du Filter dran setzen, damit 
schnelle Störflanken "nicht rein kommen", oder, wie geschrieben 
Diff-Sign-ICs benutzen (oder steinzeitiche uralte ICs benutzen, die 
extrem langsam sind)