SPI/I2C

[Trex]

Finns det några hinder att ha en master som kommunicerar med slavar både genom SPI och I2C?

Masten får givetvis sätta upp hårdvaran rätt innan den frågar/ger kommando till slaven beroende på om det är SPI eller I2C som slaven är inkopplad på.

[Swech]

Mer info behövs....
Vad menar du?
Skall du ha flera slavar anslutna samtidigt där vissa kör SPI och några I2C med samma linor?

Rent spontant skall det inte vara något problem att köra olika saker.
Utveckla frågan...

Swech

[Trex]

Tänkte använda en 16F887, SPI och I2C ligger på olika ben, så elektriskt borde det inte vara några problem.
Frågan är innan man grottar ner sig i datablad etc. att detta är möjligt så man inte lägger ner massa arbeten och åker på ett bakslag.

SPI slavarna körs på sin lina, I2C på sin är det tänkt.

[AndLi]

Ja du kan använda SPI och I2C ganska samtidigt. Gör du det interruptstyrt å borde man kunna få något som upplevs som att det görs samtidigt.

[Trex]

Verkar som det skulle kunna funka då, har ingen tidskritisk applikation utan masten skall t.ex. hämta temperatur/varvtal etc. från I2C linan sen skicka detta vidare ut på SPI linan.

Dags att grotta ner sig då!

Tackar för svaren.

[Thallion]

Tänkte använda en 16F887, SPI och I2C ligger på olika ben

Det stämmer ju inte - SDI och SDA delar på RC4. Men om du inte skall använda dig av SDI utan bara SDO så borde du kunna krångla dig runt det hela.

[Trex]

Det har du rätt i, ser också nu att RC3 är gemensam (clock) tittade snabb och misstolkade tabellen.
Får fundera vidare blir kanske att ha två PIC som pratar med TX/RX för utbyte data. Hade hoppas att slippa detta, möjligt att man kanske kan hitta komponenter som har SPI och inte I2C får leta vidare.

[Swech]

Skall du inte köra riktigt fort kan du skriva mjukvaruversioner av protokollen...
Varken SPI eller I2C är direkt svåra att fixa till utan hårdvarustöd

Swech

[vfr]

Inte mastersidan iallafall. Slavsidan är lite krångligare. På I2C måste man då ta hänsyn till att låsa klockpulsen för att kunna töja bittiden till lämplig längd och på SPI så måste man ha koll på maximal bithastighet från masterns sida.

Men är det master så är det inga som helst problem att köra rakt av i mjukvara.

[TomasL]

Jamen använd en PIC med dubbla HW istället, då slipper du problemen

[Trex]

Ja att programmera egna kommunikationsrutiner är ju inte det lättaste att få till, det bäste vore ju att kunna ha en PIC för både SPI och I2C.
Skall leta vidare på andra modeller som har denna lösning plus att man som privatperson får tag i en också!

[sodjan]

En del senare PICs har programmerabara I/O pinnar för sina olika enheter.
Även flera senare PIC18, t.ex PIC18F24J11 : http://www.microchip.com/wwwproducts/De ... e=en533683
28 pinnar med Peripheral Pin Select (PPS) och dubbla MSSP för samtidig I2C och SPI på *valbara* pinnar.
48 Mhz på internklockan (1%). Och även in PDIP för oss som vill ha enkel labbmiljö...

Väldigt flexibelt, man kan dribbla runt med I/O pinnarna även vid run-time, t.ex ha en gemensam
RS232 ingång som switchas mellan de två tillgängliga (även i 28 pin kapseln) USART'arna.
Eller låta 1 USART ta hand om 2 olika RS232 linjer utan extern logik. Eller vad man vill göra.

Och när det gäller I2C och SPI så kan man lägga signalerna på valfri I/O pinne...

Den enda nackdelen är kanske att dessa är max 3.6V (alltså i praktiken 3.3V) devices,
men det är ju mycket elektronik som är det i dag. Men för övrigt så är de "vanliga" PIC18
och programmeras precis om man är van vid.

Gå in på http://www.microchip.com/ParamChartSear ... &pageId=74
och välj "Peripheral Pin Select (PPS) Crossbar" = "Yes".