TPIC6B595 probleem

het lijkt me dat je clock en latch signalen geen vertraging oplopen aangezien, die niet door de schuifregisters heen gaan. De data lijn wel, na een lange reeks treed hier dus verschuiving op.
Je zou deze signalen ook door een buffer kunnen laten lopen of de clock snelheid verlagen, zodat het niet zo tijd critisch wordt.

Ik neem aan dat je de SEROUT van de eerste aan de SERIN van de volgende hebt geknoopt?

Het kan zijn dat je kabel storing geeft, probeer eens te ontkoppelen met een kleine C. Meet ook eens de weerstand en de spanningsval over de kabels (of als je een scope bezit, bekijk eens of je veel ruis op je datalijn hebt).

kun je eenvoudig je clock signaal inverteren?
Dat wil ook nog wel eens een simpele oplossing zijn om clock skew te minimaliseren

Tegen het einde van de lijn ziet het clock-signaal er serieus vervormd uit. Ff gegoogled en gevonden dat wanneer je de clock langs het laatste shift-register laat binnengaan, dit opgelost kan zijn, dit werkte. Wat is hier de verklaring voor?

Iemand nog ideeën om zulke dingen te vermijden? Moet er gebufferd worden, zowel data als clock en strobe ? of de data niet en de andere wel?

Heb nu eens met andere methode geprobeerd, 4094 met uln2803 darlington. Dit werkt wel perfect. Iemand hier een verklaring voor? TPIc is toch ook CMOs technologie?

hoe bedoel je daar het laatste schuifregister heen laat gaan?
Wat ook nog speelt is de fan-in en fan out.
Je kan met 1 logische uitgang slecht een beperkt aantal inputs aansturen zonder het te bufferen.

De clock door de laatste laten gaan dat begrijp ik ook niet erg.
Ik denk dat je last hebt van signaal reflecties op de clock lijn,en dat kan ook haast niet anders als er 20 ingangen op hangen.
Een fatsoenlijke termination zou hier wel eens de oplossing kunnen bieden.

Wat natuurlijk ook kan (en dat verklaart waarom het met een 4094 wel werkt) is dat je GND wordt opgelift door de grote stromen op de uitgangen.Bij een 4094+ULN gaat de stroom van de belasting door een ander pad en vervuilt je logica niet. (ligt aan je layout) maar ik denk dat je het op gaatjesprint hebt gezet,want anders heb je in een dag niet een andere versie werkend.

Ik stuur er leds mee aan, dus het gaat maar over 20mA. Hoe denk je het beste zo'n bus te termineren?
Ook merk ik het volgende, als ik met de scoop op de clock meet loopt alles in het honderd. Heeft dit iets met de capaciteit van de scoop te maken?

Wat ik voorlopig het toegepast:
Met die clock bedoel ik het volgende. Ik heb nu een serieschakeling van allemaal schuifregisters. Ik dacht mss een dalay te hebben tegen het einde van de lijn (klok wordt afgetakt door elk shift register van deze lijn). Als ik nu de clock aansluit aan het einde van die lijn zou ik aan het begin van de lijn een delay hebben. Maar omdat nu de achterste shift reg eerst inklokt alvorens de eerste krijg ik geen fouten meer. Maar ik vind het raar dat het niet op de normale manier wekt, het gaat hier ocharme over 40 cm flatcable tussen elke print (5 printen met 4 shift regs).

Net nog een oplossing gevonden. Serieweerstand tussen µController en eerste shift register van 47ohm.

Op 18 juni 2010 16:41:53 schreef MC6800:
De clock door de laatste laten gaan dat begrijp ik ook niet erg.

Een probleem bij dit soort schakeling is dat als de clock eerder bij het eerste SR aankomt daar al nieuwe data wordt ingeklokt voordat het ouder laatste bit wordt doorgeklokt. Als de eerste klok iets later aankomt heb je dit probleem niet, vandaar 'achteraan beginnen' met de klok.

Een ander probleem is ringing. Die 47 ohm weerstand doet daar wat aan, een andere oplossing is terminatie van de lijn aan het einde.

Fan-out zal niet snel een probleem zijn bij 20 CMOS inputs.

wat heeft het voor zin de clock voor of achteraan aan te sluiten?
die staat toch juist parallel aan alle clock ingangen? En de clock is dan toch juist niet vertraagd?
Hoe moet je de lijn goed termineren? Ik gebruik hetzelfde princippe en dat gaat eigenlijk zonder problemen, maar had met de scope toch wel redelijk wat ruis op de clock lijnen gezien.

Op 21 juni 2010 14:01:00 schreef Stijnos:
En de clock is dan toch juist niet vertraagd?

Als de klok niet vertraagd is heb je daar geen probleem mee. In de praktijk kan dit juist wel een probleem opleveren.

De lading die je in de lijn injecteert (het is meer 'aanbieden') verplaatst zich door diffusie. Doordat elke aangekoppelde ingang wat afsnoept van die lading zakt het golffront wat in, of wordt uitgerokken. De ladingsgradient wordt kleiner waardoor het golffront zich trager gaat voortplanten. De golf wordt naar het einde toe dus trager en de kloklijn vraagt minder stroom.

Bij de shiftregisters op het einde gaat het dan als volgt en alleen daar krijg je dan ook het probleem:
De voorgaande Q7' bezit al de data van Q6 voordat Q1 van het volgende register de oude data van Q7' heeft kunnen opnemen omdat zijn klok veel later werd getriggerd.

Injecteer je nu die lading vanaf het laatste shiftregister, dan heb je hetzelfde effect in de kloklijn maar nu worden de voorgaande registers later getriggerd, wat geen kwaad kan.