STM32 и USB (практика)

[VladislavS]

Причём тут вообще операционная система? Правильно спроектмрованное устройство в 23-м году воткнул и работай себе. Ну, разве что, в линуксе с бубном поплясать ещё надо, но всё равно должно работать.

[COKPOWEHEU]

Потому что винда это правильно спроектированное устройство не видит. Что самое забавное - виртуальные видят нормально, а вот реальные - нет.
И это еще не говоря про неправильно спроектированное устройство, которое винду вообще в BSOD отправить может.
А что за пляски с бубном вы на линуксе нашли? А то я что-то никогда необходимости в них не испытывал. Все как обычно: в линуксе работает, в винде проблемы на ровном месте.

[azhel12]

COKPOWEHEU писал(а):

винду вообще в BSOD отправить может

Устройство не может винду в BSOD отправить, только драйвер, то есть претензии к разработчику драйвера нужно предъявлять.

[VladislavS]

COKPOWEHEU писал(а):

Потому что винда это правильно спроектированное устройство не видит.

Что, даже дескрипторы не считывает? Ох уж мне эти сказки.

COKPOWEHEU писал(а):

Что самое забавное - виртуальные видят нормально, а вот реальные - нет.

Ох уж мне эти сказочники.

COKPOWEHEU писал(а):

И это еще не говоря про неправильно спроектированное устройство, которое винду вообще в BSOD отправить может.

Ни чё се...

COKPOWEHEU писал(а):

А что за пляски с бубном вы на линуксе нашли?

Из последнего. Драйвер мохи не ставился пока в BIOS не отключили Secure Boot.

COKPOWEHEU писал(а):

А то я что-то никогда необходимости в них не испытывал.

А ничего удивительного. Постоянное топтание терминала у вас уже за норму идёт.

COKPOWEHEU писал(а):

Все как обычно: в линуксе работает, в винде проблемы на ровном месте.

Вместо того чтобы просто вставил и работай.

[JackSmith]

VladislavS писал(а):

А ничего удивительного. Постоянное топтание терминала у вас уже за норму идёт.

Что вы под этим имеете в виду?

[COKPOWEHEU]

azhel12 писал(а):

Устройство не может винду в BSOD отправить, только драйвер, то есть претензии к разработчику драйвера нужно предъявлять.

В данном случае я говорю о внешнем проявлении. Устройство с криво прописанным дескриптором отправляло старые винды в синий экран. Что именно ломалось в винде - штатные драйвера, система его подгрузки, система чтения дескрипторов - не знаю.

Что, даже дескрипторы не считывает? Ох уж мне эти сказки.

При чем здесь дескрипторы? Я говорю, что устройство под ней не работает. Все дескрипторы стандартные, но вот "неизвестное устройство" и все тут. Возможно, как раз что тут описывали - неудачно выбрал VID:PID. Хотя уж на эту-то пару (от vusb) ничего сверхъестественного зарезервировано быть не должно.

А ничего удивительного. Постоянное топтание терминала у вас уже за норму идёт.

Вы так говорите будто умение использовать инструмент по прямому назначению является чем-то постыдным. Или вы предпочитаете одноклеточное возюканье мышью, когда элементарная задача растягивается на часы?

Вместо того чтобы просто вставил и работай.

Именно! Казалось бы, USB, стандартный интерфейс, в устройстве реализованы исключительно стандартные функции, вставил и работай. Но винда явно не про это...

[VladislavS]

COKPOWEHEU писал(а):

При чем здесь дескрипторы? Я говорю, что устройство под ней не работает.

Нет. Вы написали именно "не видит". Под "не видит" я понимаю - вставил и ничего не произошло. Как будто и не вставлял.

COKPOWEHEU писал(а):

Все дескрипторы стандартные, но вот "неизвестное устройство" и все тут. Возможно, как раз что тут описывали - неудачно выбрал VID:PID. Хотя уж на эту-то пару (от vusb) ничего сверхъестественного зарезервировано быть не должно.

То есть, ваше творчество, а виновата операционка. Ясно, понятно.

COKPOWEHEU писал(а):

Вы так говорите будто умение использовать инструмент по прямому назначению является чем-то постыдным.

Умение - похвально. Требование постоянно им пользоваться - нет.

COKPOWEHEU писал(а):

Или вы предпочитаете одноклеточное возюканье мышью, когда элементарная задача растягивается на часы?

Предпочитаю вообще ничего не делатью, просто вставить и пользоваться. И потом, вы мышей боитесь что-ли?

COKPOWEHEU писал(а):

Казалось бы, USB, стандартный интерфейс, в устройстве реализованы исключительно стандартные функции, вставил и работай. Но винда явно не про это...

Как раз про это. Количество и квалификация среднестатистического пользователя как раз это подтверждают. Если бы было наоборот, большинство бы красноглазило.

Добавлено after 25 minutes 51 second:
Из последнего. Изделие управляется по RS-485 через USB-шную моху. Программист пишет на питоне, так что работает и на винде, и на линухе.

На винде программист: установил драйвер с сайта производителя, сконфигурировал режим работы в 2-проводный. В дальнейшем втыкаешь в любой порт и всё работает сразу.

На линуксе тот же программист: пару дней пытался поставить драйвер, пока не допёр отключить Secure Boot. Затем каждое втыкание - устройство несконфигурировано и под непредсказуемым номером. Идёшь в терминал, смотришь под каким именем оно появилось (методом передёргивания, так как там ещё похожие устройства есть), задаёшь права доступа, задаёшь режим работы порта. И только теперь можно запустить прикладную программу.

Мне работать, а не джедайские умения демонстрировать.

[COKPOWEHEU]

VladislavS писал(а):

Нет. Вы написали именно "не видит". Под "не видит" я понимаю - вставил и ничего не произошло.

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

То есть, ваше творчество, а виновата операционка. Ясно, понятно.

Да, то есть "мое творчество" работает, но винда капризничает.
Я такое еще на эмуляции MSD видел, она какой-то экзотический запрос пыталась отправить и в упор игнорировала, что этот "необязательный запрос не поддерживается".

Умение - похвально. Требование постоянно им пользоваться - нет.

Опять странный вопрос. Если вы взаимодействуете как пользователь, необходимости в консоли практически нет (тут мне трудно оценить). Если как админ или разработчик, то, естественно, есть. Как иначе с низкоуровщиной взаимодействовать-то?

Предпочитаю вообще ничего не делатью, просто вставить и пользоваться. И потом, вы мышей боитесь что-ли?

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

На линуксе тот же программист: пару дней пытался поставить драйвер, пока не допёр отключить Secure Boot. Затем каждое втыкание - устройство несконфигурировано и под непредсказуемым номером. Идёшь в терминал, смотришь под каким именем оно появилось (методом передёргивания, так как там ещё похожие устройства есть), задаёшь права доступа, задаёшь режим работы порта. И только теперь можно запустить прикладную программу.

Какие-то очень странные телодвижения, абсолютно нехарактерные для линукс-подохода. Даже если устройство действительно настолько кривое, как вы описываете... Что, udev еще не изобрели?
Вас так огорчает, что железка, не предназначенная для прямого взаимодействия с пользователем, внезапно, ему недоступна? Ну так если хочется прямого доступа, так прописывайте права, группы и что вам там еще надо.
---
Кстати, на тему udev и "под неизвестным номером" - очень удобно, когда при втыкании переходника появляется не безликий COM38, а, например, /dev/tty_ft232_0 или, скажем, /dev/tty_DBG_0. В винде вообще возможно при подключении устройства выполнять какие-то действия с ним - создать ссылку с осмысленным именем, выставить права доступа, указать специальный драйвер, просто скрипт запустить?

Мне работать, а не джедайские умения демонстрировать.

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

[VladislavS]

Одна и та же программа в винде просто работает, а в линуксе какие-то строчки писать надо. Тем более, я просто пользователь этого рабочего места. Мне не интересно играть в админа, мне работать...

[JackSmith]

Не Linux это вещь. Надо пересобрать openocd с патчем на новый неведомой чип - пожалуйста. Нужна какая-то тулза с гитхаба - набираешь make и пожалуйста. Тут помню, год назад народ выл, что инсталятор кьют перестал работать в России. В Linux ВСЕ РАБОТАЕТ.

[VladislavS]

JackSmith писал(а):

Надо пересобрать openocd с патчем на новый неведомой чип - пожалуйста.

Гладко было на бумаге. Берём обычный CH32V. Под win есть, а под linux Харитонова Ульяна Ивановна.

[JackSmith]

Да есть софт который только для винды. Кидаю его в виртуалку и запускаю оттуда. Не вижу в этом проблем. Если очень приспичит, поставлю cygwin, протяну в тунель по ssh, и буду работать из привычной среды а не в окошке винодуз.

[COKPOWEHEU]

VladislavS писал(а):

Одна и та же программа в винде просто работает, а в линуксе какие-то строчки писать надо. Тем более, я просто пользователь этого рабочего места. Мне не интересно играть в админа, мне работать...

У вас есть программа, криво портированная на линукс (без учета особенностей ОС), и вы удивляетесь, что она плохо работает. Претензии к писателю программы, раз он не может не то что автоматизировать настройку, но хотя бы инструкцию приложить. И еще раз: скорее всего ограничение, из-за которого вам приходится явным образом разрешать опасное действие - логично.
---
На вопрос о назначении осмысленных имен и прочей логики вы предпочли скромно промолчать...

Гладко было на бумаге. Берём обычный CH32V. Под win есть, а под linux Харитонова Ульяна Ивановна.

Фига себе обычный... Он хотя бы под виндой научился через сторонние программаторы прошиваться?

[VladislavS]

COKPOWEHEU писал(а):

У вас есть программа, криво портированная на линукс (без учета особенностей ОС),

Никто ничего никуда не портировал. Программа на питоне писана, ей всё равно где работать. Фантазии про портирование оставьте при себе.

COKPOWEHEU писал(а):

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

К программисту никаких претензий. Инструкцию, как вы и хотите, он приложил. Начинается она с "открыть терминал...".

COKPOWEHEU писал(а):

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

Ну конечно же, чтобы изменить режим работы RS-485 - без рута не подходи. Забористая трава.

COKPOWEHEU писал(а):

На вопрос о назначении осмысленных имен и прочей логики вы предпочли скромно промолчать...

Да не хотел избивать младенца. Достаточно сравнить имя в диспетчере устройств "Uport-1050 serial port COMx" с "/dev/ttyUSBx".

COKPOWEHEU писал(а):

Фига себе обычный...

Да, а что в нём необычного? Многие уже с ними успешно работают.

COKPOWEHEU писал(а):

Он хотя бы под виндой научился через сторонние программаторы прошиваться?

Он под виндой прошивается и отлаживается через OpenOCD, а
под линуксом - национальная индейская изба. Покажете обратный пример?

[COKPOWEHEU]

VladislavS писал(а):

Никто ничего никуда не портировал. Программа на питоне писана, ей всё равно где работать.

Ага, ага. А если бы там еще и абсолютные пути использовались вроде /home/user/..., тоже бы говорили что "все равно где работать". Запускается != работает.

К программисту никаких претензий. Инструкцию, как вы и хотите, он приложил. Начинается она с "открыть терминал...".

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

Ну конечно же, чтобы изменить режим работы RS-485 - без рута не подходи. Забористая трава.

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

Достаточно сравнить имя в диспетчере устройств "Uport-1050 serial port COMx" с "/dev/ttyUSBx".

Где его посмотреть, а главное - как его указать в программе? Я же не буду каждый раз при подключении залезать в диспетчер устройств, перебирать полдюжины COM-портов и переписывать номер.
С тем же /dev/tty_DBG_0 никаких проблем нет, это именно что ссылка на какой-нибудь /dev/ttyACM2, его можно передавать в качестве имени порта в тот же screen, или в fopen, или куда угодно еще.

Он хотя бы под виндой научился через сторонние программаторы прошиваться?

Он под виндой прошивается и отлаживается через OpenOCD, а
под линуксом - национальная индейская изба. Покажете обратный пример?

Вы не ответили на вопрос.
Когда я пытался с CH32V307 работать, корректно это не выходило нигде. В виндовсе была только графическая утилита, которая умела прошивать по UART и падала три запуска из четырех, под линуксом попробовал openocd, не нашел конфига под программатор ft2232 (с теми, которые нашел, не заработало) и отложил пока.
Моих познаний для реверса этого поделия недостаточно. Надо или ждать пока openocd все-таки допилят (что вряд ли), или искать обходные пути вроде того же загрузчика, вроде какие-то утилиты были, и даже с исходниками. Но это нужно очень плотно засесть.
---
Так что не уходите от ответа: научился ли CH32 нормально прошиваться через сторонние программаторы или все еще вендор-лок?

[VladislavS]

COKPOWEHEU писал(а):

Ага, ага. А если бы там еще и абсолютные пути использовались

Если бы у бабушки были...

COKPOWEHEU писал(а):

Вы не ответили на вопрос. Когда я пытался с CH32V307 работать, корректно это не выходило нигде.

Собственно что и требовалось доказать. А тем кому надо работать давным давно отлаживают и прошивают.

COKPOWEHEU писал(а):

Так что не уходите от ответа: научился ли CH32 нормально прошиваться через сторонние программаторы или все еще вендор-лок?

Открою вам тайну - он прошивается вообще без программатора через USB или UART. Только никому, ладно?

[COKPOWEHEU]

VladislavS писал(а):

Если бы у бабушки были...

Вот "если бы", тогда бы и можно говорить про полную кроссплатформенность. А так - "вроде кое-как работает, сойдет".

графическая утилита, которая умела прошивать по UART
...
или искать обходные пути вроде того же загрузчика, вроде какие-то утилиты были, и даже с исходниками. Но это нужно очень плотно засесть

Открою вам тайну - он прошивается вообще без программатора через USB или UART. Только никому, ладно?

Вау, вот так тайна! Что бы я делал без этой информации!

А тем кому надо работать давным давно отлаживают и прошивают.

Да, тем, для кого подобное - работа, вынуждены терпеть и кривые дрова, и непривычные среды, и наркоманские гайды по оформлению кода, и много чего другого.
Любители могут себе позволить быть более разборчивыми.

Да не хотел избивать младенца. Достаточно сравнить имя в диспетчере устройств "Uport-1050 serial port COMx" с "/dev/ttyUSBx".

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

[azhel12]

Всем привет, вмешаюсь в вечный спор Windows/Linux за советом по поводу USB (хотя не могу не поучаствовать, год как сижу на связке Windows + WSL2)

Отлавливаю в библиотеке UB, так как добавление опции flto ломает прохождение нумерации, что в целом более чем ожидаемо, потому как в конструкции switch-case у меня локальные переменные, которые я отправляю хосту. Всё, что меньше макс.размера пакета, отправляется почти нормально, но с большими объемами начинаются проблемы, например, отправка дескриптора конфигурации.

Сейчас код выглядит примерно так, и это, очевидно, плохой код:

Код:

switch (static_cast<GetDescriptorParameter>(setupRequest->Value)) {
  case GetDescriptorParameter::DeviceDescriptor: {
    DeviceDescriptor tempDeviceDescriptor;
    FillDescriptor(&tempDeviceDescriptor);
    _Ep0::SendData(&tempDeviceDescriptor, setupRequest->Length < sizeof(DeviceDescriptor) ? setupRequest->Length : sizeof(DeviceDescriptor));
    break;
  }

  case GetDescriptorParameter::ConfigurationDescriptor: {
    uint8_t temp[128];
    // Now supports only one configuration. It will easy to support more by adding dispatcher like in endpoint/interface
    uint16_t size = _configurations.template get<0>().FillDescriptor(reinterpret_cast<ConfigurationDescriptor*>(&temp[0]));
    _Ep0::SendData(reinterpret_cast<ConfigurationDescriptor*>(&temp[0]), setupRequest->Length < size ? setupRequest->Length : size);
    break;
  }


Если соответствующие объекты (tempDeviceDescriptor, например) сделать статическими, то код начинает работать, но жалко RAM, так как нужно всего один раз.

Сегодня пришла в голову идея размещать данные для нумерации в буфере USB, сразу за выделенным для нулевой конечной точки участком, так как все равно эта память до окончания нумерации не нужна. Нормальная ли затея или как лучше размещать данные для отправки во время прохождения нумерации? Или, может, вообще вытащить формирование дескрипторов в compile-time и пусть там себе во Flash лежат, его не так жалко?

[COKPOWEHEU]

Если не собираетесь слишком сильно извращаться со структурой устройства (ну там при каждом запуске менять количество конечных точек, дескрипторов и тому подобного), то проще выкинуть во флеш и не мучиться. Тем более что всю эту динамическую конфигурацию ведь не только отправить хосту надо будет, но и самому потом в нужные точки нужные данные в нужном формате слать.

[azhel12]

COKPOWEHEU писал(а):

Если не собираетесь слишком сильно извращаться со структурой устройства (ну там при каждом запуске менять количество конечных точек, дескрипторов и тому подобного), то проще выкинуть во флеш и не мучиться. Тем более что всю эту динамическую конфигурацию ведь не только отправить хосту надо будет, но и самому потом в нужные точки нужные данные в нужном формате слать.

Согласен, сейчас прикинул, все равно ведь все эти данные где-то во Flash итак лежали (чтобы потом в RAM быть записанными), так что даже какого-то значимого оверхеда быть не должно.