Использование своих секций при компиляции Опции

[zuuuuk]

Доброго времени суток.
Я применяю ARM freescale.
и в моем проекте я располагаю несколько функций в отдельной секции.

Код

uint8_t fn_ld () __attribute__ ((section(".name1")));
uint8_t fn_md () __attribute__ ((section(".name1")));
uint8_t fn_init () __attribute__ ((section(".name1")));

linker script

Код

..............
    .name1 :
    {
     . = ALIGN(4);
    *(.name1)
    . = ALIGN(4);
    } > m_name1
.............

Подскажите, а возможно расположить в одной секции несколько функций и переменную?
вот так

Код

uint8_t var __attribute__ ((section(".name1")));
uint8_t fn_ld () __attribute__ ((section(".name1")));
uint8_t fn_md () __attribute__ ((section(".name1")));
uint8_t fn_init () __attribute__ ((section(".name1")));

что для этого нужно поправить в коде или линковочном скрипте?

Прикрепленные файлы

 attribute_electronix.zip ( 1.72 килобайт ) Кол-во скачиваний: 5

 

[SasaVitebsk]

То что вы описали, использует сименс в своих контроллерах S7-300.
Там реализовано это всё очень сложно. То что перечислили AVI-crak и Сергей Борщ, это тоже не всё.
Например новая функция может память по разному использовать. Например ей понадобится больше или меньше.
Я доподлинно не знаю, озвучу только то, что вычислил косвенно.
1. Подмену осуществляет ОС. И ОС не меняется сама.
2. Подмена осуществляется вначале прохода.
3. Меняется блок. В нём может быть как 1 так и несколько ф-ций. Каждый блок имеет свою секцию памяти. Абсолютно независимую.
4. Блок, который можно поменять в нашем embedded понимании - задача ОС. ОС вылизана так, что может запускать 1000 задач. То есть не совсем так как с МК принято.
5. Любая задача может обращаться к памяти (секции) другой задачи. Но это уже чисто на совести программиста. Контроля нет. Ты уже непосредственно по адресу обращаешься.
6. В момент подмены создаётся 2 копии задачи и 2 копии данных. Есть механизм передачи данных. Но если есть существенная разница - всё равно крах наступает. То есть всё это тоже на программиста возлагается.

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

[AVI-crak]

1000 запущенных активных задач - это уже перебор. Мне удалось запустить примерно 320 копий с двойным падением производительности, 600 копий теоретически дадут падение в 7 раз, а тысяча - уже в 20-50 раз замедление. На вытесняющей ос такое количество задач просто невозможно запустить. Но смысла в диком количестве работающих задач - нет.

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

И того, меняться может математика в чистом виде, графика, и наборы инструкций во всех смысловых вариантах. Всё это очень много весит.

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

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

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

Совместное использование памяти имеет свои ограничения, по сути - это обмен сообщениями, всегда однонаправленный. В одном ограниченном блоке памяти первая задача пишет и может читать, вторая и остальные задачи - только читать.
Есть исключение для операции - занять ресурс, или что-то подобное. Цель - вписать свое имя, имеется поддержка на уровне команд асмы, ограничение - uint32_t размер, выше нет смысла, ниже - просто глупо.

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

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

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

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

[SasaVitebsk]

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

Система, я так понимаю, значительно сложнее чем настольная ОС. Там даже файловая система с дублированием. Там ARM проц. Типа ARM9, наверное. И речь не обо мне. Речь о S7-300.
Зачем всё это сделано? Там можно заменить блок на горячую. Как аппаратный блок так и программный. Можно подключится к производственной линии, и править программу прямо во время её работы. Она при этом занимается производственным выпуском. Я лично это делал причём многократно. Понимаете, одно дело, когда разрабатываешь устройство. Ты можешь отладить его. Постепенно развивать потенциал. А в старых устройствах обновлять ПО. Другое дело одна производственная линия. И больше таких нет. И стоимость её например 100 тысяч $ и более с учётом монтажа. Завод заинтересован в его окупаемости. Но какой бы сильный программист вы не были, без ошибок сделать сложно. Кроме того, по результатам эксплуатации порой что-то изменить требуется. Но для тебя линию никто останавливать не будет. Это объективная реальность.
Взглянуть - да пожалуйста. Можно почитать 2-ух томник Бергера. Но там больше по программированию. Из этого сложно общий вывод сделать. Надо понять идеологию построения. Короче надо что-либо написать... запустить.
Там не вытесняющая многозадачность. Там очень много существенных отличий.