Schuifregister.

Ik heb een master module met een CPU en een schuifregister. Daarnaast heb ik slave modules met alleen het schuifregister.

De CPU is 3.3V, de slaves hun schuifregister draait op 5V. Door nu een levelshifter tussen de eerste module en de tweede te zetten, draait de hele bus verder op 5V. Op de eerste module moet het schuifregister zich maar zien te redden met de 3.3V outputs van de CPU. Dat lukt/werkt.

Nu wil ik een keer wat meer modules aan mekaar zetten dan origineel gepland. Met nog wat kabels er tussen ook.

Dan kan ik me voorstellen dat lange kabels roet in het eten gooien. Maar zoals je kan zien: Het clock signaal ziet er nog prima uit.

Het datasignaal lijkt hier een beetje slordig met de overshoot en zo. Dit komt omdat ik even m'n tweede groundclipje niet kan vinden. Als ik de data en clock verwissel, is het datasignaal gewoon strak. (dat moet ook wel. Die wordt "dichtbij" gegenereert: het is de uitgang van het schuifregister.)

Ik heb de truuk met de levelshifter na 5 modules herhaald, maar dat mag niet baten.

Ohja. Als ik de zevende module aansluit, gaat ook de data op de eerste 6 modules corrupt. 80-90% gaat goed, hoor, maar vaak toch foute bits in het schuifregister.

De 5V ziet er gewoon strak uit.

Hmm. Update; Het schuifregister op de laatste module was heet. Maar ik snap niet waar ie dat vandaan kan hebben, want de 15V voeding stond al een kwartier uit. Raar. Morgen verder. In de tussentijd...

Suggesties? Wat ik moet meten?

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Welk type registers ?
De details zijn mij even ontschoten, maar er is een min of meer bekend probleem met tegelijk schuiven en sampelen op de opgaande flank, na een x-aantal registers lopen klok en data niet meer synchroon genoeg om dat zo te doen.

Met bijv. de 74hc595 heb je een propagation delay van ~20nS. Je zou bij iedere chip een extra buffer tussen de clock kunnen zetten om een delay te krijgen.
Bijv. de 74hc34; of je dat met een groot aantal registers betrouwbaar krijgt weet ik niet. Beter dan een expander met wat meer i/o pinnen nemen? (bijv de PCA9506)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
High met Henk

Special Member

denk dat jij voor de 100 punten gaat: pulsje van klok is 100 ns aldus scoop, dus bij 5 registers gaat het mis...

klopt met wat jij zegt wel ongeveer.

to all newbies: RTFM/D of google eens (p.s. RTFM/D = Read the f*cking manual/datasheet).
fred101

Golden Member

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch

Waarom is de pulsbreedte van je clock geen 50%? Volgens mij heb je geen extra vertraging nodig, zolang je de clock niet te hard loopt en 50% is, aangezien het klaarzetten en samplen van de uitgang en ingang op tegengestelde clockflanken gebeurd.

Maar begrijp ik nou goed dat de data op de eerste modules verminkt raakt zodra je de laatste aansluit?

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
High met Henk

Special Member

dat kan wel: ik heb al eens gemerkt dat als je input niet goed stat op de klokflank, dat het spulletje ineens HEEL VEEL stroom gaat trekken...

waarsch gaat de voeding dus op zijn bek...

to all newbies: RTFM/D of google eens (p.s. RTFM/D = Read the f*cking manual/datasheet).
blackdog

Golden Member

Hi Rew,

Ik zou er toch voor zorgen dat je goed meet (1:10 probe)
Er even vanuit gaan dat de signalen netjes zijn, dan is er nog een volgend probleem dat kan optreden.
Door meerdere delen parallel te zetten, kan de flankstijlheid te laag worden.
Kijk een in de datasheet of er van een minimale flankstijlhied gesproken wordt en controleer dit met je scoop.
Zorg dat je massa's mooi kort zijn, dit i.v.m. groundbounce.

Ik hoop dat dit helpt...

Groet,
Bram

Waarheden zijn "Illusies waarvan men vergeten is dat het illusies zijn"

Stel. De klok loopt 5ns vertraging op na iedere module. Het schuifregister op de module verandert z'n SDO 20ns na de klokflank. De opgegeven hold tijd is nul. Dus dan heb ik toch 15ns marge op de input van de volgende module? En dat blijft zo ook na 100 modules, maar zoveel zijn het er niet.

Door een signaal als de klok door een '245 te jassen, wordt ie weer wat opgefraaid. Dus als dat het probleem is, dan had dat opgelost geweest door na zoveel modules weer een 245 te zetten.

In de software doe ik iets van

c code:

  for (i=0;i<8;i++) {
    write_bit (SDO, v & 1);
    v = v >> 1;
    // delay_us (1);
    set_bit (CLK);
    // delay_us (1);
    clr_bit (CLK);
   }

Die delays hebben er in gestaan, maar zijn er weer uit want het maakt niets uit. Normaliter zet is de v = ... tussen de set_bit en clr_bit. Dan wordt ie iets symmetrischer. Hier heb ik dat kennlijk niet gedaan. Kennelijk kost m'n set_bit en clr_bit ongeveer 5 clocks. (als ik m'n best doe, lukt het vast in 1 clock, dan zou de puls 20ns worden. Maar dat zal wel niet handig zijn om daar moeite in te steken.

De hold tijd is trouwens 2ns. Minimale pulse breedte is 15ns. Gewoon getallen waar je in software niet zomaar aankomt, dus die timing zit wel goed, denk ik.

Het datasheet tekent dat je rond de neergaande flank het beste de data kan veranderen. Tuurlijk: De opgaande flank is actief. Ze tekenen ook twee keer dat SDO op de negatieve klok flank zou veranderen. Dat is niet zo.

[Bericht gewijzigd door rew op 15 november 2017 10:21:40 (68%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

De propagation delay op SDO is 30nS typical. Dus na een aantal chips gaat de clock uit de pas lopen (zonder extra vertraging) met het datasignaal.
Kun je de SPI niet gewoon trager zetten?

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Ik doe het helemaal in software. Maar dus met 0.6 microseconde overhead in de delay_us(1) (dus 1.6us per delay = 3.2 totaal) , met 300kHz werkt het precies op dezelfde manier niet.

SDO is het bitje wat ik 16 clocks eerder naar binnenschoof. Dus als we genereus aannemen dat er 5ns vertraging per module is, dan gaat module 2 dus op t=5ns een clock zien. ZIJN SDO wordt dus op T=35 pas veranderd. En module 3 ziet dan op t=10ns een clock en wil dan stabiele data tot 10+5ns = 15ns. Aangezien de SDO van de vorige module tot T=35 stabiel bleef, houden we 25ns marge.

De 10e module ziet op t=50ns een clock pulsje, verandert op z'n vroegst de SDO output op t=80ns en op t=55ns ziet de 11e module een clock pulsje en wil dus dat tot t=60ns z'n SDI stabiel blijft.

Als ze tegelijk de clock zien is er de gegarandeerde output holdtijd minus de benodigde input hold tijd aan marge. Als er vertraging in de clock optreed gaat dat er van af.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
fred101

Golden Member

Heb je gemeten wat de output van de levelshifter en het eerste schuifregister doet wanneer je de 7de aansluit ?

Als nr 7 heet wordt zou hij kapot kunnen zijn. En dat zou ook wat met de rest kunnen doen als zijn ingang de rest probeert plat te trekken of te voeden.

Timing verschillen kun je met een logic analyser meten. (of met een scoop, wel even de skew tussen de kanalen controleren en dan de correctie in de setup instellen.

Staat de boel parallel ? Want dan moet de eerste 7x meer stroom leveren dan met 1 module (fan out)

[Bericht gewijzigd door fred101 op 15 november 2017 11:38:52 (10%)]

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
Tidak Ada

Golden Member

Dat zou dan te voorkomen zijn door ieder register via een eigen (non-inverting) buffer te klokken....

Rommelige werkplek? In de natuur is wanorde de meest stabiele toestand; de entropie is dan maximaal. Het handhaven van "orde" kost daarom altijd energie. ----------------------> TUBECOLLECTORSASSOCIATION@yahoogroups.com

't moet vandaag af. Plan: andere CPU module pakken, ALLE signalen door de 16-kanaals levelshifter sturen en dan "low fanout" werken.

De CPU stuurt nu 8 SDI via 8 GPIO ports. De clock is verspreid over 3 GPIO pins die ieder naar 2 strengen van een paar display modules gaan. De fanout op de clock is zo ook veel lager.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Dat scoopbeeld klopt toch ook niet? (de opgaande clockflank hoort middenin het SDI signaal te zitten)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Skoop trace klopt niet met je code.
In de code wordt de data gezet en daarna de klok hoog gemaakt, maar op de skoop is de klok al hoog voordat de data verandert.
En dit register klokt op de opgaande flank.

Blijkbaar zit er ergens een delay tussen write_bit() en het veranderen van de poort.

Probleem kan ook zitten in de timing van OE. Als die al komt als het register nog aan het schuiven is dan heb je ook een probleem.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Hoho! de data van de CPU naar de eerste module gaat ALTIJD goed. Wat ik op de scoop heb is het SDO van 1 module wat naar SDI van de volgende gaat.

ALS je een hardware-bitjes-schuif-module zou gebruiken, dan zou je die zo in kunnen stellen dat ie het datasignaal verandert op de neergaande flank van de klok, zodat het schuifregister veilig op de andere flank kan samplen. Mijn CPU met hardware-SPI en DMA, zou ik zomaar op iets van 16MHz kunnen laten draaien, terwijl dat nog met een factor twee valt binnen wat het schuifregister moet kunnen.... Schattig.

Maar ik heb er voor gekozen om botwen GPIO pinnen te gebruiken, dus nu moet ik het in software doen. Dus een simpel clock-hoog-clock-laag kost me nu 100ns, terwijl het dus met de hardware-SPI met een 30ns (60 ns cycle time) had gekund. Tja.

In "figure 8" zie je op het eind dat SDO hoog wordt, en dat hebben ze getekend onder de negatieve clk flank. Draait je clock 20-30MHz, dan is die 30ns delay tussen opgaande clk flank en SDO die verandert eigenlijk wel genoeg om "ongeveer op de neergaande flank" terecht te komen. Maar omdat ik langzaam ben en bijna 1 hele microseconde nodig heb om het volgende bitje uit te rekenen...

De bedoeling van het SDO/SDI signaal is dat je deze dingen aan mekaar kan hangen. Normaliter moet de fabrikant dan zorg dragen dat de vereiste input hold time (met wat marge voor clock skew) kleiner is dan de gegarandeerde output hold time. Ik denk dat TI dat gedaan heeft. Ze tekenen schematisch: Nadat de clock hoog gegaan is, gaat ie tzt weer eens een keer laag. En nadat de clock hoog gegaan is, verandert tzt het SDO signaal voor de volgende clock-wordt-hoog flank. Dat klopt precies. Die 100ns dat 'clk hoog' is op mijn scoopbeeld, ziet er kort uit, maar het is dus zodanig lang dat het lijkt dat de data vroegtijdig verandert! En daarna neem ik dus voor de volgende flank "effe vakantie".

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Hmm je hebt gelijk, Je zou eigenlijk geen last moeten hebben van propagation delay. Alle chips krijgen de klok synchroon. De opgaande flank is de actieve flank. Data-in wordt vastgelegd en data-out wordt doorgeschoven naar de volgende chip. Data-out heeft 30 nS vertraging, dus de volgende chip heeft de klok en dus zijn data dan al binnen voordat de nieuwe data-out aankomt. De nieuwe data-out is dus voor de volgende klok flank.

Er is dus 30 nS speling tussen klok en data na de eerste chip. Hoe je dat vanaf de processor aanstuurt maakt weinig uit zolang de klok maar onder 30 MHz blijft.

Ik begrijp nog steeds dat scoopbeeld niet. Op iedere slave zou de opgaande clockpuls binnen het datasignaal moeten vallen, en dat doet 'ie niet.
(de clockpuls komt te vroeg)

In "figure 8" zie je op het eind dat SDO hoog wordt, en dat hebben ze getekend onder de negatieve clk flank.

Da's gewoon zuiver toevallig. De tijd tussen opgaande clockflank en SDO is TPLH4 (20nS), heeft niets met de neergaande flank te doen.
Het zou mooi zijn als dit soort chips een 'feed-through' zouden hebben voor het clock signaal...
(nu verschuift de clock minimaal 20nS per chip)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 16 november 2017 10:16:23 schreef Arco:
Ik begrijp nog steeds dat scoopbeeld niet. Op iedere slave zou de opgaande clockpuls binnen het datasignaal moeten vallen, en dat doet 'ie niet.
(de clockpuls komt te vroeg)

Ah... Jij kijkt volgens mij scheef: de data hoort bij een andere clockpuls dan je denkt.

We kijken "geel" naar het signaal tussen de SDO van de module "links" en het SDI signaal van de module "rechts".

Op de linker (eerste) clockpuls leest de rechter module een 0 en de linker module verandert z'n output van 0 naar 1.

Op de rechter (tweede clockpuls in beeld) leest de rechter module een "1" en verandert de linker module z'n output weer van 1 naar nul.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/