В Keil CMSIS-RTOS RTX в параметрах задач указано:

Что это, зачем? Писал, не задумываясь. Теперь хочу просветиться.

ну к примеру у вас на контроллере два UART

и в одном проекте на modbus реализован на UART0 9600 а на UART1 модем AT 115200

а в другом проекте modbus реализован на UART1 19200 а на UART0 модем AT 36000

а задачи одинаковые.

тогда для проекта 1

typedef struct{
int port;
int speed;
}Suart_init;

const Suart_init mb_cfg = { 0, 9600 };
task_start( mb_task, ..., (void*)mb_cfg );

где

void mb_task( void const* arg )
{
Suart_init* arg_p = (Suart_init*)arg;
uart_open( arg_p->port, arg_p->speed );
...
}



то есть как реально в RTX синтаксис вызова не в курсе, но суть передал - вызов задач с конкретными параметрами.

Вот зачем оно конст...?

если оно будет на стеке, то по моменту запуска самой задачи естветсвено всё уплывет.

то есть так нельзя
Suart_init mb_cfg = { 0, 9600 };
task_start( mb_task, ..., (void*)mb_cfg );

а так можно
const Suart_init mb_cfg = { 0, 9600 };
task_start( mb_task, ..., (void*)mb_cfg );

или так
static Suart_init mb_cfg = { 0, 9600 };
task_start( mb_task, ..., (void*)mb_cfg );

Спасибо! Понял. Проверил в действии. Работает.

Нужно поправить - брать адрес структуры.

тогда уж
task_start( mb_task, ..., (void const*)&mb_cfg );

Вообще-то компилятор должен "съедать" этот параметр при вызове функции и без явного преобразования. Как и для параметра "void *" компилятор должен принимать указатель на любой неконстантный объект из соответствующего адресного пространства. Если отказывается, то это наверное плохой компилятор. Без явного преобразования очевидно, что безопаснее.


Какая разница в данном случае, с амперсандом или без? В случае когда голый идентификатор структуры без указания поля. Однозначнее, конечно, было бы с амперсандом, но на данный момент в Си оба варианта вроде бы одинаковые.


Квалификатор const не запретит передачу локальной переменной. Не встать на грабли - забота программиста. const в параметре "проявит себя" только внутри тела функции, когда этот указатель без явного преобразования будет передан параметром или присвоен другому типизированному указателю на константу.


Второй вариант тоже будет на стеке. Просто менять его значения нельзя будет.

Возможно, в других языках варианты одинаковые. Но не в С. В C можно структуру передавать в функцию, именно, по значению, а не по ссылке. Т.е., имя структуры не есть ее адрес. В отличие от массива.

Чем отличается результат двух вариантов выражений со структурами ниже?

Если отличаются, то в каких компиляторах.

Идентификатор/имя массива тоже не является адресом его первого элемента. Иначе выражение &mass было бы аналогом &(&mass[0]). Взятие адреса от адреса в Си допустимо?

Тем, что второй вариант не компилируется.
Keil V5.1.0
source\exsUSB.c(164): error: #171: invalid type conversion
Led9_id = osThreadCreate(osThread(Led_thread), (void *)led9);
А в каком компиляторе работают оба?

не знаю как в высших материях, но в дизамсе передается просто адрес. Задача компилятора - ругатся при попытке записи по const*



если это AVR то будет во флеше, если ARM то как указано в линкере ROM_region. А в других архитектурах как решит компиляторы, но размещать const на стеке вызывающей задачи - сомнительно.



да, мой косяк. Вместо компилятора под руками была текила, и это зло вчера меня победило

Предъявите объявление led9.
Проверьте для корректности все предыдущие версии Кейла. Если раньше оба варианта допускались, то как разработчики это обосновали и обосновали ли?


То есть от компилятора не зависит?


Я имел ввиду "проявит себя" на этапе компиляции. По сути то же самое. Вне тела функции наличие квалификатора const никак не ограничивает передачу параметров по сравнению с вариантом без квалификатора const (в прототипе функции).

А (void *)&mass скомпилируется, если это идентификатор массива? Кейла 5-ого под рукой нет чтобы проверить. Идентификаторы массивов, структур и юнионов должны (были) отличаться в применении. При явном преобразовании адреса логично было бы чтобы выражение с идентификатором было приведено к адресу силами самого программиста, дабы не возникало неоднозначностей.

Жаль, в Си нет операторов детипизации указателей, сохраняя исходное адресное пространство. В идеале ещё как-то наследующих выравнивание и другие атрибуты. Вручную для безопасной работы приходится объявлять указатель на void и потом его присваивать к другому типизированному указателю.

Проверьте на том, что имеете.
Мое мнение - для массива &mass и mass - одно и то же. Особенность языка.

Не совсем. &mass[0] и mass - вот это одно и то же. Точнее mass неявно приводится к &mass[0].

В IARе я так много раз делал без замечаний. Но если 5-ый Keil ругается на явное преобразование адреса от имени структуры без амперсанда, то использование аналогичного синтаксиса к имени массива порождает другой глюк. Кейлу логично было бы запретить использование (void *)&mass. Иначе будут новые грабли.

Наверное, так оно и есть.

Проверил. Получил.
uint16_t arr[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
uint16_t *parr = &arr;

source\Exercises.c(159): error: #144: a value of type "uint16_t (*)[10]" cannot be used to initialize an entity of type "uint16_t *"

На uint16_t *parr = &arr[0]; не ругается, естественно.

На uint16_t *parr = (uint16_t *)&arr; тоже не ругается!

Естественно. Вы же делаете явное приведение типа. В этом случае каждый сам себе злобный Буратина, а компилятор умывает руки - если вы его просите о таком, значит знаете, чего хотите.

Значит, компилятор "имеет представление" о том, что такое &arr. Почему же он неявное приведение не делает?
Ассемблерные команды получаются те же, что и для uint16_t *parr = arr;

Потому что таковы правила языка. Это называется "безопасность типов" (type safety). Он не даем вам случайно спутать теплое с мягким и мух с котлетами. Но и оставляет вам право сделать это, если вам это действительно нужно, через явное приведение типов.

В процессорах с Гарвардской архитектурой AVR, PIC, 8051 константы размещаются во флеше. Флеш расположен в другом адресном пространстве чем ОЗУ и используются другие ассемблерные команды для доступа. Разумно расположить константные массивы во флеше, поскольку если располагать их в ОЗУ, то будут использована и флеш тоже (откуда-то ведь будет инициализация читаться). Передавая такой параметр в функцию надо дать знать в каком пространстве памяти находится параметр, чтобы функция использовала правильные ассемблерные команды.
Для этого и используется слово const. Pic использует слово flash кажется, но это в микрочиповском компиляторе. С другими не работал не знаю.

Ну вот где вы такое видели применительно к языку C в реальном мире? Квалификатор const лишь дает гарантию, что компилятор не допустит изменения переменной с таким квалификатором. И никоим образом не влияет на адресное пространство. Если вы объявили переменную с квалификатором const - под нее точно так же будет выделено место в ОЗУ.
вот вам простой пример:
А теперь объясните, каким образом print_string() будет понимать - ей передали указатель на строку во флеше или на строку в ОЗУ?

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

Нет. слово const используется для другого. Как раз слово flash явлается расширением языка - квалификатором адресного пространства и используется именно для этого.

А вот в процессорах с единым адресным пространством (ARM, x86, MSP430) досуп к переменным во флеше или в ОЗУ на чтение одинаков, поэтому именно в них возможно указать линкеру размещать константные переменные во флеше не загружая копию в ОЗУ. А можно указать хранить в ОЗУ и все будет как у больших машин.

А каким образом это делается? Буквально в двух словах, если можно.

Есть способ - указать квалификатор static.

В ОЗУ этих строк не будет. Сразу будут читаться из флэш программы.

При чём тут static вообще? На ARMах const в определении переменной заставляет компилятор (и линкер) размещать её во флэше. На AVR такое не работало из-за раздельного адресного пространства.

Использование ключевых слов static и/или const для управления размещением данных (будь то flash или еще что) - вещь на 100% зависящая от конкретного компилятора. Стандарт С/С++ вообще не знает о том, что такое flash и как в нее помещать данные

Поэтом, прежде чем советовать что то типа
стоит указать, для каких именно компиляторов это справедливо

Ни для каких. static очевидно может изменяться во время выполнения программы и не может быть размещён во flash.
const размещает переменные во flash независимо от квалификатора static - актуально для IAR для ARM.

Для компилятора, входящего в состав Keil uVision. Пользуюсь этими квалификаторами.
О каком компиляторе идет речь, видно в теме неоднократно.



static const
Строка просто const из flash переписывается в ОЗУ, и уже из ОЗУ используется в функции. Лично сталкивался. И получал на форуме совет. И от кого, помню.

Что, вашему компилятору не хватает ума разместить глобальную переменную во флэше? Или вы просто не пробовали?

На примере GCC: константы складываются в секции .rodata и .rodata.* Если вы в скрипте линкера разместите эти секции в flash (выходная секция .text), то они там и будут жить. А если вы поместите их в выходную секцию .data, то они будут размещены в ОЗУ и проинициализированы из флеша. Примерно так:


Компилятор - помещать ее в секцию данных "только для чтения". А линкер - размещать ее там, куда укажут в управляющем скрипте. Для прошиваемых намертво в небольшие процессоры программ эта секция обычно размещается во флеш. А вот если процессор побольше и программа загружается в огромное динамическое ОЗУ из какой-нибудь последовательной флешки - то и секцию констант программист скорее всего разместит в ОЗУ.

Это какая-то чудовищная недоработка вашего компилятора. Допустим вы в файле myfile1.c размещаете глобальную переменную:
Если вы объявите ее с квалификатором static, то ее область видимости будет ограничена только этим файлом и вы не сможете в файле myfile2.c написать

А без static - сможете. И нет никаких объективных причин для компилятора размещать константу в одном случае в ОЗУ а в другом - во флеш.

....

Хотя... Я, кажется, понял в чем дело - вы имели дело с локальными переменными функции. В этом случае да, без static компилятор обязан создать переменную в точке объявления и уничтожить ее в конце области видимости. И сделать он это может только в ОЗУ. А с добавлением static к объявлению локальной переменной она перестает быть автоматической и может быть размещена во флеше, что вы и наблюдали. То есть никакой мистики тут нет и все происходит строго в рамках стандарта.

Да, с локальными строками.

О. А тут все о глобальных переменных спорили

На 51 уж 15 лет не писал, а на AVR и PIC реально размещал и утрамбовывал память.

К сожалению давно не программирую на этих процессорах. У кого есть IAR AVR?
Давайте простую программу напишем и создадим листинг ассемблерный. Тогда все станет ясно. Заодно map файл посмотрим.
Оптимизацию надо отключить

Что вы этим гениальным кодом хотите проверить? В ch сначала попадёт '5', затем в str1[0] запишется '5', затем в ch запишется '2', а строка ch=ch ничего не делает - она заоптимизируется почти всегда. Ах да, str1 и str2 будет размещено в ОЗУ.
Если вы хотели str2 размещать во флэш, то надо было указать квалификатор __flash.

Об этом и речь квалификатор __flash - это расширение для данной архитектуры.
Для стандарта языка квалификатор const - запрет на изменение переменной, не важно локальная она или глобальная. Размещенеие переменной в памяти - дело линкера.
На тех же 51-х архитектурах обычный указатель содержит 3 байта - 2 адрес объекта (переменной) и один байт тип памяти, где этот объект распложен. А далее библиотека раскручивает цепочку и выбирает способ считывания данных. Но возможно и прямое указание типа памяти квалификаторами idata, xdata, code. (применительно к KEIL, у ИАР думаю похожая ситуация в отношении МCS-51).
const только запрещает изменение перемнной не более того.

Только в случае с указателем есть одна тонкость.
-- это указатель на константу. Вы не можете изменить то, на что он указывает, но можете изменить его самого:
-- константный указатель. Вы не можете изменить этот указатель, но можете изменить то, на что он указывает:
-- константный указатель на константу. Вы не можете изменить ничего.

Удостоверился в Кейл для глобальных переменных:
- const (и static const, естественно) размещаются и используются из flash,
- инициализированные переменные без квалификаторов (и volatile, естественно) при старте из flash переносятся в RAM и уже там используются.
Конкретно задавать нестандартные квалификаторы не вижу необходимости.

Для процессора с линейным адресным пространством (ARM, Cortex).

Для x51 все запутаннее - там есть и медленные generic указатели (с отметкой об адресном пространстве в старшем байте и с генерацией кодов доступа ко всем пространствам при обращении по такому указателю) и указатели на конретное адресное пространство (с квалификаторами data, idata, xdata и т.д). Тут подробнее. Насколько помню, по умолчанию (без спецификатора адресного пространства) константы располагаются в памяти data, т.е. в непосредственно адресуемом ОЗУ.
С C166 не работал, не знаю, но судя по сегментированному адресному пространству тоже должны быть хитрости.
Для других процессоров Keil вроде как компиляторов не делает.

Ну и как это связано с явным преобразованием идентификатора структуры? Разве при этом недостаточно информации о том, что "заказчик" желает взять именно её адрес?

Более интересна ситуация, которую я нашёл у себя в исходниках, применения явного преобразования адреса к локальной (чаще регистровой) переменной. Вроде:

Вот здесь (во второй строке), спрашивается, компилятору хватит информации не облажаться.

Никак. С тем вопросом уже разобрались.

Как это - адрес у регистровой переменной? Ну, для PIC-ов, где все переменные - регистры, можно понять. А вы о каком процессоре говорите?

Там прикол в виртуальности этого адреса. По сути происходит/должно происходить интерпретация значения (битового представления) float как целочисленный u32. И это без использования временного union где-нибудь в оперативной памяти. Этот виртуальный адрес компилятор временно создаёт в своём личном формате хранения на этапе компиляции и только для себя, но передавать программе/программисту не обязан. А проблема заключается в явном преобразовании адреса с явным указанием (нового) адресного пространства.


Обоснование Кейла не озвучено.
Ещё интересно, как Кейл интерпретирует такое выражение:
void *ptr;
ptr = mb_cfg; // структура из начала темы
Тоже, наверное, запретил. Хотя к массиву будет допустимо.


Кейлов много. Нужно указывать версию и для какого процессора. А при неуказании, сперва проверить на всех компиляторах Кейл для разных процессоров

В середине темы по вашей просьбе я показал часть проекта с задачами - светодиодами, которая реально испытана на плате MCBSTM32 от Keil. Лично у меня нет никаких вопросов, которые стоило бы еще обсуждать в рамках заданной темы.

upd. Нет, всплыл один вопросик. Выходит, константы лучше делать глобальными? Испортить их нельзя. А пригодиться они могут в разных функциях не раз.


Cогласно языку C.

Вы всегда отвечаете вопросом на вопрос?
Может лучше посмотреть чем отгадывать?



О чем я и твержу.

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


Если константа на самом деле где-то может пригодиться, то можете делать глобальной. Все подряд делать глобальными не стоит - экспортируется много символов и размываются интерфейсы у модулей.

Стандартный прототип memcpy:
void *memcpy(void *s1, const void *s2, size_t n);
копирует из ОЗУ в ОЗУ.


IAR AVR именно так и интерпретирует const. Как не меняющий адресное пространство.

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

В вашем коде для AVR все переменные будут размещены в ОЗУ. Хотите их размещать во флэш - пишите __flash. У Viko константы были размещены во флэш потому что он пользовался компилятором для ARM.

Я вам не верю. Когда я в конце 90х работал с ним константы были размещены во флэш.

Ваше право. Но убеждать остальных на основании только лишь вашей веры как-то неразумно.