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

[Прохожий]

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

Такой, как у уважаемого 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
Припомнилось, что когда-то даже взглянул. Неприятный осадок остался (Русские буквы в языках программирования у меня ассоциируются с дописыванием соавторов в научных работах, авторских свидетельствах и т.п. Интересно, почему индусы до сих пор на санскрите какой-нибудь удалой язычок не слабали?) Сомневаюсь, что Рефлекс можно притянуть к микроконтроллерам