SPI softwarematig?

Hey,

Ik ben thuis bezig om een domotica systeem aan te leggen, ik ben van plan om dit met CAN te gaan doen.
Maar ik loop tegen een paar problemen.
De microcontrollers die microchip heeft met CAN geimplementeerd, zijn nogal prijzig.
En ik wil het gehele project zo goedkoop mogelijk zijn.
Plus dat die controllers nogal overkill zijn voor de simpele taken die ze vaak moeten doen (bijv. lampen schakelen/dimmen)
Dus heb ik hele simpele PIC12F629 besteld, nu lijkt het mij lastig om CAN software matig in zo'n chip te programmeren.
Dus kom ik bij CAN controllers met SPI interface.
Maar nu heeft die chip dat ook niet aan boord.

Bij deze heb ik dus de vraag of het mogelijk, en zo ja, niet al te moeilijk is om SPI software matig in te programmeren.

Wat ik op wikipedida over SPI heb gelezen lijkt het niet al te moeilijk. 2 shiftregisters die op kloksignalen data uitwisselen.
Maar ik kan ook een boel over het hoofd zien.

Waarom moet het persee matig? Wil je het niet gewoon in 1 keer goed doen? Of maakte je een schrijffout en bedoelde je softwarematig?

Wat noem je duur? De 18F2480 met CAN peripheral kost bij grote aantallen USD 3.72...

zo ingewikkeld is CAN helemaal niet hoor, je kunt het relatief gemakkelijk in software doen, als je een UART hebt. Je hebt wel speciale CAN bus drivers nodig.

I2C en SPI zijn goed te doen, maar beide eigenlijk niet bedoelt om lange afstanden te overbruggen.

Ik moet nog ergens code hebben voor een 4-poorts SPI interface met een gedeelde clocklijn. Dat heb ik ooit geschreven voor een schoolprojectje, waarbij een aantal controllers in een grid met hun buren moesten kunnen communiceren. De clocklijn werd gedeeld door alle controllers, en werd gezamenlijk gegenereerd, door deze dominant laag te maken. Als je wilt, kan ik wel eens in mijn archief gaan spitten.

@Sparky: Ik denk dat TS bedoelt om dan juist op hetzelfde board de can driver met SPI aansturen.

SPI en I²C gaan prima over lange afstanden, maar dan moet je ze gewoon differentieel maken. Daar heb ik inmiddels wel ervaring mee :)

@Arco,

Ik zou die chips best bij microchip kunnen bestellen. Maar dan ben ik ten eerste bijna 4 euro per chip kwijt. Dit zou opzich uiteindelijk best de beste optie kunnen zijn. Maar nu kosten de chips voor ons bijna 7 euro, en dat is nog te prijzig. een 629 kost iets van 80 cent, en die 2 andere chips kosten beide iets van 1,50 euro. Dat is al 4 euro, maar nog wel 3 euro minder dan die 2450.

Maar ik hoef volgens mij alleen een enkelvoudige serieele interface te maken.

Maar ik hoef volgens mij alleen een enkelvoudige serieele interface te maken.

De CAN bus is een differentieele bus, met als kabel UTP of STP.

We zijn van plan om telefoonkabel te gebruiken.
De CAN controller heeft een spi interface.
En die wil ik aansturen met een simpele controller. (12F629)

Op 26 maart 2009 15:35:16 schreef neoel:
We zijn van plan om telefoonkabel te gebruiken.

Stop dan ook maar met CAN te gebruiken. Differentiële signalen transporteer je nu eenmaal over twisted pair.

Vraag is dan tevens of CAN niet wat overkill is tov RS485 of zo.

Als je dan toch voor "groot" gaat is Ethernet geen optie (EN28J60) ?

Groeten, Bram

@bprosman

We hebben wel rond gekeken naar andere protocollen, maar RS485 heeft bijvoorbeeld maar ondersteuning voor 32 adressen.
Daar bovenop is CAN robuuster dan RS485.

Ik vroeg mij af welk voordeel ethernet over CAN heeft, ik heb het niet echt onderzocht, maar mij lijkt ethernet een veel uitgebreider protocol.

En voor een automatiseringssysteem is CAN mijns inziens de perfecte bus. Aangezien het is ontwikkeld voor soortgelijke "intelligentie" in auto's.

"maar RS485 heeft bijvoorbeeld maar ondersteuning voor 32 adressen."

Dan heb je wel heel oude documentatie gebruikt. 128 is tegenwoordig al standaard. Niks mis met CAN vraag was alleen of t geen overkill is.

Ik vroeg mij af welk voordeel ethernet over CAN heeft, ik heb het niet echt onderzocht, maar mij lijkt ethernet een veel uitgebreider protocol.

Klopt maar voor de lager gelegen lagen een stuk makkelijker, dan kun je met standaard bekabeling en apparatuur (routers, hubs, switches) uit de weg om je netwerk te bouwen.

Groeten, Bram

[Bericht gewijzigd door bprosman op (43%)]

Op 26 maart 2009 16:59:19 schreef bprosman:
"maar RS485 heeft bijvoorbeeld maar ondersteuning voor 32 adressen."

Dan heb je wel heel oude documentatie gebruikt. 128 is tegenwoordig al standaard. Niks mis met CAN vraag was alleen of t geen overkill is.

Dat getal 32 slaat niet op adressen, maar op de optelling vn alle 'loads' on de bus. Oudere drivers hebben een load van 1, vandaar het maximum van 32. Er zijn modernere drivers met een veel lagere load.

Wart beterft adressen ben je bij RS485 helemaal vrij: je mag het allemaal zelf bedenken...

Wat SPI betreft: dat is in de meeste gevallen nog eenvoudiger in software te doen dan SPI hardware te gebruiken. Maar SPI hardware gebruiken maakt het vaak wel sneller.

[Bericht gewijzigd door Henry S. op (0%)]

Dat software SPI niet zo snel kan als een hardwarematige oplossing kan ik begrijpen.
Je kan met een picje natuurlijk maar een maximum van 1MHz halen. En ik vraag me af of dat zelfs haalbaar is.

De maximum snelheid van de SPI is niet zo relevant. Je moet de gehele schakeling bezien. Het heeft tenslotte weinig zin om data op 1MHz te verzenden, als je niet genoeg tijd overhebt om die data te verwerken tesamen met de overige 'huishoudtaken' van de MCU...

RS-485 heeft geen maximaal aantal adressen. RS-485 is niet eens een protocol. RS-485 beschrijft alleen maar de elektrische specificaties van een bus.
Heel (echt heel erg) kort samengevat: Differentiële signalen over twisted-pair kabel. Je kan dus ook I2C of SPI of CAN of DMX (DMX gebruikt overigens per definitie RS-485) of een willekeurig ander protocol over RS-485 gooien.

1Mhz clock met een softwarematige SPI zal lastig worden. De AVR serie kan meestal tot een kloksnelheid van 16MHz (volgens de specs, in werkelijkheid nog wel wat sneller), wat betekend dat je 16 cpu cycles hebt per clockcycle van de SPI interface. Aangezien dat 2 flanken zijn, die je ook allebei nodig hebt (data samplen en nieuwe data klaarzetten), en de interrupt latency al 4 clockcycles is (worst case), heb je nog maar 4 clockcycles over om data in of uit te klokken.

Zelfs als je dat zou halen, houdt je controller, zolang je aan het communiceren bent, geen tijd meer over om iets anders te doen.

Ik betwijfel echter of je een datarate van meer dan, zeg, 20kbps nodig hebt.

Voor RS485 is zelfs helemaal niets vastgelegd over adressen, datalengtes, checksums, etc. Het is een definitie van de fysieke communicatielaag, niet meer, en niet minder.

Wouter van Ooijen heeft helemaal gelijk met zijn verhaaltje over de bus load, en als dat een probleem zou zijn, kun je altijd nog repeaters toepassen.

Overigens is CAN bus, als ik me goed herinner, ook gebaseerd op RS485, maar met wat modificaties om een 0 dominant te maken.

Wat wel belangrijk is in dit verhaal, is de keuze tussen een ster of S-bus. Bij CAN bus e.d. (eigenlijk alles wat op RS485 is gebaseerd) moet je bus uit een lange lijn bestaan, waarbij alleen korte aftakkingen zijn toegestaan. Je kunt dus niet de controller ergens in het midden plaatsen, en overal kabels heen trekken, als een ster-netwerk. Wat je wel kunt doen, is kabels gebruiken met 2 (of meer) twisted pairs, zodat je een paar hebt om de bus terug naar het midden te brengen, en vanaf daar naar een andere tak te gaan. De kabels liggen dan wel in een ster netwerk, maar de bus is nog steeds 1 lange lijn met apparaten eraan.