123
Fork of LG by
Diff: develop.txt
- Revision:
- 69:70849751d98e
- Child:
- 70:9cc252048c59
diff -r 46937d192c39 -r 70849751d98e develop.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/develop.txt Mon Feb 22 19:50:48 2016 +0000 @@ -0,0 +1,19 @@ +*** Обработка запросов *** +1. Нужно ли предусматривать возможность программного буфера передачи UART1 содержать ответ более чем на 1 запрос? +1.1. В старой программе буфер содержит 1 ответ. Запросы поступают с достаточным интервалом для передачи ответа. +1.2. Для разных запросов могут быть разными: время задержки ответа при широковещательном запросе, период ответа, +скорость ответа и скорость ожидаемого запроса. Значит нужно хранить не ответы, а запросы, причем для каждого запроса +нужен свой счетчик задержки или периода. +Если поступают два широковещательных запроса без достаточного интервала, устанавливать разные задержки ответа? +В какой момент переключать ожидаемую скорость запроса и скорость ответа? +Требуется сценарий использования. +2. Нужно ли предусматривать возможность программного буфера приема UART1 содержать более 1 запроса? +2.1. Если не нужен ответ на каждый из запросов к прибору, то имеет смысл отправлять эти запросы без интервала ожидания. +Каждый новый запрос отменяет ответ на предыдущий запрос. + +Выводы: +1. Буфер приема должен иметь возможность содержать очередь запросов. Все запросы должны быть обработаны в порядке приема. +2. Новый запрос отменяет отправку ответа на предыдущий запрос, если ответ еще не отправлен. +3. Буфер передачи должен содержать только один ответ одновременно. +4. Буфер приема целесообразно организовать как кольцевой с размером, достаточным для 10 команд. +5. Буфер передачи целесообразно организовать как линейный с размером, достаточным для хранения самого длинного ответа. \ No newline at end of file