SPI storing reductie

Op de flatcables zou ik zorgen voor aard-ledingen tussen alle SPI signalen. Dus GND CLK GND MOSI GND MISO GND. De CS lijnen zijn minder belangrijk. Eventueel kan je op het end van CLK en MOSI een termination maken naar VCC/2 met een impedantie van ongeveer de draadimpedantie. (ik schat rond de 100 ohm). De MISO moet je termineren bij de master.

Maar goed, als je met 100 ohm naar 2.5V zit te termineren, gaat er 25ma lopen als je op 5V of 0V zit. Dat is voor de gemiddelde driver weer te veel van het goede.

Ik denk dat het met de extra GNDs wel goed gaat. (na het activeren van een CS even wachten voordat je gaat sturen. Mogelijk is er overspraak en denken de buur-chips dat ze ook geactiveerd worden...)

Op 7 mei 2009 12:38:31 schreef rew:
Op de flatcables zou ik zorgen voor aard-ledingen tussen alle SPI signalen. Dus GND CLK GND MOSI GND MISO GND. De CS lijnen zijn minder belangrijk. Eventueel kan je op het end van CLK en MOSI een termination maken naar VCC/2 met een impedantie van ongeveer de draadimpedantie. (ik schat rond de 100 ohm). De MISO moet je termineren bij de master.

Maar goed, als je met 100 ohm naar 2.5V zit te termineren, gaat er 25ma lopen als je op 5V of 0V zit. Dat is voor de gemiddelde driver weer te veel van het goede.

Uit specs van de flatcable blijkt de impedance 70 ohm te zijn. Ik denk dat de interne weerstand van de microcontroller te verwaarlozen zal zijn (toch)?
De microcontroller is 3v3 max 25mA. Aan eind van elke SPI driver kan ik dan max. een weerstand naar de gnd plaatsen van 150ohm. Ik match dan niet met de kabelimpedantie, ga ik hier problemen mee ondervinden?

Hoe zit het met serie terminatie? Is dat goed toepasbaar?

Wat betreft crosstalk met de CS lijnen, hier plaats ik op elke I/O PCB een weerstand op de cs naar Gnd (ook 150 ohm)

Afsluiting is niet nodig. De golflengte van 200Khz is iets van 300 meter. De vuistregel zegt dat je bij 1/10 golflengte=30 meter pas afsluitweerstanden nodig hebt.
Wat je wel kunt doen is RC filters bij de drivers en de ontvangers plaatsen, dan filter je storingen uit. Echter, SPI blijft tricky en ik zou je aanraden om geen SPI te gebruiken voor communicatie tussen verschillende printen met kabels ertussen. 1 stoorpuls op de klok is voldoende om je besturing in de war te schoppen!

Ik zou op ieder bord een controller zetten en dan een UART gebruiken voor de communicatie. Een UART heeft van zichzelf al filtering van ongewenste signalen. Tevens kun je de pakketten voorzien van een checksum of CRC.

Op 7 mei 2009 22:17:51 schreef Nico.c:
Ik zou op ieder bord een controller zetten en dan een UART gebruiken voor de communicatie. Een UART heeft van zichzelf al filtering van ongewenste signalen. Tevens kun je de pakketten voorzien van een checksum of CRC.

Heb hier lang over getwijfeld. Ik wist niet dat UART betrouwbaarder is dan SPI? Heb voor SPI gekozen ipv UART omdat voor SPI er goedkope I/O Expander IC's te krijgen zijn (16 I/O's voor 1 euro). Bovendien kan ik met UART niet zonder een RS232 omzetter meerdere units aan de lijn hangen.

Wat ik moet schakelen zijn leds, relays en het uitlezen van knoppen. De goedkoopste PIC18, waar we een compiler voor hebben, kost 1.50. Dan moet er ook nog code voor geschreven gaan worden wat al gauw een protocol moet gaan omvatten.

De PCB's moeten los omdat elk apparaat een andere plaatsing heeft en hoeveelheid. Parallel aansturen van de PCB's zou ook mogelijk zijn geweest (evnt. multiplex) maar dan is men gebonden aan een maximale PCB. Bovendien is de ruimte van de PCB's zeer beperkt. Bij multiplex komt er minimaal 3 IC's bij (darlington array, store latches en de multiplexer zelf.)

Welke andere voordeligere (liefst eenvoudige) seriele aanstuur mogelijkheid heb ik nog meer die een hogere betrouwbaarheid dan SPI heeft?

I2C misschien?
Heb je in iedergeval geen last van Chip Selects.
(Als je toch *maar* 200khz gaat gebruiken) Enige grote nadeel wat ik kan zien is dat hij niet, hoe heet dat ook alweer? dat zowel slave als master tegelijkertijd kunnen sturen?

Een ander voordeel (of nadeel) van I2C is dat je het bijna eindeloos kan uitbreiden, echter, zit je wel dat je dat dan software matig moet oplossen (andere adressen).

Met SPI zit je ook nog met het probleem dat er een maximaal aantal devices kunnen zijn. (Ik zeg dit na aanleiding van je multiplex opmerking). Aangezien eens je de flatcable + aansluiting hebt, wordt het een stuk lastiger om extra CS-lijnen te *trekken*.

I2C lijkt me geen communicatie-systeem dat je in een omgeving met veel storing moet gaan gebruiken.

Zelf zou ik ook voor SPI gaan. 50cm bandkabel is niet overdreven lang, maar neem wel de nodige voorzorgen tegen reflecties. Ook al bedraagt de klok maar 200kHz, de flanksteilheid van de uitgangen wordt er niet minder door!
Het zal wel niet zo erg zijn zoals hier, maar een serieweerstandje aan de bron en een Thevenin-afsluiting aan het eind zou ik toch sterk aanbevelen.

Ik weet niet hoe vast je zit aan de hardware, maar mischien is rs485 ook een optie.

[Bericht gewijzigd door Gatze op vrijdag 8 mei 2009 09:11:26 (46%)]

Op 8 mei 2009 00:35:30 schreef willyp:
[...]

Heb hier lang over getwijfeld. Ik wist niet dat UART betrouwbaarder is dan SPI? Heb voor SPI gekozen ipv UART omdat voor SPI er goedkope I/O Expander IC's te krijgen zijn (16 I/O's voor 1 euro). Bovendien kan ik met UART niet zonder een RS232 omzetter meerdere units aan de lijn hangen.

Waarom RS232? Met de TTL signalen van de UART kun je ook van en naar de andere borden. Een UART sampled ieder bit 16 keer; indien de timing niet klopt wordt de ontvangst afgebroken. Eventueel kun je als je een controller gebruikt de seriele bus doorlussen. Kleine MSP430 controllers zijn ook tekoop voor +/- 1,80 en dan kun je met mspgcc (GCC voor MSP430) dezelfde source voor het protocol gebruiken die je op de PIC32 gebruikt. Dan maak je eigenlijk je eigen I/O expander. Ik denk dat het qua prijs niet eens zoveel zal schelen omdat je met kleinere connectoren uit de voeten kunt.

Het protocol kan heel simpel zijn. Conrad heeft relaiskaarten die je serieel kunt besturen. Daar zit een heel simpel protocol bij; daar zou je eens naar kunnen kijken.

Nico, dat over 16 x sampelen is niet zo.

Hij sampled op 16x de bitrate. Vervoglens, na de eerste sample, die het startbit kan zijn, sampled hij 7, 8 en 9 clocks na die eerste. Daar gaat een majority vote over heen. Voor het volgende bit gaat hij weer 3x samplen, 16 clocks na de eerste drie. Dat is dan het eerste databit.

TS, Je moet het, omdat je zo over de kosten inzit, dus commercieel in behoorlijke aantallen gaan maken straks?

Gewoon SPI, ontwerp in je snelle draden gewoon een serie-weerstand (die overbrugt kan worden/is), een condensator naar aarde, en op het end een weerstand naar VCC/2. Dat hoef je waarschijnlijk allemaal niet te bestukken.

Als je het niet vertrouwd, neem je twee breadbords, legt daar een flactcable tussen, en ga je dingen versturen. Wel even een microcontroller aan het end zetten die een lampje kan laten branden als het fout gaat. Leg ze dan zonder de metalen doos tussen de motoren, en kijk of het fout gaat....

[Bericht gewijzigd door rew op vrijdag 8 mei 2009 09:25:16 (49%)]

Op 8 mei 2009 09:13:41 schreef Nico.c:
[...]
Waarom RS232? Met de TTL signalen van de UART kun je ook van en naar de andere borden. .

Hmm, gaan de Tx drivers niet stuk van de "slaves" die verbonden zijn op de zelfde lijn? Of is dat niet wat je bedoelt?

Want de master die met alle slaves communiceert, zit de Tx op de Rx en vice versa. Maar omdat je meerdere slaves hebt zul je die moeten koppelen aan dezelfde Tx-Tx-Tx-Tx-Tx bij 5 slaves ofwel PCB's (en Rx ook * 5, maar dat maakt iig niet uit)

@Rew

Ik ben in twijfel nu, wat Nico zegt om een controller te gebruiken kan geen kwaad. Zeker niet als ik de prijzen zie. Bovendien kan ik dan alsnog SPI gebruiken maar dan met een CRC'tje erbij. Minimaliseer ik problemen tegen een lagere meerprijs.

[Bericht gewijzigd door willyp op vrijdag 8 mei 2009 09:39:07 (19%)]

I2C kan ook goed werken als je de P82B715 driver gebruikt. Die heeft veel sterkere sink drivers.
(30mA t.o.v. 3mA bij standaard I2C)
Het resultaat met SPI kan nogal wisselend zijn, omdat er niet echt 'harde' specs zijn omtrent de kabel en de drivers.
Kan dus van device tot device varieren...

Gezien de prijs van deze i2c drivers (4.50) is het niet interessant om te gebruiken. RS485 is dan (veel) voordeliger.

Een attiny2313 is rete goedkoop. Die kan je programmeren om vanalles met CRCs te doen. Als je niet structureel fouten hebt, dan is dat natuurlijk ook goed te doen.....

Ik zou in zulke omstandigheden kiezen voor RS-485. Nadeel is wel dat er dan op de i/o boards ook een cpu moet komen om het protocol te ontcijferen.
Wij hadden hier 8 vriezers staan waarbij de temperatuur sensors via SPI werden uitgelezen over een afstand van 4m.
Je ziet het al aan mij woord keuze "hadden", want het gaf toch regelmatig problemen, bestaande voornamelijk uit verminkte data. Nadeel van SPI en I2C is dat er geen checksum etc. opzit. Je weet dus nooit zeker of het is aangekomen en of het goed is aangekomen.

@REW
Als ik kijk bij farnell zie ik prijzen van 2 euro staan per chip. Relatief met de PIC18 is deze duurder.

@2N3055

Gezien de ervaringsreacties en ik me niet kan veroorloven dat er verkeerde apparaten aangestuurd worden zal ik geen gebruik gaan maken van SPI zonder foutcontrole.

Er is in het huidige systeem reeds een Modbus implementatie aanwezig "ik ben daarom aan het overwegen om, RS-485 + goedkope controller + Modbus" te gaan toepassen.
Het enige probleem hiermee is dat de huidige Modbus volledig geïsoleerd is toegepast. Mijn printen zouden dan wellicht ook geïsoleerd moeten worden wat de kostprijs aanzienlijk verhoogt

Dus nu is de afweging "SPI + Controller + Eenvoudige datacommunicatie met foutcontrole", of het bovenstaande.