Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » SPI Master für Z80... » Themenansicht

Autor

Thread - Seiten: -1-

000
25.12.2019, 11:58 Uhr
holm

Avatar von holm

ich laboriere daran herum eine bei unseren Systemen einfach fehlende Schnittstelle zu basteln,
fast jede moderne Arduino Hardware kommt mit einem SPI (Slave) Interface, es bleibt meist nichts
anderes übrig, als eine solche Schnittstelle mit Software-BitBang zu basteln was natürlich etwas
zäh wird.

Ich hatte hier im Forum schon mal nach einem obsoleten Chip gefragt der so eine Schnittstelle enthält, allerdings ist der nur noch selten und wenn das verhältnismäßig teuer zu haben. Ich habe das Ganze auch bei mikrocontroller.net diskutiert und "peda" kam auf eine recht interessante Idee mit einem 74LS299 Universalschieberegister und einem Zähler. Da ich stinkend faul bin, habe ich mir überlegt das Ganze in eine CPLD zu programmieren und den notwendigen Ausgabeport für die Chipselects noch mit darin unterzubringen. Des weiteren gibts einen Port auf dem der Status (busy, Bit7 ) abgefragt werden kann.
Da Ich von VHDL oder Verilog momentan noch keinen Plan habe, habe ich das mit Quartus II als Schematic Entry gebastelt und das Ergebnis in einem EPM3032ALC44 gebruzelt. Das Ergebnis liegt nun neben mir, ich werde mal sehen ob ich das auf eine der ECB-Prototyper Boards gelötet bekomme und heute noch mal ausprobieren kann... Familie ist aber auch noch...

Hier mal die Schaltung zur Diskussion:

Da der Bustakt des vorgesehenen Systems 6,144 Mhz beträgt (ECB CPU 280) teile ich den Bustakt noch durch 4 um auf einen erträglichen SPI-Takt von 1,536Mhz zu kommen, bei langsameren Systemen
kann man den Teiler evtl. kleiner machen.
Das EPM3032A CPLD ist ziemlich randvoll, ein Pin und 5 Makrozellen sind aber noch frei.

Bin gespannt auf Eure Meinung.

Gruß,
Holm

UPDate: Ok, ich habe in der Zwischenzeit noch einen Muxer eingebaut mit dem sich der Taktteiler für SPI zwischen/4 und /8 umschalten läßt.
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 25.12.2019 um 12:13 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
25.12.2019, 13:53 Uhr
Klaus

Hallo Holm,

ich habe mich noch nicht mit dem SPI Zeug beschäftigt, aber sicher schon ab und an bei Nachbauten genutzt.
AVR-Zeugs, Programmierung von AVR oder STM32 o.ä.
Hast Du bei Deinem neuen Projekt ein bestimmtes Ziel die SPI Schnittstelle am Z80 zu nutzen, oder ist das erst mal eine Machbarkeitsstudie?
Hardware ist ja immer das Eine, Software musst Du dann ja auch noch "bauen" ;-)

Nach dem ersten leckeren Weihnachtsbraten habe ich mir mal aus Interesse ein Video zum Thema reingezogen:

https://www.youtube.com/watch?v=iqMiI9Zgxhk

Kurze Frage:
Sind die Outputs Q1-Q8 am 74374 die Slave Select Signale?

Interessant ist das bestimmt.
Bin gespannt, ob es läuft und wofür man es später am Z80 nutzen kann.

Schöne Bastelfeiertage und viele Grüße,
Klaus

Dieser Beitrag wurde am 25.12.2019 um 14:22 Uhr von Klaus editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
25.12.2019, 14:00 Uhr
holm

Avatar von holm

..Ja, Module wie ESP8266 beispielsweise, aber auch EEPROMS, ADU und DAU sowie Schrittmotortreiber kommen mit SPI Schnittstellen die Manches doch deutlich vereinfachen.
Der Ausgabeport mit Q1 bis Q8 ist erst einmal ein einfacher Solcher, und da man die Chip Selects benötigt
war es naheliegend den mit im Chip unter zu bringen, Anschlüsse waren ja frei. Natürlich kann man da auch ne LED oder ein Relais betreiben.. ist grundsätzlich egal.

..so..ich gehe jetzt auf die Couch, die Gans verdauen :-)

Gruß,

Holm
PS: Danke fürs Verschieben!
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 25.12.2019 um 14:03 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
25.12.2019, 14:55 Uhr
Enrico
Default Group and Edit

Das sollte doch mit nem AVR als Schnittstellenwandler einfacher gehen?
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
25.12.2019, 15:33 Uhr
holm

Avatar von holm

..nein.
Ein AVR hat an der Peripherie keine Eingabe-Latches, es ist also nicht möglich von Host aus in einem Register ohne zutun des AVR Daten abzuladen und zwischen zu speichern bis der reagiert..oder einen Port zu schreiben und den erst bei einer Leseanforderung niederohmig zu schalten (sogenannte Busregister)

DL hatte mal eine Schaltung mit AT89C2051 die eine K7634 emulieren sollte, einzige Schwierigkeit dabei war die Control-Taste die über ein extra Register erreichbar ist... geht so nicht. Nachrechnen ergab das man um den Controlstatus abzufragen innerhalb von 800ns von Seiten des AVR reagieren hätte müssen, das schafft ein 89C2051 nicht aber ein schneller AVR vllt. wenn er mit einer in Assembler programmierten ISR reagiert..(zu lesenden Port abfragen und die richtigen Daten evaluieren auf anderen Port ausgeben) habs nicht probiert.
Für meine Anwendung ist die Clock-Periode des Systemclocks 167ns, also schon ein Stück schärfer.
AVR Ports haben nach wie vor keine Latches, einige PICs haben Sowas..gefallen mir aber aus anderen Gründen nicht. Bei der Grip hängt eine PPI verkehrt herum am Bus die das bewerkstelligt, bei der K1520NET eine PIO..das wollte ich mir gerne sparen. Es ist also keineswegs einfacher.

..davon mal abgesehen, was macht ein Chip der programmiert werden muß einfacher als ein Chip der programmiert werden muß?

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 25.12.2019 um 17:39 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
26.12.2019, 15:04 Uhr
Enrico
Default Group and Edit

Das verstehe ich jetzt nicht so ganz.
Der AVR hat doch SPI als Master / Slave als Hardware drin.

Als CPLD kriegst Du den Z80-Bus noch als Hardware rein, aber nun ja,
wo auch der zeitliche Aufwand da je groesser ist, haengt davon ab, was man haeufiger
macht.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
26.12.2019, 19:37 Uhr
Bert

Zitat:

Enrico schrieb
Der AVR hat doch SPI als Master / Slave als Hardware drin.

Das ist ja nur die halbe Miete.

Auf der anderen Seite will man, z.B. durch einen Schreibzugriff auf eine IO-Adresse den Transfer auslösen.
Bei diversen PICs (= programmable interface controller) konnte man, ähnlich wie bei der Z80PIO, von außen ein Byte sicher einschreiben.
Beim AVR müßtest Du z.B. mit /WR einen Pin-Change-Interrupt auslösen und im Interrupt den Datenbus lesen.
Ich hatte das mal mit STM32 probiert und war letztendlich an der hohen Latenz gescheitert. Ok, dort wollte ich auch die Adressdekodierung gleich mit in Software machen.

Holms Ansatz scheint da ganz brauchbar zu sein. Das Thema Z80-Bus + SPI steht schon eine Weile auf meiner TODO-Liste, aber relativ weit hinten...

Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
26.12.2019, 20:58 Uhr
Enrico
Default Group and Edit

Auch klar.
Das ging aber damals mit dem Atmel fuer die Serielle auf dem M051 auch ganz gut.
Sollte der AVR also erst recht schaffen.
Ist ja auch egal wie man das am Ende macht....
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
26.12.2019, 22:08 Uhr
schlaub_01

Ich habe das letztens mit einem 16MHz ATMega32 mal experimentell ausprobiert. Allerdings in C programmiert. Die typische Zeit, bis man in der Interruptroutine ist, beträgt laut Datenblatt schon mal mindestens 4 Takte. Dazu kommen noch die Synchronisationstakte für den Input Port, d.h. hier können auch typischerweise 3 Takte vergehen, bis das Signal im AVR verarbeitet wird. Selbst mit höchster Optimierung ist es mir am KC nicht gelungen, auf den Pin Change Interrupt sauber zu reagieren - da vergehen scheinbar beim WinAVR C Compiler noch sehr viele Takte mehr, so daß ich schnell bei über 1µs gelandet bin. Ein wahrscheinlicher Grund könnte das Sichern auf dem Stack sein.
Einzig mit einer Polling Schleife in der main() war das sauber machbar, aber das ist ja nicht Sinn des Ganzen. Dann bleibt auch keine Zeit mehr, um andere Dinge zu erledigen. Die Variante mit dem CPLD ist auf jeden Fall absolut sicher und funktioniert unter allen Bedingungen. Da kann man zur Not ja immer noch einen AVR anschließen...

Grüße,
Sven.

Dieser Beitrag wurde am 26.12.2019 um 23:19 Uhr von schlaub_01 editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
27.12.2019, 12:30 Uhr
holm

Avatar von holm

@Enrico: Siehe schlaub_01...es ist eben nicht so! Ich habe auch nicht vor mit 9600 Baud eine erielle Schnittstelle zu betreiben, sondern will mit eienr Taktrate von ca. 1,5Mhz Daten da raus/rein pumpen ohne mich mit irgend einem Softwareoverhead befassen zu müssen. serielle ist Pillepalle, da hätte ich ne SIO oder ne andere UART genommen.

Eine PIO kannst Du in den Byte Ein/Ausgabemodi so programmieren das Daten mit Strobe übernommen, oder aber auf den BUS geschaltet werden. Dieser doch recht primitive Mechanismus ist in der Atmel Peripherie nicht enthalten. Wie gesagt bei einigen PICs gibts Sowas, aber der berühmteste Vertreter dürfte wohl der 8042 Controller sein (UPI Universal Peripheral Interface), den gibts z.B: auch in einer Anwendung als IEEE488 Controller..aus genau diesem Grund. Ich hatte das doch oben schon erklärt?

Mal davon abgesehen unterscheidet sich die Rechenleistung des Z280 und die eines aktuellen Atmel Mikros nicht wirklich, aber es gab in der Vergangenheit auch schon in der Peripherie teilweise leistungsfähigere Rechner als es die Haupt-CPU war, ein Beispiel ist schon die PDP11 als Host mit einer Netzwerkkarte auf der ein MC68000 residiert. Ähnlich krass ist es einen STM32 als Peripherie an einem KC einzusetzen..der könnte den gleich ganz emulieren. Meine Recherchen zu ES8266 und CP/M gruben auch prompt einen CP/M Emulator auf dem ESP32 aus.. die CPU des WLAN Moduls hat genug Power das CP/M mit zu emulieren...

Ich habe den Kram oben in ein CPLD gebrannt und experimentiert, das klappt leider noch nicht so wie ich mir das vorstelle. der Frequenzteiler und der Multiplexer sind leider Murks und führen dazu, das das Schieberegister die Daten nicht übernimmt bzw. auch noch auf falsche Betriebsarten umschaltet und in Gegenrichtung schiebt.
Lasse ich das Ding mit vollem Takt laufen funktioniert es, allerdings halt viel zu schnell. Bei 6Mhz Takt neigt eine SPI und die daran angeschlossenen Peripherie-ICs dazu Späne zu machen.

Das IO-Timing des ECB der CPU280 beschreibt Tillmann Reh wie folgt, es entspricht etwa einem 6Mhz Z80:

Es sind also 3 Zyklen a ca. 167ns.
Ich muß die Schreiboperation in das Schieberegister (S1=S0=H) also so zurecht basteln, das die Daten zuverlässig auf dem Bus liegen und nur gegen Ende des Schreibzyklus eine Übernahme erfolgt.
Ich muß also die 3 Zyklen so um setzen das nur eine kurze Datenübernahme am Ende des Schreibzyklus stattfindet, aber das SR mit niedrigerem ( Viertel oder Achtel )Takt arbeitet ohne das komische Zustände an S1 und S0 auftreten können. (S1=L, S0=H shift right, H H parallel load, L L hold, unerwünscht H L shift left)

Ich habe da erst mal einen Knoten im Kopf, denke noch nach.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 27.12.2019 um 12:45 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
27.12.2019, 13:15 Uhr
HofMar

Hallo Holm,
demnach muß der volle Systemtakt am 299 anliegen, damit das Laden klappt. Ich würde versuchen den Takt (SCK) mit dem 299er Mods LL=Hold zu verlängern. Also einen weitern Zähler ähnlich dem 161, der nun die "Waitstates" zählt, den Hold-Zustand beim 299 erzwingt und den Takt SCK sperrt (ähnlich dem Tor DAND2).
Gruß Martin

Dieser Beitrag wurde am 27.12.2019 um 13:16 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
27.12.2019, 13:36 Uhr
holm

Avatar von holm

.ja.. hatte ich auch schon auf dem Schirm. Andere Möglichkeit ist den Vorteiler bei Schreibzugriff zurück zu setzen und speziell zur Datenübernahme einen zusätzlichen Taktimpuls zu erzeugen...

Ich möchte ja eben nicht einen mit Vollgas laufenden 74299... das geht mir zu schnell.
Bei Taktung mit einem Achtel der orig Taktfrequenz taucht halt mal gar keine L/H Flanke am Takteingang
der 299 auf so das er gar keine Daten übernimmt. Mann ist das vergriesgnaddelt.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
27.12.2019, 14:39 Uhr
HofMar

Hallo Hom,
an den Schreibzugriffen würde ich eher nichts "kompliziertes" machen, da hier je nach Ansteuerung leicht geänderte Voraussetzungen existieren könnten. Bei der Taktung des Schieberegisters hast Du alles unter Kontrolle. Das eigentliche Problem ist, daß das Laden des 299 synchron (gleicher Takt) zum Schieben erfolgt. Vermutlich wäre ein Schieberegister mit asynchronem Ladeeingang besser.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
27.12.2019, 15:01 Uhr
holm

Avatar von holm

Naja, beim Schreibzugriff läßt sich die Sache entschärfen in dem man beim Schreiben S0 zwangsläufig mit S1 verknüpft, d.h. also S0 auf H geht wenn S1 auf H geht (nand Gatter). Traurig ist halt das man zum passenden Zeitpunkt den Ladeimpuls erzeugen muß wenn kein Takt anliegt (was hier der Fall ist, weil ich den Takt deutlich langsamer machen möchte und ein Taktwechsel während des Schreibzyklus mit zunehmendem Teilerverhältnis immer unwahrscheinlicher wird). Das bringt mit sich die Takte innerhalb des CPU-Schreibzyklus zu zählen und zum passenden Zeitpunkt den Übernahmetakt zu generieren, dazu müßte ich mir ggf. einen Z80 IO Zyklus auch nochmal genau ansehen damit das auch da paßt. Doppelt puffern wäre die nächste Variante...

Der Vorteil des 74299 ist aber eben sein bidirektionaler "Busanschluß".
Ich habe jetzt mal in "Streng Daten digitaler Integrierter Schaltkreise" geblättert, ich finde gleich gar kein SR mit asynchronem Ladeeingang (egal ob 4 oder 8 Bit) ..abgesehen davon das das dann auch in der Bibliothek von Quartus existieren müßte oder ich müßte es "zu Fuß" zusammenbauen.

Hast Du einen Vorschlag?

Gruß,
Holm

PS: Das Dand2 ist nix weiter als ein AND Gatter mit zusätzlich negiertem Ausgang, ein 7400 und ein Negator wäre das Selbe gewesen.
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 27.12.2019 um 15:03 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
27.12.2019, 15:41 Uhr
HofMar

Hallo Holm,
nun evtl. mußt Du den Ladeimpuls nicht selbst erzeugen. Wenn Du den Vorteiler nicht zurücksetzt, sondern mit n-1 lädst, kommt sofort mit dem nächsten Systemtakt auch ein Takt wieder raus. Dieses Vorladen müßte dann aber asynchron mit der fallenden Flanke des SPI-Write erfolgen. Nur wirst Du dann das nächste Problem haben, daß nur der erste Systemtakt das 299 lädt. Das könnte zu früh sein, und die zwei bis drei Nachladungen werden benötigt.
Also brauchst Du einen Vorteiler, der beim SPI-Write nicht teilt, sondern den Takt unverändert durchreicht. Ein Demultiplexer scheidet wegen der Hazards aus.
Man könnte dazu aber ein 74 nehmen, wo nur beim SPI-Write mit den Setz- (S) und Rücksetz- (R) Eingängen dem Takt gefolgt wird. Während des Schiebens bleiben diese Eingänge inaktiv und es wird dann über den Takt- (C) und Dateneingang (D) der Takt entsprechend geteilt.
Gruß Martin

Dieser Beitrag wurde am 27.12.2019 um 15:42 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
27.12.2019, 16:16 Uhr
HofMar

Hallo Holm,
eine noch bessere Variante wäre, aus dem Systemtakt einen Mastertakt mit doppelter Frequenz zu erzeugen. (Z.B. mittels XOR des Systemtaktes mit dem über weitere Inverter verzögerten Systemtakt.) Diesen kann man dann wieder auf den Takt eines D- oder JK-Flipflop geben. Die Vorbereitungseingänge würden dann entsprechend des SPI-Write immer einen Wechsel (Teilung) oder erst nach dem Vorteiler wechseln. So werden Hazards definitiv vermieden. Jedoch können dann aus den drei Zyklen aus 009 auch mal nur zwei werden, je nach Zustand des Takts durch den Vorteiler.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
27.12.2019, 19:23 Uhr
holm

Avatar von holm

Takt durch Verzögerungs verdoppeln ist in einem CPLD oder FPGA Schweinerei..sollte man tunlichst unterlassen, nur synchrone Events. Melde mich morgen wieder..
Gruß Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 28.12.2019 um 11:20 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
27.12.2019, 22:07 Uhr
HofMar

Hallo Holm,
das hatte ich mir schon gedacht. Ich denke, dann ist meine erste Idee die Bessere. Einfach dem 161 noch einen weiteren 161 als "Vorteiler" vorsetzen. Beim 161 greift das Laden unabhängig der ENT und ENP Eingänge. Damit hast Du das U880-Interface schon mal wieder hergestellt. Dann nutzt Du das ENT weiterhin als Endekennung und kaskadierst die beiden 161 mittels ENP (oder doch umgekehrt?). Nun noch den zweiten 161 sauber initialisieren ein paar Multiplexer für die Taktauswahl (also welcher Ausgang vom zweiten 161 auf den ENP geht), mit einem weiteren Eingang beim DAND2 sauber das SCK aufbereiten und fertig bist Du.
Und Du hast überall (beide 161 und 299) den gleichen Takt, wie Du es bei synchronem CPLD Dir wünscht.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
28.12.2019, 15:34 Uhr
HofMar

Hallo Holm,
ich habe mit das mit dem Kaskadieren von 161 noch einmal angesehen. Aktuell startet der 161 mit dem Laden von 8, um dann bei 0 (eigentlich 16) angehalten zu werden. Dazu wird der Ausgang QD genommen der mittels ENP ein Hochzählen verhindert.
Ich würde das umbauen und mit 7 starten. Dann kannst Du den Ausgang RCO (wird bei 15 aktiv) negiert nutzen. Nun greift auch das Kaskadieren des zweiten 161 (Vorteiler) über den ENT Eingang (der koppelt auch zum RCO Ausgang durch). Den zweiten Vorteiler mußt Du nur entsprechend laden. Hier würde ich noch ein AND spendieren und (aufgrund der negativen Logik) den Ladeeingang (/LDN) entweder über SPI-Write oder dem negierten RCO (vom Vorteiler) koppeln. Selbst wenn du nun 15 (der Wert ist negiert zu interpretieren) in den Vorteiler lädst, sollte das ohne Teilung (also wie jetzt auch) laufen. Du kannst dann jeden Wert als Vorteiler (auch drei, fünf, sechs oder sieben) nutzen.
Wenn ich nichts weiter übersehen haben, solltest es dann schon klappen. Eine Änderung am DAND2 für SCK ist dann nicht mehr nötig.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
28.12.2019, 16:37 Uhr
holm

Avatar von holm

Kannste das mal in einer kurzen Skizze (oder einem Kicad Schaltplan) aufmalen?
Ich habe bis gestern Nacht mit meinem neuen Schwager eine Pulle Scotch ausgezutscht.. mir ist heute noch nicht nach tiefgreifenderen Gedankengängen...

:-|

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
29.12.2019, 02:01 Uhr
HofMar

Hallo Holm,
Skizze bekomme ich so schnell nicht hin. Aber hier ein "Kochrezept":
1) freqdiv und 21mux raus, Pin 2 CLK direkt auf CLK von 299 und 161,
2) ENP vom 161 nicht an QD, sondern über einen Inverter an RCO,
3) A, B und C vom 161 an VCC und D an GND (die 8 für acht Bits wird invertiert angelegt),
4) weiteren 161 hinzufügen, GND, VCC und CLK anschließen, ENT auf VCC setzen,
5) A, B, C und D mittels Jumper und Pullup einstellbar machen (auch hier werden die Zyklen zum Verzögern invertiert eingestellt),
6) RCO (des zweiten 161) an ENT des ersten 161 (anstelle von VCC),
7) den LDN des zweiten 161 über ein AND mit zwei Eingängen (wirkt hier wie ein Oder), ein Eingang an SPI Write, der andere Eingang über einen Inverter an RCO (des zweiten 161),
8) beide ENP verbinden.
Nach Schritt 3) sollte alles normal OHNE Vorteiler laufen. Aber man kann dann mit ENT Takte "aussetzen"!
Darum kümmert sich dann der zweite 161, der als programmierbarer Vorteiler arbeitet. Er wird dann aber bei jedem SPI Write sofort zurückgesetzt um einen vollen Takt zu gewähren.
Bekommst Du die Skizze auch selbst mit dem "Kochrezept" hin?
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

021
29.12.2019, 11:27 Uhr
holm

Avatar von holm

So hier?

(sorry für groß)

.mit Jumpern isses a Bissel schlecht...so ne kleine Pinzette hab ich nicht das ich die im CPLD umsetzen könnte.
Ich denke aber darüber nach wenn das funktioniert den 374 rauszuwerfen (nur seinen Chip Select nach Außen) und dafür ein weiteres Register drin unter zu bringen mit dem man u.A. den Vorteiler programmieren kann, ein Bit davon könnte die SCK Polarität umschalten usw.. Ich müßte nur den Adreßdecoder umbauen und A1 noch mit einbeziehen.
Interessant ist das das Design weniger Macrozellen erfodert als das vorhergehende, keine Ahnung Was der Fitter da treibt.

Ich steige erst mal noch nicht durch was du da machst, ich muß da mal drüber meditieren.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
29.12.2019, 12:31 Uhr
holm

Avatar von holm

...funktioniert leider nicht, es kommt lt. Oszi nicht nachvollziehbares Zeug heraus, SCK scheint durch zu laufen mit 166ns.

Eine interessante Sache habe ich in "Daten digitaler integrierter Schaltkreise" zum 161 gefunden:

"Ü ist H, wenn E2 H und der Zähler "voll" ist (HHHH). Ü ist hier wohl RCO, bei Motorola TC und im Fairchild Datenblatt RCO ..letzteres zeigt auch die Innenschaltung. RCO kommt aus einem NAND mit 5 Eingängen, 4 gehen an die Zählerausgänge, einer an den negierten EnableT (ENT). Mit ENT des Vorteilers an H wird der Ausgang niemals aktiv. (was der Aussage aus dem Buch widerspricht). Im Fairchild DB gibts aber auch ein Timing Diagramm das ein aktives RCO bei aktivem ENT zeigt, allerdings ist das H aktiv ..also ist die Innenschaltung Grütze an der Stelle, auch schön das Jeder eigene Bezeichnungen hat...

Eine Sahe daran ist häßlich: Der SCK Takt wird "Nadeln" entsprechen und das ist für eine SPI eigentlich unüblich. Normalerweise ist das ein 1:1 Takt, beispielsweise wird mit HL Falnke das Bit auf die Leitung gelegt und mit LH vom Slave übernommen. Das dürfte mit verschiedener Peripherie so mit "Waitstates" zu Ärger führen..

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 29.12.2019 um 12:31 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

023
29.12.2019, 15:41 Uhr
HofMar

Hallo Holm,
der Plan in 021 hat leider noch Fehler. Der Takt am zweiten 161 (Vorteiler) muß natürlich auch am Takt angeschlossen werden!
Wenn nun SCK die ganze Zeit durchläuft, scheint das Sperren von RCO über ENT des ersten 161 nicht so zu funktionieren, wie erhofft. ENT müßte mit obigen Fehler immer Low sein. Dann müßte RCO High sein, damit der Takt unterdrückt wird.
Aber Du schreibst selbst, daß RCO (Ü) nur High wird, wenn ENT (E2) High ist.
Also muß hier eine andere Logik her.
1) ENT des ersten 161 kommt wieder auf VCC,
2) ENP des ersten 161 wird nicht nur aus dem invertierten RCO erzeugt, sondern wir nehmen ein NOR (durch die Negierung wird's ein Und) und schalten das negierte RCO des zweiten 161 an diesen zweiten Eingang!
Das SCK wird asymetrisch, wenn es einen Vorteiler (ungleich 0) gibt. Das sollte aber nicht schaden, da immer nur mit EINER Flanke (L -> H) gearbeitet wird. Ansonsten müßte man das SCK ganz anders erzeugen. Wobei mir die Koppelung von Vorbereitungssignalen (alle Ausgänge der Zähler) mit dem Takt über eine Logik (hier DAND2) eigentlich auch mißfällt (hier könnten Hazards entstehen). Da müßte z.B. ein D- oder JK-Flipflop rein.
Gruß Martin

Dieser Beitrag wurde am 29.12.2019 um 18:21 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

024
29.12.2019, 20:37 Uhr
holm

Avatar von holm

An einen D172 als Bestandteil des Vorteilers hatte ich auch schon gedacht.

Ich kämpfe aber noch mit einer anderen Sache..Vorteiler mal beiseite.
Ich bekomme 9 SCK Impulse am Ausgang, auch wenn ich den Taktzähler wie ursprünglich vorlade,
da wird im Prinzip ein Bit vor Bit7 [...0] gesendet beim Vorladen des Zählers. Ich wollte heute eigentlich
den ollen HP 1631 Logikanalyzer mal auf der Werkstatt hoch holen, habe mich aber nicht aufraffen können :-) ..werde das morgen aber mal tun. Der 7D20 Digitizer des alten Tek den ich hier in der Bastelbude stehen habe kommt an seine Grenzen bei der Untersuchung der Signale. Eigentlich muß eine Art Logikanalyse auch mit der Designsoftware Quartus 13.0 möglich sein, ich weiß aber noch nicht wie. Auch will die Software irgendwelche Constraints von mir wissen von denen ich keine Ahnung habe, die Timinganalyse mein aber die Grenze für CLK läge irgendwo bei 110Mhz..sowas von uninteressant.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 29.12.2019 um 20:46 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

025
29.12.2019, 23:13 Uhr
HofMar

Hallo Holm,
neun SCK-Takte klingt merkwürdig. Aber ich habe eine Idee. Du hast bei der Bildung des S0 beim 299 noch ein NAND2 spendiert, was nur High wird, wenn weder SPI-Write noch das Schieben aktiv sind. So was ähnliches müssen wir beim Tor für SCK auch machen. Sowie der erste CLK-Takt mit aktivem SPI-Write kommt, ist RCO des 161 Low und das Tor könnte schon öffnen. Das sollten wir solange verhindern, bis SPI-Write aktiv ist!
Vermutlich wäre es besser diese Bedingung (Schieben ist erst erlaubt, wenn SPI-Write High ist) schon beim ENP des ersten 161 einzubauen. Also einfach noch ein AND einfügen. Das NAND2 müßte dann wieder entfallen können.
Ich sehe aber noch ein anderes Problem. Nach dem Reset des ersten 161 läufet dieser immer einmal durch. Demnach ist die Nutzung des RCO anstelle des QD doch nicht so geschickt. Da wir RCO mit dem ENT nicht mehr benötigen würde ich das wieder zurückbauen (siehe Schritte 2 und 3 in 020). Also Beschaltung des ersten 161 wieder wie unter 001. Aber ENP wird mit einem AND mit drei Eingängen erweitert. Gezählt wird nur, wenn
a) QD durch das Laden von 8 mittels LDN erfolgte,
b) RCO des zweiten 161 einen Takt erlaubt und
c) SPI-Write inaktiv (High) ist.
Dieses Signal ENP des ersten 161 nehmen wir auch als IN1 beim Tor von CLK für SCK.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

026
29.12.2019, 23:24 Uhr
HofMar

Hallo Holm,
ein D172 (72) hat aber einen negierten Takt und reagiert dann auf die fallende Flanke. Mit dem Inverter würde das klappen. Ich würde aber eher einen halben 109 nehmen. Hat alles was man braucht, positiven Takt auf CLK und /CLR, Eingang (ähnich IN1) auf J sowie /K und /PR auf VCC. /Q sollte dann Dein SCK sein.

Nachtrag:
Ich schaue mit das SPI mal genauer an. Laut Wikipedia und mikrocontroller.net gibt es vier Möglichkeiten, die leider nicht standardisiert sind. Demnach kann SCK positiv oder negativ sein. Das hast Du mit SCK und NSCK schon abgedeckt. Die zweite Unterscheidung gibt an, wo der SCK Takt ausgegeben wird. Da dieser IMMER kürzer als die Datenbits lang sind, kann er am Anfang oder Ende eines Datenbit sein. Ist er am Anfang, erfolgt mit der zweiten Flanke die Datenübernahme. Entsprechend ist es die erste Flanke, wenn er am Ende ist.
Ich ging oben davon aus, daß der SCK-Takt am Anfang liegt (CPHA=1).
Würden wir nun nicht nur am Ausgang, sondern auch den Eingang mit CLK und /CLR optional negieren. Würden wir das SCK möglicherweise zu früh erzeugen.
Dafür müßten wir ein weiteres JK-Flipflop (im 109 sind zwei drin) nehmen. Dazu wird CLK und /CLR negiert am Takt angeschlossen, das J holen wir nun nicht mehr vom Eingang des 161 (siehe 025), sondern jetzt vom Ausgang QD.
Es wird also für CPHA=0 erst der Zustand von 161 und 299 übernommen. Das SCK-Flipflop bleibt vorerst zurückgesetzt. Erst mit der nächsten Flanke des CLK wird der zuvor von 161 und 299 übernommene Zustand auch durch einen SCK-Takt auf SCK übertragen.
Von einer Forderung nach einem 1:1 Tastverhältnis für das SCK-Signal sehe ich hier nichts.
Außerdem fehlt bei Dir noch das SS-Signal. Es kann aber aus dem QD-Signal des 161 gewonnen werden.
Gruß Martin

Dieser Beitrag wurde am 30.12.2019 um 03:54 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

027
30.12.2019, 11:22 Uhr
holm

Avatar von holm

Zitat:

HofMar schrieb
Hallo Holm,
neun SCK-Takte klingt merkwürdig. Aber ich habe eine Idee. Du hast bei der Bildung des S0 beim 299 noch ein NAND2 spendiert, was nur High wird, wenn weder SPI-Write noch das Schieben aktiv sind. So was ähnliches müssen wir beim Tor für SCK auch machen. Sowie der erste CLK-Takt mit aktivem SPI-Write kommt, ist RCO des 161 Low und das Tor könnte schon öffnen. Das sollten wir solange verhindern, bis SPI-Write aktiv ist!
Vermutlich wäre es besser diese Bedingung (Schieben ist erst erlaubt, wenn SPI-Write High ist) schon beim ENP des ersten 161 einzubauen. Also einfach noch ein AND einfügen. Das NAND2 müßte dann wieder entfallen können.
Ich sehe aber noch ein anderes Problem. Nach dem Reset des ersten 161 läufet dieser immer einmal durch. Demnach ist die Nutzung des RCO anstelle des QD doch nicht so geschickt. Da wir RCO mit dem ENT nicht mehr benötigen würde ich das wieder zurückbauen (siehe Schritte 2 und 3 in 020). Also Beschaltung des ersten 161 wieder wie unter 001. Aber ENP wird mit einem AND mit drei Eingängen erweitert. Gezählt wird nur, wenn
a) QD durch das Laden von 8 mittels LDN erfolgte,
b) RCO des zweiten 161 einen Takt erlaubt und
c) SPI-Write inaktiv (High) ist.
Dieses Signal ENP des ersten 161 nehmen wir auch als IN1 beim Tor von CLK für SCK.
Gruß Martin

Das NAND war dazu da, bei aktivem SPI Write ein S1=S0=H zu erzwingen, weil sonst abhängig vom aktuellen Zählerstand des 161 auch linksschieben auftreten kann, das habe ich mit "nassem Finger" am offenen SL Eingang am Ausgang des SR oszillografisch nachweisen können, d.h. ein SPI Write erzwingt S1=S0=H.

Über die Leseseite des Theaters und die Phasenlage mache ich mir erst einmal weing Gedanken so lange das senden noch nicht fehlerfrei funktioniert.
Fehlende SS Signale? Was glaubst Du was der 374 da unten so treibt?

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 30.12.2019 um 11:25 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

028
30.12.2019, 15:35 Uhr
HofMar

Halllo Holm,
ja, Du hast mit dem NAND2 vollkommen Recht. Das wir zur Betriebsicherheit in einem extrem "unglücklichen" Zustand benötigt. Bei jedem Laden wurde mit dem ersten Ladetakt der 161 sauber mit der 8 vorbereitet, der 299 macht aber eine links Schiebung. Erst mit dem zweiten Takt (SPI-Write ist dann immer noch aktiv) wurde erneut die 8 in den 161 geladen, nun aber erst die SPI-Daten in den 299. Das hast Du mit dem NAND2 umgangen und es wird schon beim ersten Takt die Daten in den 299 geladen.
Es gibt aber noch ein anderes Problem. Es wäre möglich, daß ein SPI-Write eine laufende serielle Übertragung unterbricht. Hier haben wir noch keine Verriegelung.
Was funktioniert nach den letzten Ändrungen (siehe 025) noch nicht?
Der 374 ist für mich nur ein Portausgang. Hat der mit dem SPI etwas zu tun? Mir fehlt da eine Koppelung zum Zustand "Schieben" mittels QD des 161.
Gruß Martin

Dieser Beitrag wurde am 30.12.2019 um 15:37 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

029
30.12.2019, 16:11 Uhr
holm

Avatar von holm

Hallo Martin,

das Letzte zuerst: Der SS Ausgang der SPI ist prinzipiell immer asynchron, also ein einfacher Ausgabeport wie hier auch. Es gibt Ausnahmefälle, ja, aber die unterstützen eigentlich nie mehrere Slaves.
Beispiel ATXMega256A3BU..da habe ich verschiedene Devices dran, u.A. ne SD Karte und eine externe SIO. Es gibt aber nur einen SS Ausgang der auch noch zu Fuß programmiert werden muß. Bibliotheken wie fatfs sehen das vor.

Ich habe mich in der Zwischenzeit etwas mit der Simulation befaßt und habe auch prompt gefunden woher die zu vielen Takte kamen, eben vom Einschreiben in den 74161 über mehrere Taktzyklen. Ich mache die Qd zu ENP Rückkopplung jetzt über ein AND2, verknüpft mit SPI Write..und Ruhe ist. Des Weiteren hatte mich die PLCC Fassung geeärgert, mußte erst mal Pins nachbiegen, das 8.Bit war immer H...

Nochwas: Der Tristate-Buffer "tribuf" ist dazu da, über das Lesen eines Ports mit Bit 7 feststellen zu können ob das Schieberegister noch schiebt und ein "über den Haufen Laden" von Daten von der CPU Seite her zu verhindern. Das ist IMHO schlauer als irgendwelche Aktionen die das Hardwaremäßig verhindern sollen ohne der CPU zu erzählen das sie "ins Leere" geschrieben hat. Man müßte ja dann noch Waitstates generieren oder sowas Häßliches.

Hast Du die Möglichkeit Quartus 13.0 SP1 irgendwo zu installieren?

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 30.12.2019 um 16:17 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

030
30.12.2019, 16:46 Uhr
HofMar

Hallo Holm,
vermutlich hast Du mit dem SS auch wieder Recht. Es ist nicht immer klar, wann SS deaktiviert wird. Teilweise nach einem Byte, manchmal aber erst nach mehreren Bytes. Bei einer Koppelung zum QD würde es sichh immer vor und nach einem Byte ändern. Der Vorteil ist dann, daß man schnell viele Daten übertragen kann ohne diese Handarbeit zu leisten. In meinen Augen auch die Aufgabe. Aber durch die vielen Optionen kann das auch schnell sehr komplex werden.
Würde man SS doch für jedes Byte per Hardware erzeugen, könnte man mehrere Slaves auch an mehrere Adressen bereits beim SPI-Write koppeln. Man würde dann die Adressen binär kodiert ins Register packen und daraus dekodiert das SS erzeugen. Das hätte den Vorteil, daß wirklich nur ein Schreibzugriff nötig ist. Im Idealfall kann man dann mittels des Befehls otir mehrere KBytes am Stück übertragen. Durch das Inkrement des Adressvektor und der Schleifenbedingung sollten so viele Takte verstrichen sein, daß ein bedingungsloses Schreiben (ohne Abtesten des Done-Bits) immer erfolgreich ist. Außer wenn Dein Vorteiler so hoch eingestellt ist und damit das SPI extrem langsam ist.
Wenn nun acht Takte vorhanden sind, läuft es nun?
Was brauche ich für Quartus 13.0 SP1? Woher nehme ich das? Habe damit noch nichts gemacht.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

031
30.12.2019, 16:56 Uhr
holm

Avatar von holm

Derzeitiger Zustand, (ich habe erst mal an der Simu gebastelt).

So sieht die Simu aus:

Auf dem ollen Oszi..(sorry, ist jetzt zu dunkel in der Bude, kein vernünftiges Foto zu machen)

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

032
30.12.2019, 17:30 Uhr
HofMar

Hallo Holm,
das sieht schon mal gut aus, aber Du hast den zweiten 161 gar nicht mehr drin. Außerdem hast Du eine zu lange Laufzeit von S0, die unnötig ist:
S0 = !(SPI-Write & !(SPI-Write & QD))
S0 = !SPI-Write + (SPI-Write & QD)
S0 = (!SPI-Write & !QD) + (!SPI-Write & QD) + (SPI-Write & QD)
S0 = (!SPI-Write & !QD) + (!SPI-Write & QD) + (!SPI-Write & QD) + (SPI-Write & QD)
S0 = !SPI-Write + QD
Also kannst Du den Eingang des Inverter NOT (inst12) dirkt vom QD holen. Für das IN des TRIBUF würde ich das auch machen. Hier kann schon recht früh (während des Schreibens) die Belegung angezeigt werden.
In der Simulation würe ich auch QD, ENP, S0 und S1 mit anzeigen.
So nun das AND2 (inst33) mit einem weiteren Eingang versehen und den zweiten 161 aus 021 ranhängen (also nicht auf ENT, sondern den dritten Eingang).
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

033
30.12.2019, 17:36 Uhr
HofMar

Hallo Holm,
ich sehe da noch etwas. Du hast SPI-Write nicht nur an das AND2 (inst33) gelegt, sondern auch an ENT. Das ist auch doppelt (hat aber keine Auswirkung auf die Laufzeit). Da wir das AND2 auch für das Tor des SCK benötigen (wir hatten das mall mit ddem RCO probiert, was nicht klappte), macht das SPI-Write auf ENT hier keinen Sinn. Also kann das wieder auf VCC gelegt werden.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

034
30.12.2019, 18:55 Uhr
holm

Avatar von holm

Ja.. das hatte ich vorher gemacht, brachte aber Nichts. Es ist egal ob das an Vcc oder an SPI Write hängt. Ist Richtig, das kann zurück.

Ich habe den 2. 161 temporär rausgenommen um erst mal "Ruhe" in die Schieberei zu bekommen, der ist schnell wieder drin. IMHO hatte es keinen Sinn das Ding drin zu lassen weil es die Fehlersuche verkomplizierte.
Zwischenzeitlich mußte ich auch den Tribuf ausbauen, weil der Fitter nicht in der Lage war einen Prüfausgang (an QD) und den Threee State Buffer zu routen.
Ich will mal noch forschen wie man ohne Ausgang Signale untersuchen kann, die werden swar als combinatorial Signals geführt und angezeigt, aber die rühren sich in der Simu nicht. Warum nicht? werden doch eh nur errechnet?

Mit den langen Singalpfaden...ich glaube da nicht das das kritisch ist. Die Logik wird eh minimalisiert, das kürzt sich raus.

Die überflüssigen Takte sind erst seit dem AND hinter QD verschwunden, vorher hingen der Inverter, DAND2 und Tribuf an QD.

Ich werde heute nicht mehr weit kommen, wir sollen nachher nochmal rüber zur Nachbarin kommen, ihr Mann stirbt gerade.. Ist ein enger Freund...

Morgen kommt Gerphi (anderer Kumpel) her und feiert mit uns, wir sitzen dann sicher noch gemeinsam an der Sache.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 30.12.2019 um 18:59 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

035
30.12.2019, 19:58 Uhr
holm

Avatar von holm

..hab mal in der Doku reingelesen: Es ist nicht möglich interne Signal Nodes wie S1 und S0 in der Simu darzustellen, weil die vom Fitter wegoptimiert sind, die Knoten existieren nicht notwendigerweise.
Darstellbar sind alle Eingänge und Ausgänge sowie Register. Ich hatte deshalb provisorisch an QD einen Ausgang angelötet um mir das anzeigen lassen zu können, was dazu führte das er den Tribuf nicht mehr anschließen konnte...
Der 74161 und der 74299 sind Submodule, bestehend aus Gattern und Flipflops. Gerümpel das für die "echte" Funktion nicht gebraucht wird, wird gnadenlos rausoptimiert und da der Simulator mit dem läuft was der fitter übrig läßt, greift der da ins Leere ...Ich 'abe gar kein S0....

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

036
30.12.2019, 20:21 Uhr
holm

Avatar von holm

..so muß jetzt weg.. is suboptimal...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

037
30.12.2019, 21:49 Uhr
HofMar

Hallo Holm,
hatte mit das Quartus 13.0 SP1 runtergeladen und installiert. Das will aber eine Lizenz haben. Erst jetzt sehe ich, daß es auch eine freie "Web Edition" gibt. Das mache ich aber auch nicht mehr haute. Was hast Du genommen?
Okay, mit den fehlenden internen Signalen ist blöd. Ich kann verstehen, daß wenn diese "wegoptimiert" werden, sie nicht existieren. Aber sowohl S0 als auch S1 und ENT müssen definitiv existieren. Kommst Du an das VHDL des Fitter ran?
Dann warte ich mal Deine nächsten Schritte ab. Ich denke, daß meiste müßte geklärt sein. Muß dann nur noch ein wenig optimiert und dokumentiert werden. Evtl. bekommt man das VHDL raus und macht es dann damit.
Dann noch einen schönen Abend mit Deiner Nachbarin in dieser schweren Zeit. Das ist definitiv wichtiger als dieses Design.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

038
30.12.2019, 22:03 Uhr
HofMar

Hallo Holm,
beim zweiten 161 bleibt es beim invertierten RCO, nicht den QD nehmen! Da Du den QD mittels VCC über D setzt, sind die ersten vier SCK-Takte unverzögert. Du lädst die 12 und s braucht vier Takte bis zur 16 (0, mit QD=L und damit dem Hold vom ersten 161 und 299).
Also den Eingang des AND (inst36) nicht an QD, sondern über einen Inverter an RCO. Das Laden von 12 (A und B an GND, C und D an VCC) kann bleiben, wenn ein SCK-Takt viermal länger als ein CLK-Takt (Tastverhältnis 1:7) sein soll.
Was mich aber völlig verwundert ist die Daten laufen "rückwärts". Läuft das Schieberegister anders herum? Warum dieser Unterschied zu 031?
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

039
30.12.2019, 22:25 Uhr
holm

Avatar von holm

...wieder da.
Das mit den Rückwärtsdaten ist einfach lösbar, man kann beim Eingeben der "Arbitrary Value" quasi festlegen wo das MSB ist. Hier siehts jetzt aus wie auf dem Oszi, MSB links.

Die fehlenden Signale bekommst du genau dann, wenn Du einen Ausgang da anschließt weil der Fitter dann weiß, das dieser Punkt benötigt wird. Da aber 31 von 32 Pins belegt sind mit dem Kram den ich bisher da reingebaut habe, können wir da leider nicht aus dem Vollen schöpfen.
Ich sagte ja schon das ich das ggf. noch überdenken werde und das 374 Register rauswerfen, nur das Steuersignal übrig lassen. Dan paßt A1 noch mit hinein und man kann z.B. ein Register für den Vorteilerfaktor und die SCK Polarität da drin mit unterbringen. Freilich muß man den Decoder erweitern.

Vllt. bastele ich noch ein Bisschen mal sehen was dabei raus kommt.

Schreib mir mal ne Mail wegen der Lizenz an holm at freibergnet punkt de.

Gruß,
Holm

..habs probiert..wird immer verrückter..

Dieser Beitrag wurde am 30.12.2019 um 22:36 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

040
30.12.2019, 23:02 Uhr
HofMar

Hallo Holm,
nee, das wird nicht verrückter, du hast da etwas falsch negiert. RCO wird negiert auf LDN, aber direkt zum AND3 geführt. Der Komplex erster 161 und 299 bearbeiten einen Takt nur, wenn dieser Eingang (am AND3) High ist. RCO (der zweiten 161) wird High, wenn die 15 erreicht ist und der nächste Wert mittels LDN geladen wird.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

041
31.12.2019, 09:44 Uhr
holm

Avatar von holm

Das hatte ich gestern schon ausprobiert, es wird dann gar kein SCK erzeugt.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

042
31.12.2019, 14:26 Uhr
HofMar

Hallo Holm,
das ist extrem merkwürdig. In 039 sieht man sehr gut, daß es drei Takt gibt, wo die Bits geschoben werden und dann der vierte Takt wo nichts passiert. So wiederholt sich das auch. Eigentlich sollte das (daher auch die Negation) genau umgekehrt sein. Vielleicht legst Du diese Leitung (Koppelung der beiden 161) mal auf einen Ausgang und nimmst den in die Simulation mit rein. (Ich erwarte hier mit aktuellen Vorladung ein Signal mit einem Tastverhältnis 1 für High:3 für Low.) Ich kann mir das nicht erklären. Es müßte so funktionieren und alle obigen Analysen bestätigen das auch.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

043
31.12.2019, 14:37 Uhr
HofMar

Hallo Holm,
ich hab's gefunden. Beim zweiten 161 hast Du ENP nach dem AND3 gekoppelt. Der muß nur an den QD ran. Wir müssen hier sauber zwischen den Ausgang QD des 161 und dem Ausgang AND3 unterscheiden.
Der Ausgang QD ist BUSY oder /READY und ist High, während der gesamten Übertragung.
Der Ausgang AND3 ist SHIFT oder /HOLD und besagt, daß es bei High zu einem Takt mit aktiver Schiebung kommt.
Der Vorteiler (zweiter 161) wird über die ganze Zeit BUSY benötigt.
Gruß Martin

Dieser Beitrag wurde am 31.12.2019 um 14:39 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

044
31.12.2019, 14:45 Uhr
holm

Avatar von holm

Also RCO vom Vorteiler über Negator mit dem AND inst36 verbunden führt dazu das RCO nicht mehr aktiv wird. Ich habe den Ausgang dran gebastelt RCO ist dauerhaft L, SCK dauerhaft H.
Wolltest Du mir nicht mal ne Mail schreiben?

Bei der Schaltung von gestern Abend sieht das so aus:

also diese:

Hänge ich den Eingang des 3-Eingangs-And vor den Negator, zuckt sich kein SCK mehr und auch RCO nicht.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 31.12.2019 um 15:02 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

045
31.12.2019, 14:48 Uhr
HofMar

Hallo Holm,
es gibt noch ein anderes Problem. Der Eingang S0 des 299 geht über das NAND2 direkt an QD (BUSY) des 161. Damit hält der 299 erst nach der Übertragung an. Er soll aber auch in den "Waitstates" angehalten werden. Also ist hier auch der Ausgang des AND3 (SHIFT) zu verwenden. Das SHIFT sollte exakt den ersten 161 (/HOLD), den 299 (/HOLD) und das Tor für SCK bedienen! Ich denke mit diesen Bezeichnungen wird es auch verständlicher.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

046
31.12.2019, 14:51 Uhr
HofMar

Hallo Holm,
nein, nicht die Koppelung RCO des zweiten 161 zum EINgang des AND ändern. Die Rückkoppelung vom AUSgang des AND zum ~~ENT~~ ENP des zweiten 161 ändern!
Mail kommt, wenn ich Zuhause bin!
Gruß Martin

Dieser Beitrag wurde am 31.12.2019 um 16:42 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

047
31.12.2019, 16:05 Uhr
holm

Avatar von holm

Aaaalso..ich habe jetzt vom And -Ausgan einen Negator an ENT des Vorteiler-161 geschaltet, ENP auf Vcc.
Die Simulation zeigt das jetzt die Pausen (RCO) NACH dem Ablauf der gesamten Bitschieberei erzeugt werden... die Pausen werden also mittels ENT unterdrückt.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

048
31.12.2019, 16:41 Uhr
HofMar

Hallo Holm,
ich glaube wir reden aneinander vorbei (bzw. hatte ich auch einen Tipfehler in 046). Also Kochrezept zu Schaltung nach 044:
- oberer Eingang des AND3 nicht vom Ausgang des Inverters, sondern vom Eingang abgreifen (siehe 021),
- ENP Eingang des zweiten 161 nicht vom Ausgang des AND3, sondern vom Ausgang QD des ersten 161 abgreifen und
- Eingang des Inverters vor dem unteren Eingang des NAND2s nicht von dem Ausgang QD des ersten 161, sondern dem Ausgang des AND3 abgreifen.
Du benötigst KEINE zusätzlichen Inverter!
Sorry, bin etwas in Eile. Mit der eMail wirds heute nichts mehr. Kommt morgen. Dann habe ich hoffentllich auch mehr Zeit.
Gruß Martin

Dieser Beitrag wurde am 31.12.2019 um 18:18 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

049
01.01.2020, 11:49 Uhr
holm

Avatar von holm

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

050
01.01.2020, 14:09 Uhr
HofMar

Hallo Holm,
das sieht doch gut aus, oder?
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

051
01.01.2020, 16:10 Uhr
holm

Avatar von holm

Im Prinzip ja..ich arbeite gerade mit Gert an der Erweiterung dieser Schweinerei..ich will den Takt langsamer haben..und symmetrischer.
Melde mich dann..

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

052
01.01.2020, 16:56 Uhr
HofMar

Hallo Holm,
man könnte in die Koppelung Ausgang RCO des zweiten 161 zum Eingang des AND3 ein D-Flipflop packen und mit einem High des RCO dieses toggeln lassen. Um den ersten 161 mit dem Schieberegister 299 anzuhalten würde man das RCO mit dem Ausgang dieses FlipFlops zusätzlich ver-UND-en. Das SCK könnte man nun am FlipFlop abgreifen.

Quellcode:

_-_-_-_-_-_-_-_-_-_ CLK
-______--______--__ RCO
-------________---- FF/SCK
-______________--__ SHIFT

Damit ist aber mind. eine Takthalbierung nötig. Ein unverzögerter Takt klappt dann nicht. Auch sind dann nur gerade Teilungen möglich. Um das hinzubekommen müßte man noch den invertieren Takt hinzuziehen.
Nachtrag:
Anstelle des D-Flipflop ist ein JK-Flipflop besser. Beide J und K-Eingänge bekommen ein AND. Einer der Eingänge dieser ANDs werden zum Q bzw. /Q gekreuzt. Die beiden anderen Eingänge gehen zum RCO. Schon müßte das symmetrische (und hazardsfreie) SCK fertig sein.
Gruß Martin

Dieser Beitrag wurde am 01.01.2020 um 17:37 Uhr von HofMar editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

053
01.01.2020, 20:47 Uhr
holm

Avatar von holm

Guckma:
Das ding macht jetzt so ungefähr das was ich von ihm will.
Ich habe mir gekniffen vom 2. 161 A0 Laden zu wollen, da kommt zwas auch irgendwas raus, aber ich denke Niemand braucht ungeradzahlige Teilerfaktoren unbedingt, demzufolge verwende ich nur die HW 3 Bit. Beim Laden von A0, B=1, C=1 als0 E0 mußte ich den Takt erschwindeln, es wurde keiner mehr erzeugt, demzufolge wird da RCO vom 161 als Takt eingeblendet, der sich bei höheren Teilerfaktoren
mit dem normalen Takt überdeckt und so nicht störend in Erscheinung tritt.

Bei der simu programmiere ich die Teilerfaktoren um, erstes Datenwort mit 05, 2. Datenwort mit 02, VTB,VTC,VTD sind die dazugehörigen Ausgänge zum Test. Die 3 Bit sind negierend. Mit dem 4. Bit schalte ich die Polarität des SCK Signals um. Auch auf den Salve Select Ausgängen SS0 bis SS3 funktioniert was, ich habe hier nur mit 0 und 1 gespielt, freilich kümmert sich die Simu nicht um das Auslesen des Busy Bits das ich auch als "Busy" spaßeshalber auf einen Ausgang gelegt habe.

Eigentlich bin ich ziemlich Baff was so in das doch recht kleine CPLD mit nur 32 Makrozellen rein paßt..
Das sind nur 3 22V10....
Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

054
03.01.2020, 20:06 Uhr
holm

Avatar von holm

..so mal wieder "meld".

Das ist mein momentaner Stand, das Ding macht jetzt soweit Alles was ich von ihm will.
Änderungen sind symmetrischer SCLK, umschaltbar in der Polarität duch Bit im Vorteilerregister
und eine Verzögerung des Herausschiebens nach dem Schreiben der Daten um 2 Takte nach Abschluß des Schreibprozesses vom Rechner. Den Comparator habe ich durch einen Decoder und einen Multiplexer ersetzt, das scheint aber im CPLD etwa den selben Aufwand zu verursachen.
Leider paßt der Kram nun nicht mehr ins EPM3032, ich muß ein EPM3064 verwenden. Es sind jetzt 41 Macrozellen belegt, davon offenbar je zusätzlichem D-FF je Eine.

Wer Ideen hat wie man das weiter zusammenstreichen kann, immer her damit.

Auf dem Bild ist oben der Eingang A0 weggeschnitten (Quartus exportiert das so), also nichts weiter Kriegsentscheidendes. Die Register sind jetzt 4 Bit breit, wobei ich das Ausgaberegister auch wieder 8 breit machen kann, da die 4 VT Ausgänge nur Diagnosezwecken bei der SImulation dienten. Evtl. bekomme ich auch noch einen kleinen Eingabeport mit hinein, mal sehen. Doof ist das der Fitter sich weigert das mit der selben Anschlußbelegung wie ich sie schon als Hardware da habe zu routen, er mein er könne das nicht. :-|, ich werde also den Drahtfitz teilweise neu machen müssen.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 03.01.2020 um 20:11 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

055
03.01.2020, 21:58 Uhr
HofMar

Hallo Holm,
erst einmal herzlichen Glückwunsch zum Erfolg. Ich finde das zwar irgendwie unüberschaubar und auch etwas kompliziert, aber man kann es so machen. Ein richtiges synchrones Design ist es leider nicht geworden. Du koppelst Vorbereitungssignale (hier den negierten Ausgang RCO des zweiten 161) direkt über asynchrone Rücksetzeingänge des Flipflop zum SCK durch. D.h. hier spielen wieder Gatterlaufzeiten eine Rolle, mögliche Hazards könnten entstehen. Auf der Simulation sieht es so aus, als ob das SCK kein Tastverhältnis von 1:1 hat. Da Du den Ladeeingang A des zweiten 161 auf Low gelegt hast, wird IMMER eine gerade Anzahl von "Waitstates" abgearbeitet und damit immer eine ungerade Taktanzahlen für ein Bit. Spannend wäre was beim Schreiben einer 000h ins Waitstate-Register passiert.
Der Vergleicher 85 ist eigentlich nur ein wenig Logik (XOR und AND) und damit werden kaum Ressourcen des CPLD benötigt. Vermutlich hätte ich das sogar mit 3 XOR2 und einem AND3 gelöst, da Du A0 und B0 nicht benötigst.
Da Du beide Register 175 nur mit vier Bits bedienst, hätte man das auch an einer Adresse packen können. Die Taktlänge von SCK ist auch von der Auswahl des SPI Slave (SS) abhängig und würde daher gut passen.
Ich überlege die ganze Zeit noch, ob man nicht auch das SCK über zwei Flipflops mit positivem und negativem Takt generiert. Dann bekommt man auch wirklich ein Tastverhältnis von 1:1 hin.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

056
03.01.2020, 23:49 Uhr
HofMar

Hallo Holm,
mein Post 055 bezog sich noch auf die Schaltung 053. Dein Post 054 habe ich zu spät gesehen.
Mit dem Decoder 138 und Multiplexer 151 bin ich draußen. Das durchblicke ich ohne Simulation nicht mehr. Ich bezweifele auch das für alle "Waitstates" saubere SCK-Signale generiert werden, weil mir das nicht nach "Halbierung" sondern eher nach einfacher Subtraktion aussieht.
Die Verzögerung des Starts für das Schieben (SHIFT) könntest Du auch einfacher ohne die beiden FlipFlops haben. Lade den ersten 161 (Bitzähler) nicht mit 8 (1000) sondern mit 6 (0110) vor. Den ENP-Eingang dieses 161 erzeugst Du nun aus dem SHIFT-Signal ver-ODER-t mit dem QC Ausgang. Also kann dieser Zähler bereits ab 4 freilaufend bis 16 (0) zählen. Das Schieberegister fängt aber wie gehabt erst ab Zählerstand 8 an zu schieben. Den ENP-Eingang des zweiten 161 (Vorteiler) mußt Du dann auch noch ab Zählerstand 4 freigeben. Schon brauchst Du weniger Makrozellen. Aber warum möchtest Du diese Verzögerung? Ist das nicht eher ungünstig, da langsamer?
Mal eine ganz andere Frage. Was gibt den max. SCLK Takt bei den Slaves vor? Ist es der Takt selbst oder evtl. nur die Setup Time der Daten vor der Übernahme? Dann wäre hier ein SCLK-Signal was kein Tastverhältnis 1:1 hätte günstiger.
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

057
04.01.2020, 10:56 Uhr
holm

Avatar von holm

..Du bist ja so gemein. Die Simu hing nicht dran, weil das mittlerweile eine längliche Tapete ist, ich habe mehrere Teilerfaktoren nacheinander ausprobiert und auch das rückgelesene Byte wieder abgeholt.
Ich habe alle Teilerfaktoren zwischen 000 und 111 getestet, funktioniert so.

Zum asynchron gesetzten dff am Ausgang, ja, das stört mich auch noch, evtl. versuche ichs da mit einem getakteten JK FF noch einmal. Ich habe mal nach meinem Vorrat von EPM3064 geschaut, der beschränkt sich auf 2 Stück, genauso wie EPM3032. Ich habe allerdings eine größere Anzahl EPM7064ALC44-12 da,
also Serie MAX7000 ..und die wird wieder von Quartus nicht unterstützt, muß mal sehen ob die nachgerüstet werden kann...
Unterstützt wird MAX7000 allerdings von Altera MAX2Plus..was sich auch noch auf meinem Rechner herumtreibt, freilich sind die Schaltungseditoren nicht kompatibel zwischen den beiden Paketen, auch wenn ich vermute das das konvertierbar ist, ich muß da nochmal suchen. Da die Schaltung mittlerweile ausreichend vergriesgnaddelt ist, habe ich sie mit max2plus gestern nochmal (um-) gezeichnet, logischer aufgebaut, kommt nachher noch. Freundlicherweise kann mein Labtool48 mit Dataman48 Software auch den MAX7000, ich habe da auch noch EPM7160 in PLCC84 und solches Zeuch...
MAX7000 hat eine Besonderheit, Tristate geht da an einem Ausgang nur, wenn ein externe Pin die Tristate Umschaltung macht, hab komisch geguckt als der Compiler sagte ich soll extern 2x 2Pins miteinander verbinden. auf diese Weise wird von der internen Logik mit einem Ausgang ein anderer Ausgang in Tritate gesteuert :-O
Egal, billige und schnelle 5V Bausteine!
MAX3000 und MAX7000S sind aufwärtskompatibel, man kann die 3000er Daten direkt in einen 7000s brennen.

Zum Decoder/Multiplexer:
Wie Du an der Simu sehen kannst funktioniert das, bei jedem Teilerverhältnis. Ich hatte schon irgendwann weiter oben festgestellt das mich ungerade Teielerverhältnisse nicht unbedingt interessieren, das läßt sich auch so fein genug einstellen. Genauso ist die Frage ob das SCK Signal exakt 50% Tastverhältnis hat, eher irrelevant, ich wollte aber eben keine schmalen Nadeln die 6Mhz entsprechen.
Das was nun da rauskommt ist besser als worksforme.

Der 74138 war ursprünglich ein 74154..bis ich gemerkt habe das die unter Hälfte der Ausgänge unbelegt ist. Ist ja auch logisch. Für das aktiv schalten von SCK sind die Zählerstände des 161 unterhalb 8 uninteressant, deswegen fällt der untere Decoderteil weg, das ist also die von Dir vermißte Division durch 2.
Der auf den Zählerstand "F" folgende Takt setzt SCK wieder auf inaktiv. Das ist schon die ganze Zauberei.
Der Multiplexer wird durch den vorgeladenen Teilerfaktor (ok die Negation davon, aber das beeinflußt nur die Reihenfolge der Eingänge) gesteuert. Es gibt für jedesTeilerverhältnis einen aktiven Eingang. Der Decoder zeigt die Zählerstände des 161 an und eine Verbindung eines Ausgang zum aktiven MUX Eingang spezifiziert den Takt an dem SCK eingeschaltet wird. Abgeschaltet wird immer ein Takt nach "F".

Vorteiler 7, Daten A5 statt 46!

Ich habe Tagelang die Software auf meinen Server geladen ..mit dem Ziel das Du selber simulieren kannst!

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 04.01.2020 um 11:13 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

058
04.01.2020, 11:09 Uhr
holm

Avatar von holm

Hier die Schaltung nochmal aus MAXIIPlus:

https://www.tiffe.de/images/SPT.pdf

..ist evtl. verständlicher gemalt.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

059
04.01.2020, 15:30 Uhr
HofMar

Hallo Holm,
nein, ich wollte nicht "gemein" sein. Sorry, wenn das so rüber kam. Mit der "Tapete" sieht das richtig gut aus. Ich denke, jetzt verstehe ich das besser. Du programmierst das "Waitstate"-Register nun wirklich mit den zusätzlichen kompletten Takten, die das SCK verlängert wird. Bei einer 000h ist SCK halb so schnell wie der Mastertakt. Mit 001h, ist es ein Viertel, mit 002 ein Sechste, usw.
Ich meine das hätte meine Lösung aus 052 auch gemacht. Ich dachte Du wolltest bei 000h auch "unverzögert" rausschieben.
Demnach setzt Du den Vorteiler auf (Register*2)-1 und testest mit dem Vergleicher, Decoder Multiplexer wieder auf den Registerwert. Daher kommt also die "Halbierung". Meine Idee unter 052 war, auch die Verdoppelung (Register*2), diese aber durch ein zweimaliges Durchlaufen des Vorteilers mit einem anschließendem Flipflop zu machen.
Kann es sein, daß der Ausgang Y7 vom 138 identisch zum Ausgang RCO des 161 ist? Dann sollte man diese Signale auch zusammenführen.
Ja, simulieren kann ich das aber erst, wenn ich das auch tagelang von Deinem Server heruntergeladen habe. ;-)
Gruß Martin

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

060
04.01.2020, 15:53 Uhr
holm

Avatar von holm

Wenn der Chip mit 6Mhz getaktet ist, läuft die SPI in der schnellsten Stufe mit 3 Mhz SCK, das erscheint mir an und für sich schnell genug. Ich habe an und für sich nicht vor Videodaten vom Z180 aus zu übertragen. Ich denke nicht das man die 6Mhz wirklich hier braucht. Gut, über eine Erweiterung kann man nachdenken.

Ja, Y7 ist das Selbe wie RCO, zwangsläufig denn RCO decodiert auch nur den Zustand "F" vom Zähler.
Einen 74137,8 hatten se aber nicht :-)

Ich bin auf den Erfolg Deiner Installationsversuche gespannt, hab Dir das Projekt indessen gemailt.
Ich wette Du willst dann wissen wie man die Simu auf macht :-)

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

061
06.01.2020, 22:24 Uhr
holm

Avatar von holm

So ich habe meine derzeitige Variante mal an ein gerade vorhandenes LED Display mit Siemens SDA2131 geprömpelt, Mit 6 und 7 Waitstates läuft das gerade noch (und der Siemens ist angeblich ein Bipolar-IC!) ansonsten wird es zu schnall (deckt sich mit den DB Angaben).

Da hier ein 16 Bit Treiber verwendet wird (2 Bits schalten über PNP Transistoren die Anoden der 7-Seg Anzeigen, die erste Stelle ist über ein R-Netzwerk irgendwie so angeschlossen das sie entweder 0 oder gar nichts anzeigen kann (?), die anderen Anzeigen hängen kammartig verzahnt an den beiden Transistoren) und die Belegung ziemlich vergriesgnaddelt ist, zeigt das Ding zwar klingonscihe Zahlen an, aber zuverlässig die selben bei den selben Daten..
Ich habe keinen Bock darauf einen funktionierenden Treiber dafür zuschreiben, dieses bescheuerte Display mit LTS3401 und ohne Dezimalpunkte werde ich wohl nie wieder verwenden... aber die SPI funktioniert wie erwartet. Ich mache mir Gedanken ob ich noch einen Interrupt Ausgang für "Sendepuffer leer" implementieren soll, oder ob die bereits mögliche Abfrage über einen Port ausreicht (Polling).....
Eine Art Kür wäre es noch LSB oder MSB first programmierbar zu gestalten, aber man kann das auch in Software drehen:

// reverse MSB first to LSB first for HCS-12SS59T Display
uint8_t mirror(unsigned char b) {
b = (b & 0xF0) >> 4 | (b & 0x0F) << 4;
b = (b & 0xCC) >> 2 | (b & 0x33) << 2;
b = (b & 0xAA) >> 1 | (b & 0x55) << 1;
return b;
}

Habe ich mal bei einem MSP430 gebraucht, da war das auch nicht in der Hardware der SPI programmierbar.

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

062
06.03.2023, 09:39 Uhr
hschuetz

Hallo,
ist aus diesem Projekt etwas geworden? Der Ansatz war schon interessant.
Michael und ich haben auch eine SPI Schnittstelle für SD Karten am Z80 gebaut,
alles TTL.
https://hschuetz.selfhost.eu/ndr/hardware/neu/mspeicher/sdio/index.html

Viele Grüße
Hans-Werner

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

063
06.03.2023, 17:04 Uhr
Bert

Schöne Lösung!
Es steckt aber auch einen gewissen Aufwand dahinter (ich zähle 14 Schaltkreise).

Wie große ist der Code, um das FAT-Dateisystem auf der SD-Karte anzusprechen?
Und auch wenn es nicht ernsthaft relevant ist:
Welche Datentransferraten erreicht man mit dem Adapter (bei 2, 4 und oder 8 MHz)?

Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

064
06.03.2023, 19:00 Uhr
hschuetz

Hallo Bert,
ja, Ziel war es keine hochintrigierten Bausteine zu benutzen.
Auf der SD Karte ist ein CPM Dateisystem, kein FAT!
Der Bootvorgang ist ssssst... eine Messung haben wir nicht gemacht...Bei mir läuft die Karte in einem 4 Mhz System.. Software hat Michael Haardt dazu geschrieben.
Viele Grüße
Hans-Werner

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]