Kysymys:
Kuinka ohjelmoin 2 CAN-solmua lähettämään jatkuvasti peräkkäin?
Xegara
2013-10-02 17:26:41 UTC
view on stackexchange narkive permalink
Oletan, että minulla on kolme CAN-solmua: A, B ja C. ensimmäiseen solmuun. Haluan tehdä, että solmu B ja C lähettävät jatkuvasti CAN-kehyksen solmuun A peräkkäin (esim. Solmu B -> solmu A, solmu C -> solmu A, solmu B -> solmu A). Voinko vain määrittää alemman SID: n B: lle kuin C ja tehdä vain seuraavan koodinpätkän?

Solmu B 

  samalla (1) sendCANmsg (data, NODE_A, sizeof ( data), RTR_OFF);

Solmu C 

  while (1) sendCANmsg (data, NODE_A, sizeof (data), RTR_OFF);

SendCANmsg: n sisällä tässä on katkelma: 

  TXB0CONbits.TXREQ = 1; // Pyydä viestin lähetystä (TXB0CONbits.TXREQ); // Odota, kunnes viesti lähetetään.

Muuten käytän PIC18F25k80: ta tämän toteuttamiseen. Ajattelin vain, että solmun B lähettämisen jälkeen, kun solmu C on lähettämässä viestiään. Solmu B voittaa taas väylän välimiesmenettelyn, jolloin solmulle C ei tule mitään mahdollisuutta lähetykseen. Joten korjaan, että voin vain ajatella, on lisätä pieni viive, kuten: 

  while (1) {sendCANmsg (data, NODE_A, sizeof (data), RTR_OFF); delay_us (10);}

Vai olenko väärässä? :)

Kaksi vastused:
Scott Winder
2013-10-02 17:53:07 UTC
view on stackexchange narkive permalink

Koska tämä menetelmä tuo väylän lähes 100-prosenttiseen käyttöasteeseen, oletamme, että nämä 3 solmua ovat ainoat väylässä. 10µs viiveesi perusteella oletamme myös, että väylän nopeus on 500 kbps (ts. 5 bittiä viivettä tai 1 bitti vähemmän välimiesmenettelyn jälkeisestä odottamisesta viestien välillä).

Menetelmä toimii riippuu suurelta osin CAN-ohjaimesi toteutustiedoista. Luotettavampi tapa saavuttaa tämä olisi saada solmu B ja C odottamaan lukemaan toistensa viesti ennen lähettämistä (jolloin solmu B lähettää aluksi odottamatta). IE:

  1. Herätys
  2. Solmu C odottaa viestiä B
  3. Solmu B lähettää
  4. Solmu B odottaa viestiä C
  5. Solmu C lähettää
  6. Solmu C odottaa viestiä B
  7. jne.

Desynkronoinnin huomioon ottamiseksi kukin odotusjakso pitäisi olla aikakatkaisu, jonka jälkeen solmu lähettää riippumatta siitä, onko se saanut toisen solmun viestin.

Tämä tasoittaa väylän käytön ja jättää jokaisen ohjaimen suorittamaan muita tehtäviä odottaessaan viestiä (sen sijaan yrittää lähettää jatkuvasti välimiesmenetyksen sattuessa).

Huomaa, että tämä on CAN: n epätavallinen käyttö. Sinua saatetaan palvella paremmin yksinkertaisemmalla protokollalla, kuten SPI: llä (solmun A on kysyttävä B: tä ja C: tä, mutta välimiesmenettelyä ei tarvita, ja kaikki voi olla DMA- ja / tai keskeytysohjattua).

Kiitos vastauksestasi. :) Tajusin juuri, että voin käyttää hyväksyntisuodattimia vain kyseiseen toteutukseen (esim. Havaitsemaan, onko toinen solmu lähettänyt CAN-sanoman). PICf25k80: ssa on kuitenkin vain 6 hyväksymissuodatinta ja 2 hyväksyntämaskia. Jos CAN-verkko kasvaa suuremmaksi, jonnekin alle 2 ^ 11 - 1, riittääkö hyväksymissuodattimet ja naamiot? :)
En ole varma, mitä tarkoitat, kun sanot "vähemmän kuin mutta lähellä 2 ^ 11-1". Kapasitiivisen kuormituksen vuoksi yhteen CAN-väylään liitettävien solmujen määrälle on käytännöllinen rajoitus - se on yleensä hieman yli 100 solmua. CAN: n tavanomaisempi käyttö olisi tapahtumavetoinen ympäristö (mahdollisuuksilla äänestämiseen ja joitain harvinaisia ​​syketyyppisiä viestejä). Ajatuksena on pitää väylän käyttöaste mahdollisimman alhaisena, vaikka siitä tulee vaikeampi, kun väylään lisätään lisää solmuja. Skenaario on pikemminkin kuin juoma paloletkusta, jatkuvilla konepistoolin päivityksillä.
Minun mokani. Minun olisi pitänyt sanoa jonnekin välillä 0 ja 2 ^ 11-1. Koska SID on 11 bittiä pitkä, joten mielestäni CAN-verkon raja on 2 ^ 11-1. Kiitos huomautuksesta. Haluan vain tietää, mitä tapahtuu, jos se laukaisisi jatkuvasti. Todellinen toteutukseni on, että minulla on 6 solmua, mutta vain yksi solmu kerää tietoja muista viidestä solmusta. Joten suunnitelmani on, että muut 5 solmua lähetetään peräkkäin keräyssolmulle n millisekunnin välein. Mitä mieltä sinä olet? Onko RTR parempi valinta?
Kysymys on todella, tarvitsetko päivityksiä niin usein. Siinä tapauksessa, että "isäntä" (tiedonkerääjä) tarvitsee vain satunnaisia ​​päivityksiä ja pieni viive on hyväksyttävä, RTR: llä on järkevää. Jos pääkäyttäjä tarvitsee välittömän pääsyn nykyiseen arvoon, mutta arvot muuttuvat hitaasti, muut solmut voivat vain käynnistää viestit aina, kun muutoksia tapahtuu. Jos arvot muuttuvat riittävän nopeasti, ne työntävät väylän käyttöastetta ylöspäin, ja voi olla hyödyllistä saada ne lähettämään pyöreän tyyliin, kuten olet ehdottanut. Huomaa vain, että round-robin ei ole skenaario, jolle CAN on suunniteltu.
Se on täysin järkevää nyt. Unohdin, että jokaisella solmulla on erilaiset prosessit ennen tietojen lähettämistä keräyssolmuun. On järkevää lähettää vain muutoksen tapahtuessa. Kiitos herra :)
Olin Lathrop
2013-10-02 17:41:27 UTC
view on stackexchange narkive permalink

Ensinnäkin solmuilla ei ole tunnuksia, viesteissä on.

Tämä on hankalaa, eikä sitä ole suunniteltu CAN: lle. Sen pitäisi toimia, jos jokainen solmu viivyttää tarkoituksellisesti vähän jokaisen onnistuneen lähetyksen jälkeen. En muista, saako PIC 18F25K80 -laitteisto tietää, milloin kehys todella lähetetään, mutta se todennäköisesti lähettää. Toinen solmu tarvitsee vain lyhyen ikkunan, jotta se näkee kehyksen lopun ja alkaa lähettää. Kun tämä toinen solmu alkaa lähettää, ensimmäinen viivästyttää viestiään automaattisesti kehyksen seuraavaan loppuun asti.

Tämä kuulostaa kuitenkin CAN-väylän väärinkäytöltä, ja parempi vastaus voi olla uudelleen ajattele koko arkkitehtuuria.

Kiitos vastauksestasi. Myönnän virheeni. Tein virheen toteamalla, että solmuilla on tunnukset. Anteeksi tuosta. Joka tapauksessa, mikä tuo arkkitehtuuri olisi? :)
Muuten, siitä mitä sanoitte, että sen pitäisi toimia, jos jokainen solmu viivästyttää tarkoituksella vähän jokaisen onnistuneen lähetyksen jälkeen ja kun tämä toinen solmu alkaa lähettää, ensimmäinen viivästyttää viestiään joka tapauksessa automaattisesti kehyksen seuraavaan päähän. Tarkoittaako se, että se toimisi, jos lisäisin vain pienen viiveen vain solmuun B, koska solmupiste B voittaa välimiesmenettelyn CAN-viestin lähettämisen jälkeen solmusta C?
@Xegara: Kyllä, sinun ei tarvitse viivyttää yrittäessäsi lähettää matalimman prioriteetin viestiä.
Hienoa. Mainitsit, että tällaista toteutusta ei ole suunniteltu CAN: lle. Haluaisin tietää enemmän CAN: n asianmukaisesta toteutuksesta. Mistä aloitan? :)
CAN on suunniteltu hyvin useille solmuille, joista jokaisella on suhteellisen pieni kaistanleveys (esimerkiksi verrattuna ethernetiin). Paljon viestiä voi lentää ympäriinsä, ja jokainen solmu kuuntelee vain sitä, mikä välittää. Sinulla näyttää olevan yksi ohjain ja kaksi erillistä datasolmua. Tätä voidaan palvella paremmin esimerkiksi SPI: n kanssa, jossa isäntä hallitsee suoraan, kun kukin solmu lähettää tietoja. Miksi CAN on mielestäsi sopiva tapauksellesi?
Lainasin juuri skenaarion vastaamaan kysymykseeni. Todellinen toteutukseni on, että minulla on 6 solmua, mutta vain yksi solmu kerää tietoja muista viidestä solmusta. Joten suunnitelmani on, että 5 muuta solmua lähetetään peräkkäin keräyssolmulle n millisekunnin välein. Lisäksi CAN: n ominaisuus on, että voin vain lisätä toisen solmun ohjelmoimatta uudelleen muiden solmujen CAN: ää, mikä tekee siitä erittäin joustavan. Mitä mieltä sinä olet?


ⓘ
Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...