File content as of revision 80:7eb5dbb80c81:

08.03.2016 Dile Tant
1. Строка в основном цикле:
       if (Event100K)  {           // событие раз в 100 кГц
   на самом деле выполняется каждый цикл основного цикла после первого прерывания таймера.
   Смотрим:
       Event100K  = 0;   - main.c
       
       Event100K --;     - MTimer.c, TIMER2_IRQHandler, Event100K == 65535;
       
       if (Event100K)  { - main.c, основной цикл, Event100K == 65535;
         Event100K --;   - main.c, основной цикл, Event100K == 65534;
         
       if (Event100K)  { - main.c, основной цикл, Event100K == 65534;
         Event100K --;   - main.c, основной цикл, Event100K == 65533;
   и т.д. Я неправ?
2. Проверка счетчиков времени в основном цикле может приводить к ситуации, когда первый байт счетчика времени прочитан перед прерыванием, а второй байт - после.
В результате, значение счетчика будет прочитано некорректно. Например: до прерывания 0x01ff, после прерывания 0x0200, прочитано 0x0100!
Для корректной работы с таймером обращаться к счетчикам времени следует только в прерывании таймера.
Для основного цикла должны быть доступны только флаги временных событий, выставляемые в прерывании, проверяемые и сбрасываемые в основном цикле в процессе обработки события.

06.03.2016 Dile Tant
Прием команд может быть организован через прерывание: DeviceUART.h/DeviceUART.c.
Заполнение программного кольцевого буфера приема в прерывании независимо от чтения из него и выполнения команд в основном цикле.

23.02.2016 Dile Tant
% - деление по модулю (остаток от деления)
int length = (start > end) ? (end + InputBufferSize - start) : (end - start);
Если (start > end), то length = (end + InputBufferSize - start), иначе length = (end - start)
Выздоравливай

22,02,2013 Апухтин
Про очеред запрсов!
1 я не знаю, но думаю что не надо, в гороскопе нет я процесов, которые должны чегото ждать, или не так?
запросили счетчик вот получай, выставили напряжении вот тебе, => все команды должны быть выполненны сразу, я так думаю.
естественно должно быть запрос и сразу ответ, гирос всегда ведомый, если запрос широковешателный, то пускай ждут ответа какоето время
лишняя путаница

чтобы получать сразу несколко команд, можно их хранить в буфере приема (считывать не стирая).

1. Буфер приема должен иметь возможность содержать очередь запросов. Все запросы должны быть обработаны в порядке приема. 
2. Новый запрос отменяет отправку ответа на предыдущий запрос, если ответ еще не отправлен.  -- ок
3. Буфер передачи должен содержать только один ответ одновременно.                           -- ок
4. Буфер приема целесообразно организовать как кольцевой с размером, достаточным для 10 команд.
5. Буфер передачи целесообразно организовать как линейный с размером, достаточным для хранения самого длинного ответа.

по остальному не знаю, наверно очеред на команды не нужна 


при этом все данные зранятся в буфере приема (нераскодированные) они уже сделанны, я их сейчас переписываю
с тебя просто обработчик команды и потом его мне (строкой) и с задержкой. приболел я


завтра позвоню

чо значит (b->buffer[(start + 1) % InputBufferSize])  знак %
int length = (start > end) ? (end + InputBufferSize - start) : (end - start); и вот это




мистер Л
*** Обработка запросов ***
1. Нужно ли предусматривать возможность программного буфера передачи UART1 содержать ответ более чем на 1 запрос?
1.1. В старой программе буфер содержит 1 ответ. Запросы поступают с достаточным интервалом для передачи ответа.
1.2. Для разных запросов могут быть разными: время задержки ответа при широковещательном запросе, период ответа,
скорость ответа и скорость ожидаемого запроса. Значит нужно хранить не ответы, а запросы, причем для каждого запроса
нужен свой счетчик задержки или периода.
Если поступают два широковещательных запроса без достаточного интервала, устанавливать разные задержки ответа?
В какой момент переключать ожидаемую скорость запроса и скорость ответа?
Требуется сценарий использования.
2. Нужно ли предусматривать возможность программного буфера приема UART1 содержать более 1 запроса?
2.1. Если не нужен ответ на каждый из запросов к прибору, то имеет смысл отправлять эти запросы без интервала ожидания.
Каждый новый запрос отменяет ответ на предыдущий запрос.

Выводы:
1. Буфер приема должен иметь возможность содержать очередь запросов. Все запросы должны быть обработаны в порядке приема.
2. Новый запрос отменяет отправку ответа на предыдущий запрос, если ответ еще не отправлен.
3. Буфер передачи должен содержать только один ответ одновременно.
4. Буфер приема целесообразно организовать как кольцевой с размером, достаточным для 10 команд.
5. Буфер передачи целесообразно организовать как линейный с размером, достаточным для хранения самого длинного ответа.