Един char няма да помогне с кой знае колко, идеята е колкото се може по голям пакет наведнъж.

Както гледам тази идея като цяло може спокойно да бъде преместена в раздел БЕЗУМНИ ИДЕИ....

Не ни подценявай

:) това беше само ирония ама мисля че е време да направите нещо вече по този проект

Правим, само че проекта се движи бавно, на участниците не се плаща за него, всеки си има някаква работа и малко свободно време

Един съвет - Обобщете го някъде - може и други да мислят по проекта

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

Като гледам предложения от The Wizard протокол не виждам нещо с което да е по добър или по универсален от предложения от мен.

Този протокол съм го мислил специално за управлението на подобно устроиство.
- има ID на устроиството което е удобно за изграждането на алгоритъма на приемане от страна на процесора. То не е необходимо при работата с USB-to тъи като FTDI си има сериен номер които индетифицира съответното устроиство. Но все пак това ID прави протокола удобен за работа и с друг вид сериина комуникация.
- има къси команди / тези на които най старшия бит е 0 при които пакета е само 6 байта / предават се 3 баита като операнд на командата.
- дълги команди които изппращат или приемат до 256 баита данни + 2 байта операнд и 1 баит дължина на пакета които може също в някои случаи да се ползва като операнд.
- Ако е необходимо да се изпрати по голям от 256 баита пакет от данни по този протокол става като се пусне заявка с команда към устроиството което трябва да изпрати данните след което се очаква за отговор в вид на "data package" като ограничение за максималната дължина на пакета няма тъй като в "SENT DATA PACKAGE" няма дължина на пакета. Което дава свобода на реализацията на работата с пакети данни.

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

възможно най късата команда е 4 байта
[01 04 01 04]

01 API/ID.....група команди..... можеш да имаш 256 групи(pipes,endpoints... в този смисъл)
04 дължина на буфера
01 командата - например PING
04 XOR

дълга команда
01 FF read .....data[252]............... xor
максималната дължина на буфера е 256
ако LEN стане INT..... данните са доста

Това не е измислено от мен - взел съм го от Сименс ГСМ - просто казах че съм го пробвал многократно и дава много добри резултати

Интересното беше да разгледате пик 18F4550 - 12 MPS, има си USB2.0 със 16 end-points, както и Паралелен порт за FPGA-то. Така FTDI-то отпада и може да се развие много по голяма скорост на дата обмен, както и този протокол за който дискутираме може да отпадне(USB - контролен EP0, Сериален EP1, паралел EP2....)

Господа, извинявам се, че се намесвам в движение! Хрумна ми нещо относно протокола за връзна:
никъде не споменавате /или аз поне не съм видял/ за протокол удобен за POSIX /Portable Operating System Interface/, ще поясня малко. Aко се работи под Linux например, можете да изчетете цялата памет от анализатора във файл /давам пример по RS232 COM1/ с простите команди в един текстов файл:

за USB-to мисля ще стане със /dev/sda0.

нещо като FTP протокола може да е ASCII или BIN, всички команди към ЛА-то да са в ASCII формат включително и операндите, а ще предвидите команда която да превключва трансфера на данните от ЛА-то към PC във формат ASCII или BIN.

Какви са предимствата:
под WIN си работите със драйвери и обмена е във BIN формат /както ще го правите/;
под Linux Unix си работите в ASCII формат и избягвате писането на драйвери, можете да пренасочвате входа и изхода на данните от ЛА към друга програма, управлението може да се сведе само до текстови комадни от файл, ЛА може да се управлява дистанционно по TCP/IP в интернет от една малка Linux<50MB инсталация на някаква дънна платка, резултата може да се вижда като HTML страница и т.н. И всичко това без написването на нито един драйвер или ред програма!

TheWizard
всъщност подобна организация на протокол даде Predator. Обмислях го тоя вариант но има следното неудобство като се ползава.
- при указване на големина на буфера с един байт имаме буфер до 256 байта и на всичкото отгоре не е 256 баита защото от 256 баита трябва да извадим 4те баита на командата ИДтата и Xor-a . И нямаме операнди.

Да разгледаме случая искаме да запишем страница от паметта на серииния флаш които е вързан на микроконтролера.
По предложения от мен протокол това ще стане само с една комада тъй като има 256 баитов буфер + 2баита операнд който посочва коя страница трябва да се пише.

Да разгледаме и друг случай. Искаме да натъпчем цялата Рам на анализатора с данни през USB-to. Ще стане така:
- изпращаме команда която да активира функция в анализатора която да очаква пакет дата 1 Мб. След получаване потвърждение за готовност от страна на анализатора се започва изпращането на Data Package с големина 1 Мб. Тъи като в процесорния модул приемането е реализирано изцяло на прекъсването едновременно с приемането може де се изпраща приетото по SPI или паралелен канал (зависи как ще е реализирана връзката) към FPGA модула. Така се получава че изпращаме 1 мегабаит данни по възможно най бързия начин.

Ако ползваме 2 баита за големина на буфера при твоя протокол положението се пооправя но пак губи по удобство на работа в сравнение с този. Също и XOR е по неудачна проверка от SUM. Все пак това е е устроиство в което има доста енергонезависима памет и не е желателно да има грешно интерпретирани команди или данни. Протокола които предлагам е защитен с 2 контролни суми. Първо на самата команда което изключва възможноста командата да се интерпретира погрешно и втора 2 баитова контролна сума за самите данни. Като ако съответно нямаме данни в съответната команда втората секция на командата е напълно изключена и не се излъчва и не се очаква.

forest_gump
Ако трябва да работим с ASCII команди това ще усложни протокола и са излишни главоболия. Управлението на това устроиство е много по сложно от четене на паметта му. FTDI си има драйвер и за под линукс и не е проблем да се направи всичко както си е под Windows. А и както изглежда ентусиасти за проекта липсват така че надали някой ще напише софт и за линукс.

Идеята за протокола е моя, аз обаче отдавна съм променил тоя протокол, в момента дължината на <Data Size> е 2 байта и се стремя да предавам по-големи пакети ако става въпрос за трансфер по USB. Наистина няма нужда от 2 ID байта, аз го ползвах заедно с RS485 протокол и идеята ми беше бъдеща възможност за разширяване на устройството. Аз лично съм съгласен с протокола на Nikola, не виждам какво пречи дължината на <Data Size> да е 2 байта. А и говорим за USB кабел не по-дълъг от 1m, едно CRC8 май ще свърши чудесна работа Идеята за PIC18F4550 ми допада, особено след като в сайта на Microchip има драйвер за "USB Mass Storage Device"

Аз си мислех за CRC16 но преди по ICQ-to ти бях споменал че съм правил експеримент на 500000 бода. Цяло денонощие бях оставил компа да праща 256 байтов буфер random data а АТмегата да го връща и бях направил CRC32 контрол. За цялото денонощие нямаше един грешен пакет. Кабела ми е грубо някъде 1,5 - 2 метра а от FTDI do ATmega имам някъде около 60 см свободно висящ кабел като включително и масата е така висяща. И сметнах че връзката е доста надежна и не е необходимо CRC, затова и оставих обикновенна контролна сума. А дължината на буфера на командата изходих не само от опростяване на протокола. На практика се явява че трябва данните обикновенно да се зареждат в буфер в RAM паметта. Но дори да се ползва АТmega128 рама е 3кб. Просто няма място за по голям буфер. Ако се прехвърлят повече данни накуп то това се прави в съответствие с това откъде вземаш и къде пращаш. А в такъв случаи е по удачно да се ползват различни процедури в зависимост от случая затова и метода Sent Data Package e по удачен от голям буфер в самата команда.

А дори да оставим настрана негативизма които Microchip е създала около произведенията си все пак пика не може да замени двуканалния FTDI. С него няма да има директна връзка с FPGA-to. А за драйвера на Микрочип имам много съмнения доколко ще работи като хората. А който вече се е разправял с драивера на FTDI вече знае че забележки по него няма. Отработили са го хората.
А и за АТмега имам вече готова настроена и изтествана опашка от задачи и още някои неща които са си нещо като операционна система,имам направени библиотека за комуникация,библиотека за работа с цветния LCD ot Ericson. BrianStorm беше казал че е готов с библиотеката за зареждане на ядрото в Спартана от серииния флаш. Освен това имам доста дребни и полезни библотечки пак за АТмегата. Това хич не е малко работа която е свършена. Дори с това дето е написано процесорния модул може вече да си работи.

Abre az principno s bibliotekata o6te ne sym gotow ... taka i ne izqhnihte kwi funkcii to4no iskate .... rabotata e 4e uspqh da probwam procesa sys zarezdaneto na qdroto koeto e i cqlata rabota .... natam si e samo 10-20min pred kompa ...

Abre gledam 4e ste po4nali tuka protokoli da mislite ..... ima li smisyl da se prawi towa ne tozi etap ... ?

Daite pyrwo da spretnem okon4atelniq wariqnt na shemata i da po4nem s iz4ertawaneto na PCB'to ... taka de ako 6te pi6eme soft .. pone da znaem ot kakwo 6te se systoi zelqzoto ..... (PS sori za latinicata .. ama na teq kompowe w TU't nqma FlehType ..... )

Nikola, за PIC18F4550 нямах в предвид да ползваме наготово драйвери от сайта на Microchip Идеята ми беше по скоро за USB device със повече контрол... PIC-a има хардуерен PSP (Paralell Slave Port), SPI и I2C, една камара I/O-та и възможност за по-голям буфер за разлика от FTDI чиповете. Казвам го като идея Верно си падам малко мазохист