Показать сообщение отдельно
Старый 04.06.2008, 11:17   #5
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 174
Благодарил(а): 15 раз(а)
Поблагодарили: 665 раз(а) в 607 сообщениях
По умолчанию Ответ: Считывание архива из SMH\Pixel

За протыми словами "Читала данные из EEPROM" стоит:

1) Динамическое распределение памяти в контроллере влечёт за собой создание собственного протокола передачи данных.

2) Ограниченность производительности контроллера и EEPROM повлечёт общее замедление работы контроллера во время выгрузки архива, как отнесётся к этому пользовательская программа?

3) Как распределить приоритеты между выгрузкой архива и работой программы?

4) Как ограничить количество записей в EEPROM со стороны внешнего устройства?

Поясню более детально.

1а) Протокол - данные могут размещаться в разных областях EEPROM, области могут быть различных размеров.

1б) Простое открывание "окна EEPROM в модбас" невозможно, т.к. модбас адресует только 64К, а у нас в Пикселе уже 256К ЕЕPRОМ.

1в) Простое открывание "окна EEPROM в модбас" невозможно, т.к. любые неосторожные действия при подключении стороннего устройства могут повлечь за собой порчу данных в EEPROM.

2а) Если программа не расчитана на "растяжку" времени цикла и/или в установленном времени цикла не оставлено достаточно "запаса" для работы "выгрузки архива", то работа алгоритма такой программы может быть нарушена.

3а) Во время выгрузки архива выгоднее всего работать блоками большой длины. А если в это время программе тоже потребовалось чтение или запись в EEPROM?

3а1) Можно посылать блок заново. Тогда может сложиться ситуация, когда программа постоянно прерывает передачу, что сделает невозможным выгрузку архива.

3а2) Можно посылать блок данных из буфера, но как быть, если программа обновляет данные, которые помещены в буфер? Не забываем о памяти, требующейся для буфера и затратах производительности на копирование данных.

3а3) Можно пересылать данные мелкими партиями. Это повлечёт увеличение как времени передачи, так и потерю производительности контроллера.

3б) Если запись в EEPROM с утилиты и из программы совпадут по времени? Да ещё и в одну и ту же ячейку? Кто главнее?

4а) Если открыть "окно EEPROM в модбас", то как защитить EEPROM от частых перезаписей? Не секрет, что периодические запросы в модбасе используются повсеместно. Такие запросы быстро исчерпают ресурс EEPROM. Можно сначала читать данные и сравнивать их с записанными, но это займёт ресурсы процессора. При большом количестве запросов пользовательской программе будет "некогда" выполняться. К тому же это не защитит от постоянной перезаписи изменяющихся данных.


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

Вам от контроллера нужна стабильность Windows'95 ??? Мне - не нужна.

Именно поэтому реализация каких-либо функций (не только архивных, но и любых других) будет проведена только после снятия ВСЕХ рисков.


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием