Если у Вас лично стоит выбор — детальный разбор того, чем уже занимаешься или освоение новой архитектуры — то это Ваши проблемы. У меня такая проблема не возникает — когда даже не мне понадобилось, а знакомый попросил, я достаточно быстро разобрался и с STM8, и с IAR-ом для него (с Cosmic-ом тоже, но он без плюсов, поэтому был отставлен). Т.е. не только в оболочке, но и в том, как компилятор на низком уровне работает с камнем — это нужно было для портирования по просьбе того знакомого scmRTOS на STM8.
Сейчас у меня CM3 в ходу, для разнообразия в две разных работы заложил STM32 и LPC17. Еще в одном месте подумывал в альтерину софт-ядро какое-то затолкать, но потом решил, что для сложной работы все равно снаружи LPC17 стоит, а для средней по скорости внутри будет достаточно заточенного под задачу самодельного микропрограммного автомата с глубиной стека 3 уровня и программной памятью на 128 32-битных команд (задействовано около 100). Что-то в духе
(само собой, поля микрокоманды if и compare/wait опциональные, кроме того некоторые из команд операционного поля, тот же set, может дожидаться ack от того устройства, входному биту которого делается set/clr).
Как видите, меня хватает и новые архитектуры осваивать, и в старых детально разбираться (мне казалось, что это только помогает при освоении новых, если только новые не стараться освоить столь же поверхностно), и открытые проекты поддерживать, и свой закрытый, но бесплатный вести, и на форумах зря время тратить.

Для тех, кто плохо читает, повторяю — первые двести байт экономии получено без применения процессоро- и компиляторо-зависимых вещей. Даже предзагрузка указателя — ещё не «полностью…»

Я понимаю желание доказать свою точку зрения без доказательств, но читаем внимательно
Это называется «не насторожило»?
Насторожило задолго до того, как я за этот исходник взялся.

Пожалуйста, покажите в моём исходнике место, кторое при изменении может привести к неработоспособности программы по вине уже существующего исходника.
Вариант с привязкой к регистрам прошу не рассматривать, на всякий случай повторю еще раз
Вариант с предзагрузкой указателя можно рассматривать.
Можно было бы ещё показать на примере, какой из указанных мной, громко говоря, приёмов на какой платформе (контроллер+компилятор) может привести к значительному ухудшению кода (вместо -25% по объёму хотя бы +5%) или к его нестабильности (зависимости работоспособности от опций компилятора или размеров массивов, ...).

Какие проблемы??? Сами придумали??? Или вам так просто хочется??? ))))))))))))))


А зачем тогда на белый свет это надо было вытаскивать??? Понтов ради??? Поздравляю, у вас получилось!!! ))))
Доказательства чего вам нужны??? )))))) Вас две версии компилера "наставили на путь истинный"... вам мало??? ))))))))))))
Или вы так этого и не поняли???
avreal... прекращайте...
У меня не было желания с вами спорить... сами захотели...

А караван ползёт (Начинаем продолжать - 3).

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

Итоги:

Размер кода больше того, что было для первого этапа правок исходного варианта, но совсем ненамного. Если и тут сделать для avr-gcc аналогично второму этапу работу через указатель на структуру с форсированием загрузки указателя и привязку переменных к регистрам, то код соответственно уменьшится, но не это сейчас важно.
При этом программа уже и делает немного больше Во-первых, программа не пишет в EEPROM ключ, если он уже там есть, при этом всё равно даёт длинную вспышку светодиода, означающую «да, ключ в EEPROM толи уже был, толи только что записан, но он там есть». Во вторых, при отсутствии места для ключа в EEPROM даётся короткая серия вспышек средней длины. Eсли это не нужно, то можно убрать лишнее, сделать
и она станет так же ненамного немного короче первого варианта правок.

Я разделил приём сигнала (в прерывании) и обработку полученных данных в бесконечном цикле в main(). Т.е. тут я ту маленькую задачу, для которой «эх, королевство маловато, компилятору разгуляться негде», делю на две еще мельче.
Вообще любая задача делится на всё более мелкие. Научившись аккуратно писать отдельные предложения мы в конечном итоге научимся писать и «Войну и мир» «Властелина колец» длинные тексты.
При таком разделении программу легче модифицировать, например, менять протокол приёма либо расположение ключей (скажем, внешняя I2C EEPROM).
Кроме того, при этом упростился обработчик прерываний, что уменьшило его пролог/эпилог. Как я уже писал, вызов (не-inline) подпрограмм из обработчика прерываний приводит к сохранению/восстановлению в нём всех не callee-saved регистров. Сокращение числа сохраняемых регистров на 11 — это сокращение времени работы обработчика на 44 такта, что очень немало при периоде прерываний 9.6 МГц / 20 кГц = 480 тактов.

С той же целью облегчения модификаций я практически все параметры загнал в enum-ы и автоматизировал пересчёт времён из микро/мили-секунд в параметры работы таймеров. При желании можно сделать и длину кода в байтах полностью настраиваемой по числу битов (с автоматически выбираемым 32/16/8 разрядным типом для буфера приёма и циклом по байтам в подпрограммах поиска и записи ключа). Обойдется это, думаю, не более, чем в 40-50 байт кода.

Из интересу я сделал универсальный исходник, компилирующийся как в AVR Studio/avr-gcc, так и в IAR. Почти все необхлодимые вещи собраны в начале в #if defined(...).
Чем свежее компилятор, тем меньше ему нужно подсказок.
NOINLINE не влияет на размер кода IAR и сравнительно свежих версий avr-gcc (4.5.3, 4.7.1).
OS_MAIN ещё нужен avr-gcc 4.5.3 и IAR 6.10, уже не нужен avr-gcc 4.7.1.
Странно, но у IAR размер кода вышел немного больше, я ожидал на пару-тройку десятков байт меньше, чем у avr-gcc. Я не сильно большой поклонник IAR-а, пользуюсь им иногда вынужденно. Поэтому он у меня есть, но я в него слишком глубоко не лезу и мне сейчас не интересно разбираться в причинах. Возможно, я что-то недоуказал ему в опциях.

Естественно, я мог где-то ошибиться, необходимо подтверждение работоспособности от автора исходного проекта

Новая табличка, уже только для компиляторов, которые всегда под рукой. В колонке new размер кода для «слегка расширенной» функциональности и в скобках для «назад суженной».

В архиве проекты для AVR Studio, IAR 5.51 и 6.10, работающие с общим исходником в каталоге src.

Спрашивайте, если что-то непонятно (кроме того, зачем я всё это делал ).

Ничего удивительного....
IAR уже давно перестал быть лидером... другие компилерописатели тоже время зря не теряли...
И там где он всё таки выигрывает в объёме - проигрывает в скорости...
Поэтому сравнения компиляторов и дают в результате +- лапоть...

Чойт моя студия 4.18 не хочет открывать проект, пишет что ненаходит один или более файлов проекта.....

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

Вариант 1 -- для данного случая. Я вручную в xml-файле mreceiver.aps заменил пути к файлам на относительные. Распаковать и записать не место того, что в проекте.

Вариант 2 -- для всех подобных. Я на тех зачёркнутых файлах правая кнопка мыша (хотя какая она правая, она внешняя, на дальнем от клавиатуры краю мыша; я уже лет пять, как переложил мыша, точнее, трекбол, под левую руку и у меня то левая кнопка...) Remove File From Project. После чего добавить в проект файлы, поднявшись на каталог вверх и потом войдя в каталог src. Там два файла, mreceiver.c и pin_macros.h

как на сях будет ?
jmp 0x0000
swap R16

1)
Строго говоря, это вызов функции, а не переход. Но именно в данном случае всё равно, так как потом стек проинициализируется заново.
Берём константу 0 и приводим её к типу указателя на функцию. Потом эту функцию вызываем.
Более развёрнуто:

Должно работать в чуть менее, чем всех компиляторах/контроллерах.
Вот, например, код для x86:

Для WinAVR будет три команды — загрузка Z нулём и icall

2) Именно для WinAVR, зная что и как делается стартапом и линкером, можно обойтись одной командой call/rcall:
Вызов любой из этих "функций" компилируется в одну команду и еквивалентен переходу на нулевой адрес.


Точный ответ на именно этот вопрос -- asm("swap r16");
А вообще -- смотреть доку на компилятор.
Для WinAVR


Кроме того, avr-gcc 4.5 уже был достаточно грамотен, чтобы скомпилировать это
в это
А «свежий» avr-gcc это уже как минимум версия 4.7.

Спасибо за развернутый ответ.

[quote="avreal"]


Странно, у меня в 6.10 Ваш проект прошел на 702 байта (((.

А это без сбора в пенсионный фонд тех шести байт между векторами, которые он заполнил чем-то там (reti, если стоит псиса Initialize unused interrupt vectors with RETI instruction на вкладке System в General Options)

Последний заполненный адрес 0x2C3, т.е. размер кода 0x2C4, что равно 708, что равно 702+6.

avr-gcc тоже заполняет неиспользованные вектора, причём переходом на ловушку.

Да ужжжжж.....
У меня терпения наверное не хватит, научится настолько правильно писать на С. Программа хотя и меньше весить стала, но для новичка как я, больно тяжела для восприятия, с одними только макросами, да енумами (только что узнал что это такое.....), долго разбирался, потом со структурами я еще не дружу пока, тоже надо будет вникать.....

Кстати в протеусе проверил, не фурычит, светики вообще молчат (вместо реле, у меня тоже светик), хоть при программировании, хоть во время приема серии.
Хотя в память серия записывается (удерживать кнопку во время приема серии) но потом на эту же серию не реагирует.
Вот если что проект в протеусе.

Серия вроде правильно записывается, завтра тоже проверю наточняк.

Ну так и в «челевеческом» языке тоже не всё сразу приходит
«с одними только спряжениями глаголов, да подчинёнными предложениями»...

Ну я на свежую голову завтра попробую просмотреть.
Серия хоть правильная записывается?

p.s. Нет у меня протеуса.
XP-шка и та в виртуалбоксе.
Неужели придётся протеус ставить ?

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

Это тот самый регулятор. Кстати несмотря на 7-ми сегментник, я туда умудрился впихнуть довольно немалый функционал: индикацию температуры, частоты (вход измеряет или данные от термопары или от частоты с датчика вращения), в меню настраиваются пороги для прямого выхода управления, 8 порогов для цифрового выхода управления, настраиваются варианты отображения состояния выходов на 2-х разрядном индикаторе, настраивается режим работы регулятора и т.д.

На совсем свежую голову не вышло — сегодня последний день перед отпуском (где тут смайлик кота, собирающего грибы и всё такое прочее?)

Протеус не понадобился. Остатков свежести головы хватило.
Всё элементарно -- когда я последние зажержки да мигания переводил на тот blink и компанию, я забыл поднять SEI() выше первого delay.
Само собой, таймер receiver.led_timer некому декрементировать. Оно и висит в той задержке.
Нужно перенести одну строку.
Надеюсь, это всё.

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

Такссс......
"Начинаем задавать вопросы 1" по первой правке, (по последней вообще мало что понятно, потому начну с первой)).....

Какую роль здесь играет static? (у переменной вроде знаю, а у ф-ции....)

Для чего эта абракадабра в начале?

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

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

*) Функция main() хоть и немного обособленная, но она всё же обычная С-функция. И в принципе может рекурсивно вызывать сама себя или вызываться из других функций программы:
recur 1 2 3
И компилятор обязан оформить функцию так, чтобы она могла так вызываться. Вот на этом оформлении и экономим при помощи OS_main. У IAR для этого слово __task.
Такая функция может не сохранять регистры, которые обычно должна сохранять вызываемая функция («callee-saved registers»).
У avr-gcc тоже есть OS_task, но OS_main идёт дальше, атрибут говорит ещё, что функция начинает выполняться при запрещённых прерываниях, что даёт возможность в сложных функциях упростить вормирование кадра локальных переменных на стеке.
http://gcc.gnu.org/onlinedocs/gcc/Funct ... butes.html

Специально поискал среди Вашего шума - и нашел хоть что-то полезное. Спасибо за Ваш вклад. Но знаете, пришлось искать...

Вспомнил свои регистрационные данные (а уж точнее - обновил пароль), чтобы через 2 года зайти на форум не только как читатель. Причина проста: хочу выразить благодарность уважаемому avreal за его великолепные уроки!
- в этих уроках есть и правила хорошего тона (поверьте, не лишние даже людям, время от времени пишущим на С в течение последних 20 лет),
- в них есть приемы, которые можно применять (автор достаточно тщательно указывал подводные камни, чтобы не фыркать на возможные "эффекты"),
- в них есть практически переписанная программа для коллеги shads-а, показывающая прекрасный подход к проектированию дивайса

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

Хорошего отпуска, Учитель avreal!

Брат! Тебя очень не хватало на этом форуме.
Я все ломал голову, почему тебя тут нет..... оказ-ся ты тут был, и вот теперь вернулся - будет веселее (мы намного чаще по одну сторону барикад чем по разные)
У меня (по твоему совету и совету Леонида Ивановича) не плохие результаты в освоении C. Уже один проект готов на 50%. Сначала радовался что код быстро растет, а теперь переживаю, вдруг такими темпами да не влезет в мегу8, придется или контроллер менять (а я уже успел к нему привыкнуть), или применять советы AVReal-а.....

Нет, брат, никакого выбора! И контроллер лучше бери из серии 48-88-168-328, и такие простые и полезные советы нужно применять.

По линейке 48-88-168-328. Она же очень похожа на мегу8, но более современная. И в ней есть удобство: не влез код в 4К - берешь 8К, мало - берешь 16К, ну а до 32К твои девайсы не скоро доберутся.
А по советам. Ну, элементарное: локальные функции обозвать статиками - это что, сложно? Да и main() - для меня было новостью, что можно ее вызов упростить, но это же очень просто взять и использовать! Т.е., в моих планах пройтись еще разок по урокам уважаемого Учителя и взять на карандаш то, что бесспорно и понятно. Советую и тебе не пренебрегать таким кладом.