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

[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-ух томник Бергера. Но там больше по программированию. Из этого сложно общий вывод сделать. Надо понять идеологию построения. Короче надо что-либо написать... запустить.
Там не вытесняющая многозадачность. Там очень много существенных отличий.

[AVI-crak]

Зачем всё это сделано? Там можно заменить блок на горячую. Как аппаратный блок так и программный. Можно подключится к производственной линии, и править программу прямо во время её работы. Она при этом занимается производственным выпуском.

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

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

Но если подобный садомазо режим существует - я требую детального объяснения его алгоритма работы. С наскальными рисунками - выполненные кровью убитых мамонтов.

[SasaVitebsk]

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

Непереводимая игра слов. Да нет. Там всё по честному - компилится и заливается.

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

Но если подобный садомазо режим существует - я требую детального объяснения его алгоритма работы. С наскальными рисунками - выполненные кровью убитых мамонтов.

К ОСи ты не имеешь отношения. Там даже функций нет и вызовов. Она как бы не существует.
Грохнуть можно. При несовпадении блока переменных. У тебя сразу линия клац. ))
В моём случае десятки ампер в фазе. )) Очень шумно. При этом сразу брак. ))
Собственно мы ушли от темы.

Предложение топикстартеру - Поставить внешнюю флэшку. Подгружать прошивку пусть медленно, как 100% загружено рестартовать с заливкой новой прошивки.

[AVI-crak]

Непереводимая игра слов. Да нет. Там всё по честному - компилится и заливается.

Реальность, китайский автономный чпу станок, работает совершенно автономно, без постоянной связи с компьютером, по "программе" записанной на флешке.
Дык вот, G код на флешке - это откомпилированная программа или всё-же набор управляющих команд?