Vlákno názorů k článku Arduino Mega na zbernici s PC od TechnikTom - Docela by mne zajímalo, proč všichni pro tyhle...
-
Docela by mne zajímalo, proč všichni pro tyhle multimaster sběrnice tvrdošíjně používají RS-485, když už tu leta máme i levné budiče pro CAN sběrnici, které poslouží stejně a jsou navržené i pro koklizní stavy. Měl jsem v plánu udělat protokol, který by pro arbitraci využíval princip z CAN, třeba vysílal svoje ID a četl, zda přijímá to samé. Pokud ne, čekal by na další příležitost. Pokud by měl sběrnici volnou, poslal by svá data normálně seriovým protokDocela olem.
Pokud by jeden bit pro arbitraci trval jako celý byte plus stopbity následně přenášených seriových dat, tak by arbitraci příjemci vyhodnotili jako frame error a neragovali.
Dokonce by se dalo využít devítibitové adresování pro buzení příjemců při adresaci jen právě jich. -
A navíc s FT-CANem můžete mít i topologii do hvězdy, v podstatě neřešíte impedanci, odrazy (všechny konce mají aktivní přizpůsobení). Když nemáte nataženou dvojlinku, tak to jde i po jednom drátě (proti zemi, a opravdu stačí na obou koncích zemnicí tyč, vracet to opravdu hlínou).
Mám nějaké senzory natahané po stodole po nějakých původních silových drátech, kterým se papírová izolace dávno rozpadla, a chodí to bez problémů. Jednou žílou napětí, jednou data (CAN H), return vlhkou zdí/zemí.
-
Transceiver stojí dolar (moře destiček na aliexpressu).
Jestli Arduinem myslíte nějaký odpad z 90. let typu ATmega nebo ATtiny, tak si ještě připatíte další 1-2 USD za CAN controller (a s tím pak mluvíte po SPI). Soudobější čipy (STM32, ESP32, ...) to mají v sobě.
Jestli Arduinem myslíte ten softwarový ekosystém, tak ano :-)
22. 9. 2021, 12:11 editováno autorem komentáře
-
Automotive HSCAN transceiver mam zrovna naquotovany za EUR 0.204 :-), je to levnejsi nez RS485kove (ty neumim koupit tak levne).
Vyhoda RS485 je, ze to je UART, takze si tam implementujete cokoliv chcete, ale musite resit vse okolo.
CAN-BUS funguje tak, ze mate 'mailboxy' do kterych sypete az 8 bytove zpravy, controller se stara vlastne uplne o vsechno, o prijem, odesilani, kolize, ... jen v aplikaci musite kontrolovat jestli se zpravy odeslaly a zda to co chcete se prijima. Akorat potrebujete spravny MCU.
Pro predstavu, takhle nejak to vypada na aute (id, data):
15.4.2021 19:23:12.693 0000028B 0000000000000000
15.4.2021 19:23:12.712 00000281 0000000000000000
15.4.2021 19:23:12.762 00000281 0000000000000000
15.4.2021 19:23:12.772 00000286 0000000000000000
15.4.2021 19:23:12.782 0000039E 0000000000000000
15.4.2021 19:23:12.792 0000028B 0000000000000000
15.4.2021 19:23:12.802 00000380 0000000000000000
15.4.2021 19:23:12.808 000003C4 000006
15.4.2021 19:23:12.812 00000281 0000000000000000
15.4.2021 19:23:12.822 0000029B 0000000000000000
15.4.2021 19:23:12.862 00000281 0000000000000000(je to body can nejakeho starsiho auta,)
22. 9. 2021, 13:07 editováno autorem komentáře
-
Spravny MCU ani netreba. Existuju aj separatne CAN PHY na SPI, dokonca aj v THT verzii, takze sa to da spajkovat dohromady aj trafopajkou. U CANu by som skor ako nevyhodu videl, ze pre dlhsie spolahlive vedenia je s tym trocha ostara to cele nakonfigurovat skrz presne hodiny a odrusenie. Dalej tam je mozna nevyhoda v tom, ze vela PHY bude riesenych len pre 125/250/500(/1000) kHz, co moze byt pre vela aplikacii overkill. A nakoniec RS485 je v podstate fyzicka vrstva CANu bez jeho CSMA/CA daneho arbitrazou.
-
"A nakoniec RS485 je v podstate fyzicka vrstva CANu bez jeho CSMA/CA daneho arbitrazou."
Dovoluji si nesouhlasit, NE to rozhodne neni ! Nechapu kde se tento nesmysl dokolecka bere.
Ano, SPI CAN controllery jsou, ale stoji ale vic nez nejaky Cortex-M3/4 s CANem. Jeste je nekde pouzivame a je to tragicke reseni.
-
Mohli by ste svoj rozpor mojho tvrdenia rozvinut? Rad sa niecomu priucim.
A zrovna dnes to s cenou toho Cortexu s CANom ani nemusi byt pravda. Najlacnejsie L0+ co uz ma CAN bude kludne za 5+ eur, ak vobec bude k zohnaniu.
Kazdopadne suhlasim s tym, ze ATmega je mrtva vec (tusim velku cast tych cipov sam Microchip uz ani nevyraba a su to iba klony) a netreba na nom stavat nove dizajny.
-
Mrknete na prubehy signalu z nejakeho datasheetu, nebo pres google images a bude to myslim jasne hned. Stejne na nich je to, ze maji dif. signal, takze mozna RS485 xcvr pujde pouzit na prijem CANu, ale to pujde i LM393. V laboratornich podminkach.
FTCAN je tim jak jdou proti sobe CANH/CANL podobny RS485, ale ma spoustu detailu navic, jeden z nich je treba zde zminovana terminace a fault mody.
Sehnat nejaky levny Cortex s CANem nemam az takovy problem, obcas je potkavam, nejde-li o tisicova mnozstvi. Posledni dobou celkem casto prochazim ruzne arrow/digikey/... a vykupuju co je zrovna skladem (ne teda ty SoC, jine souc.)
-
arduino nie je len atmega. je to libka ktora je portovana na vela cpu vratane STM32, esp8266, esp32. NO a ma kopec kniznic na rozny HW vzajomne kompatibilnych. Ano kvalita je otazna ale ak chce clovek nieco polepit trafopajkou a nestudovat datasheety k tym svabom je to idealne. Staci pozriet projekt tasmota
-
CAN (treba CANOpen) je super ale neni to pro "kurvilky", protokol uz je moc slozita zalezitost.
Zatimco RS-485 (treba modbus) je tak strasne primitivni, ze ho pochopi kazdej za jeden vecer a behem druhyho vecera napise svoji implementaci.
A ja to mam stejne, ac jsme v byvalem zamestnani pouzivali CANOpen velmi hojne na pokrocile urovni, tak domu bych si to nedal
Pokud budete chtit CAN radic znasilnit do nejakeho nevyhovujiciho protokolu, tak z toho muzete bejt celkem smutnej (treba opakovani zprav v tom muze udelat celkem hokej). + je tam hrozne velka rezie zprav...
Pokud chcete znasilnit pouze budic CANu a honit pres to treba UART, tak tim proti budici RS485 nic moc neziskate (atorat to ze pri kolizi mozna vyhraje dominantni uroven). Navic tam ale pravdepodobne nebude zachovanej "bit stuffing", coz muze mit negativni nasledky na spolehlivost prenosu (neumim posoudit jak moc vazne)
Jako nejvetsi nevyhodu ale vidim, ze nemuzete pouzit nic z toho co uz existuje. Jako treba nakoupeny senzor, nakoupeny prevodnik CAN-USB, nakoupeny analyzator sbernice... Nic. Prijde mi to jako cesta do pekel. To bych radeji venoval par tydnu do studia canopenu...
-
Nejako nevidim dovod CAN akokolvek znasilnovat. CANopen je len volitelna, tuho aplikacna vec. Nikoho nikto nenuti ju pouzivat (ofc kym si nenakupim gadgety, ktore na holom CANe nevedia chodit). Jedina povinna vec je CAN ID a nadavat na to a s nim spojenu arbitraz je, ako keby clovek nadaval na to, ze I2C vyzaduje adresaciu.
-
Kdyz jsem mluvil o znasilnovani reagoval jsem na prispevek od "TechnikTom", ze ktereho se mi zdalo, ze chce pouzit CAN pouze jako fyzickou vrstvu ale budit to z radice UARTu.
Pochopitelne muzete jet na "cistem" CANu v tom vam nijak nebranim. :)
Jenom uz jsem videl par projektu, kde se po CANu tunelovala seriova linka (pekne jedna zprava jeden znak) a velike prekvapeni jak strasne je to pomale (rezie) a jeste vetsi prekvapeni, ze se po nasazeni zjistilo, ze se obcas nejake znaky opakuji.
Tak mi prislo dobre na to upozornit, ciste z edukativnich duvovu ;) -
Pointa CANu je právě že žádnej protokol po večerech implementovat nemusím. Na jednom konci vložím do mailboxu struct, vyšlu ho s daným IDčkem, a na všech ostatních nodech (které dané ID zajímá) se mi ten stejnej struct objeví v jejich mailboxech. Neřeším jak, proč, protože už to vyřešili jiní místo mně.
Ano, vědět jak funguje jeho bit timing, bit stuffing, arbitrace atd. je přínosem hlavně pro diagnostiku, ale nepotřebuju to k provozu. Narozdíl od bastlení nějakých hrůz nad holou 485 nebo nedejbože modbusem a jeho 16bitovými typy :-)
-
Vyhoda CANu je moznost prioritozvat spravy (podla "adresy") a hlavne fungovat asynchronne. Je nutene si rozmysliet adresaciu ale potom posielenie sprav je limitovane len 8byt payloadu aj ked vacsinou si vystacim len 0 bytami na riadeni sluzi uz rovno adresa. z pripojenim na ESP32 mam portov jak hadov nemusim implemntovat nic z pohalhu CAN BUS deje sa to "samo" staci par centovy prevodnik z ALI. Tak isto lahko mozem implmenovat lopatovac z CAN na MQTT niekde ked uz je siet. RS486 a postupne obvolavanie kazdeho je opruz. Hlavne ked chcem riesit tlacitko a naslednu reakciu (zvoncek) nebude predsa zvoncek zistovat kazdu sekundu a nestalcil niekto tlacitlo aby som zacal zvonit ??? Treba rozlisovat senzory a aktivne prvky. Senzor ma posielat svoj stav a kazdy koho to zaujima ma reagovat.
-
CAN je pěkný, ale arbitrace běží na bittime a tak pro 1 Mbit/s nemůže být linka delší než 30 metrů. V rámci našich CAN projektů, příspěvků do kernelu, QEMU atd. na ČUT FEL vznikl i vlastní CTU CAN FD řadič a jsme v kontaktu s návrháři CAN FD a teď CAN XL protokolu. Klasický CAN má potíž krátkýc zpráv a omezení délky linky nepřímo úměrně rychlosti. CAN FD po dobu přenosu dat přechází na vyšší rychlost/bitrate, ale již když jsem návrh prvně viděl, tak jsem prezentujícímu z CiA říkal, že budou zásadní problémy s nevyváženým buzením při data bitrate a že by linka z dominant recesive měla přejít po dobu přenosu dat na push pull. Automobilky měli s CAN FD ze začátku mnoho potíží a dnes se používá místo slibovaných 20 Mbit/s na data je 2 Mbit/s. I tak to není ono, přidávají se do budičů řízení zakončovací impedance, které při přechodu dominant recessive slouží k potlačení odrazů a zákmitů, improved signal integrity. Nakonec se stejně výrobci rozhodli pro návrh nového standardu, CAN XL, kdy se pro arbitraci používá dominant recessive a po dobu datového přenosu se přechází na push-pull (něco co měl uLAN na 8051 vybavené jen úplně primitivním UARTem vymyšlené před 30 lety, takže o tolik jsme byli napřed). Výhoda CAN XL pak je, že přechází po dobu data pase na nižší a symetrické napěťové úrovně a že po dobu arbitrace je recessive nula a dominant od rozdílu 1V, jako u klasického CANu. Tady náš původní uLAN pro spolehlivost vyžaduje v klidovém stavu rozvážení, protože u komerčních RS-485 transceiverů většinou není definovaný vložený offset do dohodovací diferenciální úrovně. Pokud by tam bylo definované, že je třeba od 0.3 do 0.7 V tak by to nebylo potřeba, ale zase v datové fázi by to zkracovalo nuly. Ale i tak je otázkou, jestli mnoha koncepcích nebude uLAN stále dále než CAN XL. Přitom řadič na CAN FD ano na CAN XL si bez placení licenčních/patentových poplatků nemůžete dovolit prodávat a asi ani řešení, kde by to bylo vyřešené nějak v "soft-core". uLAN byl dokumentovaný a zdrama od začátku.
