Comments 8
надеюсь через какое-то время они поправят у себя для всех веток контроллера, а не только L4
Года 3 назад, пришлось работать с CAN на L4.Работа какоето время шла нормально, потом CAN пересталал отвечать и ошибкой вызова всех CAN функций HAL. Копание кода показало, что при определнных условиях не было осовбожения аналога мутекса. Полез искать оказалось для семейсфа F ошибка давно найдена и регена. А для L они не стали глядеть, хотя код был по сути копией от F.
Может сейчас чтото поменялось, но я бы сильно не рассчитывал.
По обнаруженным ошибкам сделан Pull Request в официальный репозиторий ST, надеюсь через какое-то время они поправят у себя для всех веток контроллера, а не только L4.
Вот за это - большое человеческое спасибо.
Но библиотеки ST не идеальны и видимо не проходят должного тестирования функционала.
Вы чрезвычайно сдержанны в выражениях.
Одним лишь ST дело тоже не ограничивается. Если у вас популярная аппаратная платформа и есть возможность свободно выбрать ОС, есть смысл использовать что-то вроде NuttX/Zephyr/ChibiOS, где необходимая функциональность может быть доступна из коробки, и в отличие от софта от вендоров МК их код обычно всё-таки работает.
В статье говориться
-ТСЯ
По приведенным портянкам текста кажется что в библиотеке от ST исправлять нужно больше, чем полный объем моей реализации :)
Еще заинтересовала фраза что «нельзя задать LUN больше 8» — решил проверить. Нет, до 15 видит спокойно и без всяких плясок с бубном. Первый раз в жизни видел диск /dev/sdr. Надо еще в винду эту штуку подключить посмотреть что с ней станет
Еще заинтересовала фраза что «нельзя задать LUN больше 8» — решил проверить. Нет, до 15 видит спокойно и без всяких плясок с бубном. Первый раз в жизни видел диск /dev/sdr. Надо еще в винду эту штуку подключить посмотреть что с ней станет
ST-ная библиотека излишне раздута…
В linux больше 8 LUN — просто игнорирует не опрашивая.
Дистрибутив: Debian 11.0
Ядро: 5.10.0-8-amd64
Ни скармливание ядру, ни модулю options scsi_mod max_luns=255 не помогает. Как вы побороли данную проблему?
В 7 и 10 винде все 16 LUNs открылись достаточно быстро, секунд за 10. Обновил статью, приложив скрины.
Длинные портянки кода под спойлер убрал, чтобы читалось удобнее
В linux больше 8 LUN — просто игнорирует не опрашивая.
Дистрибутив: Debian 11.0
Ядро: 5.10.0-8-amd64
Ни скармливание ядру, ни модулю options scsi_mod max_luns=255 не помогает. Как вы побороли данную проблему?
В 7 и 10 винде все 16 LUNs открылись достаточно быстро, секунд за 10. Обновил статью, приложив скрины.
Длинные портянки кода под спойлер убрал, чтобы читалось удобнее
Debian 10 (кажется), ядро 5.6.0-2-amd64, все 16 LUN работают из коробки. Я только из статьи узнал что где-то бывают подобные проблемы.
Такое количество «флешек» в диспетчере файлов смотрится довольно дико.
… я почти хочу проверить что будет, если сделать дисков больше, чем букв, как именно операционки на это отреагируют…
В 7 и 10 виндеДобавлю что на winXP тоже определяются все 16, правда довольно медленно.
Такое количество «флешек» в диспетчере файлов смотрится довольно дико.
… я почти хочу проверить что будет, если сделать дисков больше, чем букв, как именно операционки на это отреагируют…
Огромное спасибо за ваш код, сделал 2 диска, LUN_NUM_EEPROM is WriteProtected
int8_t STORAGE_IsWriteProtected_FS(uint8_t lun)
{
switch(lun)
{
case LUN_NUM_MICROSD:
return (USBD_OK);
case LUN_NUM_EEPROM:
return (USBD_BUSY);
default:
return (USBD_FAIL);
}
}
несмотря на это, в
static int8_t SCSI_ModeSense6(USBD_HandleTypeDef *pdev, uint8_t lun, uint8_t *params)
проверка
/* Check If media is write-protected */
if (((USBD_StorageTypeDef *)pdev->pUserData)->IsWriteProtected(lun) == 1)
{
MSC_Mode_Sense6_data[2] |= 0x80;
}
срабатывает для обоих (для lun=LUN_NUM_MICROSD и для lun=LUN_NUM_EEPROM) и
WIndows 7 запрещает писать на оба диска, полечил костылем:
if(lun==0)
{
MSC_Mode_Sense6_data[2] &= 0x7f;
}
Windows теперь разрешает запись на LUN_NUM_MICROSD и запрещает на LUN_NUM_EEPROM
но как сделать это корректно не знаю :(Sign up to leave a comment.
USB Mass Storage BOT чиним multi LUN у STM32