Problem mit SPI Flash AT45DB321D

[Philipp (Gast)]

Hallo,

für ein aktuelles Projekt habe ich eine Platine hergestellt. Zur 
längerfristigen Speicherung von Daten habe ich einen SPI Flash mit 
draufgesetzt.
http://www.reichelt.de/-EE-Flash-Eproms/AT-45DB321D-SO/3//index.html?ACTION=3&GROUPID=4510&ARTICLE=112458&SHOW=1&START=0&OFFSET=500&;
Ich habe bereits versucht das Statusregister auszulesen, aber da habe 
ich nur Müll bei rausbekommen. Danach habe ich versucht die 
"Manufacturer and Device ID Information" auszulesen. Das Ergebnis 
übertrage ich per UART an den PC. Aber ich bekomme immer nur 0x00 oder 
0xff ausgegeben. Am UART liegts nicht.
Am Atmega1284p liegen die Korrekten 5V an und er läuft sauber mit 16Mhz, 
was ich mit Oszi und Delay getestet habe. Den SS Pin setzte ich als 
Output.
Der Flash hat 3,3V anliegen. Da die Pins alle 100% 5V Tolerant 
(Datenblatt) sind, habe ich alles direkt an den Mega angeschlossen. Die 
Verbindungen habe ich mehrere male durchgemessen und auch auf 
Kurzschlüsse getestet, aber ich konnte da keinen Fehler finden. Hättet 
ihr vielleicht eine Idee woran es liegen könnte?

Testcode:

#define F_CPU 16000000UL

#include <avr/io.h>
#include <util/delay.h>

#define DDR_SPI    PORTB
#define DD_MOSI    PINB5
#define DD_SCK    PINB7
#define FLASH_CS  PINB1
#define DD_SS    PINB4

void USART_Init( unsigned intbaud );
void USART_Transmit( unsigned char data );


void SPI_MasterInit(void)
{
  /* Set MOSI and SCK output, all others input */
  DDR_SPI = (1<<DD_MOSI)|(1<<DD_SCK)|(1<<FLASH_CS)|(1<<DD_SS);
  PORTB |= (1<<FLASH_CS);
  /* Enable SPI, Master, set clock rate fck/16 */
  SPCR = (1<<MSTR)|(1<<SPR0);
  SPCR |= (1<<SPE);
  
}
uint8_t SPI_MasterTransmit(char cData)
{
  PORTB &= ~(1<<FLASH_CS);
  _delay_ms(1);
  /* Start transmission */
  SPDR = cData;
  /* Wait for transmission complete */
  while(!(SPSR & (1<<SPIF)))
  ;
  cData = 0x00;                    //4 Byte müssten zurückkommen Datenblatt Seite 21
  cData = SPDR;
  USART_Transmit(cData);
  cData = 0x00;
  cData = SPDR;
  USART_Transmit(cData);
  cData = 0x00;
  cData = SPDR;
  USART_Transmit(cData);
  cData = 0x00;
  cData = SPDR;
  USART_Transmit(cData);

  PORTB |= (1<<FLASH_CS);
  
  return cData;
}

void USART_Init( unsigned intbaud )
{
  /* Set baud rate*/
  UBRR0 = intbaud;
  /* Enable receiver and transmitter*/
  UCSR0B = (1<<TXEN0);
  /* Set frame format: 8data, 2stop bit*/
  UCSR0C = (1<<USBS0)|(3<<UCSZ00)|(3<<UCSZ01);
}

void USART_Transmit( unsigned char data )
{
  /* Wait for empty transmit buffer*/
  while( !( UCSR0A & (1<<UDRE0)) )
  ;
  /* Put data into buffer, sends the data*/
  UDR0 = data;
}

int main(void)
{
  //5 Leds
  DDRC = 0xff;
  PORTC = 0x00;
  
  SPI_MasterInit();
  USART_Init(8); //16Mhz, Baud: 115200
  
  char msg[] = {"Hello... Ready!"};
  for(uint8_t i=0;i<15;i++)
  {
    USART_Transmit(msg[i]);
  }
  
  PORTC = 0xff;
  _delay_ms(500);
  
  while(1)
  {
    uint8_t abc = 0x00;
    abc = SPI_MasterTransmit(0x9F);
    
     for(int i=0;i<2000;i++)
     {
       _delay_ms(1);
    }
    
  }
}

[Philipp (Gast)]

Ich habe Probleme das Bild mit dem Schaltplan aufzumachen, da es 
anscheint etwas groß geraten ist. Hier nochmal kleiner.

[Frank K. (fchk)]

Wenn Du Daten empfangen willst per SPI, musst Du aktiv ein Dummy-Byte 
hinschicken. Du bist Master, Du musst den Takt bereitstellen, und der 
AVR taktet nur, wenn er was zu senden hat. Was ist egal.

So sollte es gehen:

uint8_t SPI_MasterTransmit(char cData)
{
  PORTB &= ~(1<<FLASH_CS);
  _delay_ms(1);
  /* Start transmission */
  SPDR = cData;
  /* Wait for transmission complete */
  while(!(SPSR & (1<<SPIF)));
  cData = SPDR;

  SPDR = 0x00;
  while(!(SPSR & (1<<SPIF)));
  cData = SPDR;
  USART_Transmit(cData);
  SPDR = 0x00;
  while(!(SPSR & (1<<SPIF)));
  cData = SPDR;
  USART_Transmit(cData);
  SPDR = 0x00;
  while(!(SPSR & (1<<SPIF)));
  cData = SPDR;
  USART_Transmit(cData);
  SPDR = 0x00;
  while(!(SPSR & (1<<SPIF)));
  cData = SPDR;
  USART_Transmit(cData);

  PORTB |= (1<<FLASH_CS);
  
  return cData;
}

fchk

[Philipp (Gast)]

Hi,

das funktioniert irgentwie immernoch nicht. Ich habe jetzt mal einen 
LogicAnayliser angeschlossen und es scheint gar kein SPI Clock zu 
kommen. Und was ich auch gerade noch festgestellt habe ist, dass 
anscheint der FLASH_CS niemals auf LOW geht, obwohl er das eigentlich 
müsste.

MfG
Philipp

[Peter Z. (hangloose)]

Stimmt das mit dem WP Pin?
WP pin gehört doch auf VCC mit 100k
und nicht auf GND

[Christian R. (supachris)]

Schaltest du die USART überhaupt in den SPI Modus? Laut den Kommentaren 
läuft die um USART Modus, und Stoppbits haben bei SPI auch nichts zu 
suchen...

[Philipp (Gast)]

Peter Z. schrieb:
> Stimmt das mit dem WP Pin?
> WP pin gehört doch auf VCC mit 100k
> und nicht auf GND

Laut Datenblatt muss WP auf GND gezogen werden, wenn der Flash vor 
Schreib- und Löschvorgängen geschützt sein soll. Da der Flash nur sehr 
selten gelöscht und neu beschrieben werden soll, ist die Protection 
dauerhaft an, und ich kann die dann deaktivieren, indem ich den Atmega 
Pin auf High schalte.

Aber wo wir gerade beim Pullup/down sind. Ich habe überall Pullups/downs 
von 10k verwendet. Sollte man besser 100k sein, und könnte das die 
Lösung meines Problems sein?

Christian R. schrieb:
> Schaltest du die USART überhaupt in den SPI Modus? Laut den Kommentaren
> läuft die um USART Modus, und Stoppbits haben bei SPI auch nichts zu
> suchen...

Der Flash hängt am SPI Interface. Der UART (0) ist für die Ausgabe und 
hat nichts mit dem SPI Interface zu tun.

[Philipp (Gast)]

Moin,

ich habe den Fehler gefunden und könnte mich selber schlagen dafür.

#define DDR_SPI    PORTB

Hat schon mal jemand versucht mit Register PORTB einzustellen, ob der 
jeweilige Pin ein Ein- oder Ausgang ist? Ich habs versucht und es 
funktioniert definitiv nicht. Wie denn auch?

Naja der SPI an sich läuft jetzt, und der LogicAnalyser zeigt auch an, 
dass er korrekt läuft, nur leider bekomme ich noch keine Antwort vom SPI 
Flash. Vielleicht ist er bei meinen Experimenten mit der Heißluftpistole 
(sind alles SMD Teile) draufgegangen. Ich werde ihn die Tage mal 
wechseln und melde mich dann wieder.

Danke aber soweit schonmal für eure Hilfe
Lg Philipp

[Arne (Gast)]

Ich nehme in der Firma einen 45DB161 und mit dem hatte ich anfangs auch 
Schwierigkeiten. IIRC gibts da ein undok. "Feature".
Laut meinem Code ist der Ablauf wie folgt:
/CS low
WREN Command
/CS high
2µs (etwa) warten, sicher geht hier deutlich weniger
/CS low
RDSR Command
Byte lesen (parallel ein Dummybyte senden)
/CS high

Das Toggeln der /CS Leitung wr bei mir der Kasus-Knaxus, um korrekt mit 
dem Teil zu kommunizieren.

[Philipp (Gast)]

Hi,

das habe ich jetzt mal versucht aber eine ganz komische Reaktion 
bekommen. Ich habe den Code angepasst und geflashed und plötzlich ging 
es. Das korrekte Statusregister wurde ausgegeben. Aber dann habe ich den 
Code wieder etwas geändert, so dass ich die Manufacturer and Device ID 
Information bekomme. Und plötzlich ging es nicht mehr. Also wieder 
zurück und nur Statusregister, was aber auch nicht mehr ging.

Dann kam ich gerade aus der Schule und habe das Teil wieder angschlossen 
und plötzlich hat der Flash wieder das richtige Statusregister zurück 
gegeben. Dann habe ich den ISP angeschlossen und wieder geflasht und 
wieder kommt keine Antwort mehr. Ich habe das Gefühl, dass es da 
Probleme mit dem ISP gibt, dass da vielleicht bei flashen auch der SPI 
Flash ein paar Befehle einfängt oder so.

  PORTB &= ~(1<<FLASH_CS);
  _delay_us(1);
  PORTB |= (1<<FLASH_CS);
  _delay_us(2);
  PORTB &= ~(1<<FLASH_CS);
  /* Start transmission */
  SPDR = cData;
  /* Wait for transmission complete */
  while(!(SPSR & (1<<SPIF)));
  cData = SPDR;
  
  SPDR = 0x00;
  while(!(SPSR & (1<<SPIF)));
  cData = SPDR;
//   SPDR = 0x00;
//   while(!(SPSR & (1<<SPIF)));
//   cData = SPDR;
//   USART_Transmit(cData);
//   SPDR = 0x00;
//   while(!(SPSR & (1<<SPIF)));
//   cData = SPDR;
//   USART_Transmit(cData);
  PORTB |= (1<<FLASH_CS);
  USART_Transmit(cData);
  return cData;

[bla (Gast)]

Arne schrieb:
> Laut meinem Code ist der Ablauf wie folgt:
> /CS low
> WREN Command
> /CS high
> 2µs (etwa) warten, sicher geht hier deutlich weniger
> /CS low
> RDSR Command
> Byte lesen (parallel ein Dummybyte senden)
> /CS high
>
> Das Toggeln der /CS Leitung wr bei mir der Kasus-Knaxus, um korrekt mit
> dem Teil zu kommunizieren.

Kommt hin, im Datenblatt steht explizit, dass eine "Operation" mit 
Transitionen vom CS# gestartet und beendet werden muss:

"A high-to-low transition on the CS# pin is required to start an 
operation, and a low-to-high transition is required to end an 
operation."

Es ist zwar etwas schwammig was genau "operation" hier ist, aber 
sicherlich ist ein dauerhaftes CS# das auf Low liegt nicht möglich und 
wird nicht funktionieren.

[Philipp (Gast)]

Also langsam werde ich echt bekloppt. Ich habe das Board gerade eben 
seit ein paar Stunden wieder in Betrieb genommen und konnte sofort 
Problemlos das Statusregister auslesen. Einmal kurz Strom weg und wieder 
dran und es kommt nichts mehr zurück nichts mehr. Ich habe als 
Kondensator für die Spannungswandler 4x 1uF drauf. 2x für den 5V und 2x 
für den 3,3V Wandler(LM1117). Könnte es sein, dass wenn ich den Strom 
wegnehme und das mitten im Senden/Empfangen des Optcodes und 
Statusregisters, dass sich der Flash irgendwo aufhängt und durch die 
Kondensatoren weiterbetrieben wird, so dass er bei nur kurzer Zeit ohne 
Strom immer noch dort hängt? Nach länger Strom weg gehts ja plötzlich 
wieder.


Lg
Philipp

[eProfi (Gast)]

Du hast bestimmt gesehen, dass die Programmierschnittstelle ebenfalls 
das SPI-Interface verwendet.  Als stecke mal den Prog-Adapter ab  oder 
baue ein paar serielle (47 . 1000 Ohm) Widerstände dazwischen.

[Philipp (Gast)]

eProfi schrieb:
> Du hast bestimmt gesehen, dass die Programmierschnittstelle
> ebenfalls
> das SPI-Interface verwendet.  Als stecke mal den Prog-Adapter ab  oder
> baue ein paar serielle (47 . 1000 Ohm) Widerstände dazwischen.

Deswegen habe ich an der CS Leitung zum Flash einen 100k PullUp. Somit 
dürfte er theoretisch keine Befehle entgegennehmen wenn geflasht wird, 
da CS auf HIGH bleibt.

>serielle (47 . 1000 Ohm)
Wo genau sollten die Widerstände hin? direkt an den ISP Adapter? Ist es 
egal, wie hoch der Widerstand ist? Welchen genau würdet ihr mir 
empfehlen?

Lg
Philipp

[Falk B. (falk)]

@ Philipp (Gast)

>Deswegen habe ich an der CS Leitung zum Flash einen 100k PullUp.

Naja, bissel hochomig, geht aber noch.

>Somit
>dürfte er theoretisch keine Befehle entgegennehmen wenn geflasht wird,
>da CS auf HIGH bleibt.

ja.

>>serielle (47 . 1000 Ohm)
>Wo genau sollten die Widerstände hin? direkt an den ISP Adapter?

Gar nicht. Die brauchst du nicht.

Ich habe vor kurzem im dem IC gearbeitet, der lief problemlos. Allerding 
habe ich einen Pegelwandler für SO benutzt, der von 3,3V auf saubere 
5V Pegel umsetzt. Das könnte bei dir ein Problem sein.

Noch ein Tipp: Bildformate. Deine beiden Schaltpläne sind einfach 
viel zu groß.

Hier meine beiden Funktionen für das Schreiben und Lesen von Pages.

#define CS_FLASH_LOW   PORTD &= ~(1<<PD6);
#define CS_FLASH_HIGH  PORTD |=  (1<<PD6);

uint8_t spi_io(uint8_t data) {
    SPDR = data;
    while(!(SPSR & (1<<SPIF)));
    return SPDR;
}


void write_page(uint8_t *data, uint16_t page) {
    uint16_t i;
    uint32_t adr;
    
    adr = (uint32_t)page << 10;

    CS_FLASH_LOW
    spi_io(0x82);
    spi_io(adr>>16);
    spi_io(adr>>8);
    spi_io(adr>>0);

    for (i=0; i<528; i++) {
        spi_io(data[i]);
    }

    CS_FLASH_HIGH
}

void read_page(uint8_t *data, uint16_t page) {
    uint16_t i;
    uint32_t adr;
    
    adr = (uint32_t)page << 10;

    CS_FLASH_LOW
    spi_io(0xD2);
    spi_io(adr>>16);
    spi_io(adr>>8);
    spi_io(adr>>0);
    spi_io(0);
    spi_io(0);
    spi_io(0);
    spi_io(0);

    for (i=0; i<528; i++) {
        data[i] = spi_io(0);
    }

    CS_FLASH_HIGH
}

ich hoffe, R20 ist nicht bestückt, denn damit wird dein IC 
schreibgeschützt, zumindest einige Pages.

[Philipp (Gast)]

Falk Brunner schrieb:
> Ich habe vor kurzem im dem IC gearbeitet, der lief problemlos. Allerding
> habe ich einen Pegelwandler für SO benutzt, der von 3,3V auf saubere
> 5V Pegel umsetzt. Das könnte bei dir ein Problem sein.

Da liegt nicht das Problem. Ich lese CLK, MOSI und MISO mit einem 
LogicAnlyser mit, und CLK und MOSI sind dort volkommen in Ornung. 
Zusätzlich habe ich an MISO/SO noch mein Oszi gehängt und einen 
einmaligen Trigger bei steigender Flanke mit einem Triggerlevel von 1V 
eingestellt. Aber da kommt auch nichts. Ich habe noch 2 weitere von den 
Flashes rumfliegen, finde die aber grade hier im Saustall nicht wieder. 
Ich denke dass ich den dann mal austauschen werde.

Falk Brunner schrieb:
> ich hoffe, R20 ist nicht bestückt, denn damit wird dein IC
> schreibgeschützt, zumindest einige Pages.

Der ist bestückt mit einem PullDown. Allerdings geht der Pin auch an 
PinA1 mit dem er hochgezogen werden kann. Das habe ich so gemacht, da 
der Flash nur selten programmiert werden muss und so nicht aus versehen 
irgendwas programmiert werden kann.

[bla (Gast)]

Kannst du einen Screenshot vom Locic Analyzer zeigen wo idealerweise ein 
kompletter Zyklus drauf ist mit WREN, RDSR, usw. und allen Leitungen 
(CLK/SI/SO/CS#/WP#/RESET#)?

[Philipp (Gast)]

bla schrieb:
> Kannst du einen Screenshot vom Locic Analyzer zeigen wo
> idealerweise ein
> kompletter Zyklus drauf ist mit WREN, RDSR, usw. und allen Leitungen
> (CLK/SI/SO/CS#/WP#/RESET#)?

Hi,

ich hatte das Bauteil jetzt nochmal ausgetauscht und sämtliche Leitungen 
geprüft, aber keinen Fehler finden können.
Ein Bild werde ich mal versuchen zu machen. CLK, SI, SO kann ich direkt 
abgreifen, für den Rest werde ich mal Leitungen anlöten.

lG
Philipp

[Philipp (Gast)]

Hier habe ich einmal den Output des LogicAnalysers. Scheint aber alles 
ok zu sein. WP und Reset konnte ich leider nicht bekabeln, aber ich habe 
es manuell mit dem Oszi überprüft. Beide Pins sin auf HIGH/5V.

Ich habe auchnochmal Schaltplan und Layout angehängt (diesesmal in 
anständiger Größe) und auch die Eaglefiles für Eagle 6.x.
Da ich sowieso die nächsten Tage Platinen in China bestelle hatte ich 
überlegt, einfach mal hiervon einen Satz mit fertigen zu lassen. Für 
9,5$ ist das ja nicht alzu teuer für 10 Platinen. Dann kann ich mir 
zumindest sicher sein, dass ich nicht doch einen Fehler bei der 
Herstellung gemacht habe, obwohl ich das schon viele male geprüft habe.

Könntet ihr bitte einfach nochmal über den Schaltplan und das Layout 
gucken, ob da irgentwelche Fehler drauf sind?

[Falk B. (falk)]

@ Philipp (Gast)

>Ich habe auchnochmal Schaltplan und Layout angehängt (diesesmal in
>anständiger Größe)

Immer noch zu groß, 150 dpi reichen für Schaltpläne im Eagle. Oder 
gleich als PDF drucken, ist noch besser.

>Da ich sowieso die nächsten Tage Platinen in China bestelle hatte ich
>überlegt, einfach mal hiervon einen Satz mit fertigen zu lassen. Für
>9,5$ ist das ja nicht alzu teuer für 10 Platinen.

Wenn dein Prototyp NICHT läuft? Merkwürdige Strategie.

> Dann kann ich mir
>zumindest sicher sein, dass ich nicht doch einen Fehler bei der
>Herstellung gemacht habe, obwohl ich das schon viele male geprüft habe.

Mein Gott, so einen IC mit soooo wenig Pins krigt man auch mit 
Fädeldraht zum laufen. Mach das!

>gucken, ob da irgentwelche Fehler drauf sind?

Wie gesagt, MISO am AVR will offiziell 5V*0,7=3,5V für HIGH sehen, das 
kann dein Flash mit 3,3V nicht schaffen. Praktisch KANN es gehen, muss 
es aber nicht. Ich hab hier einen 74HCT125 als Pegelwandler 
genommen.

SPI Mode 3 kann man nehmen, muss aber aufpassen, einige Kommandos sind 
bei SPI Mode 3 verschieden. Ich hab das Ding mit Mode 0 betrieben und es 
lief problemlos.

uint8_t check_busy(void) {
    uint8_t status;    

    CS_FLASH_LOW
    spi_io(0xD7);
    status=spi_io(0);
    CS_FLASH_HIGH

    return !(status & 0x80);
}

Probier mal SPI Mode 0.

[holger (Gast)]

Ich kann mich Falk da nur anschliessen. Mode 0 ging bei mir auch.

Der ganze Plan leidet zudem unter akutem Mangel an
Abblockkondensatoren.

[Falk B. (falk)]

@ holger (Gast)

>Der ganze Plan leidet zudem unter akutem Mangel an
>Abblockkondensatoren.

In der Tat, solche Grundvoraussetzungen übersieht man fast ;-)

http://www.mikrocontroller.net/articles/Kondensator#Entkoppelkondensator

[Philipp (Gast)]

Hi,

Mode 3 hatte ich nur mal probiert, weil Mode 1 auch nicht funktioniert 
hatte.
Ich habe jetzt sämtliche Verbindungen zum tausendsten mal durchgemessen 
und musste feststellen, dass anscheint die Durchkontaktierung von MOSI 
nicht richtig drin war. Da es zwischendurch ja mal funktioniert hatte, 
werde ich da das Board wohl irgendwie belastet haben, dass die 
Leiterbahnen verbunden sind. Das nächste mal sollte ich mir 2x überlegen 
so viele Duko's auf eine Platine zu packen, wenn ich die noch selber 
Löten muss.

Status und Manufrakturinfos gehen jetzt problemlos. Der Rest dann 
sicherlich auch.

Falk Brunner schrieb:
> Wie gesagt, MISO am AVR will offiziell 5V*0,7=3,5V für HIGH sehen, das
> kann dein Flash mit 3,3V nicht schaffen. Praktisch KANN es gehen, muss
> es aber nicht. Ich hab hier einen 74HCT125 als Pegelwandler
> genommen.

Laut Datenblatt ist der Faktor bei VCC= 2.4V - 5.5V bei 0.6, also 0.6*5 
= 3V. Ich werde trotzdem noch versuchen einen Pegelwandler mit 
draufzubekommen, allerdings scheint das Teil, auch mit vielen Arduinos 
mit 5V problemlos zulaufen.

holger schrieb:
> Der ganze Plan leidet zudem unter akutem Mangel an
> Abblockkondensatoren.

An den Spannungswandlern sitzten jeweils 2x 10uF Tantal.
Der Rest sollte 10nF werden. Wo sollte ich welche hinbauen?


Und gleich nochmal eine Frage zu einem anderen Thema, falls hier jemand 
Ahnung von RS485 mit dem MAX490 hat. Würdet ihr empfehlen an die 
Leitungen Pullup/down's dranzuhängen? Die scheint die Max-Reihe nicht 
mit drin zu haben.

Lg
Philipp

[Falk B. (falk)]

@ Philipp (Gast)

>An den Spannungswandlern sitzten jeweils 2x 10uF Tantal.
>Der Rest sollte 10nF werden. Wo sollte ich welche hinbauen?

Was ist daran nicht zu verstehen?

http://www.mikrocontroller.net/articles/Kondensator#Entkoppelkondensator

>Ahnung von RS485 mit dem MAX490 hat. Würdet ihr empfehlen an die
>Leitungen Pullup/down's dranzuhängen?

Nein. Sowas gehört an den Bus.

[Philipp (Gast)]

Falk Brunner schrieb:
> Was ist daran nicht zu verstehen?

Sorry hatte nichr richtig gelesen. Ich habe jetzt jeden VCC Pin aller 
Chips mit zusätzlichen 100nF's versehen und noch ein paar VIA'S gesetzt, 
wie auf der Seite geschrieben steht.

Falk Brunner schrieb:
> Nein. Sowas gehört an den Bus.

In wiefern an den Bus? Der Max488/490 sitzt ebenfalls mit auf der 
Platine und ein Anschluss für die Differentialleitungen habe ich auch 
drauf. Ich bin mir jetzt nur nicht sicher ob da Pullup/down's noch dazu 
kommen sollten. Laut den Datenblättern steht davon nichts aber in 
manchen Schaltplänen habe ich die gesehen.

Lg
Philipp

[Falk B. (falk)]

@ Philipp (Gast)

>> Nein. Sowas gehört an den Bus.

>In wiefern an den Bus?

Die Terminierung incl. ggf. Pull-Widerstände.

http://www.mikrocontroller.net/articles/RS-485#Weitere_Hinweise

> Der Max488/490 sitzt ebenfalls mit auf der
>Platine und ein Anschluss für die Differentialleitungen habe ich auch
>drauf. Ich bin mir jetzt nur nicht sicher ob da Pullup/down's noch dazu
>kommen sollten.

Im Normalfall nicht. Die meisten Empfänger sind sowieso fail safe, 
sprich, bei offenem Eingang erkennen sie einen gültigen Pegel.

> Laut den Datenblättern steht davon nichts aber in
> manchen Schaltplänen habe ich die gesehen.

Ja, einige Empfänger sind nicht fail safe, die flattern dann, wenn der 
Eingang offen ist.

[Philipp (Gast)]

Die Kondensatoren habe ich jetzt hinzugefügt und zur Terminierung des 
Bus noch den Pullup/down.

Ich danke euch für eure Hilfe.

Lg
Philipp