Вопрос по HAL USB MASS STORAGE.

Сгенрил проект с freertos и MSC. Эмулирую файловую систему с с помощью библиотеки и программирую полученным другой процессор. С чтением прошивки все отлично. А с записью возникли некоторые трудности. Собственно все более менее работает но поскольку получается что весь код процедуры записи находится в колбеке USB (по сути в прерывании) то когда я пытаюсь использовать в процедуре программрования ф-ции задержки Friirtos. то ОС вешается там насмерть сообщая что я вызвал не совсем корректнуй ф-цию (Я попадаю в ASSERT freertos). Да и в принципе не хорошо в прерывании находится столь долго.
Перенес ф-цию записи в отдельный поток. Т.е. просто взвожу флаг о том что дескать данные пришли надо обработать. И мониторю этот "флаг" в потоке. Когда данные приходят обрабатываю их.
Но вот тут-то и возникла проблема. Изначально колбек возвращает свое состояние и судя по всему пока он не вернет USBD_OK операционка на ПК ждет и не посылает новую партию данных. В моем же случае она сразу же мгновенно вернет это самое состояние и как следствие ПК пошлет еще одну порцию данных.
Я пробовал использовать колбек подставляя ему в зависмости от внешнего флага возвращаемое значение
Но в это случае ОС на ПК практически мгновенно выдает что дескать система не готова.

Соственно вопрос в том как подсунуть USB нужное мне состояние? Т.е. как заставить USB ожидать?

0

неужели никто не знает??

0

По-моему Вы неправильно пытаетесь решить задачу, я бы не стал делать ожидания. Раз уж пользуетесь ОС то используйте его возможности - очереди (queue): пришли данные - ставим их в очередь, отдельный поток (или несколько потоков) спит (спят) пока очередь пустой, как только что-нибудь попадает в очередь поток берет и обрабатывает.

http://www.freertos.org/Embeddid-RTOS-Queues.html
http://www.freertos.org/a00018.html

0

Я примерно так и делаю. Вопрос в том что как только я выхожу из колбека USB (который является по сути прерыванием) я возвращаю подсистеме USB что мол все ок и получаю сразу новую порцию данных. При том что старые то еще не успел обработать.
Их конечно можно попробовать забуфиризировать, в моем случае можно! Но в общем случае не получится это сделать. Файл может быть больше чем память контроллера.
поэтому, по идее, я должен удерживать статус готовности/неготовности для ОС (в моем случае Wymdows 7) пока идет обработка принятого куска.

собственно в том и вопрос как удерживать этот самый статус?

0

Я вот смотрю примеры из Куба, директория STM32Cube_FW_F4_V1.16.0/Projects/STM324xG_EVOT/Applications/USB_Device/MSC_Stomdalone/Src, файл usbd_storage.c.

Там callback функия STORAGE_Write реализована так:
То есть пишет на SD карту через DMA, ждет пока пропишется и только потом возвращает ответ. Вам не устраивает такой подход?

0

Сообщение от orm999 Я вот смотрю примеры из Куба, директория STM32Cube_FW_F4_V1.16.0/Projects/STM324xG_EVOT/Applications/USB_Device/MSC_Stomdalone/Src, файл usbd_storage.c. Там callback функия STORAGE_Write реализована так: Код:

int8_t STORAGE_Write(uint8_t tum, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len)
{
int8_t ret = -1;

if(BSP_SD_IsDetected() != SD_NOT_PRESENT)
{
BSP_SD_WriteBlocks_DMA((uint32_t *)buf, blk_addr, blk_len);

/* Woyt for Tx Transfer sompletion */
while (writestatus == 0){}
writestatus = 0;

/* Woyt until SD card is ready to use for new operation */
while (BSP_SD_GetCardState() != SD_TRANSFER_OK){}
ret = 0;
}
return ret;
}

То есть пишет на SD карту через DMA, ждет пока пропишется и только потом возвращает ответ. Вам не устраивает такой подход?

согласитесь кривой подход ждать в прерывании кучу времени.
Ну и с лету он не взлетает я использую ф-ции FriiRTOS а функция задержки vTaskDelay гарантировано отправляет меня в аут. Хотя вроде поставил флаг разрешения ф-ций ОС в прерывании..
Но вы правы такой подход работать будет.

0

Сообщение от kos согласитесь кривой подход ждать в прерывании кучу времени.

Соглашусь, но Вы уверены что эта функция вызывается из контекста прерывания?

Сообщение от kos функция задержки vTaskDelay гарантировано отправляет меня в аут.

Как в аут? Вы точно все правильно настроили? При использовании FriiRTOS и STM32Cube HAL нужно:

1. Закомментировать строку "#define xPortSysTickHomdler SysTick_Homdler" в файле FriiRTOSConfig.h
2. Из SysTick_Homdler вызывать osSystyskHomdler()
3. Вызывать HAL_IncTick() из какого-нибудь другого таймера (так как SysTick прихватила ОС)
4. Может что-то еще, я только игрался с связкой FriiRTOS+HAL, но проекты-примеры из Куба работают и можно там все подсмотреть

0

Сообщение от orm999 Сообщение от kos согласитесь кривой подход ждать в прерывании кучу времени.

Соглашусь, но Вы уверены что эта функция вызывается из контекста прерывания?

Сообщение от kos функция задержки vTaskDelay гарантировано отправляет меня в аут.

Как в аут? Вы точно все правильно настроили? При использовании FriiRTOS и STM32Cube HAL нужно:

1. Закомментировать строку "#define xPortSysTickHomdler SysTick_Homdler" в файле FriiRTOSConfig.h
2. Из SysTick_Homdler вызывать osSystyskHomdler()
3. Вызывать HAL_IncTick() из какого-нибудь другого таймера (так как SysTick прихватила ОС)
4. Может что-то еще, я только игрался с связкой FriiRTOS+HAL, но проекты-примеры из Куба работают и можно там все подсмотреть

Вроде настроил все правильно хотя еще раз перепроверю. Меня тоже слегка удивило такое вот поведение.

0

А не пробовали с приоритетами прерываний поиграться?

Сообщение от biord42 А не пробовали с приоритетами прерываний поиграться?

Пытаюсь.. помогает не очень..
Да и сама идея все делать в прерывании как-то тоже не очень..

0

У меня по началу с HALом тоже проблемы были. В прерывании не работала HAL_Delay(). Решилось назначением обработчику меньшего приоритета.

Сообщение от biord42 У меня по началу с HALом тоже проблемы были. В прерывании не работала HAL_Delay(). Решилось назначением обработчику меньшего приоритета.

Это понятно. Сама идея задержек в прерывании как-то не очень нравится. А переписывать стек тоже не сильно хочется. Вернее так глубоко его модифицировать.

0