Keil Оптимизатор Опции

[vlad_new]

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

Сообщение отредактировал vlad_new - Jan 16 2012, 16:49

[scifi]

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

[vlad_new]

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

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

Сообщение отредактировал vlad_new - Jan 16 2012, 19:52

[scifi]

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

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

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

[vlad_new]

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

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

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


Сообщение отредактировал vlad_new - Jan 16 2012, 20:18

[aaarrr]

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

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

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

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

[vlad_new]

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

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

[scifi]

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

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

Код

char* const nv_Buf_RS485 = (char*)Buf_RS485;

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

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

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