Велофара NightKeeper 2 - новая версия

[R-2]

Это ПРОИЗВЕДЕНИЕ во всех смыслах. Автор - гений нашего времени.
Мне завидно. Потому что у автора в портфолио появилась вещь, противопоставить которой что то равное по весомости (пусть и в другой области творчества) трудно.

[prcoder]

Новости с фронта

Тьфу... Не шутите так...

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

А почему так сложно получается ? Для ELT я прошивку за несколько вечеров написал.
Разрисовать конечный автомат на бумажке с переходами, да запрограммировать его.
Ну ещё разобраться с обработкой показаний датчиков.
Вы на си пишете прошивку или на ассемблере ? Там какой МК используется ?

[V R P]

А почему так сложно получается ? Для ELT я прошивку за несколько вечеров написал.

Видимо моя прошивка несколько сложнее .

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

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

Вы на си пишете прошивку или на ассемблере ? Там какой МК используется ?

Пишу не я, я бы такую не написал. На Си под STM32 и STM8.

---------- Добавлено 22.02.2015 в 00:03 ---------- Предыдущее сообщение 21.02.2015 было в 23:53 ----------

Да, кстати говоря. Сегодня посидели и поковыряли прошивку, вроде отловили оставшиеся сомнительные места. Пришлось пошагово проверять работу контроллера осциллографом, по коду найти место вероятного глюка не удавалось. После тестов станет понятно, может это уже и конец ее доработки.

[Kompilator]

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

Анимация работает в своём прерывании, обработка кнопок в другом прерывании, меню (реакция на кнопки) в третьем, если сумма времени выполнения всех прерываний не занимает всё контроллерное время, то проблем не будет.
У меня контроллер загружен на 60% примерно и это с учетом того, что он сам следит за током на диодах т.к. сделал без драйвера светодиодов, с ним такой гибкости управления 3-мя каналами не добиться. И батарею сам смотрит.

[prcoder]

Видимо моя прошивка несколько сложнее .

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

Короче, я за упрощение в целях повышения надёжности

[V R P]

Короче, я за упрощение в целях повышения надёжности

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

[prcoder]

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

Это да. По-этому неплохо бы предусмотреть возможность несложного обновления прошивки.
Например через USB. Чтобы пользователь мог сделать это самостоятельно. Далее тщательно собирать
отзывы пользователей первых партий, исправлять недочёты и мелкие неудобства, отправляя им обновления.

[V R P]

Это да. По-этому неплохо бы предусмотреть возможность несложного обновления прошивки.
Например через USB. Чтобы пользователь мог сделать это самостоятельно. Далее тщательно собирать
отзывы пользователей первых партий, исправлять недочёты и мелкие неудобства, отправляя им обновления.

Несложно обновлять не получалось, тем более по юсб, там и так впритык все влезло в имеющиеся габариты. Да и сама процедура обновления добавила бы еще кучу глюков и затянула бы сроки написания прошивки. Обновлять особо нечего, функционал не меняется, главное обеспечить его функционирование. А рассылать глючные прошивки и потом напрягать всех их обновлением - это называется выпустить сырой продукт. Да и далеко не всегда можно все исправить в прошивке, плату 3 раза пришлось переделывать изза софтовых проблем. Тут пользователь бы уже ничего не сделал. Так что я придерживаюсь принципа изготовление законченного устройства, не требующего в дальнейшем вмешательства и обслуживания. Я же не конструкторы/киты делаю, а готовые устройства.

[Morne Taru]

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

+1

[Archie]

Обновлять особо нечего, функционал не меняется, главное обеспечить его функционирование. А рассылать глючные прошивки и потом напрягать всех их обновлением - это называется выпустить сырой продукт. Да и далеко не всегда можно все исправить в прошивке, плату 3 раза пришлось переделывать изза софтовых проблем. Тут пользователь бы уже ничего не сделал. Так что я придерживаюсь принципа изготовление законченного устройства, не требующего в дальнейшем вмешательства и обслуживания. Я же не конструкторы/киты делаю, а готовые устройства.

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