Diff: develop.txt

Revision:

149:abbf7663d27d

Parent:

80:7eb5dbb80c81

Child:

156:e68ee0bcdcda

diff -r 7ce8c1fd00f7 -r abbf7663d27d develop.txt
--- a/develop.txt	Fri Apr 29 13:53:50 2016 +0000
+++ b/develop.txt	Tue May 03 05:12:26 2016 +0000
@@ -1,80 +1,34 @@
-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!
-Для корректной работы с таймером обращаться к счетчикам времени следует только в прерывании таймера.
-Для основного цикла должны быть доступны только флаги временных событий, выставляемые в прерывании, проверяемые и сбрасываемые в основном цикле в процессе обработки события.
+03.05.2016 Dile Tant
+Использование портов:
+    UART0 - порт обслуживания  / Service port
+    UART1 - порт команд/данных / Host port
 
-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 я не знаю, но думаю что не надо, в гороскопе нет я процесов, которые должны чегото ждать, или не так?
-запросили счетчик вот получай, выставили напряжении вот тебе, => все команды должны быть выполненны сразу, я так думаю.
-естественно должно быть запрос и сразу ответ, гирос всегда ведомый, если запрос широковешателный, то пускай ждут ответа какоето время
-лишняя путаница
-
-чтобы получать сразу несколко команд, можно их хранить в буфере приема (считывать не стирая).
+Идентификация параметров:
+    Всем параметрам присваивается хэш/hash. В качестве хэш-функции можно использовать
+        hash(name, type) = crc32(name) ^ crc32(type),
+    где name - имя переменной в RAM или константы в ROM, type - тип.
+    Например: crc32("uint16_t") ^ crc32("device.settings.address") = 0x4d8e4523
+    
+Хранение констант и переменных в RAM:
+    Все параметры хранятся в переменной device.
+    При загрузке инициализируется таблица адресов переменных hashParamTable[HASH_PARAM_COUNT] в формате hash32 : address32 ： size32,
+    где hash32 - хэш параметра, address32 - ссылка на параметр, size32 - размер в байтах.
 
-1. Буфер приема должен иметь возможность содержать очередь запросов. Все запросы должны быть обработаны в порядке приема. 
-2. Новый запрос отменяет отправку ответа на предыдущий запрос, если ответ еще не отправлен.  -- ок
-3. Буфер передачи должен содержать только один ответ одновременно.                           -- ок
-4. Буфер приема целесообразно организовать как кольцевой с размером, достаточным для 10 команд.
-5. Буфер передачи целесообразно организовать как линейный с размером, достаточным для хранения самого длинного ответа.
-
-по остальному не знаю, наверно очеред на команды не нужна 
-
-
-при этом все данные зранятся в буфере приема (нераскодированные) они уже сделанны, я их сейчас переписываю
-с тебя просто обработчик команды и потом его мне (строкой) и с задержкой. приболел я
-
-
-завтра позвоню
-
-чо значит (b->buffer[(start + 1) % InputBufferSize])  знак %
-int length = (start > end) ? (end + InputBufferSize - start) : (end - start); и вот это
-
-
-
+Доступ к параметрам через Host port
+    Формат команды:
+        cc address8 code16 hash32 crc32
+    code16:
+        H_PARAM8_R : чтение 1-байтного параметра
+        H_PARAM16_R: чтение 2-байтного параметра
+        H_PARAM32_R: чтение 4-байтного параметра
+        H_PARAM8_W : запись 1-байтного параметра
+        H_PARAM16_W: запись 2-байтного параметра
+        H_PARAM32_W: запись 4-байтного параметра
 
-мистер Л
-*** Обработка запросов ***
-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
+Хранение констант и переменных в ROM:
+    Сектор 22 - таблица адресов в формате hash32 : address32
+    Сектор 23 - данные по адресам из таблицы адресов
+    Чтение из ROM:
+        FlashReadAll()
+    Запись в ROM:
+        FlashWriteAll()
\ No newline at end of file