[AlexandrY 3]

есть лицензия, которая запрещает использовать MQX где-то кроме фрискейловских процов.

MQX идет с лицензией разрешающей ее использование только на чипах от NXP.

Также нельзя публиковать исходники MQX от своего имени. Но модифицировать и делиться ими можно.

 

[Kabdim 0]

The license agreement from NXP only permits distribution of the provided code in object form only, and only if that object code is integrated into a physical device that contains an NXP processor. Насчет делится загнули как-то. В общем не отрицая положительных качеств MQX стоит заметить что на нём стоит вендорлок.

[AlexandrY 3]

The license agreement from NXP only permits distribution of the provided code in object form only, and only if that object code is integrated into a physical device that contains an NXP processor. Насчет делится загнули как-то. В общем не отрицая положительных качеств MQX стоит заметить что на нём стоит вендорлок.

Вы логику включите.

У них форум есть с обсуждением комьюнити версии MQX. Они там ее модифицируют как хотят. Как они это делают не делясь исходниками?

А также эта фраза говорит, что скомпилированные библиотеки под чипы NXP с MQX могут выкладываться свободно.

А привязка к узкому семейству чипов это даже хорошо, не будет ненужных веток и фрагментации.

[Шаманъ 0]

У меня тоже - почти всё своё :rolleyes: Кроме RTOS разве что. Хотя и к ней тоже порт - свой, ну ещё кой-какие её корректировки.

А так и USB-device (когда нужен) - свой, и TCP-стек - свой, и графические библиотеки - тоже свои, о математике и прочих фильтрах и не говорю... :laughing:

Ну и правильно :)

 

Это как я понимаю - массивы указателей на обработчики? Они у Вас во флешь или интерактивно в runtime-е в ОЗУ создаются?

Нет, макросы разворачиваются прямо в код из цепочки if/else и выховы функций без использования указателей.

 

У меня тоже так же сделано. Только имена макросов другие :rolleyes:

:)

 

Видите, вы даже толком не можете описать "своё"

Потому что документацию на него не делали, а API ваше фрагментарное и архаичное. Небось и полного тестирования не делали, и даже профайлинга.

Такого недокументированного всеми забытого добра на гитхабе тоннами лежит.

Ну вот еще один пуп вселенной, которому все должны - проходите мимо, я Вас не задерживаю. И да продолжайте хамить - сразу видно, что на другое не способны...

[Kabdim 0]

У них форум есть с обсуждением комьюнити версии MQX. Они там ее модифицируют как хотят. Как они это делают не делясь исходниками?

То что они не собираются наказывать своё комюнити, в тех случаях когда они считают нарушения незначительными это одно. А вы, к примеру, выкладывая что-то завязанное на MQX на тот же гитхаб - нарушаете лицензию, это другое. Поймите нет второго сорта лицензионной чистоты, когда вы почти "соблюдаете" лицензию. Либо ваш продукт белый в плане лицензий, либо он их нарушает и вы находитесь из-за этого в зоне риска. Это как с электриками которые нарушают ТБ - не все сталкиваются с последствиями своих нарушений, но это не значит что так поступать правильно.

А привязка к узкому семейству чипов это даже хорошо, не будет ненужных веток и фрагментации.

Ммм, давайте не будем называть недостатки достоинствами? :)

[AlexandrY 3]

Это как с электриками ...

 

Ммм, давайте не будем называть недостатки достоинствами? :)

При чем тут электрики если вы плохо поняли лицензию.

Вот у меня выложен стек USB.

Абсолютно лицензионно чисто.

 

А недостатком привязка возможно была до того как объявили о i.MX RT. А теперь это только достоинство.

 

Ну вот еще один пуп вселенной, которому все должны - проходите мимо, я Вас не задерживаю. И да продолжайте хамить - сразу видно, что на другое не способны...

Уважаемый, если вы тут хотите продавать, то что лежит бесплатно на каждом углу, то имейте совесть. И не флудите в форуме.

[linuxbergi 0]

Нате, глумитесь.

Премного благодарен! Многая лета.

 

В книге 'Making Embedded systems' описывается шаблон программирования МК под названием 'драйвер', ну это так.

Залез в USB-FS-Device_Lib_V4 и ужаснулся, мрачное нагромождение файлов и не понятно по какому принципу.

Меня интересовало как можно подойти к проблеме.

 

Общая схема, два конечных автомата, один автомат отвечает за переходы между состояниями USB устройства, а второй за сборку управляющих запросов из отдельных транзакций. После сборки сообщения , передаётся первому автомату и служит событием, которое может изменить его состояние. Когда смоделировать поведение устройства оказывается затруднительным одним автоматом, то оказывается просто смоделировать несколькими конечными автоматами, взаимодействующими друг с другом передачей сообщений.

 

 

 

Но при ближайшем рассмотрении выяснилось, что обработку управляющих запросов от хоста невозможно представить одним конечным автоматом. Схема сложней. После выполнения транзакции SETUP нужно раскодировать конфигурационный пакет. По результатам расшифровки выбирается один из некоторого множества конечных автоматов, отражающий запрос. Ниже граф переходов для запроса GET_DESCRIPTOR c несколькими стадиями данных. Транзакции выполняются аппаратурой автоматически, по результатам выполнения выставляют флаги. Хост инициирует тр. setup, из сост. I переходит в S, готовит буфер USB для следующей транзакции от хоста и т.д.

 

[Шаманъ 0]

Уважаемый, если вы тут хотите продавать, то что лежит бесплатно на каждом углу, то имейте совесть. И не флудите в форуме.

Уважаемый, тут нет покупателей, чтобы что-то продавать ;)

Да и кому продавать у меня есть, как пример, на применение моей RTOS были куплены эксклюзивные права вместе с поддержкой-сопровождением одной не нашей конторой, которая с ней выпускает девайсы тиражем несколько десятков тысяч в год (видимо на каждом углу у них не получилось найти :laughing: ), так что вопрос продаж меня совсем не волнует, уж поверьте...

Изменено 7 августа, 2017 пользователем Шаманъ

[linuxbergi 0]

И ещё вопрос для специалистов. Могут ли быть вложенными управляющие передачи? Например, началась передача setup и не завершая её хост начинает новую? Из разных источников разные ответы, по-моему полная ерунда. То что хост может внезапно закончить начатаю передачу, это знаю. А вот вложенные передачи? Тогда нужно складывать контекст. Да и какой максимальный уровень вложенности? В "USB complete" написано что вроде как могут быть вложенные.

[Kabdim 0]

Абсолютно лицензионно чисто.

В то что вы так заблуждаетесь я охотно верю. Но с учетом того что я вам привел разъяснения представителя правовладельца, который черным по белому написал что так лицензия не разрешает, на мой взгляд, ваша убежденность в собственной правоте явно сильнее чем должна бы быть.

На этом позвольте откланяться.

[AlexRayne 7]

покурите библиотеки libopencm3, unicore-mx (клон) - может и не понадобится вам пилить свою обертку

[prottoss 0]

При чем тут...

Я попрошу Вас, как модератора, не флудить в ветке! Вы не одного поста по теме не написали... Как обычно, в прочем.

 

 

Но при ближайшем рассмотрении выяснилось, что обработку управляющих запросов от хоста невозможно представить одним конечным автоматом. Схема сложней...

Заблуждаетесь. Совершенно один конечный автомат.

У меня описан вот так:

/* Control transfer states */
typedef enum __USBD_CTRL_STATE
{
    USBD_CTRL_STAGE_SETUP,                    /* SETUP packet */
    USBD_CTRL_STAGE_DATA_OUT,                /* OUT data packet */
    USBD_CTRL_STAGE_DATA_IN,                /* IN data packet */
    USBD_CTRL_HANDSHAKE_ZLP_IN,                /* The handshake IN ZLP packet was sent */
    USBD_CTRL_WAIT_HANDSHAKE_ZLP_OUT,         /* Wait a OUT ZLP packet */
    USBD_CTRL_STALL_REQ,                     /* STALL enabled on IN & OUT packet */
    
} USBD_CTRL_STATE, *P_USBD_CTRL_STATE;

 

 

И ещё вопрос для специалистов. Могут ли быть вложенными управляющие передачи? Например, началась передача setup и не завершая её хост начинает новую? Из разных источников разные ответы, по-моему полная ерунда. То что хост может внезапно закончить начатаю передачу, это знаю. А вот вложенные передачи? Тогда нужно складывать контекст. Да и какой максимальный уровень вложенности? В "USB complete" написано что вроде как могут быть вложенные.

На чем я учился - во вложении.

Вложенных передач нет. Есть стэйт машина, любой шаг влево-вправо - сброс.

usb_in_a_nutshell.pdf

[ViKo 1]

Есть книга:

Михаил Гук. Шины PCI, USB и FireWare

В ней хорошо описана работа USB.

[prottoss 0]

В конечном счете примерная схема взаимодействия (у меня):

Обязанности драйвера USb периферии:

1. Обеспечение инициализации периферии USB устройства. Сюда не входит инициализация тактовых частот и портов ВВ. Этим занимаются целевые драйвера МК.

2. Обеспечение отключения периферии USB.

3. Обеспечить подключение устройства к шине. В основном это возможность отключить/подключить встроенный пулл-ап резистор (если имеется) и дополнительная инициализация модуля USB-

устройства (если требуется).

4. Вызов библиотеки верхнего уровня (для энумерации устройства и специфичных для класса вызовов) через ТРИ вызова (SETUP, DATA IN, DATA OUT).

5. Предоставлениеотдельного интерфейса для ЕР0.

4. Обеспечить корректную установку адреса устройства. В разных семействах МК есть нюансы при установке адреса устройства.

4. Предоставление приложению интерфейса прямого ввода вывода через конечную ЕР.

5. Возможность, если требуется, дополнительных обработчиков типа Resume, Suspend и т.п. и связи их с приложением.

 

Обязанности библиотеки:

1. Надежная стэйтмашина через три вызова от драйвера (SETUP, DATA IN, DATA OUT).

2. Возможность подключения обработчиков запросов от специфических классов.

 

 

[prottoss 0]

При чем тут электрики если вы плохо поняли лицензию.

Вот у меня ... выложен стек USB

Это не стек. Это няшные хидеры