Designförslag önskas ; val av PIC / internkommunikation

[emwtur]

Funderar på att bygga en liten leksak till bilen ( en gammal 940 )
en bildator - säkert den första som kommit på idén
Nåväl - det avskräcker inte mig ;
En ganska enkel display och fyra knappar som man kan styra en meny med är min grundtanke.
Displayen får troligtvis bli en teckenbaserad 4x20 eller 2x20 processorn - ja en PIC tänkte jag
men ...
vilken skall man välja ?
Tanken är att kunna mäta spänningar med någorlunda noggrannhet , 10 bitars A/D minst.
( vill bla kunna kolla batterispänning under start )
måste kunna prata med en RTC via SPI eller I2C
sedan vill jag kunna prata med ytterligare PIC:ar senare - tänkte lägga till en processor som räknar pulser från hastighetsmätaren och en som summerar öppettiderna på spridarna .

Skall man satsa på CAN mellan processorerna ?
skall man köra med samma gränssnitt till alla processorer och RTC så lutar jag mot SPI.

Någon som vill kommentera ?
/emwtur

[swesysmgr]

Realtidsklockor finns även med helt egna mycket enkla seriella protokoll t.ex. DS1302 så du behöver egentligen inte ens SPI. Displayen är en digital IO port (eller två) beroende på hur du vill koppla.

Bygg en version med en processor enbart och få den att funka först, skriver du i C så blir det enkelt att portera över från en PIC18 utan CAN till en med i ett senare skede.

Hur mycket störningar och spänningsmatningsproblem det är i en bil kan jag inte uttala mig om men garanterat mycket mer än på labbplattan

Tillägg: Skärmen går garanterat på 5V, antagligen realtidsklockan också så välj en 5V pic så slipper du nivåomvandling från 3,3V. Har du PICKIT2 eller 3? Det kan begränsa urvalet av modeller lite.

[blueint]

Kika på denna:
EF: Bildator (temperatur- och RPM-mätning och visning)

Förslag är annars att söka efter: Bil dator, bildator, mäta, visa, mikrokontroller, lcd, tft, osv.

Själv hadde jag valt Atmel AVR iofs

I bilens 12 V system får du räkna med pulser på minst 30 V liksom att spänningen försvinner i några sekunder vid start osv. För denna funktion kika på skyddad matning. Själva omvandlingen till t.ex 5 V eller 3,3 V kan göras med linjär regulator eller enkla switchkretsar.

Kommunikation inom samma enhet bör kunna ske med elektriskt gränssnitt såsom single ended. Kanske även mellan enheter, men bilmiljön är sannolikt rätt "j-vlig" så differentiell signalering bör du nog överväga. Det går att åstadkomma med en enkel RS-485 transceiver för ~15 SEK.

CAN ger garanterad respons osv. Men ökar kostnad och komplexitet i varje nod (200 SEK/nod). Annars är differentiell multidrop (RS-485) med UART signaleringsprotokoll en rimlig avvägning mellan kostnad/funktion.

Realtidsklocka (RTC), skärm (LCD), analogomvandlare (A/D), osv kan du räkna med har någon form av single-ended seriellt bit-bang protokoll.

[Icecap]

Med erfarenheten från min gamla bildator:
Varför strula till det med en massa processorer? Välj rätt teknik och processor och en enda kan klara allt! Att blanda in fler processorer ger mer trubbel än det ger mervärde men är det ett måste är differentiell signalering det enda rätta.

Jag tror att du helt enkelt inte vet vad du vill bygga men bara att det ska vara "häftigt" och ha "coola bussar" osv. Det kan ha sin rätt också men du kunde likaväl vara en användbar grej du bygger...

[emwtur]

att jag vill har flera processorer är väl mest för att dels kunna utveckla inkrementellt.
dels att PIC (tycker jag ) är ganska struliga att kombinera ihop ingångar,utgångar och interface så att det funkar i slutändan. - många stödjer tex I2C och SPI . men nästan alla dom använder samma pinnar till båda gränssnitten.
Dvs jag vill ha en processor som sköter huvuddelen av beräkningar , menyer , lagring etc
senare komplettera med enkla delsystem som hanterar olika storheter ( tid , läge, bränsle, etc )
Helst skulle jag vilja ha en RTC som bara har ett trettiotvåbitars tal med antalet sekunder och själv räkna ut vad klockan är

[Icecap]

Sådana RTC finns!

DS1371, DS1372, DS1374, DS1672 som exempel.

[sodjan]

Notera att flera PIC modeller har RTC inbyggd.
Dock inte någon PIC16 så vitt jag kan se...

[emwtur]

Sådana RTC finns!

DS1371, DS1372, DS1374, DS1672 som exempel.

Men ingen SPI

Då måste jag använda I2C mellan mina egna processorer ( eller annat interface - typ CAN )

[emwtur]

Notera att flera PIC modeller har RTC inbyggd.
Dock inte någon PIC16 så vitt jag kan se...

Just nu ligger väl PIC18F4550 eller -4553 bäst till på min lista -
- eller PIC18F45K80 om jag vill gardera med CAN i framtiden.

[blueint]

Låt en mikrokontroller prata I2C med realtidskretsen isåfall. Så kan mikrokontrollern prata asynkon UART med din "huvud" kontroller i sin tur?

[sodjan]

Du nämnde CAN tidigare. Kanske inte helt nödvändigt, men ett väldigt
intressant område om du vill se det hela mer som ett utbildningsprojekt.

CAN har flera väldigt "snygga" egenskaper, t.ex är det helt utan adresser
till de olika enheterna/noderna. Man jobber med meddelande-ID och
varje node väljer själv vilka meddelanden som man ska lyssna på (eller
skicka ut). En node kan t.ex regelbundet skicka meddelande "ute-temp"
på CAN-nätet och de noder som är intresserade av just "ute-temp" lägger
upp det meddelandets ID i sitt "filter". Övriga noder skiter helt i det...

[emwtur]

jooo - CAN låter trevligt.
skall enligt vad jag läst mig till dessutom vara störtåligt.

Nu kommer väl "huvudprocessorn" att sitta i instrumentpanelen och dom andra processorerna max så långt bort som passagerarsidans fotpanel.

Jag bara retar mig så på att ;
hittar man en perfekt processor så visar det alltid sig vara något som strular.
RTC finns hur många som helst med I2C men - då låser man bort dom pinnarna så man kan inte använda SPI - och jag känner mig lite nervös för att använda I2C mellan mina processorer - SPI känns lättare.

Jaja - jag skall bara bli klar med min intervalltorkare sen skall jag ta tag i bildatorn
- extra instrument är redan inropat på tradera

[swesysmgr]

CAN ger garanterad respons osv. Men ökar kostnad och komplexitet i varje nod (200 SEK/nod). Annars är differentiell multidrop (RS-485) med UART signaleringsprotokoll en rimlig avvägning mellan kostnad/funktion.

200:- för AVR kanske, du får en PIC18 med CAN för 40:- + moms på Elfa och en transciever till den för 12:- + moms.

CAN är ganska enkelt att få att fungera, det är väldokumenterat och controllern gör det mesta av jobbet. Att sitta och göra egna protokoll tar mycket mer tid om man inte kan det sedan tidigare.

[swesysmgr]

hittar man en perfekt processor så visar det alltid sig vara något som strular.
RTC finns hur många som helst med I2C men - då låser man bort dom pinnarna så man kan inte använda SPI - och jag känner mig lite nervös för att använda I2C mellan mina processorer - SPI känns lättare.

Då får du antingen strunta i CAN och välja en PIC18 med två MSSP-moduler så kan du köra SPI och I2C samtidigt eller så väljer du att ha två mikrocontrollers med CAN och alla SPI enheter på den ena och alla I2C på den andra. Sen får data skickas mellan dem via CAN. Det fungerar bra men det blir mycket mer kod att felsöka.

SPI till något som sitter 1m bort är jag tveksam till, använd CAN eller I2C eller något annat mer lämpat för längre avstånd.

Välj en modell så bra som möjligt och bygg en prototyp så ser du vad din hårdvara faktiskt kommer att behöva kunna göra.

[blueint]

I²C är nog rätt känsligt på längre sträckor precis som SPI osv. Dvs single ended, och I²C behöver dessutom två datalinjer.