demiurg_spb вполне справедливо возразил вам. Типы переменных, под которые резервируется место в ОЗУ это глобальные и static. Переменные типа auto (локальные) образуются на стеке или в регистрах, как и тип register. Посмотрите раздел 6.7.1 Storage-class specifiers в стандарте C99 ISO/IEC 9899:1999. volatile это квалификатор типа, который не влияет на размещение переменной, но влияет на способ обращения к ней (запрещает "кэширование" значения).

Это конечно так, но опять же, в данной ситуации это неважно, а точнее имеет место только постольку, поскольку ноль в такую переменную пишется командой из семейства st_ , которые берут и копируют регистр в память. Я, в данном случае, сказал только то, что видел в действиях компилятора. А компилятор при смене модификатора с auto на volatile запихнул её в память и стал использовать соответсвующие операции чтения/записи (естественно без кэширования доступа).

Кстати говоря, ещё никто не ткнул меня носом в конкретную функцию и не сказал:"Она ТАК НЕ может работать!". Учитывая, что все самоделки делались под конкретные задачи, то никто им не отдаёт параметры, выходящие за пределы работоспособности. В случае my_itoa самое большое поступающее число-это 59, в случае my_ltoa - 300000. В таком виде они (по коду) обязаны работать правильно.

Ключевой вопрос-как можно испортить регистр, ничего не делая с ним напрямую?

Сообщение отредактировал Dzhesertep - May 14 2010, 21:00

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

Ну память видимо стековая-это наиболее вероятно так. Знаю, что в правила хорошего тона не входит делать что-либо в прерывании, но если очень хочется-то можно (к тому же когда оно одно) Всё равно все функции укладываются в одно прерывание с небольшим запасом. И прерывание каждую секунду, а не миллисекунду.

Все от задачи зависит. Бывают задачи, которые только в прерывании и выполняются.
Это у вас сейчас так. Но вот вы чуть-чуть расширите функциональность и столкнетесь с тем, что уже не успевает. Зачем привыкать к дурному? Вы ответьте самому себе на вопрос: зачем вам в программе нужна дата? Обычно дата нужна только пользователю, чтобы посмотреть ее. В программе же нужны относительные отчеты интервалов времени. Вот и переведите счетчик секунд в дату только при запросе пользователя. Или при смене ее, если делается визуализации даты/времени. Ведь даже будильник проще сделать на относительных интервалах времени. Поскольку сравнивать одну переменную проще и быстрее, чем сравнить группы переменных.Такой способ отсчета времени давно уже используется в системе UNIX (UNIX-время). Есть готовые библиотеки для перевода счетчика секунд UNIX в дату/время. У них сейчас только одна проблема 32-х битного счетчика хватит до 2038 года. Поэтому рекомендуют использовать 64-х битную переменную. В общем не стоит велосипеды изобретать.

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

Ржу не могу - гадание на картах Таро прямо-таки!
Правильно расставьте приоритеты и поймите что есть причина, а что следствие.
Хочется долбиться об стену - пожалуйста, но стоит помнить, что сумасшествие дело глубоко интимное и не стоит всех и каждого "озарять" потоком своего мутного сознания.

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

Сообщение отредактировал Dzhesertep - May 15 2010, 09:09

Всё, тему можно закрывать, нашлась именно ошибка, сокращая массив в my_itoa забыл, что отдаю ей не только двузначные числа, но и одно четырехзначное, что вызвало наезжание на стэк.

Сообщение отредактировал Dzhesertep - May 15 2010, 14:56