Svenska ElektronikForumet

Jodå, det går alldeles utmärkt. I2C tex kan vara multimaster, så något liknande det skulle man kunna göra.

Det som behövs är collision detect, brukar normalt göras genom att man lyssnar samtidigt som man sänder.
Är det tex två som pratar samtidigt kommer den enas resultat på bussen skilja sig beroende på om 0 eller 1
är dominant och då slutar man sända när man märker att man inte får ut det man vill på bussen.
För den som slutar sända innebär det att man inför en "backoff" tid som får slumpas fram mellan nåt min
och max värde så att ifall det är flera som vill sända samtidigt så minskar man risken för collision på
omsändningen.

Tyvärr verkar få fältbussar fixa detta. CAN tror jag gör det men det blir ju lätt komplex design med den...
Dock finns det tex de som implementerat CAN i ren sw på AVR

Behovet är stort tycker jag om man vill ha ner strömförbrukningen. Vill man tex ha en knapp (eller annat
userinterface input) så är det ju himla dumt om en master måste polla den varje 50 ms eller så.
Pollar man den för långsamt kommer systemet upplevas "trögtryckt" och pollar man för snabbt så ökar
förbrukningen i systemet plus att det slösas med bandbredd.

Xlntboy skrev:Vill du ha riktigt overkill lägg in FlexRay. Du lär komma upp i hastigheter på 10mb/s på kommunikationslinan. Bl a X6 från BMW har den. Jag antar att det blir nog lite programmeringsjobb för att få det funka.

Lite programmeringsjobb? Du skojar inte, det är inte helt trivialt att smälla upp en FR-buss. Mycket mer komplex än CAN. Och riktiga FR-transceivrar har knappt gått att få tag på fram tills nyligen. Det har körts med RS485-transceivrar så länge, men då missar man en hel del av funktionaliteten som FR har att erbjuda (bus guardian, redundanta kanaler osv).

LIN är ganska trevligt, gjort för att kunna implementeras med en UART och billig transceiver. Det finns nått som kallas wakeup frame på LIN, den används för att väcka alla noder då någon har data att sända. Det kan skickas ut av vilken nod som helst. Så istället för att ständigt polla noden med knappen som saxofon nämnde, så kan bussen ligga i sleep och den enskilda noden väcka alla när någon trycker på knappen.

saxofon skrev: För att slippa polla (vill ha så lite trafik som möjligt för att spara ström) så behöver noderna kunna signalera förändringar.
Tex när man tänder en lampa ska det signaleras, en knapp kanske ska tända flera lampor.

Om man ser vad CAN skulle kunna göra i det fallet. CAN-controllers har oftast (alltid?) stöd för ID-filtrering, så istället för som på LIN där alla noder väcks så behöver endast de CAN-noder som släpper igenom framen i filtret vakna.

chille skrev:CAN och liknande är uteslutet då hårdvaran blir för dyr och mjukvaran blir så komplex att det inte längre går att ha en billig MCU för några kronor.

Hur mycket är för dyrt?

/me passar på att promotear CAN och AVR lite när jag ändå är i full gång med att skriva
Antar att en del av er vid detta laget har sett http://elektronikforumet.com/forum/view ... =3&t=20742 och http://projekt.auml.se/
Tycker det är ett ganska bra exempel på hur avancerade saker man kan göra med en liten uC och relativt billig hårdvara. Och just nu i avseendet som hemautomationssystem så jobbas det för fullt på PC-sidan med bland annat googles v8-motor så vi kan skriva enkla javascript som tar hand om intelligensen i systemet.

Tyvärr är EF-tråden ganska ouppdaterad med vad vi lyckats åstadkomma senaste tiden, ingen som riktigt haft tid och energi att basunera ut framstegen.

Priser saxxat från futurlec:
Som du ser så är den 10 gånger så dyr. Om man ska ha 50 noder så blir det ju altså 6500:- istället för 650:- Sen får man ju såklart lite rabatt när man köper 50-pack, en Mega48 kostar bara $1.40. Vad CAN123 kostar vet jag inte då den inte finns i lager.

Jag har suttit och funderat och klurat och var lite sugen på att köra LIN, men det är ju sån liten pris/utrymmesskillnad mot RS485, så det kanske är lika bra att köra på stort.

I en bil får man nog passa på för diverse transienter och välja skärmad med kabel med twist. Enheter som ska mäta t.ex. temperatur kan med fördel elförsörjas direkt från buskabeln så besparar man sig en del EMC besvär för enheter som inte kräver galvanisk koppling till omgivningen.

Mest energi lär man spara genom att nätverkets MCU'er försätts i "sleepmode" med interrupt-on-port-change aktiverad. Och sedan minska nonsenstrafiken genom att den MCUn som behöver skickar ut datapaket då händelsen inträffar. Om nätverket är upptaget märks det genom att linjen förblir "0" trots att den är släppt. Och isåf väntar man en slumpvald tid, och försöker senare. Implementering kan ske både med open-collector eller eia-485.

Alla enheter kommer förstås att väckas när det sker något, men om man slipper pollningsmetoden så sparar man in det ändå.

Ang pollning, tänk om du var tvungen att lufta luren 5'e minut för att kolla om någon ringer.. hallå? bonjour? hallo? hola?


Verkar vara fler som tänkt på nätverk av riktigt billiga noder som man kan få om kollar low-end Freescale och PICF84, PIC10Fx som man kan få för runt 7-8 kr/st inkl moms. Det blir en del noder.. Borde duga för att slå på och av reläer o.dyl.

chille skrev:Priser saxxat från futurlec:

Kod: Markera allt

ATMega48 32-Pin 20MHz 4kb 8-bit SMD Microcontroller (RoHS Compliant)   $1.60 (Cirka 13kr)
AT90CAN128 64-Pin 16MHz 128k 8-bit Micro. with CAN Controller         $15.90 (Cirka 130kr)

Som du ser så är den 10 gånger så dyr. Om man ska ha 50 noder så blir det ju altså 6500:- istället för 650:- Sen får man ju såklart lite rabatt när man köper 50-pack, en Mega48 kostar bara $1.40. Vad CAN123 kostar vet jag inte då den inte finns i lager.

Jag har suttit och funderat och klurat och var lite sugen på att köra LIN, men det är ju sån liten pris/utrymmesskillnad mot RS485, så det kanske är lika bra att köra på stort.

http://projekt.auml.se/ kör dock inte AT90CAN128, utan ATmega168+mcp2515. Korten har då switchad nätdel också. (Se alla detaljer kring vår "mcu-nod" på Corecard ). Dessa enheter beställs monterade, och det antar jag är en förutsättning för dig om du ska ha 50 noder? Vi har också PCBer om du vill komma undan billigare genom att montera själv.
Vill du inte köpa kort av projektet finns alla underlag för att beställa själv (dvs vi kör allt öppet, kod pc/embedded, hårdvara schema/layout/bom).
Vi kommer ner i runt 130kr/st för monterade kort. Och då är det bara tuta och köra, koppla upp enheterna och skriva din kod, skriva make; make install så har du dessutom flashat enheten med ditt program över can.
PCBerna kan du få för 15-20kr/st.

Du skulle komma ner i bra mycket mindre jobb med en "färdig" hårdvara, och drivrutiner, och bootloader osv. Jag tror dessutom att det blir billigare, men ibland är det lätt att stirra sig blind på komponentkostnaden.

Något att fundera på är också hur man upptäcker nya noder på nätverket. Eller om man skulle tappa "innehållsförteckningen" hur man får fatt på dom igen.

Vår lösning med nya noder på bussen sköts ungefär såhär:
Vi har ett modulsystem där varje nod kan innehålla ett antal moduler. Tex en för en ansluten DS18S20, en för sitt anslutna relä osv.
Varje nod har ett unikt ID som den skickar ut när den startar upp första gången på en buss, vår PC-mjukvara ser då att det har kommit en ny nod och frågar noden vilka moduler den har i sig.
PC-mjukvaran skickar ett list-kommando och då svarar noden med en lista på modulerna den har. På PCn finns lista i XML-format med vilka olika slags mjukvaror/moduler som är möjliga och vilka noder som finns på bussen med vilka moduler. Den listan uppdateras hela tiden när nya noder kommer online.

Varje modul på bussen kan ses som en egen nod, moduler som är knutna till specifik hårdvara måste givetvis finnas i noderna som de är anslutna till (än så länge iaf, kanske skapar vi nått ännu mera abstrakt hardware abstraction layer senare). Men vi kan också ha moduler som innehåller logik/intelligens, dessa kan placeras i vilken nod som helst som har plats för det. Tex kan man välja att lägga en modul som använder inkommande IR-paket (från fjärrkontroll) och mappar om det till paket som styr relän anslutna till olika noder i en nod med endast temperatursensorer i sig. Lite rörigt förklarat kanske, men kontentan är att vi kan skapa moduler och placera var vi vill på bussens noder.

Hur hanteras fallet om den initiala "hallå jag är här" störs ut av t.ex brus? (eller elak hårdvarutestare )

Eller om PCn tappar sin (XML) lista över tillgängliga noder?

Ser man CAN-noderna som en del i ett nätverk där de kan agera router för sina moduler (1-wire/i2c?). Så borde man kunna lägga upp det som ett träddiagram. Så att man undgår så många specialfall som möjligt.


Där t.ex. enhet nr 13 nås genom 2 -> 8 -> 9 -> 12 -> 13

> Hur hanteras fallet om den initiala "hallå jag är här" störs ut av t.ex brus?

Det sköts genom att CAN självt är CSMA/CD. Varje nod ser ju till att det den vill skicka kommer ut på bussen utan att någon annan stör ut paketen.
Det som inte går att hindra är ju ett totalt avbrott på bussen. Se också svaret på nästa fråga.

> Eller om PCn tappar sin (XML) lista över tillgängliga noder?

Noderna skickar också ut heartbeats var tionde sekund, finns det då en nod som inte är identifierad i listan så görs den initiala processen om listning av moduler på nytt.
Genom dessa heartbeats kan vi även se ifall någon nod försvinner då dess heartbeats inte har skickats under en viss tid.
Eller menar du om jag tex skulle glömma av vad "0x123" är för slags modul? De definitionerna är globala för projektet så det ska alltid finnas någonstans att plocka hem dem ifrån.

> Ser man CAN-noderna som en del i ett nätverk där de kan agera router för sina moduler (1-wire/i2c?). Så borde man kunna lägga upp det som ett träddiagram.

Nu vet jag inte om det blivit något missförstånd här kanske (oklarhet från min sida antagligen). En modul kan vi säga motsvarar en task som körs i en nod. Om en modul styr ett relä, pratar I2C med DS18S20 eller bara är lite logik som tar inkommande paket och skickar ut något annat beroende på innehåll spelar ingen roll. De hanteras på samma sätt.
Sedan om man nu ska dra ethernet-paralleller så routar vi egentligen inget utan hubbar det En modul vet inte var målet för paketet finns, om det ens finns något. När en modul skickar ett paket, dels ekas det tillbaka till alla andra moduler i noden och dels skickas det ut på CAN-bussen. Inkommande paket från CAN skickas in till alla moduler/taskar. De i sin tur filtrerar fram vad som är intressant.
Nu ska jag inte svära på att det är exakt såhär det fungerar, men av det jag lärt mig av vårat modulsystem så är det såhär det fungerar på ett ungefär. Jag själv har varit ganska inaktiv i projektet det senaste men försöker hänga med i framstegen så gått det går.
Din fina bild fungerar inte riktigt att jämföra med vårt system. Nog har vi en PC (eller annan nod med intelligensen) som man skulle kunna kalla master i vissa avseenden, tex att det är via den som vi sköter omprogrammeringar, mesta intelligensen osv. Men ur ett elektriskt och protokollmässig perspektivt så är alla noder likvärdiga (åter igen CSMA/CD).

> Så att man undgår så många specialfall som möjligt.

Specialfall?

Tänkte om styrdatorn (PC) tappat bort att det finns en temperatur nod i t.ex. källaren. Men det löses med heartbeat i detta fall. Om man är villig att ta nackdelen att väcka alla andra noder.

Speciallfall på det sättet att olika nivåer kräver olika sätt att ta sig fram sett från avsändaren (ung som bangpath) eller att t.ex. noder har en address, och moduler en annan etc.. Men det verkar ha lösts mha "hub" lösningen.

hitttade några opensource protokoll som verkar användbara:

http://www.bdmicro.com/code/robin
http://ulan.sourceforge.net

blueint skrev:Tänkte om styrdatorn (PC) tappat bort att det finns en temperatur nod i t.ex. källaren. Men det löses med heartbeat i detta fall. Om man är villig att ta nackdelen att väcka alla andra noder.

Normalt sett väcker man inte upp alla noderna med heartbeatet utan filtreringen sker i CAN-kretsen eller i det fallet man har uc med inbyggd CAN så är det endast CAN kretsen/CAN delen i uc som är vaken och filtrerar. OM datan är av intresse för noden i fråga så skickas interrupt som väcker upp processorn.