Абдуринщики на марше.

[stalkernet]

получается бабки лежат - не ты поднимешь, так кто-то другой
уж лучше себе поднять чем кто то другой огород подчистит

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

[NewWriter]

а дисплей раскрашивает через FSMC.

)) Кстати, FSMC для дисплея - это уже дико устаревший вариант эпохи первых F103. Ну это так, к слову.

этом же плане про MODBUS

А причем тут протокол Модбас и набор правил МИСРА? Хотя, в принципе, если соблюдаешь правила хорошего тона в программировании, то и виснуть там ничего не будет в Модбасе. Потому что, когда ты пишешь прогу по всем правилам, ты СРАЗУ уже не допускаешь неоднозначностей и опасных мест.
Ну как вам проще объяснить, чтобы вы наконец-то поняли о чем именно я говорю... ну не знаю, ну вот давайте вот например вот так:

switch(value){
case 1: /* что-то выполнить */;
break;
case 2: /* что-то выполнить */;
break;
}

и представим, что value по какой-либо причине оказалась не равна ни 1, ни 2. Особенно если value - это читаемое извне значение. То есть, на ошибочное значение никак не среагировали, пропустили.

Или другой пример. Цикл ожидания чего-либо:

while(!event) { }

- это потенциальный источник мертвого зависания. Причем, тут даже две ошибки. Первая - если event объявлен НЕ volatile. Тогда компилятор при оптимизации выкинет вообще event, посчитав ее константой. И вторая ошибка - а вдруг event не наступит никогда? Вооо. Нужен таймаут ожидания.
Знающий, опытный программер видит такие проблемы на два шага вперед, еще даже не написав эту строчку.

Ладно. Третий пример, совершенно практический. Кто немного вкурсах MIDI, тот поймет. Там, кароче, значения второго и третьего байта сообщения должны быть в диапазоне 0 - 127.

void MIDI_SendNoteOn(uint8_t note, uint8_t velocity)
{
    SendInterface(0x90);
    SendInterface(note);
    SendInterface(velocity);
}

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

void MIDI_SendNoteOn(uint8_t note, uint8_t velocity)
{
    if(note › 127) note = 127;
    if(velocity › 127) velocity = 127;
   /* код отправки */
}

Ну что, теперь понятно, что такое грамотное, отказоустойчивое программирование? Имеют ли ардуино-скетчи подобные "излишества"? Знают ли вообще об этом ардуинщики, когда делают "контроллер пассажирского лифта"?
Ошибки многих кодописателей в том, что они считают, что если какое-то событие явно не может произойти, то оно и не произойдет никогда. Как показывает практика, если событие может произойти, то оно рано или поздно произойдет, когда для этого наступит время, стечение обстоятельств или просто по "закону подлости".

[verdana]

)) Кстати, FSMC для дисплея - это уже дико устаревший вариант эпохи первых F103. Ну это так, к слову.

Не буду возражать. Непринципиально.
У меня и F429 так работал. Может и некошерно, но это именно для себя.

Подставьте любой термин по вкусу.
Смысл не изменится ни на йоту.

А по поводу случáев...
https://kazus.ru/forums/showpost.php...&postcount=321

[verdana]

"-Чем отличается хороший лётчик от плохого?
-Хороший лётчик умеет делать всё то же, что и плохой,
но кроме того, совершенно точно знает, чего нельзя делать" ©

[mahacytl]

Кстати

В целом согласен, кроме настроя именно против Ардуин.
Мой коллега, которого я упомянул, был именно классическим ардуинщиком, т.е. любил повторять схемы на основе Atmel без анализа схемы, кода.
Но это вопрос философский.
Мы с ним как-то поспорили - я - какой интерес повторять чужие конструкции, чужие коды, не вникая в них?
Он - а вам какое дело, мне это нравится.
Я вспомнил про своего знакомого, который хранил массу системных программ - например, когда я его спросил - у тебя есть P-CAD ? - он спросил - какую версию - у него были от 1. до Altium.
Ну спасибо, что у него всё это есть, но зачем это всё хранить?
Мне это напомнило тем, что он не вникал в них - просто хранил.
Мой коллега, надо признать, стал вникать в код, менять под себя.
И это правильно.
Просто наезд на ардуино мне напоминает своё.
10 лет назад у нас на фирме было принято программировать на PIC - было официально принято на учёном совете.
Ну на PIC, так на PIC, я вообще был знаком с 8086 и Z-80.
Наш системный программер на остановке поговорил на остановке с программером конкурентов - PIC гавно, Atmel рулит.
Ну, я и не являлся адептом PIC, за что платят, то программирую.
Просто, повторюсь, проблема не в контроллере, а в подходе к нему

[NewWriter]

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

[NewWriter]

кроме настроя именно против Ардуин.

Я НЕ против Ардуин. Я против того, чтобы их пихали втуда, куда им вход запрещен. И я это уже не раз повторил. Ардуина - это не только плата, но и адруино-подход к программированию вообще. Дело не в микроконтроллере. AVR и PIC встречается в серийных устройствах гораздо чаще, чем тот же STM32. Между прочим, контроллер пассажирского лифта OTIS - там PIC. Причем, еще даже в DIP-корпусе. Но он прошел сертификацию на безопасность.
А приходилось ли вам видеть "бутерброды" из ардуино-шилдов, обмотанные паутиной проводов, и засунутые в стандартный электрический шкаф? Ну-ну, так посмотрите, поглазейте.
Вот, вот это - как думаете, безотказно ли будет работать?



беспаечные платы знаете? Фкурсах, что у них ослабевают прижимы контактов и что помехи по шинам питания просто ужасны?


Касательно готовых плат - есть и Intel Edison, и Raspberry, которые в принципе являются готовыми для работы. Те же "Малины" ставят как контроллеры LED-панелей. Причем, китайцы их пачками штампуют. Правда, говно получается низкопробное, надежность - вообще отстой, сам сталкивался.

Кстати, для желающих программировать в промышленных масштабах - есть PLC (ПЛК, программируемый логический контроллер). Сименсы например считаются весьма кошерными и расово верными для промышленной автоматики. Берите, пользуйте. По крайней мере, за схемотехнику сам Сименс ручается, к нему все косяки, ежели вдруг чаво.

[verdana]

но и адруино-подход к программированию вообще..

А что именно?
Абстракция от железа?

Ну так по сравнению с LD и FBD для PLC, Ардуино нервно курит в углу.
И ни кто на них не матерится...

[ForcePoint]

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

Прощу прощения, но тут взаимоисключающие пункты.

[NewWriter]

Не, не абстракция от железа. Нет. Ладно бы только абстракция. Абстракция и универсальность влияет только на скорость и эффективность использования процессорного времени. Абстракция - это вообще правильный подход в кодонаписании, когда все разложено по полочкам, по уровням.
Но вот универсальность - враг оптимальности.
Ладно, хрен с ней, с абстракцией.
Я говорю о ардуино-подходе, когда вон там, как на картинке в предыдущем посте. Каша. И такая же каша - в программном коде. ВОТ о каком ардуино-подходе я говорю.
Часто (да почти всегда) ардуинщики ляпают код ужасно нерационально. Зачастую, аппаратные интерфейсы МК заменяются программной их реализацией, да еще в самом черезжопном варианте, когда тайминги делаются через блокирующий delay. Из-за чего вся система получается просто тормознутой.
Вот и об таком ардуино-подходе я толкую.
Вот!

ПЛК конечно тоже еще тот венец творения. Но они хотябы сертифицированы. Имею ввиду Сименс, как самый распространенный и многоуважаемый. Еще есть Овен, как вариант для тех, у кого не хватило денег на Сименс.
Но вы посмотрите на внутренности ПЛК. Там стоят весьма производительные процы (микроконтроллеры), дающие на выходе очень даже невысокий КПД. Как раз по причине универсальности. Фактически, внутри там крутится транслятор кода. Но почему ПЛК сертифицированы? Да потому, что блоки, из которых генерируется исполняемый код, они построены по отработанному отказоустойчивому алгоритму.