Auslesen von Quad-UART durch AT90S8515

Steffen Kirn Gast #35663
Lesenswert?
• ▲
▼ 
Hallo,

ich möchte einen Quad-UART (16C554) an einen AT90S8515 anschliessen um 
damit 3 serielle Kanäle auf einen Kanal zu multiplexen. An PORTA hängt 
der 8bit Datenbus zwischen µC und UART, an PORTB die Interruptkanäle des 
UART und SPI, über PORTC gebe ich die Kanal- und Registeradresse an den 
UART aus, an PORTD hängen die veroderten IRQs an INT0, TXRDY, RXDY und 
schließlich noch IOW (Write-Strobe)und IOR (Read-Strobe).
Probleme macht mir gerade IOR. Bei steigender Flanke von IOR gibt der 
UART die Daten auf den BUS aus und hält sie max. 20ns. Ich setze IOR 
über CBI auf '0', im nächten Takt mit SBI auf '1', was mir meine 
steigende Flanke ergibt. Wenn ich nun im nächtsten Takt durch "in r18, 
PINA" die Daten einlesen will, sind aber seit der steigenden Flanke bei 
8 MHz schon 125 ns vergangen, und die Daten sind gar nicht mehr auf dem 
BUS. Hat vielleicht schon jemand Erfahrungen mit einem externen UART (am 
besten 16C55*) am AT90S**** gemacht und kann mir vielleicht einen Tip 
geben.

Danke im Vorraus

Steffen
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter D. #35664
Lesenswert?
• ▲
▼ 
Ich kenne jetzt nicht den 16C554 aber die meisten Peripherie-IC 
verhalten sich wie RAM, d.h. die Daten sind solange stabil, wie /IOR auf 
low liegt.

Der 8515 hat doch sogar einen externen RAM Bus, da ist es doch das 
einfachste den 16C554 wie RAM anzuschließen.


Peter
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Steffen Kirn Gast #35665
Lesenswert?
• ▲
▼ 
Danke für den Tip Peter!

In dem Datenblatt von TI zum 16C554 sind die ZZDe für das Lesen und 
Schreiben etwas konfus. Ich dachte, ich darf die Daten erst nach der 
steigenden Flanke von /IOR lesen. Aber Dank deinem Tip und nochmaliger 
genauer Betrachtung darf ich schon nach mind. 30 ns nach der fallenden 
Flanke lesen. Die steigende Flanke signalisiert dem UART nur, dass die 
Daten gelesen wurden und er sie nicht länger halten muss.

Ich hab nun mein Programm dementsprechend abgeändert und es scheint 
korrekt zu funktionieren. Gelobt sei der In-Circuit-Emulator, da sieht 
man was wirklich vor sich geht, hoffe ich!
Das mit dem externen SRAM BUS war auch meine erste Idee, aber meinem 
Prof hat der Vorschlag nicht so gefallen.

MfG

Steffen
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter D. #35666
Lesenswert?
• ▲
▼ 
"aber meinem Prof hat der Vorschlag nicht so gefallen"

Sowas gibt es. Der hat wohl schon eine Lösung fertig in der Schublade 
und wenn da einer mit was anderem daherkommt, müßte er sich ja wieder 
reinarbeiten.

Bequemer, codesparender und schneller als das umständliche Pins extra 
setzen und clearen ist das SRAM Interface allemal.


Peter
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

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.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.