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
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
Hallo, wie waere es mit einem kleinen cpld (xil coolrunner) oder fpga (xil xc3s50an) in dem Du die entsprechende Logik unterbringst ? Gruss ein bastler
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.
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
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.
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
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.
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 | } |
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
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
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
Angehängte Dateien:
-
Ausgangsport.png
18 KB
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
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.
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
>Verwende einen Renesas RXN, der hat die Anweisungen auch in Assembler >(BTST, BCLR sowie BSET). Auch R8C/M16C/M32C/R32C... haben das
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.
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
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
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
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
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.
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
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.
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
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.
>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.
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.
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.