Споры о подходах к программированию МК, ASM vs C, и не только Опции

[_pasha]

С чем связана такая лЫчная нЭпрЫязнь (с) к прерываниям?

На модбасе свет клином не сошелся, есть еще 9-битные протоколы, есть самописный с неплохим показателем по избыточности - тот, что системно критиковал one-man-show, их выбор завязан на константы в еепроме, хранить которые в озу не хоцца - озу надо беречь.
Получается, весь прерыванческий таракан завязан на очереди - и ему пофиг какой тама протокол. В общем, пришел к эскейп- последовательностям для определения таких моментов

Код

Timeout35  модбас
Timeout15  модбас
No_Escape если != 0, то ескейп-символ в очереди также и читаемый символ
Frame_Resync для 9 бит если посреди фрейма пришел байт адреса, == адресу устройства
Broadcast_call ширка
Break или frame error
Error переполнение буфера
Bit9

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

[Гость_MrYuran_*]

Зачем нужен "дядин" софт?

"Дядин софт", в данном случае FreeModbus, являет собой пример хорошего стиля и чёткой структуризации.
Я, честно говоря, там очень многому научился.
Осталось ещё документацию в doxygen освоить до конца.
В чём преимущество?
В том, что эта библиотека, единожды имплементированная в проект, практически без всяких телодвижений одинаково работает что на AVR, что на MSP, что на LPC, STM32 или PC под Win/Lin.
Когда хардварные платформы меняются чуть ли не каждый год, кросс-портируемость становится решающим фактором.
Байты и килогерцы нынче уже поштучно не учитываются.
Зато учитываются человеко-дни (и даже часы), необходимые для внесения изменений на ходу в живые проекты.
И если какая-то часть кода вцепилась в железо мёртвой хваткой, это очень плохо.

А самое интересное, это когда приходят товарищи учёные и говорят: а помнишь мол, года этак два назад ты нам вот так делал, а потом переделал вот тут и вот там?
Так ты вот это верни, вот там оставь, а вот здесь мы ещё сами пока не знаем, подумаем...
И начинаешь волосы рвать.
С виду незначительные изменения (с т.з. юзера) иногда в корне ломают всю логику работы, и если она ещё и на железо завязана, то это вообще труба.

[_pasha]

Что может быть хуже, чем "Дядин софт"?
Только "Тетин софт".
Хотя, нескольких толковых Ымбед-теток знаю.

[Прохожий]

"Дядин софт", в данном случае FreeModbus, являет собой пример хорошего стиля и чёткой структуризации.
Я, честно говоря, там очень многому научился.

Хороший стиль - это когда работает на всех вариантов тестов.
И долгое время.
Мой первый девайс, который я имплементировал(с) в одну из машин на нашем производстве, был сделан на PIC16F676 и работает уже 5 лет без остановки.
При этом было всякое и выключение общего питания, и броски напряжений, и неудачное поведение механиков...
Это преобразователь напряжения термопары в частоту 1...2 кГц, сделанный за неделю.
Потому, как машина стояла, а итальянские аналогичные девайсы обещали только через месяц.
Вторая аналогичная ситуация произошла, когда навернулся старинный механический контроллер одной из наших машин.
Представляющий собой шедевр механической английской мысли.
Машина питается от 12 не стабилизированных Вольт со страшными пульсациями от всяких там клапанов, пускателей и хитрых реле.
PLC, имеющего такое питание, релейные выходы и входы, работающие от 12-ти Вольт, на тот момент быстро в течение 2-х недель достать было невозможно.
Пришлось все делать самому.
PIC18F252 с нашей местной помойки и горстка 155-ой серии решили все проблемы.
Получился параметрируемый кулачковый автомат со сдвиговым регистром, синхронизированным с машиной.
Тому уже полтора года непрерывной работы с теми же самыми эксплуатационными приколами.
Другое дело - мое личное отношение к подобной лепнине, пусть даже и своей.
Для нашей службы - это гемор, по-любому.

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

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

А самое интересное, это когда приходят товарищи учёные и говорят: а помнишь мол, года этак два назад ты нам вот так делал, а потом переделал вот тут и вот там?
Так ты вот это верни, вот там оставь, а вот здесь мы ещё сами пока не знаем, подумаем...
И начинаешь волосы рвать.
С виду незначительные изменения (с т.з. юзера) иногда в корне ломают всю логику работы, и если она ещё и на железо завязана, то это вообще труба.

У меня нет логики работы. Есть гиперавтомат с процессами.
Есть процессы верхнего уровня, есть и нижнего.
Они все элементарны с точки зрения сложности.
И изменение логики работы элементарного процесса - не проблема.
Можно так же без труда добавить новый процесс и расширить функционал девайса в целом.

[_pasha]

и работает уже 5 лет без остановки.

Таж фигня, только 8. Это не членомерство, просто некоторые истины приходят в голову, после чего мы говорим практически на одном языке.

При этом было всякое

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

[_pasha]

QP
Долго ругался на лишние сущности, а потом столкнулся с юзерами, которые ни бум бум в языках программирования, зато граф состояний вкуривают быстро. LD - ваще не знают Вот такая пионэр-автоматизация.
Ы?

[Гость_MrYuran_*]

Ы?

Я присматривался пару лет назад.
Времени правда так и не нашёл подробно изучить.
Но вопрос интересный.
Может, и не всю программу так организовывать, а только там, где надо.
Типа визарда или плагина к тому же С::В организовать

Еще в одном из журналов "радио" читал про примочку, которая преобразует в программу цифровую логическую схему.
Получаем этакий "эмулятор ПЛИС", с оговорками и ограничениями, естественно.
Но это уж вообще для закоренелых жестянщиков.

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

[_pasha]

Может, и не всю программу так организовывать, а только там, где надо.
Типа визарда или плагина к тому же С::В организовать

Да, там не хватает этого и построителя графов зависимостей, как в Crystal Flow или в более старом Understand C/C++, доблестно прибитым на эльхе модераторами ФТП

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

Смежный вопрос - JIT-компиляция с языка FBD. В принципе, если ограничить функц. блок одним типом "два входа - один выход" - озу будет жрать минимум.
QNXовые штучки для референса. Ничего сильно нового , просто для кругозора.
[attachment=2655:document.pdf]

[Прохожий]

QP
Долго ругался на лишние сущности, а потом столкнулся с юзерами, которые ни бум бум в языках программирования, зато граф состояний вкуривают быстро. LD - ваще не знают Вот такая пионэр-автоматизация.
Ы?

Де факто и де юре в нашем деле LD в сочетании с FBD не знать нельзя.
Просто не возьмут на работу.
Мы же простые эксплуатационщики.
Все уже написано до нас.
Наше дело - разобраться с ошибками.
В 99,9% случаев - программа не причем.
Но она - часть оборудования.
И ошибки с теми же датчиками ищутся, как правило, по программе.
Так что придется этим юзерам вкуривать таки LD.
Иначе ничего продать не получится.

[_pasha]

[attachment=2671:PIC18_div_by_N.zip]
Вмемориззз.
Хоть и давно об этом говорено, но.

[pwn]

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

Это два различных пути познания. У каждого свои плюсы, свои минусы. Очень доходчиво растолковано в этой сказке http://subscribe.ru/archive/rest.mystery.o...5/10134031.html

Невозможно отдать предпочтение тому или иному способу. В данном случае все зависит от программиста

Именно так, пути равнозначны. Но... их можно смешивать. Так быстрее. Сначала продумываешь. Потом терпение лопается и начинаешь писать. Потом набивши лоб о грабли опять сидишь продумываешь. Так итераций меньше и результат достигается быстрее. Возможно это третий способ познания Наиболее доходчиво об этом написал Ларри Уолл в своей книге Программирование на Perl. В том месте где он говорит по Лень, Нетерпение и Самомнение

[Прохожий]

... Лень, Нетерпение и Самомнение

Три страшных порока любого инженера.
Наиболее подвержены как раз программисты, ПМСМ.
Вы, кстати, как относитесь к РТОС во встраиваемых ответственных системах?
И к дядиному коду в них же?..

[pwn]

Три страшных порока любого инженера.

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

Наиболее подвержены как раз программисты, ПМСМ.

Что есть то есть

Вы, кстати, как относитесь к РТОС во встраиваемых ответственных системах?
И к дядиному коду в них же?..

Спокойно. Ибо пока еще не юзал Но думаю ничерта страшного, все можно применять был бы смысл. То есть как я всегда говорю - все определяет конкретная задача. Хотя в теме мелкоконтроллеров склонен к распределенным системам. Это типа когда есть несколько мелких узкоспециализированных камней, которые решают каждый свой кусочек задачи а промеж собой связаны каким нить междумордием. Это когда задача в один камень не лезет. А если лезет то также склонен развешать все по прерыванием а в мэйн лупе курить бамбук

[Гость_MrYuran_*]

Вы, кстати, как относитесь к РТОС во встраиваемых ответственных системах?
И к дядиному коду в них же?..

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

[Прохожий]

А если лезет то также склонен развешать все по прерыванием а в мэйн лупе курить бамбук

+500!
В мэйне можно еще и HMI делать...

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

Использование дядиного кода предполагает его предварительное тщательное изучение.
Если есть желание плутать в дебрях чужого сознания, то почему бы и нет?
Примеры использования РТОС с косяками я уже приводил.
Можно и дядин абсолютно рабочий код обрамить своим, так, что будет плохо.
Грабли абсолютно те же...

[pwn]

Грабли абсолютно те же...

Думаю дело не в граблях. Просто нужно чтобы как MrYuran-у осточертело все время решать проблемы через городушки на прерываниях и тогда тошнота от старого подхода будет стимулом к унификации Я вот под микроконтроллеры пишу мало и редко и поэтому и тошноты нет и надобности особой в RTOS тоже. Зато много пишу под перл и пхп и вот там да, и унификация на высоте, и дядиного кода не менее 80% в виде сторонних модулей. Так что вопрос надо не надо юзать РТОС стоит рассматривать также с позиции как много кода пишется и до какой степени это уже ос....ло

[Прохожий]

Думаю дело не в граблях.

Да и в граблях тоже. Я бы здесь разделил грабли, связанные с методикой познания, о которой мы говорили выше.
И грабли, связанные с тремя пороками.

Просто нужно чтобы как MrYuran-у осточертело все время решать проблемы через городушки на прерываниях и тогда тошнота от старого подхода будет стимулом к унификации Я вот под микроконтроллеры пишу мало и редко и поэтому и тошноты нет и надобности особой в RTOS тоже. Зато много пишу под перл и пхп и вот там да, и унификация на высоте, и дядиного кода не менее 80% в виде сторонних модулей. Так что вопрос надо не надо юзать РТОС стоит рассматривать также с позиции как много кода пишется и до какой степени это уже ос....ло

Дык, аналогично, за тем исключением, что для больших машин я тоже пишу редко, когда приходится делать HMI для автоматических систем.
В остальном все совпадает. С++ Builder однозначно предполагает очень много дядиного кода.
Остался один вопрос.
На каком самолете предпочтете полететь?
На том, где система сделана на РТОС с кучей чужого кода, или на системе, построенной на прерываниях?

[pwn]

На каком самолете предпочтете полететь?

На ВАЗ 21099. И то потому что она вся до последнего винта моими ручками перебрана. Не факт что косяков нет. Не факт что не влуплюсь где нить. Но ... хотя бы некого будет винить потом

На том, где система сделана на РТОС с кучей чужого кода, или на системе, построенной на прерываниях?

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

[Прохожий]

На ВАЗ 21099. И то потому что она вся до последнего винта моими ручками перебрана. Не факт что косяков нет. Не факт что не влуплюсь где нить. Но ... хотя бы некого будет винить потом
Это ни при чем. Можно и на РТОС идеально сделать, а на прерываниях такого нашкодить, что самолет так и останется набором запчастей, понятия не имеющих о том что они могут летать. Так в чем же дело? Ответ на этот вопрос дан давно: Нельзя быть слугою двух господ. Если на первом месте бабло и прибыль, то все остальное всегда будет на втором. И результат соответствующий, хоть на РТОС хоть на прерываниях. Ымбед это не куча процов там где мог стоять один ОУ или корпус 74-й логики. Ымбед это кода никто не хочет работать на конкретный практический результат, и если он все же достигается то только потому что иначе не платят бабок. Правда и в этом случае жисть быстро доказывает что король голый и бабки платились зазря. И как правильно сказали, если ымбед был в каком нить станке то вы попали на бабки. А если в самолете - то на крематорий.

А существует ли РТОС, даже за бабло, авторы которой берут на себя все риски применения?
Или как это нынче принято поставка "как есть"?
На прерываниях накосячить сложнее, чем при применении РТОС.
Причины очевидны - двойной вторяк (1. МК, 2. РТОС).
В случае МК - вторяк одинарный.
А Ымбед - это не только паталогическая тяга к баблу, но еще и некомпетентность.
Зачастую воинствующая...

[orthodox]

Нельзя быть слугою двух господ. Если на первом месте бабло и прибыль, то все остальное всегда будет на втором. И результат соответствующий, хоть на РТОС хоть на прерываниях. Ымбед это не куча процов там где мог стоять один ОУ или корпус 74-й логики. Ымбед это кода никто не хочет работать на конкретный практический результат, и если он все же достигается то только потому что иначе не платят бабок.

В цитатник.