Есть такой вот код:



Изначально предполагалось, что так как usb_txtail unsigned char, то оно досчитает до 255 и начнет снова с нуля без всяких танцев с бубнами. А фиг...

Если после этого вставить строчку:

то все работает на ура. Если этой строчки нет - досчитав до 255, начинается какая-то свистопляска, оно выводит содержимое буфера еще раз...

Есть какие-нить идеи на эту тему?

Если добавить эту строку, то элемент с индексом 255 никогда не будет записан.
Осталось разобраться, почему эта запись все ломает. Может быть, буфер случайно объявлен как usb_buffer[255]?

Есть два варианта:
1. usb_buffer[(unsigned char)(usb_txtail++)]=0x05;
2. usb_buffer[usb_txtail++ % 255]=0x05;

А Вас не смущает то, что результат работы этих двух вариантов будет разным?

Проблема не в типе char, с которым компилятор обошелся совершенно корректно, а, скорее всего, в размере буфера.

А тип самого буфера наверное unsigned int? А попробуйте-ка разбить код на две операции

и сообщите что получается.

Скомпилил вот такой код:
Так вот, после значения 255 переменная indx принимает значение НОЛЬ. Ищите косяки в программе. НИКОГДА, если переменная объявлена как CHAR, компилятор не переделает ее в INT, LONG, LONLONG или FLOAT, если вы прямо ему об этом не укажите...

"Никогда не говори ''никогда''" А про приведение типов в языке СИ вы знаете? И что бывает в случае арифметических операций с числами разной разрядности, надеюсь тоже в курсе?
Цитата из K&R (переводная, из библиотеки Мошкова). Глава 1.6. Массивы

Еще раз предлагаю инкремент индекса вынести как отдельную операцию. У меня нет IAR for AVR, чтобы проверить получившийся результат на ассемблере.

Код приведен в первом посте.

Вот еще в Википедии отыскал существенное (по-моему) замечание/комментарий, подходящее как раз для данного случая.

Раздел 1.4 Pointers and Arrays.

Что под этим подразумевается? В отладчике смотрели?
Ведь судя по приведенному коду всё должно быть нормально.
Или это в результате вставки того пресловутого условия?

Приведите сгенерированный код с условием и без него.

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

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

Полностью согласен. Впрочем, автор топика в результате получил от компилятора в точности то, о чем просил

Вы читайте, не то что выделенно большими буквами, а все предложение)

Когда мы приводим один тип к другому, мы УКАЗЫВАЕМ компилятору про тип, и, соответсвенно, разрядность переменой, тип которой мы приводим. Когда мы выполняем арифметические операции над числами разной разрядности, мы то же, неявно УКАЗЫВАЕМ компилятору на разрядность операции...

А если компилятор начнет предполагать, что после инкремента какой то переменной может произойти переполнение разрядной сетки, то все переменные, в конечном итоге, у него превратятся в LONGLONGLONGLONGLONG.....................

Для того, что бы проверить код, не обязательно иметь ИАР Си, возьмите от Борланда или Мелкософта...



К сожалению, не читал данное произведение...

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

Я вообще не понял в чём проблема!


Получится

судя по асм. листингу usb_txtail однобайтовая переменная, а значит добавленная строка вообще не влияет на результат, либо её добавляют не после "этого", а перед "этим"!

Ну да ладно читаем дальше.

А "оно" и должно выводить ещё раз! Индекс то обнулился!



Было сказано про арифметические операции в которых участвуют переменные разных типов