Портируемый код - миф или реальность? Опции

[CD_Eater]

Очень хочется покидать камушки в огород тех, кто пишет на Си и верит в миф о лёгком портировании кода. Нет возражающих? Ну, тогда начну.

Недавно на телесисях была поучительная ветка. Вот она
http://telesys.ru/wwwboards/mcontrol/1809/...es/173406.shtml
Прочитайте её, интересно.

Прочитали? Тогда продолжим.
Это почти классический пример - ЯВУ скрыл от программиста важнейшую деталь реализации: с виду атомарная инструкция "PORTB ^= 1" на самом деле оказалась неатомарной, и автор совершенно не ожидал, что здесь придётся заботиться о корректном доступе к общему ресурсу (порту B ) в многопоточной среде (фоновая задача + обработчик прерывания). Если бы человек писал на ассемблере, он бы легко увидел эту потенциальную "борьбу за ресурс" и принял бы обычные в таких случаях меры. Не исключено (хотя маловероятно), что автор предвидел эту возможную угрозу, но понадеялся, что компилятор достаточно умный и автоматически выберет самый оптимальный вариант реализации, то есть, "PINB = 1", сделав операцию атомарной (разумеется, компилятор сделал бы это из соображений оптимизации по скорости/размеру кода, а не из заботы об атомарности). Для нас важно одно: простые и однозначные с виду операции ЯВУ могут (в зависимости от компилятора и железа) оказаться вовсе не такими простыми и однозначными.

Теперь представьте такую ситуацию. У Вас есть Сишный исходник и Вы портируете код проекта на другой МК. Разные не только МК, но и компиляторы. Предположим, что в проекте встречается ситация, аналогичная приведённой выше: в фоновой задаче и в обработчике прерывания используется нечто вроде "PORTB ^= 1", но в предыдущей реализации (при старом МК и старом компиляторе) эта операция была атомарной, а в новой реализации (на новом МК и новом компиляторе) перестала быть атомарной. Вопрос: заметите ли Вы это???
При переносе исходника Вы успешно подправите имена портов, замените где нужно номера битов этих портов, но придёт ли Вам в голову менять стандартную Сишную инструкцию "PORTB ^= 1" на какую-то другую? Да никогда в жизни! И программа успешно скомпилируется, и на Вашем столе она заработает без ошибок, и пирожок с полки Вы возьмёте, преисполненный гордостью за умение легко портировать программы. А потом, через месяц-другой, придут недобрые вести с поля - что-то там не фурычит. Приезжай, творец, разбирайся что натворил - изредка бывают сбои. Спорим, что первое, на что Вы подумаете - это на недостаточную помехозащищённость Вашего девайса. Вероятность того, что прерывание попадёт внутрь Read-Modify-Write последовательности, достаточно мала и при тестировании обнаружена не будет, но вот в поле (помножьте эту вероятность на тысячу устройств, которые Вы уже изготовили и внедрили) уверенно даст о себе знать. Пока Вы, начиная с мыслей о помехозащищённости, дойдёте до реальной причины неисправности, пройдёт порядка месяца, не меньше, т.к. это очень труднообнаруживаемая ошибка. Вы вряд ли станете искать ошибку в софте, т.к. при портировании код фактически вообще не был изменён, а в предыдущей реализации сбоев не было. Возможно, ошибку так и не найдёте, но будете всем рассказывать сказки про плохую помехозащищённость или ужасную глючность новых МК...

Имхо:
Надеяться на лёгкую портируемость проектов с одного МК на другой - это путь в страну Грабляндию. Создавая проект, пишите его применительно к данной задаче и для данного МК. Если всё же придётся переносить на другой МК, переносите только блок-схему алгоритма, заново наращивая "скелет" деталями реализации. Чаще всего придётся даже немного изменить алгоритм работы, приспособив его к особенностям новой периферии (например, использовать не поллинг пина по таймеру, а функцию захвата и т.п.).

P.S. Сейчас меня обвинят в том, что я не люблю или не умею писать портируемые программы, что большинство программистов в мире пишут только портируемый код, и что за портируемым кодом будущее. В ответ замечу одну большую разницу - не сравнивайте программирование для PC и для МК. Легко портируются те программы, которые фактически не зависят от аппаратуры, например, математические вычисления (БПФ, фильтры и т.п.). Большинство программ для МК сильно зависят от железа. Правильный с точки зрения программирования подход к созданию легко портируемого кода состоит в том, чтобы выделять в отдельные функции (возможно, inline-функции) всё обращение к периферии, и при каждом портировании переписывать эти функции полностью. Причём для одной и той же операции, например, для "PORTB ^= 1", должны присутствовать две функции: одна реентабельная (для случаев типа нашего), другая нереентабельная, зато быстрая (для обычного однопоточного программирования). Тогда проблем будет гораздо меньше, но программы перестанут быть эффективными. Короче, стандартная ситуация с плюсами и минусами универсальности (тут очень в тему будут слова автора с ником -=Shura=- про джаву - искать гуглем по сайту телесистем фразу "anal sex")...

[sensor_ua]

Уважаемый,
я, конечно, понимаю Ваше настроение. Похоже, написание портируемого кода от Вас требуют по работе и аргументируют этим требованием использование инструмента, якобы избавляющего от проблем при портировании. ИМХО, во-первых нужно просто не уходить в крайности. Я бы сказал просто - ассемблер не обеспечивает портируемость априори. Это совсем не значит, что Си её обеспечивает безо всяких дополнительных мер. Существуют разные подходы к обеспечению портируемости кода, которые можно разделить (слегка) - по разновидности применяемого компилятора и по группированию портируемых участков кода и аппаратно/инструментально зависимых. Для многих ОС есть порты под различные компиляторы (назовём упрощенно "различные синтаксически различающиеся комплекты диалектов Си и ассемблеров"). Но, например, для исходных кодов файловых систем часто выделяются аппаратно-зависимые части - функции ввода вывода - функции чтения/записи блока данных на/с носителя.
В то же время нужно было бы напомнить о самом языке Си - в нём, в отличие от других ЯВУ, например, Паскаля, НЕТ ОПЕРАТОРОВ ВВОДА-ВЫВОДА. Это не случайно. Умные книги повторять не буду - сами почитаете, если вдруг не читали.
Указанные проблемы неатомарности некоторых операций должны быть, ИМХО, понятны без утомительного застирывания. Упрощение записи ещё не повод не понимать, что же будет выполняться
x^=y; => x = x^y;
Далее вспоминаем, что x объявлена как volatile.
Начинаем вспоминать, что значение порта ДОЛЖНО быть прочитано при любых условиях, модифицировано и уж после записано назад. Уж не помню, но в C51 чтение-модификация-запись порта вроде бы была атомарной операцией, но, даже если и так, то это скорее исключение. Итого - операция ввода-вывода, если следовать канонам Си, должна быть описана функцией. (Но мы-то сами знаем, что нам надо). Конечно, если в такой функции не обеспечить атомарность, то получим тот же негативный результат. Но язык тут нипричём. Это мы не обеспечили при при написании функции её реентерабельность. Мы знаем, что прерывания могут быть, и позволяем себе такую небрежность. Но это ввод-вывод. Аналогичная по проблематике фигня с математическими библиотеками, не обеспечивающими реентерабельность - можно по незнанию/непониманию/нежеланию напороться на весь цвет проблем))
http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%...%81%D1%82%D1%8C

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

[defunct]

Недавно на телесисях была поучительная ветка. Вот она
......
Прочитайте её, интересно.

"программу на C для Tiny13" я вообще не понимаю.

Но если абстрагироваться от t13, достаточно только глянуть на код чтобы сказать - будут проблемы.
Для обеспечения портируемости полностью соглашусь с sensor_ua - надо:
1. разделять код на портируемый участок и аппаратно записимый.
2. описывать функции ввода/вывода.

Легко портируются те программы, которые фактически не зависят от аппаратуры, например, математические вычисления (БПФ, фильтры и т.п.).

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

А для работы с аппаратурой есть небольшая прослойка - ОС, которая и затачивается под требуемые платформы.

[sensor_ua]

А для работы с аппаратурой есть небольшая прослойка - ОС, которая и затачивается под требуемые платформы.

ИМХО, скорее BSP, который протачивается , если предполагается использование ОС, под конкретную/ые ОС.

[Petka]

Очень хочется покидать камушки в огород тех, кто пишет на Си и верит в миф о лёгком портировании кода.

ИМХО выделенная часть фразы лишняя.
Проблемма не в Си а в заблуждениях.

Это почти классический пример - ЯВУ скрыл от программиста важнейшую деталь реализации:

Скрыл? Ужас! Ну и что? Хотите открою тайну? Одна строчка в большинстве языков не "превращается" в одну машинную команду.

Надеяться на лёгкую портируемость проектов с одного МК на другой - это путь в страну Грабляндию.

А писать каждый раз непортируемые программы и алгоритмы это путь в ту же страну, только проездом через "Геморляндию"

P.S. Сейчас меня обвинят в том, что я не люблю или не умею писать портируемые программы, что большинство программистов в мире пишут только портируемый код, и что за портируемым кодом будущее. В ответ замечу одну большую разницу - не сравнивайте программирование для PC и для МК.

Тот пример, который Вы привели как раз показывает то, что разницы между PC и МК при программировании на ЯВУ нет. Проблема синхронизации задач и разделения обхих ресурсов при многозадачности, успешно решаемая на PC аналогично должна решаться и на МК. Если "думать узко" то и будут возникать такие непредсказуемые и загадочные проблемы. Успешно пишу большие и сложные программы на Си под PC и МК. и ни разу не пожалел что ЯВУ скрыл от меня какие-то мифически "важные детали реализации". Гораздо приятнее отладить алгоритм на ПК, а потом практически без переделок применить его в МК. Си это позволяет. А вот с асмом придётся сходить в "грябляндию" =)

[Прохожий]

"программу на C для Tiny13" я вообще не понимаю.

Но если абстрагироваться от t13, достаточно только глянуть на код чтобы сказать - будут проблемы.
Для обеспечения портируемости полностью соглашусь с sensor_ua - надо:
1. разделять код на портируемый участок и аппаратно записимый.
2. описывать функции ввода/вывода.
Если работа с аппаратурой - не самоцель портируемой программы, то может так случиться что при переходе с платформы на платформу вообще ничего не переписывается... пример - IP стек.

А для работы с аппаратурой есть небольшая прослойка - ОС, которая и затачивается под требуемые платформы.

Т.е., обобщая по-порядку:
1. Подбираем подходящую ОС и с помощью напильника в виде смеси С и АСМ (или С в чистом виде?)подгоняем ее под желаемую функциональность.
2. Опять же разделяем софт на 2 части - аппаратно-зависимый и нет (тоже работа).
3. Аппаратную часть пишем на смеси С и АСМ (или С в чистом виде?).
4. Независимый кусок пишем на С или С++.
Поправьте, если что-то пропустил.
И что, такой подход однозначно гарантирует отсутствие обсуждаемых ошибок? Или уменьшает затраты на их поиск?

[Petka]

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

Совсем нет. Ошибки ошибками, а переносимость переносимостью. При переносимости переносится как работающий код, так и ошибки в нём.

[sensor_ua]

Т.е., обобщая по-порядку:

Даже не смешно.

1. Подбираем подходящую ОС и с помощью напильника в виде смеси С и АСМ (или С в чистом виде?)подгоняем ее под желаемую функциональность.

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

2. Опять же разделяем софт на 2 части - аппаратно-зависимый и нет (тоже работа).

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

3. Аппаратную часть пишем на смеси С и АСМ (или С в чистом виде?).

Пишем по возможности не на асме, потому как часть может быть также портируема в рамках как минимум семейства камней (например, работа с УАРТом в м8 и м88 похожа, но оно разное как минимум из-за разных имён регистров, разного количества управляющих регистров и т.п. Но работа спортами от этого не меняется) - если протачивание несущественно по сложности/затратам, то разруливается #ifdef-ами.

4. Независимый кусок пишем на С или С++.

А есть что-то против (кроме ответственно проведенного п.1 - всмысле программист отправляет электронщика в сад из-за несоответствия ресурсов поставленной задаче)?

И что, такой подход однозначно гарантирует отсутствие обсуждаемых ошибок?

Чтобы ошибок не было, нужно ничего не делать.

Или уменьшает затраты на их поиск?

Уменьшает и существенно - уже отлаженный софт трогать не надо.

[SSerge]

И в конце концов приходим к неутешительному (для некоторых) выводу:
"Что ни делай, а головой думать всё равно придётся!"

[Прохожий]

Совсем нет. Ошибки ошибками, а переносимость переносимостью. При переносимости переносится как работающий код, так и ошибки в нём.

Оно-то понятно. Но имелись ввиду ошибки, связанные именно с портируемостью, типа тех, что во всяких-разных ОС закрыты критическими секциями. От этого такой подход гарантирует?
К примеру. В основном теле вычисляем некий 16 битный параметр. Его, затем, передаем в обработчик прерывания путем двух операций байтовой пересылки. Где гарантия того, что прерывание не наступит сразу после первой команды, если человек забыл его запретить перед выполнением этих двух команд?
А если человек портирует софт с 16 разрядного МК на 8 разрядный? Или с 32-х разрядного на 16-ти разрядный?

[ArtemKAD]

А есть что-то против (кроме ответственно проведенного п.1 - всмысле программист отправляет электронщика в сад из-за несоответствия ресурсов поставленной задаче)?

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

После чего следует вопрос программисту - а на кой закладывать в устройство ресурсы, которые в 2-4 раза превышают требуемые для решения задачи (причем как по объему так и по скорости)?

Сообщение отредактировал ArtemKAD - Oct 6 2007, 14:23

[sensor_ua]

От этого такой подход гарантирует?

Не очень понятна суть вопроса. Если портировать, то портировать. Если писать новое, то писать. Если умеете писать, то прочитать некий код и увидеть ОЖИДАЕМЫЕ потенциальные проблемы сможете. Бездумно присоплить можно и кактус к берёзе, но елочка в пятнышко не получится

В основном теле вычисляем некий 16 битный параметр. Его, затем, передаем в обработчик прерывания путем двух операций байтовой пересылки. Где гарантия того, что прерывание не наступит сразу после первой команды, если человек забыл его запретить перед выполнением этих двух команд?

Тут Вы что-то напутали. В обработчик ничего не передаём - он сам своё возьмёт Но проблема понятна - как пример переменная отсчёта таймаута, модифицируемая (обычно декрементом) в обработчике прерывания таймера. Заботиться нужно
Вот пример критической секции от ReAl (я, правда мог чего чуток зацепить, но работоспособность сохранена) - так пишу
#define ATOMIC_CODE(_code_) do { \
unsigned char sreg = SREG; \
cli(); \
{ _code_; } \
SREG = sreg; \
} while(0)

Но читаю uint16 переменную (так как проверяю на ноль)
с помощью такого

#define Lo(X) (*(((unsigned char*)&X)+0))
#define Hi(X) (*(((unsigned char*)&X)+1))

#define __countdown16(X) ((Hi(X))?true:(!!(Lo(X))))
получается несколько компактнее (в силу специфики задачи)

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

После чего следует вопрос программисту - а на кой закладывать в устройство ресурсы, которые в 2-4 раза превышают требуемые для решения задачи (причем как по объему так и по скорости)?

Потратить в 2 раза больше времени можно за свой счёт. ЗА это время конкурент может выйти на рынок с изделием с чуть бОльшей себестоимостью, но его потом уже можно и не выдавить.
Если же задача сэкономить пару центов на кремнии и получить огромный гешефт от неслабой партии изделий, то тут программиста, не умеющего сделать глубоко оптимизированный код, нужно гнать или воспитывать. Но портируемость и глубокая привязка (считай АСМ) обычно не сидят рядом. Портируемый софт уменьшает time-to-market, но может (не всегда) требовать несколько бОльший ресурс по кремнию. Плясать нужно, ИМХО, от денег. А кремний всё дешевеет. Сегодня LPC2138 стОит в розницу почти также, а LPC2103 меньше, чем ATmega128. А LPC2378 дешевле ATmega2560. Да, самые дешёвые чипы конкурируют только между собой, но всё относительно. Если задача чуть сложнее, чем может влезть в ATtiny13, то следующее ценовое предложение сразу даёт в сравнении запас по ресурсам. Для изделий же с небольшими партиями разница по оплате труда программиста и затратам на кремний будет заметна - нынче дешевле кремний
А насчёт 2-4 раза, то посмотрите сами, где необходимость, а где "так получилось". Не нужно обобщать.

[Прохожий]

Не очень понятна суть вопроса. Если портировать, то портировать. Если писать новое, то писать. Если умеете писать, то прочитать некий код и увидеть ОЖИДАЕМЫЕ потенциальные проблемы сможете. Бездумно присоплить можно и кактус к берёзе, но елочка в пятнышко не получится

А если цейтнот? И хочется все-таки бездумно?

Тут Вы что-то напутали. В обработчик ничего не передаём - он сам своё возьмёт Но проблема понятна - как пример переменная отсчёта таймаута, модифицируемая (обычно декрементом) в обработчике прерывания таймера. Заботиться нужно

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

[rezident]

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

А какие еще другие способы существуют? Я в таких случаях передачи параметров только способы с флагами использую.

[sensor_ua]

А если цейтнот? И хочется все-таки бездумно?

Дык кто мешает? Вспоминается Шри Ауробиндо - писал примерно такое: "в мире не много людей, умеющих думать, но ещё меньше людей, умеющих не думать". Результат может быть самый разный. Но "если всё заработало сразу, то количество ошибок чётное"(С).

Я ничего не напутал.

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

[Прохожий]

А какие еще другие способы существуют? Я в таких случаях передачи параметров только способы с флагами использую.

Такой, как у уважаемого sensor_ua. В основном цикле: запрещаем интересующее нас прерывание -> пересылаем данные -> разрешаем интересующее нас прерывание, если я правильно вник в его код.

[rezident]

Такой, как у уважаемого sensor_ua. В основном цикле: запрещаем интересующее нас прерывание -> пересылаем данные -> разрешаем интересующее нас прерывание, если я правильно вник в его код.

Я не очень хорошо знаком с AVR и мнемоникой его команд, но CLI по-моему это запрет всех прерываний.

[sensor_ua]

CLI по-моему это запрет всех прерываний.

Ну да. В IAR __disable interrupt(). Только в том макросе сначала сохраняется состояние регистра статуса (там где флажок разрешения прерывания сидит), потом запрещаются прерывания, а после выполнения кода восстанавливается содержимое регистра статуса, т.е. если прерывания до выполнения такого кода были запрещены, то они по выходу не будут разрешены, в отличие от пары
__disable_interrupt();
{_code_;}
__enable_interrupt();

[Прохожий]

Дык кто мешает? Вспоминается Шри Ауробиндо - писал примерно такое: "в мире не много людей, умеющих думать, но ещё меньше людей, умеющих не думать". Результат может быть самый разный. Но "если всё заработало сразу, то количество ошибок чётное"(С).

Ну вот, приехали... Значит получается, что выигрыша по сравнению с АСМ нет. Мотивировка:
1. Надо изучить ОС, в которой, как правило, не без косяков. Избавиться от чрезмерной функциональности. После этого, внимательно посмотреть ейный порт на желаемый вычислитель. Желательно при этом еще и разобраться с архитектурой последнего, включая систему команд.
2. На всякий пожарный просматриваем собственные ранние опусы на предмет косяков типа вышеприведенного.
3. Разбираемся в дядином софте, который желаем придрючить к системе, в плане будущих подобных эксцессов.
Выполняя все вышеперечисленные пункты делаем по дороге пару - тройку ошибок, которые замечаем только на объекте. Все - дело сделано.

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

Какую- такую конкретику?

[rezident]

Ну да. В IAR __disable interrupt(). Только в том макросе сначала сохраняется состояние регистра статуса (там где флажок разрешения прерывания сидит), потом запрещаются прерывания, а после выполнения кода восстанавливается содержимое регистра статуса, т.е. если прерывания до выполнения такого кода были запрещены, то они по выходу не будут разрешены, в отличие от пары
__disable_interrupt();
{_code_;}
__enable_interrupt();

Я конечно же заметил, что SREG сохраняется. Дело-то ведь не в этом. Прохожий написал

В основном цикле: запрещаем интересующее нас прерывание -> пересылаем данные -> разрешаем интересующее нас прерывание, если я правильно вник в его код.

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

[Прохожий]

Прохожий написал

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

Дело в том, что я не особо силен в AVR, и мне показалось, что так будет логичнее. Я, лично, пользуюсь разными способами защиты данных в зависимости от обстоятельств. Прерывания стараюсь запрещать как можно реже.
Можно воспользоваться способом, позаимствованным из PLC. Там это дело выполняется один раз для всех переменных и всех прерываний в конце или начале основного цикла. При этом, запрет прерываний должен быть глобальным.

[sensor_ua]

Ну вот, приехали...

Вспоминается анекдот о Василии Ивановиче с Петькой и лабораторной работе с тараканом. "Вывод: Без ног не слышит".

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

Я Вам ни разу не предлагал ставить ОС или обсуждать необходимость её применения. Только коснулся вскользь способа обеспечения "всеядности" во многих ОС. Использовать ОС или нет здесь обсуждается в соответствующих темах.

2. На всякий пожарный просматриваем собственные ранние опусы на предмет косяков типа вышеприведенного.

Я привык доверять коду, прошедшему проверку. Некачественный продукт останется некачественным, если не приложить усилий.

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

Если не разобраться, то результаты чаще неудовлетворительны. Если Вы заплатили деньги за какую-нибудь библиотеку, то смело можете требовать внимания от техподдержки, ежели прикурчиваете фри вариант, то врядли всё будет гладко сразу. А тем более при портировании кода с одной платформы на разительно отличающуюся. Украинская поговорка говорит "Дешева рибка - пагана юшка" (дешёвая рыбка - плохая уха). Как пример - недавно пытались прикрутить NutOS к борде почти не отличающейся от референсной схемы. А не тут-то было - такого конфига железа в их конфигураторе вааще не поддерживается, а перетачивать через окучивание lua и кое-как притёртые #ifdef-ы - не сладкое дело. Оно по минимуму прицепилось, но нафиг такие обрезки. Положили туда реверсом (плата на ATmega2560) свою старую наработку - BSP от платы с мегой128 плавно перерос в своё время в BSP для плат на LPC2138, потом для LPC2378, а теперь прикрутили обратно. Дрова в основном пошли от м128. Протоколы пошли без перетачивания. Шедулеры старые довели до актуального состояния. Выгребли пару внесенных неосмотрительно траблов с обращением ко __flash. Кстати в коде для LPC (Keil) для совместимости такие модификаторы (__flash, __generic) были написаны (с оглядкой на мегу), но, естественно, заглушены пустышками.

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

Стараемся не делать. А Вы?

Какую- такую конкретику?

Я не понял, кто кому чего передаёт. Через какие флаги. Я пишу модульно. Прерывания "живут" где-то в BSP и приложение о них не знает ничего, кроме того, что они есть (правильнее - могут быть разрешены). Использую неожидающие функции ввода-вывода и очереди заданий для пересылки данных.
Может, имеете в виду случай, как, например, функциональный генератор, работающий в жёстком риалтайме, реализованный в обработчике прерывания таймера? Типа хочу выдать столько импульсов такой-то длительности и с такой-то паузой - как передать эти параметры этому драйверу, если параметры не uchar и вааще не один параметр? Да, можно пытаться через флаги. Примерно так в конце концов и получается. Только обновление данных практически безболезненно делается в том же теле обработчика после выполнения предыдущих заданий. Если нужно жёстче, то, ИМХО, нужно поднимать тактовую, чтобы не был страшен джиттер при запрещении/разрешении прерываний.

[ReAl]

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

Ну так запись в "не-атомарно-доступную" используемую в прерывании переменную и есть один из этих "крайних случаев".

ATOMIC_CODE( var_16_bit = new_value; );
запретит прерывния в самом худшем случае (когда двухбайтовую переменную new_value тоже сначала надо зачитать из ОЗУ) на просто ужасающие аж десять тактов! Аж в два с половиной раза дольше, чем выполнение команды ret!
Ну ладно, следующая команда тоже будет выполнена при запрещённых прерываниях и если после этого ATOMIC_CODE будет стоять эта самая команда ret, то хором прерывания будут запрещены на 14 тактов. Если программа к этому критична, то нужно писать на ассемблере, там можно сократить до пяти тактов :-)

Макрос ни в коем случае не планировался для запихивания внутрь него больших кусков кода. Собственно, как тут уже говорилось, думать головой всё равно надо

[rezident]

Ну так запись в "не-атомарно-доступную" используемую в прерывании переменную и есть один из этих "крайних случаев".

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

думать головой всё равно надо

естественно я согласен

[Прохожий]

Я Вам ни разу не предлагал ставить ОС ...
Я привык доверять коду, прошедшему проверку...

Ладно, оставим ОС в покое и собственный код тоже. Допустим, там все ОК.

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

Тогда получается, что все идет к тому, что софт для МК надо покупать. Т. е. модель получения качественного продукта для МК стремительно приближается к тому же самому для PC.

Стараемся не делать. А Вы?

Вам как ответить? Как хотелось бы или правду?

Я не понял, кто кому чего передаёт. Через какие флаги. Я пишу модульно. Прерывания "живут" где-то в BSP и приложение о них не знает ничего, кроме того, что они есть (правильнее - могут быть разрешены). Использую неожидающие функции ввода-вывода и очереди заданий для пересылки данных.

Нет, речь идет о чисто автоматном программировании, когда сначала создается автоматная модель того или иного процесса, опирающаяся в своих входных переменных на прерывания и поллинг, а потом, функции переходов и выходов реализуются как в обработчиках прерываний, так и в основном теле программы. Процесс, если он быстрый как бы "расползается" по прерываниям, а если медленный, то группируется в основном теле. Для взаимодействия процессов, используются "защищенные" переменные различной длины.
Приблизительно так...
Такой подход гарантирует формальную верификацию алгоритма и его кодировку как на ЯВУ, так и на АСМ. И еще получается реальная событийность.

[defunct]

Т.е. нужно помнить где именно данная конкретная переменная может измениться и запрещать именно эти прерывания,

Это как раз пример того как можно ухудшить портируемость кода.

а в примере запрещаются все прерывания.

А этот способ будет работать на любом процессоре. Если нам нужна портируемость выбираем его.

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

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

[sensor_ua]

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

Автоматное программирование в том виде, который пропагандирует Шалыто, требует, если грубо, специального языка. Некоторые механизмы использования "безопасных" переменных можно подсмотреть в использовании семафоров - правильная процедура модификации завсегда безопасна. Что касается практической реализации, то ближе к реальной - nesos FSMOS http://www.nilsenelektronikk.no/nenesos.html, хотя есть свои нюансы. Я бы напоминил ещё и о Protothreads, которое может перекрыть множество задач с необходимостью хранить состояние.
А если Вы попробуете реализовать переключения в обработчиках прерываний, например, на ARM, то с очень большой вероятностью Вам потребуется ОС, потому как main выполняется в одном режиме ядра, а прерывания - в другом. Так что Вас, похоже, нужно агитировать таки за ОС

Тогда получается, что все идет к тому, что софт для МК надо покупать. Т. е. модель получения качественного продукта для МК стремительно приближается к тому же самому для PC.

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

[ReAl]

Можно и без запрета прерываний обойтись

Взвести флаг "буду модифицировать", по которому обработчик прерывания не должен обращаться к данной переменной в данном входе?
Ну это зависит от того, что хуже - задержать все прерывания на пару микросекунд или же в этом одном прерывании задержаться с обработкой на один период прерываний. Бывает и такое.
Можно вообще завести две переменные и атомарно изменяемый (байтовый) флаг - какой из них прерывание может пользоваться и модифицировать другую, а потом менять состояние флага. Но это нужно знать, чего именно хочешь.
IMHO, для большинства случаев запрет прерываний на пару-тройку микросекунд при помощи того ATOMIC_CODE не вносит в программу ничего плохого и дешевле по коду и ОЗУ, чем все эти танцы с флагами ради великой идеи "не держать прерывания запрещёнными", даже на время в полтора десятка тактов процессора, раза в три-четрые больше, чем выполнение команды ret
Может, тогда и подпрограммами не пользоваться чтобы джиттер не вносить? Опять-таки, бывает и такое, бывает и уход в sleep определённых фазах работы программы, чтобы даже за счёт rjmp/br* джиттер убрать. Но, опять IMHO, как раз это особые ситуации, для программ, где всё просчитано по шуткам тактов. Мне почему-то кажется, что большинство программ - это не ногодрыжество с точностью до такта.

[Прохожий]

Автоматное программирование в том виде, который пропагандирует Шалыто, требует, если грубо, специального языка.

Мне ближе Рефлекс, хотя я не во всем согласен с автором этого проекта. Там априори гарантируется сохранение потенциально опасных переменных.

ближе к реальной - nesos FSMOS http://www.nilsenelektronikk.no/nenesos.html, хотя есть свои нюансы. Я бы напоминил ещё и о Protothreads, которое может перекрыть множество задач с необходимостью хранить состояние.
А если Вы попробуете реализовать переключения в обработчиках прерываний, например, на ARM, то с очень большой вероятностью Вам потребуется ОС, потому как main выполняется в одном режиме ядра, а прерывания - в другом. Так что Вас, похоже, нужно агитировать таки за ОС

Спасибо за информацию, потому как за ОС агитировать меня не надо. Просто проекты до сих пор были обозримыми. Не более 15 процессов с разной скоростью. И 18-ый PIC - это не ARM. До сих пор этого хватало. Если придется заниматься чем-то более монстрообразным, тогда и подход будет другим - с ОС, изучением чужого кода и т.д и т.п.

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

Дык, это понятно. Не платишь денег - делаешь сам. Платишь - за тебя это делают другие. Но Вы абсолютно правы - где гарантия, что эти "другие" не подведут тебя под монастырь?
А с другой стороны, бывают такие МК проекты, что один человек с ними уже не справляется.

[sensor_ua]

Мне ближе Рефлекс

Обнаружил тут целую ветку http://electronix.ru/forum/index.php?showtopic=15909
Припомнилось, что когда-то даже взглянул. Неприятный осадок остался (Русские буквы в языках программирования у меня ассоциируются с дописыванием соавторов в научных работах, авторских свидетельствах и т.п. Интересно, почему индусы до сих пор на санскрите какой-нибудь удалой язычок не слабали?) Сомневаюсь, что Рефлекс можно притянуть к микроконтроллерам

[_Pasha]

Господа!
А заметили ли Вы, что программирование на асме - в современном смысле слова это не программирование. Лично я, владея огромным уже количеством ассемблеров, программистом себя не считаю.
Призываю всех не приветствовать впредь бессмыленную полемику не тему "Что лучше - С или асм"

[Прохожий]

Обнаружил тут целую ветку http://electronix.ru/forum/index.php?showtopic=15909
Припомнилось, что когда-то даже взглянул. Неприятный осадок остался (Русские буквы в языках программирования у меня ассоциируются с дописыванием соавторов в научных работах, авторских свидетельствах и т.п. Интересно, почему индусы до сих пор на санскрите какой-нибудь удалой язычок не слабали?) Сомневаюсь, что Рефлекс можно притянуть к микроконтроллерам

Просмотрел указанную Вами ветку еще раз. Там ни автор ни его оппоненты не остановились на том, что алгоритм, выраженный в терминах языка, представляет собой совокупность автоматов. Т. е. процесс - это и есть элементарный автомат. Вся программа - это их совокупность.
Насчет санскрита - тут я с Вами согласен на все 100% - есть определенные правила и их надо выполнять. Но у автора есть и нормальный вариант.
Позволю себе не согласиться с тем, что этот язык нельзя притянуть к МК. Если рассматривать "чистое" железо МК как данность, некую среду, то почему бы и нет? Чем отличается (в логическом плане) железо МК от железа какого-нибудь промышленного агрегата. Те же регистры, биты, входы, выходы. На самом деле очень похоже.
К сожалению, автор делает акцент именно на пром. автоматику. Там ему однозначно ничего не светит...

[sensor_ua]

Но у автора есть и нормальный вариант.

Посмотрел ЧаВО - действительно упоминается. Но в доке только русские буквы. На сайте слить кроме доки нечего.

[Прохожий]

Господа!
А заметили ли Вы, что программирование на асме - в современном смысле слова это не программирование. Лично я, владея огромным уже количеством ассемблеров, программистом себя не считаю.
Призываю всех не приветствовать впредь бессмыленную полемику не тему "Что лучше - С или асм"

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

Сообщение отредактировал Прохожий - Oct 7 2007, 18:10

[sensor_ua]

Наверняка есть еще.

)) Регулярно поднимаются вопросы о борьбе с выравниванием и упаковкой структур - классика 8-D

[_Pasha]

А смысл этого конкретно разговора - это не противопоставление ЯВУ, С в частности, и низкоуровнего программирования (АСМ), а поиск оптимальной точки с которой необходимо уходить от таких понятий как регистр АЦП, Регистр статуса, Бит переноса, Обработчик прерывания и т. д. в сторону более абстрактных вещей.

Нет таких! НЕТУ!!!
Для меня ЯВУ - средство автоматизации труда программиста (извините за банальность). И вот, дебильные макросредства всех асмов, которые не содержат IRP, IRPC, REPT и т.д. надо компенсировать чем-то. А на "С" пишутся именно аппаратно - независимые вещи.
З.Ы. И не дергайте вы ногами в Си

Сообщение отредактировал _Pasha - Oct 7 2007, 18:29

[Прохожий]

Посмотрел ЧаВО - действительно упоминается. Но в доке только русские буквы. На сайте слить кроме доки нечего.

[attachment=14256:attachment] - вот методичка для студентов, простите - это без всяких намеков .
Просто это единственное место, где есть английская нотация - в конце опуса.
Но я лично имел ввиду Рефлекс просто, как концепцию программирования в real-time.
На мой взгляд, ему действительно далеко до реального заместителя ОС при реализации крупных проектов на навороченном МК.
А вот для микро- и мини- проектов - было бы неплохо. Правда, для этого ему опять же кое чего не хватает - инкапсуляции смены состояния процесса непосредственно в обработчике прерывания, например. Опять же непонятно наличие ярко выраженных временнЫх переменных, сведенных в отдельное понятие ТАЙМАУТа. В МЭК 61131-3 - это все как-то более логично.
И последнее, применение языка затрудняет полное отсутствие компиляторов на известные платформы типа AVR, PIC, ARM. Боюсь, что до этого не дойдет никогда...

Нет таких! НЕТУ!!!

Да не кричите Вы так громко . Объясните, лучше, чего нету. А то я оглох и ничего не понял...

А на "С" пишутся именно аппаратно - независимые вещи.

Аппаратно независимые вещи пишутся в стандартах и учебниках на различных языках. А уж на чем они будут воспроизведены в коде - дело десятое. К стати, есть еще масса способов обеспечения абсолютной переносимости кода, в том числе и аппаратно-программные. Тот же МЭК 61131-3 для промавтоматики, к примеру. Причем это все реально работает лет 30.

З.Ы. И не дергайте вы ногами в Си

Нет буду. Назло...

[sensor_ua]

вот методичка

спасибо, взглянул. (и у меня, оказывается, в свалке загруженного оно уже было) Если заменить FOR ALL на public (использую #define __public extern // с подчеркиваниями чтоб с плюсами не дралось если что), а FOR LOCAL - на private (использую #define __private static), то замечу, что достаточно давно подобные конструкции (TIMEOUT и т.п.) использую и языком не называю (придумывал не я, но использую). С первого взгляда типов для "защищенных" (или чего там надо?) переменных не заметил

[Прохожий]

спасибо, взглянул. (и у меня, оказывается, в свалке загруженного оно уже было) Если заменить FOR ALL на public (использую #define __public extern // с подчеркиваниями чтоб с плюсами не дралось если что), а FOR LOCAL - на private (использую #define __private static), то замечу, что достаточно давно подобные конструкции (TIMEOUT и т.п.) использую и языком не называю (придумывал не я, но использую).

А мне лично локальные переменные не нравятся (видимо не умею их готовить ). Потому как приводят к излишней возне со стеком. Хотя, использую их достаточно часто.
Насчет TIMEOUT - отдельная тема. Чем таким временнЫе переменные заслужили отдельного понятия в виде функций типа delay(Time) или TIMEOUT(Time)?
А основная причина, по которой я упоминал Рефлекс, в том, что там отражена достаточно близкая мне модель программирования, позволяющая обеспечить многозадачность без привлечения ОС даже на языках низкого уровня.

С первого взгляда типов для "защищенных" (или чего там надо?) переменных не заметил

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

[SasaVitebsk]

Хочу предложить посмотреть на всё это с другой стороны.

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

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

С другой стороны длина аналогичной программы на СИ меньше. И это объективно. От этого никуда не уйдёшь. Переменные - более обособлены. Программа более структурирована. В связи с этим время отладки будет меньше. Я беру средне статистический случай. Можно сделать трудновылавливаемую ошибку в любой программе на любом языке. В среднем время отладки будет меньше. Что и подтверждает практика.


По поводу портирования мне кажется всё сказано. Даже если на Си она будет трудно портируема, то на АСМе она вообще не будет портируема. Здесь просто нет альтернативы. Как минимум пока нет.

[sensor_ua]

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

Ой, не разобрался видно я в этом Рефлексе, ну да и ладно.
Насчёт многозадачности и ОС - я бы это обсуждал в соответствующей теме соответствующего раздела. Но пару слов скажу. Вспомним ДОС и появление Виндовс - во главу угла при появлении Виндовс ставились удобство работы (красота-масота и т.п.) и МНОГОЗАДАЧНОСТЬ. Но тот же ДОС обслуживал (и много ещё где живёт и обслуживает) несколько ПРОЦЕССОВ (ввод-вывод, распределение памяти и т.д.) и аж одну ЗАДАЧУ пользователя. Такой задачей (но крутой) была и Windows3.1. "Обычные" ОС для встраиваемых решений на микроконтроллерах, например, uCOSII, предлагают незамысловатое упрощение - и процессы и задачи становятся равнозначными и сливаются в одно - task - всё-таки в задачу (зато система называется многозадачной). Оно вроде и пофиг, но всё-таки есть нюансы. Особенно различия заметны во временной базе задач/процессов. (это отдельная тема).
Если Вам нужно только переключение задач, то это одно. Если одна задача может "неукоснительно рекомендовать" другой выйти из неактивного состояния, то уже возникают вопросы (когда будет доставлена рекомендация, ограничен ли срок её жизни, как она соотносится с другими рекомендациями, и когда она начнёт выполняться) (т.е. шедулер может понадобиться), но если нужно общение между задачами/процессами, то получится ОС. Как бы Вы реку не назвали, течь от этого она не перестанет. Но в то же время определений ОС много, какое верное - не знаю

[Прохожий]

Ой, не разобрался видно я в этом Рефлексе, ну да и ладно.

Да оно то и не надо. Просто пример...

Насчёт многозадачности и ОС - я бы это обсуждал в соответствующей теме соответствующего раздела. Но пару слов скажу. Вспомним ДОС и появление Виндовс - во главу угла при появлении Виндовс ставились удобство работы (красота-масота и т.п.) и МНОГОЗАДАЧНОСТЬ. Но тот же ДОС обслуживал (и много ещё где живёт и обслуживает) несколько ПРОЦЕССОВ (ввод-вывод, распределение памяти и т.д.) и аж одну ЗАДАЧУ пользователя. Такой задачей (но крутой) была и Windows3.1. "Обычные" ОС для встраиваемых решений на микроконтроллерах, например, uCOSII, предлагают незамысловатое упрощение - и процессы и задачи становятся равнозначными и сливаются в одно - task - всё-таки в задачу (зато система называется многозадачной). Оно вроде и пофиг, но всё-таки есть нюансы. Особенно различия заметны во временной базе задач/процессов. (это отдельная тема).
Если Вам нужно только переключение задач, то это одно. Если одна задача может "неукоснительно рекомендовать" другой выйти из неактивного состояния, то уже возникают вопросы (когда будет доставлена рекомендация, ограничен ли срок её жизни, как она соотносится с другими рекомендациями, и когда она начнёт выполняться) (т.е. шедулер может понадобиться), но если нужно общение между задачами/процессами, то получится ОС. Как бы Вы реку не назвали, течь от этого она не перестанет. Но в то же время определений ОС много, какое верное - не знаю

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

[defunct]

Да оно то и не надо. Просто пример...
А если Вы изначально при проектировании оперируете такими понятиями как "процесс", "обмен данными между процессами", "время реакции", "защищенные данные"? То, что вы пишете уже изначально работает как ОС. Вопрос нужна ли она в этом случае? Не окажутся ли такие понятия, как мьютекс, семафор, очередь задач, контекст задачи, тот же шедулер немного лишними?

Вот и ответ на все ваши вопросы выше. У вас появился собственный ОС, вы прекрасно знаете как он работает, распространите его на несколько платформ и пишите под него легко переносимые "процессы". Портируемость как для Вас будет обеспечена. Без доли иронии.

[_Pasha]

Почти шепотом:
IAR большой, ему видней...
На фоне дебилизации ассемблеров в "С" портируются жизненно-важные вещи типа TCP/IP стека, IEEE754, библиотеки поддержки LCD и прочее.
После чего очевидное преимущество в скорости разработки привлекает новых пользователей. Проблема остается. Проблема в том, что детерминированный результат получается разными способами.
Теория назначений, способная давать решение проблемы, до сих пор развивается.

Зримая аналогия дилеммы ЯВУ-АСМ - это автоматическая трассировка платы. Совершенно неприемлема для 80% устройств.

Абстракции...
JMP, CALL,ADD, XOR(EOR), RET(RETURN), NOP в конце концов, есть во всех контроллерах. Так на хрена же в одном случае пишется RJMP, а в другом GOTO, JP, JMP ? Получается, что из-за отсутствия мета-мнемоник мы ищем абстракции, перепрыгивая довольно солидный пласт абстракций, содержащийся в кодах операций и операндах?

Еще один прикол - появление псевдо-сишных директив в ассемблерах. Не менее смешно, чем написать TCCR1B+=0x01; и думать, что таймер запустится за 3 цикла.

Целесообразность портирования. Например умножение двух signed int на меге - 19 тактов, на пике -35 . Смысл плавно умирает. Но, если не знать этого - все зашибись!

Думаю, что ОС должны вырастать из схемы целевого устройства. Тогда и весь бардак сойдет на нет. На ОС возложить (писать на асме):
1. Инициализацию всего хозяйства,
2. Все прерывания,
3. Поддерживаемый набор функций через таблицы адресов (как продолжение таблицы векторов прерываний),
4. Сами базовые функции. Конечно, чем меньше их, тем лучше
5. Даже арифметику. Как-то заглянул в листинг Mikroelectronika Pascal for dsPIC. Написал (Паскаль):
var A,B,C:real;
begin
B:= 1.0; A:= 3.1415926; C:= A+B+ B*B;
end.
***** Ё-моё, какая там баранина !!! *****
Ничего DSP-шного не используется. Куча кода в режиме совместимости с PIC18. Вот так...

Сообщение отредактировал _Pasha - Oct 8 2007, 00:09

[sensor_ua]

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

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

[mse]

Этта...Смотрю, читаю...;О) ИМХО моё такое. Ц- не ЯВУ. Это некий асемблер для абстрактного процессора. Поэтому "Ц vs АСМ", смысла не имеет. Ессно, переносимость с "АСМ" на "АСМ" будет легче, чем с АСМ на АСМ.
Бо ЯВУ ращщитаны, ИМХО, на работу с датыми, работа с аппаратурой спрятана от программера в ОСи и либраритеках, а в эмбеддерстве немаловажное значение имеет имана работа с жылезом. Поэтому от конструкций типа TCCR1=real_time_tick_data или PORTx=all_leds_on никто не застрахован, даже в языке самово-самово ВУ. В этом смысле, ЯВУ для МК, штука частично фиктивная.
Значить, карма у нас такая - ручками шоркать битики. А тут уж, автоматизировать процесс переноса шорканья, кто во что горазд. ;О)

[forever failure]

Бубен как бубен. Похлещще видывали, эт даже не бубен, а так, бубенчик. Чо к чему в попу тарахтеть на четыре страницы, на асме точ так же на такие же грабли можно наступить.

[_Pasha]

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

... И за этими громкими понятиями часто кроется очень мало программного кода. Надо тему открыть по поводу параллельного программирования на avrasm.

[Dog Pawlowa]

...Значить, карма у нас такая - ручками шоркать битики. .. ;О)

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

Кстати, есть места, где необходимость управления прерываниями не зависит от разрядности контроллера:

Код

void CTB0(void) //clear transmitt buffer
{   __disable_interrupt();    
    tx_head0=tx_tail0=0; // clear tx buffer indexes
    __enable_interrupt();
}

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

[sensor_ua]

Кстати, есть места, где необходимость управления прерываниями не зависит от разрядности контроллера:
void CTB0(void) //clear transmitt buffer
{ __disable_interrupt();
tx_head0=tx_tail0=0; // clear tx buffer indexes
__enable_interrupt();
}

Если правильно понял, то это работа с кольцевым буфером? Простите, а зачем индексы занулять, если кольцевой?

[defunct]

Если правильно понял, то это работа с кольцевым буфером? Простите, а зачем индексы занулять, если кольцевой?

Обнулять не обязательно конечно, но даже такую конструкцию
head = tail;
надо защищать.

Думаю, что ОС должны вырастать из схемы целевого устройства. Тогда и весь бардак сойдет на нет. На ОС возложить (писать на асме):

Не всегда есть необходимость ОС писать на ASM.
Например задачи промавтоматики не требуют супер-пупер скорости, и гораздо выгоднее чтобы алгоритм работы ОС хорошо просматривался, в ущерб скорости. ASM вставки можно понять и принять если их неболее 1-2% от всего кода.

[Dog Pawlowa]

Если правильно понял, то это работа с кольцевым буфером? Простите, а зачем индексы занулять, если кольцевой?

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

[sensor_ua]

но даже такую конструкцию
head = tail;
надо защищать.

IMHO, не всегда. Обычно обнуление буфера передачи производится при выключенной передаче.

[defunct]

IMHO, не всегда. Обычно обнуление буфера передачи производится при выключенной передаче.

если обнуление делается при выключенной передаче, тогда какие вопросы к head = tail = 0 (начальная инициализация)?
вопрос к __disable_interrupt() / __enable_interrupt() должен быть. ;>

[sensor_ua]

тогда какие вопросы к head = tail = 0 (начальная инициализация)?

Скоропостижное выключение самой передачи наглым уравниванием индексов не встречал Потому и озадачился

[Прохожий]

Абстракции...
JMP, CALL,ADD, XOR(EOR), RET(RETURN), NOP в конце концов, есть во всех контроллерах. Так на хрена же в одном случае пишется RJMP, а в другом GOTO, JP, JMP ? Получается, что из-за отсутствия мета-мнемоник мы ищем абстракции, перепрыгивая довольно солидный пласт абстракций, содержащийся в кодах операций и операндах?

Эта проблема в промавтоматике закрыта, или частично закрыта. Есть некие примитивные мета-языки LD или FBD. Ими широко пользуются. Проекты с одного ПЛК портируются на другие совершенно без проблем. Но там это дело приводили в порядок такие монстры как SIEMENS и ABB в течение 10 лет.
В области МК, на мой взгляд, это невозможно.

Еще один прикол - появление псевдо-сишных директив в ассемблерах. Не менее смешно, чем написать TCCR1B+=0x01; и думать, что таймер запустится за 3 цикла.

Целесообразность портирования. Например умножение двух signed int на меге - 19 тактов, на пике -35 . Смысл плавно умирает. Но, если не знать этого - все зашибись!

А зачем портировать с одного 8 битового процессора на другой?

Думаю, что ОС должны вырастать из схемы целевого устройства. Тогда и весь бардак сойдет на нет. На ОС возложить (писать на асме):
1. Инициализацию всего хозяйства,
2. Все прерывания,
3. Поддерживаемый набор функций через таблицы адресов (как продолжение таблицы векторов прерываний),
4. Сами базовые функции. Конечно, чем меньше их, тем лучше
5. Даже арифметику. Как-то заглянул в листинг Mikroelectronika Pascal for dsPIC. Написал (Паскаль):
var A,B,C:real;
begin
B:= 1.0; A:= 3.1415926; C:= A+B+ B*B;
end.
***** Ё-моё, какая там баранина !!! *****
Ничего DSP-шного не используется. Куча кода в режиме совместимости с PIC18. Вот так...

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

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

Да я просто о том, что при определенных стилях и подходах к программированию в сочетании с величиной проекта можно миновать все эти понятия и получить достаточно надежный результат. При этом человек оперирует совершенно другими абстракциями, таким как конечный автомат, состояние, функция переходов и т. д. Эти абстракции проверены временем. Их трудно испортить субъективизмом проектировщика.
Поэтому и возник вопрос насчет ОС, которую порой пытаются применять там, где в этом нет никакой необходимости. Если нет нужды в применениии монстрообразных МК, то зачем ОС? А если не предусматривается смены платформы, то и С, в общем-то, не нужен.

Ну и русский язык вытеснен в этой специфической области за неимением собственных устоявшихся терминов/понятий;(
А врачи говорят на латыни...

Хорошо, давайте попросим автора Рефлекса сделать дополнительно еще и украинский вариант .

[SasaVitebsk]

Кстати, есть места, где необходимость управления прерываниями не зависит от разрядности контроллера:

Код

void CTB0(void) //clear transmitt buffer
{   __disable_interrupt();    
    tx_head0=tx_tail0=0; // clear tx buffer indexes
    __enable_interrupt();
}

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

И в добавление скажу что я с аналогичным хомутом (определение свободного места в кольцевом буфере) столкнулся впервые на 80х51 на ASM. И никакой ЯВУ мне не скрывал сути. Я её и так не заметил. Поэтому зачем приплетать одно к другому непонятно. Единожды столкнувшись - учитываешь возможность такой ошибки на любом языке.

[defunct]

А зачем портировать с одного 8 битового процессора на другой?

Чтобы не зависеть от какого-то конкретного семейства / модели МК.
Вот взять PIC16F877, с позапрошлого года цены на него просто взлетели и сейчас составляют в некоторых точках от $12 за шт. Те же задачи можно переложить на AT89S52 ($1 за шт) или m16 например ($2 за шт).

[Прохожий]

Чтобы не зависеть от какого-то конкретного семейства / модели МК.
Вот взять PIC16F877, с позапрошлого года цены на него просто взлетели и сейчас составляют в некоторых точках от $12 за шт. Те же задачи можно переложить на AT89S52 ($1 за шт) или m16 например ($2 за шт).

Можно было бы взять какой-нибудь 18-ый PIC тоже недорого и ничего не портировать. У Microchip-а c этим делом все в порядке. Своего клиента они не упустят. Даже в 24-х PIC-ах остался целый пласт команд от 18-го (хотя они там и нафиг не нужны), чтобы у людей голова не болела.

[Proton]

Хорошо, давайте попросим автора Рефлекса сделать дополнительно еще и украинский вариант .

2Прохожий
Сделайте дополнительно ещё и украинский вариант Рефлекса.

[Прохожий]

2Прохожий
Сделайте дополнительно ещё и украинский вариант Рефлекса.

Это не ко мне, это к автору... Только горилку и сало не забудьте.

Сообщение отредактировал Прохожий - Oct 8 2007, 17:01

[_Pasha]

Не всегда есть необходимость ОС писать на ASM.
Например задачи промавтоматики не требуют супер-пупер скорости, и гораздо выгоднее чтобы алгоритм работы ОС хорошо просматривался, в ущерб скорости. ASM вставки можно понять и принять если их неболее 1-2% от всего кода.

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

А зачем портировать с одного 8 битового процессора на другой?

Кроме ценовых свойств есть еще:
1. Факторы, влияющие на топологию платы. В моем случае (силовая электроника) это уже не смешно.
2. Уникальное сочетание периферии. Например, есть такой PIC18F2431. Там есть HW-модуль обработки инкрементального энкодера. В большинстве случаев юзеру он нафиг не нужен. А тут вдруг- выстрелило некое количество. Какой выход? ИМХО, обогатить модельный ряд, потому что сразу заложить целых три ноги в светлое будущее, в некий универсальный преобразователь частоты - это смерть. Потому что через месяц упорного анализа и переоценки ценностей девайс раздуется до размеров Солнечной Системы.
В общем, моя история больна таким набором МК: ATmega48,AT90PWM3,MC68HC908MR8, PIC18F2431,dsPIC30F2010,dsp56F801. И надо портировать программу, которая уже 2 года "GOOD ENOUGH", но писана для меги 8.

При этом человек оперирует совершенно другими абстракциями, таким как конечный автомат, состояние, функция переходов и т. д. Эти абстракции проверены временем. Их трудно испортить субъективизмом проектировщика.

Попробую испортить.
Все объясняют реализацию конечного автомата какими-то переменными состояния, переходами и т п
Писал когда-то. Тошно. Читать - страшно. Решил автоматизировать. Через таблицы переходов.
Но функциональное наполнение-то осталось. Геморлэнд.
А вот конструкции для параллельного программирования - непрерывные фрагменты кода с переопределяемой точкой входа, тоже вроде как конечный автомат, но результат при реализации на AVR (подчеркиваю, только на AVR) настолько великолепен, что натянет по эффективности/читабельности/простоте отладки добрый десяток альтернатив. Только не портируется, зараза.