- Pro vkládání komentářů se musíte přihlásit
V zápisku „Až přijde opravdu CAN FD“ jsem zmínil nekompatibilitu CAN FD rámců s řadiči CANu, které CAN FD neumí, tedy řadiči klasického CANu. Na internetu se píše o konceptech budičů CANu s funkcí CAN FD shieldu, které by blokovaly přenos FD rámců do klasického řadiče. Nešlo by to ale udělat lépe? Jak? Klasické budiče CANu podporují obvykle rychlosti až 2Mbity. Tedy více než dovoluje norma, tj. 1Mbit. Je tak možné přes ně bez výrazného zkreslení posílat i rychlejší data. Sample point je obvykle nastaven na 87.5 procenta. Představme si, že v rámci 1 bitu se nebude přenášet 1 bit, ale třeba 4. Klasický řadič bude samplovat na 87.5 procenta a přečte nějaký stav bitu a tedy nějaká celková data. Řadič něčeho, čemu můžeme říkat například CAN HD, však bude samplovat na 12,5, 37.5, 64.5, 87.5 procentech. Může tak přečíst 4 násobek dat. Samozřejmě by šlo jít i na větší násobek dat, jen by nebylo zachováno přirozené pořadí bajtů.
Ptáte se a co třeba CRC, musel by se použít přece jiný polynom na zabezpečení delších dat. Je ale možné použít druhý CRC pro data navíc a obětovat pro něj některé nové datové bajty. Stejně tak indikaci HD CAN rámce by bylo možné realizovat pomocí nějakých kontrolních bitů v rámci dat. CAN HD frame by pak při 4 násobném vzorkování neměl 32 datových bajtů ale jen třeba 28. Při 8 násobném pak místo 64 batů jen 60.
Na CANu by pak vedle sebe mohly pracovat jak původní CAN 2.0 jednotky i nové CAN HD. Klasický řadič by nenarušoval komunikaci CAN HD, dokonce by byl schopen z těchto rámců číst 8 datových bajtů. V zařízení by se pouze při výrobě použil rychlejší budič CAN sběrnice, aby nedocházelo ke zkreslení signálu mezi budičem a klasickým řadičem při přenosu HD rámců.
Úplně celé to není úplně z mé hlavy, něco podobného jsem již zahlédl v nějaké studii někde na internetu, bohužel již nedokážu dohledat původní zdroj.
A ještě jedna poznámka. CAN FD používá rezervovaný bit R0 pro indikaci, že se jedná o FD rámec. Ona vlastně je chyba již v CAN 2.0. Pokud by se definovalo již dříve v CAN 2.0, že pokud R0 má opačnou úroveň (recessivní), nemá si řadič CANu všímat zprávy až do konce rámce, mohl se problém vyřešit již na začátku. Řadiče CANu by byly od začátku navrženy tak, aby tyto zprávy ignorovaly a byla by zajištěna současná funkčnost starých i nových řadičů na jedné sběrnici.
Další věc, o které si myslím že mohla u CAN FD protokolu fungovat jinak, je to, jak funguje přepínání rychlosti. CAN FD rámec obsahuje příznak (BRS - baud rate switch), ze kterého se detekuje, že se používá v rámci datové fáze rámce jiná rychlost. Rychlost v datové fázi je dána dopředu, tedy buď jsou zařízení stejně nakonfigurována, nebo se musejí předem při inicializaci nějak domluvit pomocí protokolu vyšší úrovně.
Nebylo by ale lepší místo 1 bitu pro BRS použít třeba 4 bity a přímo v rámci indikovat na jaký násobek základní rychlosti se přepíná. Odpadla by nutnost konfigurovat 2 rychlosti, nastavovala by se pouze jedna základní. Node, který použije přepnutí rychlosti rozhodne jaký násobek bude použit, příjemce je schopen to za běhu detekovat a přepnout se. Rychlost-násobky by bylo možné dynamicky měnit, například pokud se detekuje horší kvalita přenosu.
Ale po bitvě je každý generál :-)
DS