Глюки с char-ами в MSPGCC, то ли руки кривые... Опции

[MrYuran]

Столкнулся (уже не первый раз) с неприятной особенностью MSPGCC в части работы с переменными типа char. при подсчёте контрольной суммы пакета иногда возникают сбои.

Код

static char volatile Uart0Buffer[8];
static unsigned char Csumm;
...
Csumm=1;    
for (i=0;i<6;i++)    
{        
  Csumm += ~Uart0Buffer[i];           // вычисление контр. суммы    
}    
if(!((Uart0Buffer[6]-Csumm) & 0xff))           // контр. сумма верна и вообще

Последнее условие раньше выглядело if(Uart0Buffer[6] == Csumm) и работало через раз, пока не наложил байтовую маску. Такие вот дела.

[MrYuran]

В продолжение темы об особенностях сравнения:

Есть у меня счётчик системных тиков Time, и есть Timer, который защёлкивает текущее значение в определённый момент.
Затем происходит сравнение
if(Time-Timer>(RegDelay+10))
{DoSomething()}
То есть отсчитывается задержка и выполняется определённое действие.
Timer и Time - unsigned int.
Как мне кажется (и вроде бы так и работает), при переполнении Time всё будет продолжать работать как надо. Нет ли тут подводных граблей? (имеется в виду "проблема 2000 года")
И что произойдёт, если в Timer загонять время для будущего запуска действия (Timer=Time+Delay), а потом сравнивать
if(Time>Timer)
(Это я сейчас так сделал, а потом озаботился)
Time и Timer теперь unsigned long, но и он когда-то переполнится...

[rezident]

В продолжение темы об особенностях сравнения:

Есть у меня счётчик системных тиков Time, и есть Timer, который защёлкивает текущее значение в определённый момент.
Затем происходит сравнение
if(Time-Timer>(RegDelay+10))
{DoSomething()}
То есть отсчитывается задержка и выполняется определённое действие.
Timer и Time - unsigned int.
Как мне кажется (и вроде бы так и работает), при переполнении Time всё будет продолжать работать как надо. Нет ли тут подводных граблей? (имеется в виду "проблема 2000 года")
И что произойдёт, если в Timer загонять время для будущего запуска действия (Timer=Time+Delay), а потом сравнивать
if(Time>Timer)
(Это я сейчас так сделал, а потом озаботился)
Time и Timer теперь unsigned long, но и он когда-то переполнится...

Это вполне нормальный способ отсчета задержек и периодов времени. Я везде его применяю. Но у него есть два недостатка:
1) величина измеряемого периода ограничена разрядностью переменной. Например, у меня везде отсчеты идут в миллисекундах. Даже если период прерывания в котором переменная инкрементируется отличается от 1мс, то все равно она увеличивается на значение равное периоду, выраженному в миллисекундах. Поэтому 16-и разрядный unsigned int дает промежуток времени всего лишь 65,5с, а 32-х разрядный unsigned long немногим более 1,5 месяцев.
2) на архитектурах с разрядностью меньшей, чем используемая переменная, нужно предпринимать дополнительные действия по обеспечению атомарности доступа к такой переменной. Т.е. приходится перед считыванием ее значения запрещать прерывание, в котором эта переменная инкрементируется.