Forum: Mikrocontroller und Digitale Elektronik 8-Bit Latch mit "Read-back"


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 TenereMike (Gast)


Lesenswert?

Hallo,

brauche eine Porterweiterung für meinen µC. Habe bis jetzt immer den 
74HCT273 bzw. 74HCT573 an meinem 8-Bit Bus verwendet. Nachteil ist 
hierbei, dass ich mir den aktuellen Ausgangszustand in einer Variablen 
merken muss, da ich von den o.g. Bausteinen nichts zurücklesen kann.

Jetzt sind mir die Bausteine

74xx666, 74xx667, 74xx793, 74xx794, 74xx990

aufgefallen. Hierbei handelt es sich um 8 Bit Speicher mit Read-back 
Funktion. D.h. der Inhalt des Speichers kann zurückgelesen werden. Diese 
würden genau das machen was ich möchte.

ABER, diese Bausteine scheinen auf dem Markt wohl nicht so üblich zu 
sein, da sie entweder nicht zu bekommen sind, bzw. stolze Preise haben.

Hat hier jemand eine Idee, bzw. was nehmt ihr für Bausteine um einen 
8Bit Ausgangsport zu realisieren, der zurückgelesen werden kann?

Bin für alle Ideen offen.

Im voraus schon mal vielen Dank.

Gruß Micha

von Peter D. (peda)


Lesenswert?

TenereMike schrieb:
> Nachteil ist
> hierbei, dass ich mir den aktuellen Ausgangszustand in einer Variablen
> merken muss, da ich von den o.g. Bausteinen nichts zurücklesen kann.

Ich sehe darin keinen Nachteil, sondern einen Vorteil.
Das Lesen einer Variable im internen SRAM geht schneller, als Lesen vom 
externen Bus.

Und erzähl nicht, daß Du 1024 Register anschließt und dann die 
benötigten 1kB Shadow SRAM zuviel sind.


Peter

von bastler (Gast)


Lesenswert?

Hallo,

wie waere es mit einem kleinen cpld (xil coolrunner) oder fpga (xil 
xc3s50an)
in dem Du die entsprechende Logik unterbringst ?

Gruss

ein bastler

von kolabier (Gast)


Lesenswert?

Verstehe auch nicht, was daran nachteilig sein soll, sich den 
Ausgangszustand in einer Variable zu merken.

Zur Porterweiterung nutze ich auch gerne eine Schieberegister-Kette mit 
74HC595 (spart noch mehr Pins). Da kannst du den letzten QH' dann 
natürlich auch wieder an einen Eingangspin des uC hängen.
Du musst beim Lesen dann natürlich immer das gelesene Bit wieder vorne 
in die Schieberegisterkette reinfüttern, damit der Ursprungszustand nach 
einmal Durchshiften wieder hergestellt ist.
Da das 74HC595 ein output latch hat, ändert sich an den Ausgängen beim 
Durchshiften erstmal nichts.

von TenereMike (Gast)


Lesenswert?

Danke zunächst mal für die schnellen Antworten, wollte aber eigentlich 
nicht über Vor- und Nachteile diskutieren.
Aber zur Info, meine Controller unterstützt den bitweisen Zugriff auf 
Memory-Mapped Ports. Das hat dann in meinem Fall den Vorteil, des sehr 
sehr einfachen Zugriffs auf ein einzelnen Bit des 8-Bit Ports (von denen 
ich übrigends 5 benötige)

Der Zugriff sähe dann wie folgt aus:

typedef struct {
  char bit0: 1;
  char bit1: 1;
  char bit2: 1;
  char bit3: 1;
  char bit4: 1;
  char bit5: 1;
  char bit6: 1;
  char bit7: 1;
}TYP_PORT1;

TYP_PORT1 port1  _at(0x50000);   // Die Variable port1 auf Adr.0x50000 
legen

void main()
{

  port1.bit0 = 1;   // Bit0 setzen

  if(port1.bit2)    // Bit2 abfragen
  {

  }
}


D.h., so habe ich einen sehr einfachen und schnellen Zugriff auf den 
Port.

Ich suche einen Standardbaustein wie z.Bsp den 74ALS667, dieser ist aber 
nicht sehr gängig...daher die Frage nach anderen Lösungen. D.h. ich such 
eine einfache Lösung und möchte bestimmt keinen FPGA oder ähnliches 
einsetzen.

Gruß Micha

von (prx) A. K. (prx)


Lesenswert?

Wenn es darum geht, Bits einzeln zu setzen/löschen zu können, ohne den 
vorherigen Zustand kennen zu müssen, dann tuts vielleicht auch der '259. 
Da gehen die Bits dann allerdings nur einzeln, weil adressierbares 
Latch. Dafür ist es gut verfügbar.

von (prx) A. K. (prx)


Lesenswert?

Den 74HCT646 gibts sogar bei R.

von Peter D. (peda)


Lesenswert?

TenereMike schrieb:
> Aber zur Info, meine Controller unterstützt den bitweisen Zugriff auf
> Memory-Mapped Ports.

Dieser C-Code läuft aber auch auf CPUs ohne Bitzugriff, die Bitfelder 
setzt ja der Compiler in Code um.


TenereMike schrieb:
> D.h., so habe ich einen sehr einfachen und schnellen Zugriff auf den
> Port.

Sicher, daß das auch schnell ist?
Hast Du Dir mal den erzeugten Assembler angeschaut?
Die CPU muß immer einen Lese- und einen Schreibzyklus machen.

Schnelle Bitzugriffe gehen daher nur mit internen Ports.


Peter

von (prx) A. K. (prx)


Lesenswert?

Peter Dannegger schrieb:

> Schnelle Bitzugriffe gehen daher nur mit internen Ports.

Per 74HC259 am 8-Bit Bus bedeutet, einfach nur einen Wert auf den Bus zu 
schreiben, nicht mehr. Bei einem adressierten Bus schreibt man 
beispielsweise den gewünschten Wert als Datenbit auf ein durch die 
Adresse (oder ggf. andere Datenbits) definiertes Portbit. Einen Reset 
hat das Ding netterweise auch.

von kolabier (Gast)


Lesenswert?

TenereMike schrieb:
> Danke zunächst mal für die schnellen Antworten, wollte aber eigentlich
> nicht über Vor- und Nachteile diskutieren.

Die Bereitschaft darüber zu diskutieren würde dir in der Tat aber evtl. 
hilfreich sein.

Zurück zu deinem Lösungsansatz:

Dein Memory-Mapped Port nützt dir etwas, wenn du nur einen 8-Bit Latch 
anschließen willst.
Was du vergessen hast ist, dass der Port und der externe Baustein sich 
darüber "einigen" müssen, wer den 8-bit Bus treiben soll/darf.

Wenn du mehrere Port-Expander anschließen willst, musst du dafür auch 
ein Adressing hinbekommen, ein klassisches DMA Interface macht dies für 
dich über separate, nach aussen geführte Adressleitungen.

Da du dies mit deinem uC vermutlich doch "von Hand" erledigen musst, 
stellt sich nach wie vor die Frage, warum Shadow-Variablen nicht der 
richtige Ansatz sind.

Für bitweises Zugreifen gibt es einfache Möglichkeiten.

z.B.
1
unsigned char port_shadow[5];
2
3
set_bit(port_nr, bit)
4
{
5
    port_shadow[port_nr] |= (1 << bit);
6
    
7
    // add code here to put port_shadow[port_nr] to 8-bit bus
8
    // and clock data into expander port_nr
9
}
10
11
clear_bit(port_nr, bit)
12
{
13
    port_shadow[port_nr] &= ~(1 << bit);
14
    
15
    // add code here to put port_shadow[port_nr] to 8-bit bus
16
    // and clock data into expander port_nr
17
}
18
19
20
unsigned char get_bit(port_nr, bit)
21
{
22
    return (port_shadow[port_nr] & (1 << bit)) ? 1 : 0;
23
}

von TenereMike (Gast)


Lesenswert?

A. K. schrieb:
> Den 74HCT646 gibts sogar bei R.

Vielen Dank A.K. genau sowas suche ich.

Peter Dannegger schrieb:
> Sicher, daß das auch schnell ist?
> Hast Du Dir mal den erzeugten Assembler angeschaut?
> Die CPU muß immer einen Lese- und einen Schreibzyklus machen.

Verwende einen Renesas RXN, der hat die Anweisungen auch in Assembler 
(BTST, BCLR sowie BSET).

Micha

von Peter D. (peda)


Lesenswert?

TenereMike schrieb:
> Verwende einen Renesas RXN, der hat die Anweisungen auch in Assembler
> (BTST, BCLR sowie BSET).

Du schreibst aber keinen Assembler, sondern C.
Die Preisfrage ist daher immer noch, was benutzt der Compiler?
Schaus Dir endlich mal an, wieviel Instruktionen er wirklich benötigt 
und wie lange die dauern.


Peter

von Frank K. (fchk)


Lesenswert?

TenereMike schrieb:

> Hat hier jemand eine Idee, bzw. was nehmt ihr für Bausteine um einen
> 8Bit Ausgangsport zu realisieren, der zurückgelesen werden kann?

HC573+HC541 für die umgekehrte Richtung

oder seriell
HC595+HC597

Und, ja, ich hatte eine Anwendung, wo ich Ports mit je einem 595 und 
einem 597 realisieren musste. Beim 595 kann man ja nur den Inhalt des 
Schieberegisters zurücklesen, nicht aber den Inhalt des 
Ausgaberegisters. Und genau dafür brauchte ich die 597'er. Ich hätte 
auch 165'er nehmen können, aber die 597'er waren layouttechnisch 
günstiger, weil das Pinout von 595 und 597 sehr ähnlich ist.

fchk

von TenereMike (Gast)


Angehängte Dateien:

Lesenswert?

Frank K. schrieb:
> HC573+HC541 für die umgekehrte Richtung

So ähnlich war meine erste Idee auch (2 mal einen LVX573). Bin 
inzwischen wieder bei meiner ersten Lösung angelangt. Ich füge den 
Schaltplan mal an. Vieleicht kann mal jemand drüber schauen ob das so 
funktioniert.

Gruß Micha

von MCUA (Gast)


Lesenswert?

Bausteine 74xx6xx oder höher sind meistens 2..4x teurer als eine 
equival. Schaltung mit 2 ICs. Ausserdem sind diese 'Nummern' bei neueren 
Technologien sehr schlecht erhältlich.
Ich würd entweder 2x '74xx5xx (oder kleiner) nehmen, oder PLD.

von Uwe (Gast)


Lesenswert?

nen altes PLD wird warscheinlich das billigste sein und hat noch einige 
andere Vorteile. Unter anderem hats auch noch nen gewissen Funfactor 
z.B. kanste einfach bei ner Motorsteuerung nen Endschalter 
Hardwareverdrahten, so das nen Programmierfehler keinen 
Sciherheitskritischen Zustand des Systems auslößt. Oder du hast nen 
Timer zuwenig na denn machste dir den halt mit nen par FlipFlops aus dem 
PLD. Kannste auch noch nen Par FlipFlops nehmen und nen Compare machen, 
nen paar gatter dazu und du hast nen Zusätzlichen outputcopare oder PWM 
(bei dem du die modi und frequenzteiler selber definieren kannst usw.) 
UND DAS FÜR DEN GLEICHEN PREIS

von MCUA (Gast)


Lesenswert?

>Verwende einen Renesas RXN, der hat die Anweisungen auch in Assembler
>(BTST, BCLR sowie BSET).
Auch R8C/M16C/M32C/R32C... haben das

von Willi (Gast)


Lesenswert?

Es ist erschreckend, dass jemand einen RX einsetzen will und für die 
Ansteuerung von popeligen 8 LEDs zusätzlich einen HCT646 braucht.

TenereMike schrieb:
> Bin für alle Ideen offen.

Nimm einen SCSI-Kanal mit 74HC595 für die LEDs und lasse per DMA den 
Wert der LEDs ausgeben. Freilaufend passiert das über eine Millionen 
Male pro Sekunde. Da muß man dann nichts zurücklesen.
Damit sich der Prozessor nicht zu sehr langweilt, lasse ihn am besten 
noch Quadratwurzeln aus zufälligen float-Zahlen ziehen; meinetwegen auch 
jede µs.

von Thomas O. (kosmos)


Lesenswert?

ich nehme an dein Problem ist, dass du zuwenige Register hast, das läßt 
sich aber ganz einfach umgehen in dem du deine Werte im SRAM ablegst 
dann brauchst du sie nicht aus dem Latch zurücklesen sondern einfach 
wieder aus dem SRAM.

Hier mal ein kurzes AVR Assembler Beispiel

.DSEG  ;Reserve jeweils 1 Byte im SRAM
Variable1:  .byte 1
Variable2:      .byte 1
Variable3:      .byte 1

ldi temp, 0b10100000  ;Speichere Daten im SRAM
sts Variable1, temp

lds temp, Variable1     ;Lade Daten wieder aus dem SRAM

von TenereMike (Gast)


Lesenswert?

Hallo, was ist denn hier los...?????

Ich habe eine ganz einfache Frage bezüglich eines kleinen 
Hardwarproblems gestellt und hier wird über Sinn und Unsinn des 
Verfahrens diskutiert. Ich habe nicht vor hier das komplette Projekt in 
allen Einzelheiten aufzuzählen und vor allem zu rechtfertigen. Aber nur 
zur Info, ich habe nicht vor mit dem RXN nur ein paar LEDs anzusteuern. 
Den Schaltplan den ich hier angehängt habe ist nur ein Ausschnitt von 
einem viel größeren Projekt. Und glaubt mir, der RXN wird hierbei 
richtig gefordert. Und ja, mir ist bekannt, wie man das ganze auch in 
Software machen kann, und nein, ich habe nicht zu wenig Register....

Gruß Micha

von Thomas O. (kosmos)


Lesenswert?

wenn du genug Register hast frage ich mich wieso du den Zustand des 
Latches zurück lesen willst. Worin siehst du den Vorteil darin das Latch 
auszulesen? Kmomt es wirklich auf jeden Takt an

von Peter D. (peda)


Lesenswert?

Nun, Du solltest erstmal den Rat annehmen und im Assemblerlisting 
nachschauen, ob überhaupt optimierter Code erzeugt wird.
Nicht alles, was in C schön hingeschrieben aussieht, muß dann auch 
wirklich optimal sein.

Ehe man Hardwareaufwand treibt, sollte man prüfen, ob das überhaupt was 
bringt. Bisher vermutest Du nur, daß der Code besser wird.

Letztendlich muß trotzdem ein Read/Modify/Write über den externen 
Datenbus gehen. D.h. auch wenn die CPU das als ein Befehl macht, braucht 
sie dafür deutlich mehr Zyklen, als für ein einfaches Write.

Daneben gibt es auch die Frage der Funktionssicherheit. Ein externes 
Latch kann kippen oder es gibt Busfehler. Der interne SRAM ist da 
deutlich stabiler.
Z.B. hatte ich mal das Problem, daß durch EMV-Test auf das Display wirre 
Zeichen dargestellt wurden. Die Lösung war dann, einen Schattenspeicher 
für das Display einzurichten und zyklisch das Display zu refreshen.


Peter

von Willi (Gast)


Lesenswert?

Peter Dannegger schrieb:
> Nun, Du solltest erstmal den Rat annehmen und im Assemblerlisting
> nachschauen, ob überhaupt optimierter Code erzeugt wird.

Optimierung ist bei solchen Prozessoren zunächst kein Problem - sie 
rennen auch ohne schnell genug.
Es geht wohl um einen RX62N:
http://hk.renesas.com/products/mpumcu/rx/rx600/rx621_62n/rx621_62n_root.jsp

Wenn man LEDs mit wenig Hardware betreiben möchte, wäre im einfachsten 
Falle ein PCF8574 oder besser ein neuerer IIC-Port Expander ausreichend 
und rücklesbar.

TenereMike schrieb:
> Und glaubt mir, der RXN wird hierbei
> richtig gefordert.

Ein schlechtes Design kann einen Prozessor auch richtig fordern, ohne 
einen Nutzen zu liefern.

von Peter D. (peda)


Lesenswert?

Willi schrieb:
> Optimierung ist bei solchen Prozessoren zunächst kein Problem - sie
> rennen auch ohne schnell genug.

Das war aber genau der Grund des OP, mit nem Haufen Hardwareaufwand 1-2 
CPU Zyklen (vermeintlich?) einzusparen.
Daher meine Frage, ob der Compiler das überhaupt supportet.


Die Reneas-Webseite hilft einem auch nicht weiter. Ich hab nirgends 
gefunden, daß die CPU ein Read/Modify/Write auf dem externen Bus 
unterstützt.

Irgendwie versuchen jetzt alle IC-Hersteller, ihre Webseiten möglichst 
schlecht zu gestalten. Atmel hat ja kürzlich auch einen gewaltigen 
Rückschritt getan.


Peter

von Willi (Gast)


Lesenswert?

Peter Dannegger schrieb:
> Die Reneas-Webseite hilft einem auch nicht weiter.

Nimm den obigen Link und gehe über 'Documentation -> Hardware Manual'.
Da steht auf knapp 2000 Seiten, alles was das Herz begehrt. Unter 12.2.5 
wird der ext. Bus beschrieben: vom Feinsten!

Ab und zu wird man den Bus bremsen müssen, damit die ext. Hardware noch 
mitkommt.

von Peter D. (peda)


Lesenswert?

Willi schrieb:
> Nimm den obigen Link und gehe über 'Documentation -> Hardware Manual'.
> Da steht auf knapp 2000 Seiten, alles was das Herz begehrt.

Puh, der ist mir mehrere Nummern zu kompliziert.
Ehe ich da durchsehe, habe ich mit nem 8-Bitter mein Programm schon 
längst fertig.

Die Antwort, ob er das vom OP gewünschte Feature kann, habe ich nicht 
gefunden. Ich habe aber auch nur 20min reingesehen.

Ohne fertige Configurations-Libs oder Wizzards braucht man bestimmt 
ewig, da durchzusteigen.


Peter

von Willi (Gast)


Lesenswert?

Peter Dannegger schrieb:
> Puh, der ist mir mehrere Nummern zu kompliziert.

Nicht so ungeduldig, junger Mann.
Unter 12.3.1 wird gezeigt, was zur Aktivierung eines CS-Bereiches 
notwendig ist: enable, Datenbusbreite (8,16,32) und Anordnung der Daten 
big/little endian.
Läßt man die weiteren Register in Ruhe, so ist schnellstmöglicher 
Zugriff eingestellt. Der maximale Bustakt kann auf 50MHz eingestellt 
werden.
Dann muß man noch einstellen, dass die Ports für Daten- und Adressbus 
auch als solche verwendet und wie /RD und /WR erzeugt werden sollen.

Unter Figure 12.16 wird das Timing gezeigt.
Figure 12.38 zeigt, wie interne und externe Busse friedlich 
nebeneinander arbeiten und sich nicht gegenseitig ausbremsen.

Beim Cortex sind ist die Konfiguration doch sicherlich ähnlich.
Es gibt Beispielroutinen (hwinit.c), die zeigen, wie einfach eine 
Konfiguration erledigt wird. Das ist nicht komplizierter als ein UART 
zum Laufen zu bringen. Für einen Profi wie Dich doch ein leichtes Spiel 
;-)
Man lernt doch immer gerne dazu.

von MCUA (Gast)


Lesenswert?

>Letztendlich muß trotzdem ein Read/Modify/Write über den externen
>Datenbus gehen.
Das stimmt so nicht. Der TO will nur ein Write mit Readback machen.
Um Write zu machen : WR
Um Read zu machen : RD
kein Modify.
Da die CPU nach Write nicht automatisch ein Readback macht, muss das mit 
sep. RD-Befehl gemacht werden.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Lesenswert?

TenereMike schrieb:
> So ähnlich war meine erste Idee auch (2 mal einen LVX573). Bin
> inzwischen wieder bei meiner ersten Lösung angelangt. Ich füge den
> Schaltplan mal an. Vieleicht kann mal jemand drüber schauen ob das so
> funktioniert.

Hab' ich früher ganze TTL-Gräber mit gebaut. Funktioniert hervorragend. 
Ich habe allerdings 574er, bzw. 374er, genommen, weil die 
flankengesteuert sind.

mfg.

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.