По повод дискутирания в другата тема USB-CAN преходник, има нещо, дето все още ме човърка, докато мисля хардуера и платката, а именно кой USB вариант е най-удачен. Устройството няма да е HOST и OTG, понеже няма смисъл от това. Няма да е и HID, защото е недостатъчно като скорост, и/или трябва да разделям данните между няколко виртуални HID устройства, за да докарам нужното ми бързодействие. Понеже не съм дорасъл достатъчно, смятам да ползвам библиотеките на Microchip за момента, но в примерите са дадени един куп варианти, и ми е малко трудно да избера кой от тях би бил най-удачен. Целта е да се докара около мегабит и половина скорост между PC-то и PIC32-ката, за да мога пълноценно да използвам и дебъгвам трафика по CAN шината, дори и при пълната и скорост от 1 мегабит.

Та, в библиотеките на Microchip има следните примери, на които към момента съм се спрял:
1. LibUSB - Generic Driver Demo
2. MCHPUSB - Generic Driver Demo
3. WinUSB - Generic Driver Demo
4. WinUSB - High Bandwidth Demo

Някой да има някакъв коментар по въпроса? До сега странях от разправии с USB, понеже знам че е тъмна индия там и е сложно, но така или иначе рано или късно щях да стигна до това, искам или не. Затова и реших че му е време вече и с това да се преборя, поне до някъде. Ще съм благодарен на всякаква помощ от препатили.

Ако решиш да смениш фирмуера чрез обикновенна USB Flash карта, тогава е полезно да поддържаш HOST-а.


Е той полезния трафик е далеч под 1 Mbps, горе долу на 64-бита полезна информация ( 8-те байта в пакет ) имаш още толкова битове ( при SID са по-малки пакетите ) за синхронизация, начало на фрейм, край на фрейм, контролни суми, идентификатори. Като цяло потребителската информация е максимум около 450kbps. Т.е. 1MBps по USB би трябвало да може да трансферира в реално време CAN трафика. Просто остави големи USB буфери, където да тъпчеш CAN данните. Утре ако се сетя ще погледна PEAK USB CAN адаптера какъв точно трансфер използват.

Мдам. Оказва се че PEAK май ползват собствени kernel драйвери. А сега да се уча да пиша драйвери за windows и да ги сертифицирам никак не ми се ще. HOST за момента категорично няма да мъдря. Много ще ми дойде. Искам просто преходник USB-CAN, който да не е виртуален COM порт, и чийто фирмуер да ъпдейтвам през USB-то от HEX файл.

...всъщност, някъде из интернет имаше схемата на преходник със същите чипове като PCAN-USB на PEAK. Ако се окаже съвместим и с фирмуера и софтуера им, най-много направо да го метна него.

Ми той Host-а на Microchip си е готов, няма какво да пишеш там, освен да го инициализираш. То не е задължително и да го правиш, просто си остави на платката един USB Host конектор, за всеки случай, ако ти се наложи да не правиш нова платка. За PEAK PCAN-USB ти казах, че имат интерфейсен DLL, вътре са 10-тина функции, които викаш и толкоз. При мен DLL го зареждам динамично, щото не намерих LIB файл и Qt-то не знае как да го направи ( по-скоро аз не знам ). Хардуера на PCAN-USB е с един моторолски 8-битов процесор.

Ама пак реши какво искаш де, щото в друга тема искаш скорост на трансфер по USB, сега пък споменаваш "просто преходник". Ако е просто USB <-> CAN преходник, който да не е виртуален COM порт, то MCP2515DM ти върши перфектно работа, не ти трябва да пишеш драйвери, сваляш си libusb , в линка някъде в предишните ми постове има работещ пример, имаш две-три функции да извикваш, протокола между PC-то и MCP2515DM е от прост по-прост, все ще докараш трансфер от 0.5Mbps чисти CAN данни. Схемата на MCP2515DM я има, и герберите ги има, и фирмуера също.

Засега ровичкам в посока варианта с PIC32, на който се ползва вграденото USB и вградения CAN. Още повече че на по късен етап написаното за него ще ми върши работа и в други проекти. Така или иначе особено с малките версии на PIC32-ката ползването на другите до голяма степен може да се избегне, освен ако не се търси някаква специфична периферия, дето PIC32-ките нямат. А и все пак до голяма степен кода може да се направи преносим, както всъщност microchip са и направили в примерите от първия пост.

Та, разглеждайки снощи микрочипските примери стигнах общо взето до 2 извода:
- Ако не трябва голяма скорост, но трябва гарантирано време на трансфер - HID варианта е добро решение, но е ограничено само до един входящ и изходящ ендпойнти, и като приемем че пакетите са по 64 байта максимум, това значи трансфер максимум от 64000 байта в секунда. Прав ли съм до тук?
- Ако трябва голяма скорост но не критична по време (до колко бързо ще стане зависи от натовареността на "шината"), то Bulk transfer е добър вариант. Тук може да се дефинират повече от по един входящ и един изходящ ендпойнти (в примера на микрочил са дефинирани 3 изходящи например), от което теоретичния максимум като скорост е по 64000 байта за всеки ендпойнт. Тоест, в случая с 3 ендпойнта имаме 192000 байта в секунда теоретичен максимум, ако към конкретния хост не са навързани много маймуни. Правилно ли разсъждавам до тук? Ако да, какъв е разумния брой ендпойнти, които е възможно да се ползват. Тоест, каква бройка има смисъл, ако се търси максимална скорост, защото чисто от шесто чувство предполагам че от определена бройка нагоре смисъла е никакъв, ако натоварването на "шината" клони към 100%.
- Ако натоварването на USB 1.1 клони към 100%, това значи ли че ако върху USB2.0 хост имам само full speed USB девайси, тя пак ще е натоварена на 100%? Тоест, ако дефинирам толкова ендпойнти че да натоваря USB1.1 шина, значи ли това че ако ползвам USB2.0 такава, останалите маймуни на клона няма да влиаят особено предвид доста по-голямата скорост на двойката?

Ще съм благодарен на всякаква информация по въпроса. Аз се ровичкам и в момента, но в повечето документи се набляга на детайлите, а аз искам да схвана общата картинка преди това, за да мога да схвана по-добре и детайлите после.

¶, споменаваш libusb. Libusb използва ли специфични драйвери за под Windows, или ползва неговите си, а е само интерфейс към тях? И ако продължим да разсъждаваме в тая посока, като имам 3 варианта на "generic driver demo" на микрочип, значи ли това че и трите използват вградения си windows-ки драйвер, и са просто 3 различни интерфейса към него? Не че към момента е супер важно, но е добре устройството да може да върви и на нещо друго, освен windows, а libusb го има и за linux и за android, което си е плюс.

Мисля че поне си изясних номера с многото ендпойнти. Според писания из интернет, при Bulk трансфери няма смисъл, защото дори за 1 ендпойнт се ползва целия свободен към момента ресурс. 1000 пъти в секунда се poll-ват само другите видове ендпойнти.

...само ми е чудно защо в "high bandwidth" примера на микрочип ползват 3 ендпойнта в такъв случай...

Чак сега подгрях... "Generic driver" e това, дето е в PICльото. Другото е софтуера на PC-то.

Мешавина пълна ми настана в тиквата. И libusb ми се струва най-човешко до тук.

Jan Axelson, потърси нейните книжки. Ако не ги намериш се обади, имам ги, там всичко е обяснено. Сайта й е http://www.lvr.com , има много примери.

libusb мисля е само интерфейс към същестуващите Windows драйвери. http://www.libusb.org , още в началото пише че са две несъвместими версии: libusb-0.1(като че ли вече си е изпяла песента) & libusb-1.0, едната се разклоняваше на libusb-win32, а аз използвам hidapi библиотеката, защото се оказа, че HID класа са го премахнали от libusb-1.0 . Та с въпросната hidapi подкарах комуникацията между MCP2515 платката и Windows Qt конзолна програма. За сега съм спрял дотук, защото не е ясно какво трябва да се право оттук нататък. Като цяло MCP2515 платката ще я заместя с един PIC32, тъй като ще бъде решение в един чип за USB & CAN.

Мерси, ще погледна, макар че малко ми се поизясниха нещата.

Като завърша платката ще я постна тук със все софтуера. Предполагам ще сколасам в понеделник да я дам за правене. Софтуера - чак като сглобя и намеря време да го напиша.

Последно се колебая между libusb и mchpusb библиотеката на microchip. Работата с двете е почти еднотипна. И все едно и двете ще работят с един и същ фирмуер на устройството ми се струва, така че окончателно ще преценявам като почна PC софтуера.

...а току виж го направя и с "двоен" стандарт - и чисто USB и емулация на COM. Тогава може да се търси съвместимост с тия на PEAK, както и с тия на CANUSB. Второто като протокол е лесно. Ама това като го докарам до там, а до тогава има много време.

Засега съм го докарал до тук. Единственото ми колебание е дали да не му бучна и един неизолиран DC-DC за 3.3v, вместо линейния микрочипски.

ПП: Свалих си и "USB Complete - 4th edition". Ще си имам занимавка за уикенда.

Да посея една сянка на съмнение...
При 1,5 или 12 Mb/s , каква скорост реално може да даде PC частта?
Имам смътни спомени от един семинар, че реалните скорости са няколко (не 2 ) пъти по-ниски . И не става въпрос за допълнителните байтове .

На мен всичко над мегабит и половина ми върши работа, а даже и в това има доволно резерви. Иначе, съвсем реално, обмен от около 4-5 мегабита е съвсем реалистичен, ако няма много маймуни на клона и комуникацията е предимно еднопосочна. 4 съм виждал с очите си.

Като стигна до някъде ще направя тестове.

Не съм гледал какво представлява mchpusb , спрях се на libusb защото поддържа Windows и Linux, пробвал съм я и на двете платформи.



Виж какви сметки направих ( може и да греша някъде ). При Extended CAN frame с по 8 байта на всяко съобщение ( т.е. максимално дълго съобщение ) имаш следните битове:
- 1-bit Start-Of-Frame;
- 32-bits Arbitration Fields;
- 6-bits Control Fields;
- 64-bits Data Fields;
- 16-bits CRC;
- 1-bit ACK slot bit;
- 1-bit ACK Del;
- 7-bits End-Of-Frame;
- 3-bits IFS ( пауза между пакетите );

Или общо ще имаш 131-битово CAN съобщение. При 1Mbps всеки бит ти се предава за 1us, или едно такова съобщение ще заема CAN мрежата за 131us, т.е. на секунда можеш да приемеш или предадеш теоретично 7633 съобщения, това умножено по 64 бита полезна информация ти дава 488.512 kbps. Ако в мрежата ти има примерно десетина CAN възела и предават едновременно ще има конфликти и съответно изчаквания между отделните възли, така че тези полезни 488kbps ще спаднат да речем до към 400kbps. Ако имаш и по къси CAN съобщения трафика ще спадне още.

USB Full Speed, при HID устройство можеш 1000 пъти в секунда да приемеш или предадеш 64 байта, т.е. общ трансфер 64 000 * 8 бита = 512kbps, което е с ~5% > от 488kbps. Не знам дали USB Full speed заема шината допълнително за служебни трансфери по време на теоретичните 512kbps. Ако не го прави в останалото време вероятността да се сбереш в HID class и същевременно да следиш CAN bus на скорост 1Mbps е много голяма.

Един PIC32 има достатъчно памет да му пуснеш няколко 64-байтови USB буфери, така че всяко дошло CAN съобщение да се тъпче там, за да може да не пропуснеш нито една заявка за трансфер от страна на USB-то. Примерно за J1939 съм си направил приемна и предавателна опашка от до 16 CAN съобщения всяка, т.е. дойде ли нещо по CAN чета го и го пъхам в тази опашка, като имам време го обработвам. При предаването натъпквам всичко в опашката и оставам прекъсванията да си теглят съобщенията.

Всъщност сметката не е точно тая, защото предавам от PC-to към PIC-льото целия "arbitration field" + 8-те байта данни + един байт за команда, тоест 32+64+8 = 104 бита, или 13 байта.

7633 съобщения по 13 байта са 793.832 kpbs. Естествено точно максимума ще се достигне крайно рядко, ако въобще се достигне, така че има достатъчно основания да се помисли по въпроса. Начина винаги да смогва като HID, дори да е стигнат абсолютния максимум по CAN шината, е да направя две виртуални HID устройства във фирмуера, и да броя четно-нечетно, за да знам къде да предавам и от къде да чета.

Мисля че докарах схемата и платката, и към края на другата седмица ще имам сглобено устройство и ще започна да боричкам софтуера.

sparkybg,

Коя програма използваш при дизайна на платката?

Altium Designer 10.