Как использовать переменные типа volatile и одновременно пользоваться стандартными библиотеками, где все сплошником char*.
Приходится везде вписыать что то типа:
volatile char Buf1[100], Buf2[100];
.....
memcopy((char*)Buf1,(char*)Buf2,20);
.....
Если же Buf не будут volatile, то оптимизатор выбрасывает строки типа: Buf1[0]=7;
Может как то можно переопределить в билиотеках char на volatile char, ну или еще как то справится с этими неудобствами?

А почему это проблема? Если выбрасывает, значит они не нужны.

Вот пример кода.
Заполняем массив Buf_RS485 и отправляем его в UART. Первый байт в массиве определяет его длинну.
Первые 2 строки после case00: копируют некие данные известной длинны. Поэтому в следующей строке эта длинна и записывается.
Далее, если есть Cnt_sob, то туда еще кучка всего вписывается и другая длинна перезаписывается.
Таким образом отправляется либо короткий, либо более длинный пакет.
Так вот 3 строку оптимизатор игнорирует и пакет отправляется с неверной длинной!

Несовсем понятно о какой строчке идёт речь. Можекте пометить её в исходнике?

Угу. Пометил. Вот эта имелась ввиду:
Buf_RS485[0]=u-1;

Этот код какой-то кривой. Например, переменная 'char Buf_RS485;' используется как массив. Что это? Неточно запостили? Будьте любезны постить реальный код. Кто знает, что Вы там ещё переиначили? И лучше с отступами, а также обрамлять тегами (code)(/code).
Вы подозреваете баг в компиляторе, а я подозреваю баг в программе. Чаще бывает второе.

Уже подправил. Реальный код слишком длинный. К тому же похожие проблеммы с оптимизатором не редки. И как правило когда индекс =0, или он const.
Иногда помагало обозвать переменную индекса массива как static. Но вот в этом куске бубны с танцами не помогли.

Это глюки в программе с вероятностью 99%.
Поскольку реальный код видеть нет возможности, то больше сказать нечего. Даже если бы был реальный код, было бы слишком трудно в нём разобраться, так как написан он (если судить по показанному отрывку) не самым лучшим образом, мягко говоря.

Update:
Забыл добавить. О глюках судят по результатам выполнения программы. Например, если содержимое пакета данных на проводе отличается от ожидаемого. Если Вы смотрите на содержимое переменных в отладчике и видите неожиданные значения - не факт, что это глюк. На высоких уровнях оптимизации бывает так, что данные отладчика весьма слабо коррелируют с исходным кодом. И вообще отлаживать удобнее на самом низком уровне оптимизации.

Да отступы почему то здесь не выходят, хотя в режиме редактирования я их вижу. А на счет глюков в программе: ну так она же работает если без оптимизатора или
Buf_RS485 описать как vu8 ( volatile unsigned char ), но тогда в сотнях местах приходится вписывать явное преобразование типов. memcopy((char*)Buf_RS485,.... )

Updete: Да я в таких случиях смотрю код ассемблера. А о веревке: Так и есть другое устройство принимает пакет с ошибочной длинной.

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

Потому что Вы не оформили свой код в теги [сode] [/сode]

Если бы оформили - все бы отсупало:

В сотнях мест?!! О ужас! Вероятность глюка в программе приблизилась к 99,9%.
Зачем вообще включаете оптимизацию? Если работает - не трогайте. Не открывайте ящик Пандоры. Есть большой класс ошибок, чувствительных к уровню оптимизации. Они Вам нужны?

Не знал что так надо. Век живи век учись. Ща попробую.

Подобные симптомы свидетельствуют отнюдь не в пользу версии о правильности программы, а совсем даже наоборот.


Странный совет. Правильнее было бы не выключать оптимизацию, дабы по мере написания программы выгребать содержимое ящика.

Естественно. Внешний массив и обязан быть volatile, тем более что он используется в прерываниях. Ну так я и спрашивал как бы
сделать так, чтоб в стандартные библиотеки передовать тип volatile без явного преобразования типа повсеместно.
Может через какой нибудь typedef переопределить типы параметров в библиотеке. А может еще какие то другие есть решения.

Подозреваю, что автор - очень начинающий программист на Си. Зачем лишние грабли на дороге?

В KEIL-е без оптимизатора на код смотреть противно. Да и скорость почти 2 раза ниже.

Нет, не обязан.

Можно тупо объявить указатель на этот массив и использовать его в вызовах библиотечных функций:

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


Лучше не начинайте. А то я начну рассказывать, какие эмоции вызывает Ваш код :-)

Чтобы научиться по этой дороге ходить, разве нет?

Думал я про указатель. Иногда так и делаю. Код нормальный с точки зрения 8 битных процессоров, где указатель является очень
сложной конструкцией и работает через библиотеки жутко медленно. ARM-наоборот. Ему только указатели и подавай.
Да я собственно и не претендовал на программиста. На перелопачивание СРМа и MS-DOSа меня в свое время хватало, а Андроид писать и не собираюсь.
Но в любом случае, как я Вас понял, пороблемма снимается изменением стиля работы с буферами. Типа заводим буфер и сразу на него указатель. А про
индексы на всегда збываем.
PS: Подредактировано.

Да, забыл. Можно просто макрос. Ну и я переврал немного с указателем: не нужно его делать const, иначе он ничем не лучше volatile - требует приведения типа.

Вот только хотел спросить про const Я подредактировал предыдущее сообщение.
Сенкю.

Позволите позанудствовать немного?

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

Хороший совет тем, кто перелез с 8 битников на ARMы, а таких сейчас очень много.
К стате почему эту строчку оптемизатор отбрасывает - понятно. Поскольку Buf_RS485[0] нигде далее не используется, она, типа, и не нужна! А то что
это нужно прерыванию компелятор в упор не видит. А зря. Вот и приходится либо где нибудь влепить холостую дурь типа k=Buf_RS485[0];
либо терять скорость на куче volatile.
Но вопрос то стоял не почему оптимизатор в Keil-е дурной , а как в библиотеке подмену на volatile сделать. Хотя может это и не возможно, поскольку
библиотека уже оптимизирована на регистровые операции и заставить библиотечные ф-ции сбрасывать регистровые переменные в ОЗУ вряд ли возможно.
А может я и ошибаюсь. Собственно я это и хотел выяснить.

Опять всё по кругу...


Абсолютно верно.


Компилятор вообще много чего не видит и не должен видеть. Вы как будто пытаетесь ему приписать роль этакого телепата-волшебника, угадывающего намерения программиста. А программист на что?


Лепить холостую дурь не надо.
А вот одно из применений volatile - для переменных, используемых как в основном потоке, так и в прерывании. Действительно, каждый доступ к volatile потенциально замедляет программу. Поэтому число таких доступов уменьшают до минимального необходимого уровня. Есть как минимум несколько способов это сделать.


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


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

Продолжу от лица неопытных новичков
Можно было бы конечно продублировать все библиотечные функции своими аналогами, внутри которых заводятся локальные переменные нужных типов, им присваиваются значения параметров и с ними вызываются библиотечные функции. Но мне кажется, это несколько коряво, хотя как лучше - не знаю.
Простейший пример из практики - преобразование числа в строку. Мне было проще написать эту функцию самому, чем копаться в библиотеках. Она принимает аргумент типа int. А мне надо вызывать её и с int и с char. Два решения лежат на поверхности:
1 - написать дубль этой же функции, но принимающий char
2 - заводить лишнюю переменную int куда присваивать нужный char, и с ним вызывать функцию
Оба решения мне не нравятся. Но как сделать красивее - не придумал. Использование указателя не только не помогло, но и таит ошибку при исполнении.

А почему бы не передавать ей char без лишних телодвижений?

Хороший вопрос!
Я сначала написал, а потом начал что-то вспоминать про "неявное преобразование типов" и т.п. Будете смеяться, но не помню, почему я был вынужден так изголяться... Или там передавался наоборот указатель на int...

ЗЫ щас попробую найти код и посмотреть
Точно, принимаю указатель Чтобы переменная изменялась а не передалась по значению и все.



а в другом месте нужен вызов с указателем на char



ЗЫ вышеприведенный код содержит ошибку - это не финальная редакция, я её потом исправил - тут неправильно пишутся буквы 16-ричной строки числа, поскольку A, B и т.д. идут не сразу после "9" в таблице символов Но на принципиальном вопросе это не отражается, а его напомню кратко - нам надо передавать не числовое значение переменной в функцию, а указатель на неё, чтобы функция в процессе своего выполнения изменяла этот параметр. А при передаче указателя на char в указатель на int он обрастет ещё соседним байтом и будет ошибка.

Зачем, нет ЗАЧЕМ делить на 16 последовательным вычитанием? Можно просто написать n >> 4.

С указателями - да, никакой автоматики не предусмотрено.

Точно! Спасибо за науку. Буду задавать больше глупых вопросов - подозреваю, что узнаю и не такое. Например, если длина кольцевого буфера равна степени 2, то инкремент его индексов делается тоже как-то проще, без прямой проверки на превышение. Но стоит поиграться размером буфера в дефайнах - и всё поломается


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

Можно записать в дефайне размер как (1 << N). Но лучше, конечно, делать нормальную проверку - не тот случай, когда стоит экономить две копейки.

Я тут попробывал интерсный тип указателя к библиотекам подставлять. (void*) - свободный тип называется. Тогда все автоматом преобразуется как
надо. И все нормально работает. Посмотрел код на ассемблере - все впорядке. Ничего лишнего не добавляется. А что нельзя было сразу в библиотеках такой интересный тип использовать? Бит он и в африке бит, как его не переобзави.

А как надо? volatile он не отменит - все равно преобразовывать придется
Где надо там используется. В memcpy например
void - это не бит! void* вообще разименовать нельзя, не преобразовав сначала во что то осмысленное