Един колега повдигна днес интересен въпрос за изчисляване на натоварването на CAN мрежата. В предишните коментари смятах 131 бита ( EID с 64 информационни бита ). Но има една уловка, която бях забравил:


Това означава, че в зависимост от стойността на битовете между Start of Frame и CRC полето CAN предавателя ще вмъкне по един допълнителен бит, ако намери 5 последователни бита с една и съща полярност ( този бит се премахва от съобщението в приемника ). Някои специфицират максимално дълго съобщение от базовите 131 бита + допълнителни 19 , или допълнителни 27 бита. Не знам кое от двете е вярно ( 150 бита или 158 бита ), но тази подробност може да намали с около 15% капацитета на мрежата, ако се случват често неподходящите комбинации от 5 еднакви последователни бита.

Сглобих го, па и взе че тръгна USB-то.

В bulk transfer mode. Не било чак толкоз трудно. Ама "USB Complete" книжката МНОГО помогна да разбера кое-що, за което горещи благодарности! Хванах libusb примера и го разчистих от плявата, като оставих само частта за PIC32.

Сега остава да свърша само моята си част, и всичко ще е на шест!

Току що тествах за реална скорост на трансфер. При 99% еднопосочен трафик (от компютъра към PIC32-ката), в Bulk Transfer. Изпраща и PIC32-ката успява да поеме блок от 1 022 840 байта (или почти мегабайт) в секунда.

Е, естествено PIC32-ката нищо не прави с тая информация по време на теста, освен да я прекара през буферите си. Единствено се опитва да изпраща статус какво е получила като брой байтове и в кой буфер. Ping-pong буферирането с по 2 буфера за вход много сериозно вдига трафика, защото докато PIC32-ката се разправя с полученото другия буфер приема следващото. Върху същия USB хъб има включени и флашка и PICKIT3, по време на теста - неактивни.

Та, толкоз относно въпросителните колко може да даде USB Full speed режима. По дефиниция 10% от времето е резервирано за системни месиджи, и остават 10.8 мегабита, от които аз "напълвам" 10.23.

Тоя термин винаги ме е дразнил, какво общо има между ping-pong и двоен буфер не знам, обаче западняшката литература е пълна с ping-pong простотии.

Иначе браво за трансфера, това на един endpoint ли ?

Един ендпоинт, да.

То и мен ме дразни ping-pong-а, ама така са го решили. Най-малкото докато си изчистя съмненията дали не са го нарекли така с някаква задна мисъл, която не ми стига акъла да си представя. Пък накрая се оказва че "не били компютри, а компоти".

Е па то не личи ли ...
Иначе каква е скоростта по тоя CAN че HID не ти е ОК .. а иначе микрото не знам как са, ама на силабс USB работи повече от добре, и не забелязвам да е много бавно.

Бе то личи, ама що не "double buffering" ами ping-pong? С тоталната обърквация с термините и постановката на самото USB, просто ми дойде малко в повече. До снощи борих защо тъпото libusbdotnet не ми изкава DataReceived event, а то искало непълен или нулев USB пакет като маркер за край на трансфер. Пак USB Complete книжката помогна. После пък се зачудих "Трансфер" хардуерна или софтуерна хава ли е и прочие истории. И така докато стигна до простичкия извод че всичкото "USB Stack" на Microchip е едно голямо писане за едно голямо нищо. Сега вече ми е просто, ама продължавам да твърдя че всичко около USB е правено и документирано от болни мозъци. Платените VID например са тотална тъпанарщина.

Скоростта на CAN-а е мегабит максимум, доволна част от което се губи. В 90% от случаите и HID би вършил работа. Просто исках максимума. Правя си прости библиотеки за dotnet и PIC32 в момента, за да върви като stream. Тройно буфериране, един вид. RX и TX буфери, от които като ми трябва чета. От страна на PC-то - същото. Тогава библиотеката ще върви и с UART/COM порт, и с ethernet, и с квото се сетиш. Един вид универсален прост комуникационен интерфейс, който ще ползвам и по-нататък, евентуално. Ако не мина на PIC на RX62 де, ама той и за там ще може да се направи. Много съм им се наточил на тия гадини.

Дедо Боре разправяше, че като бил в Китай и питал защо нещо си не е направено така, ами иначе, обикновено отговора бил тук е така, та затова и ги кръстил Такай . По дедукция същата работа и с ping-pong, ако ги питаш защо точно ping-pong вдигат рамене и ти казват тук е така . Иначе личи, като загубиш сума време да се кьориш в сорс кодове се разбира, че значи double buffer..... ма тук е така

Ами не ми се види множко, при нас ако се нe лъжа на силабса 5 МB го докарваме с HID драйвер, но не знам тая пиковска история USB1 или 2 поддържа.

USB Full speed поддържа. 12 мегабита демек. При тая скорост HID-а е ограничен до 64к в секунда (по един 64 байтов пакет на всяка милисекунда).

Става, с 10 endpoint-a

Като как HID с 10 ендпоинта? В "оная" книжка пише че HID устройствата са ограничени до един изходящ и един входящ endpoint?

Или 10 виртуални HID устройства? И пак на full speed става 640к в секунда, а не 5 мегабайта?

Ако е High speed вече е друго де. 1024 байта за трансфер на всеки 125us, ако се не лъжа?

Абе възможно е да съм малко в грешка, защото едно време не бяхме с HID драйвери, но тоя тест по спомен го правихме сравнително скоро та мисля че HID си беше ... ако дойде хищника ще каже.

Едит.
Признавам оглупявам явно, тоя проц който ползваме няма как да поддържа 5 MB сега го погледнах, , той е Full Speed, явно са били 5 Mb.

Едно допълнително въпросче ми се явява. Накарах datareceived ивента да ми се задейства при край на транзакция - като пратя непълен или нулев пакет към PCто. Обаче не мога да накарам примерно като сендна към устройството 100 килобайта, пък устройството приеме например 4 килобайта от тях, софтуера на PC-то да отчита това. В момента като изпратя много данни към устройството и то не ги приеме всичките, libusb-то ми връща че устройството не е приело нищо.

Какво трябва да направя от гледна точка на устройтвото, така щото libusb-то да се усети че все пак част от данните са приети от устройството? Някакви системни месиджи ли трябва да изпращам от устройството към PC-то? Опитах задам на PIC32-ката да приеме непълен пакет, например от 10 байта, обаче не става. Все ми връща че нищо не е изпратено след изтичане на времето за таймаут.

Бе дай кода, дето мъчиш... кой ще ти гадае