[D'AVerk]

 Сообщение от alibek :

Насчёт больше жрать - это не так. BT LE может на какой-нибудь AG13 пару лет работать.

Я правильно понимаю, что в вашей голове BT отдельно, а чип который его поддерживает отдельно? Сам BT может ничего не жрать в выключенном состоянии, а вот чип, в который он интегрирован жрать будет, надо смотреть конкретно сколько.

[INFERION]

 Сообщение от alibek :

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

Т.е. можете подсказать уже готовое не глючное хорошо поддерживающееся и без китайских иероглифов приложение для конфигурации фонарей? Да хоть чего угодно - оно всё усратое и наспех слепленное китайцами. Интересно, почему?.. Такое написать - ещё сложнее и дороже чем сам фонарь спроектировать. Да, именно с учётом всех стеков, API, фреймвёрков, сред для разработки и т.п. (без них было бы ещё сложнее). И это основная проблема, на мой взгляд. Поэтому совать отдельный чип (BLE), функционал которого просто не будет раскрыт в фонаре - зачем? Другое дело - дописать код фонаря под уже имеющийся USB разъём (поднять CDC класс и реализовать простую загрузку конфига в EEPROM фонаря - не сложно) - а дальше народ пусть сам пилит софт, если ему интересно. Что-то запилит адекватное - можно будет потом пересадить на BT, а сейчас какой смысл? Вот и делают такое только ради галочки в каких-то непонятных продуктах.

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

 Сообщение от D'AVerk :

Я правильно понимаю, что в вашей голове BT отдельно, а чип который его поддерживает отдельно? Сам BT может ничего не жрать в выключенном состоянии, а вот чип, в который он интегрирован жрать будет, надо смотреть конкретно сколько.

Там немного. Эти чипы оптимизированы на низкое потребление и в дежурном режиме потребляют что-то в районе пары микроампер. Для сравнения - одна только подсветка кнопки в выкл. у Юника потребляет микроампер 30. Только вот поддержка BLE сразу ставит вопросы безопасности и надёжности соединения, и в этом плане провода просто проще.

[D'AVerk]

 Сообщение от INFERION :

народ пусть сам пилит софт, если ему интересно

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

[Rivarez]

 Сообщение от fnksb :

Вообще же организовать настройку через usb намного сложнее, чем кажется

Записать параметры фонаря на флеш память сложно? Разве что-то может быть проще и дешевле?

[INFERION]

 Сообщение от D'AVerk :

И в гробу он видал пиление софта с заливкой потом через провод.

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

 Сообщение от Rivarez :

Записать параметры фонаря на флеш память сложно?

Нет. А вот поднять канал связи для этого - да. Один только VID/PID и драйверы под разные ОС сколько вопросов вызывают, а стек в самом фонаре поднять? Дескрипторы все эти описать, отладить инициализацию устройства и т.п...
И не на Flash, т.к. это не надёжно (повредить прошивку проще, и соседние данные из-за постраничной перезаписи), неудобно (постраничный доступ), во время операций намертво вешает ядро МК (т.к. именно из flash читается исполняемый код), ресурс меньше (ещё и запись только страницами по 64/256 байт, хоть тебе только 1 байт нужно записать) и т.п. - а на EEPROM (хотя, у того же STM32 и выбора то нет), который и сам фонарь может без проблем править под свои нужды.
Кстати, подвисания ядра во время программирования Flash иногда вызывают отваливание устройства (прямо по середине критической процедуры) из-за слишком маленьких таймаутов ожидания у USB, отсутствия синхронизации в это время и т.п. Этот интерфейс, по-моему, только пользователи и любят...

 Сообщение от Rivarez :

Разве что-то может быть проще и дешевле?

Да - не реализовывать USB стек в драйвере фонаря, не покупать VID, не писать свои драйверы/ПО под ПК, Мак, Андроид, Айфон, не платить за их подписи, не нанимать разработчиков прикладного ПО под все эти платформы, у которых типовая ставка порядка килобакса в месяц, и работы не на 1 месяц...

[D'AVerk]

 Сообщение от Rivarez :

Записать параметры фонаря на флеш память сложно?

Сложно. Потому что в фонаре нет выделенной флешпамяти, да с контроллером записи туда. Используют флешпамять прямо внутри AVR чипа. А писать на нее напрямую через usb нельзя.
Вы бы для начала поинтересовались как работает USB, в варианте ehci и ohci.

Помню как-то писал на ассемблере обработчик для низкоуровневого доступа к флешке ключу доступа, Etoken, то еще удовольствие

[D'AVerk]

 Сообщение от INFERION :

VID/PID и драйверы под разные ОС сколько вопросов вызывают,

Можно эмулировать просто флешку. С стандартным драйвером доступа.

 Сообщение от INFERION :

стек в самом фонаре поднять?

А вот это придется, да. И пакеты разбирать, и файловую систему эмулировать.

[INFERION]

 Сообщение от D'AVerk :

Можно эмулировать просто флешку. С стандартным драйвером доступа.

И конфиги туда отправлять в текстовом формате, редактируя в блокноте? )
Интересно, как ОС отреагирует на носитель с объёмом памяти 128 байт и размером кластера в...? При этом ещё и если текст отправлять - он не будет храниться в исходном виде, и при попытке записать что-то не стандартное (ASCII файл со строгим форматом и названием файла) будет ругань... И всё это выглядит как лютые костыли. Реализовывать полноценную флешку, в которой контроллер сам будет искать config.ini и парсить его? Это уже явно не AVR (а другие МК хуже подходят для прямой задачи в фонаре).

 Сообщение от D'AVerk :

в фонаре нет выделенной флешпамяти, да с контроллером записи туда. Используют флешпамять прямо внутри AVR чипа. А писать на нее напрямую через usb нельзя.

Есть EEPROM на 128/256/512 байт, с отличным побайтовым доступом, не блокирующим выполнение кода. И ещё существуют программные USB загрузчики для тинек, занимающие пару килобайт и таки пишущие во Flash. Для меня это пока магия, но имею ввиду.

[D'AVerk]

 Сообщение от INFERION :

Интересно, как ОС отреагирует на носитель с объёмом памяти 128 байт и размером кластера в...?

?
ОС у нас будет заглядыватьв нашу спеку только через то что мы ей покажем. Мы ей можем сказать что у нас 16гб в фонаре. А на деле игнорировать все что нам посылают сверх первых 128 байт, вы как маленький.

 Сообщение от INFERION :

туда отправлять в текстовом формате, редактируя в блокноте?

Ну тут два варианта, либо простейшее ГУИ, которое пишет сейв файл в формате прямого байтового хранения на фонаре (авр получает пакеты данных, первые 128 байт кладет себе, если есть еще что-то игнорит).
Второй вариант -парсить на лету текстовый файл с параметрами, оставляя себе только значения, остальное отбрасывая, но это ресорсоемче и больше шансов на ошибку составителя файла. Поэтому вариант с гуи надежнее.

Зы в наше время слабать гуи для базовых настроек под винду дело одного дня.
Другое дело, что так не изменить логику работы прошивки, а только мелочи типа настроек.

[INFERION]

 Сообщение от D'AVerk :

Мы ей можем сказать что у нас 16гб в фонаре. А на деле игнорировать все что нам посылают сверх первых 128 байт, вы как маленький.

О, ещё больше китайских костылей! Флешки с Али научили? )

 Сообщение от D'AVerk :

либо простейшее ГУИ

Ему уже лучше и нормальный CDC поднимать, или даже общаться с устройством напрямую через его эндпоинт без какого-либо конфигурирования (ну, кроме определения адреса на шине). Тут и VID никакой не нужен, и без драйвера можно обойтись, насколько мне известно. Но необходимо писать прикладное ПО (то самое "простейшее ГУИ").

 Сообщение от D'AVerk :

Второй вариант

Надёжнее, т.к. всё равно парсить и проверять все данные извне на корректность. Даже содержимое EEPROM проверяется при загрузке, ну а вдруг на заводе не прошили, или повредилось что-то при очередной записи? Другое дело, что парсить лучше таки бинарные данные, а не человекопонятный текст.

 Сообщение от D'AVerk :

Зы в наше время слабать гуи для базовых настроек под винду дело одного дня.

Не думаю. Если делать не на тяп ляп, то намного дольше делать даже консольную версию с нормальными диалогами и проверками ошибок. А потом ещё мучиться с линковкой библиотек, на которые не будет ругаться хотя бы XP (потому что он всё ещё, внезапно, встречается у людей). А GUI так вообще потребует продуманности на уровне "подгрузить файл при перетаскивании на окно", "предложить сохранить не сохранённые данные при закрытии или открытии нового файла", поддержка запуска с параметрами (для любителей батников) и прочие плюшки, которые реализуются таки вручную...

P.S. Это ж тема по какому-то фонарю вроде была? )