коллеги, давайте, наконец, напишем что-нибудь. )

[Dale]

Все равно не уловил идею. Обработчик прерываний должен быть простым и коротким, вряд ли понадобится явно выделять в нем состояния и уж совсем недопустимо его блокировать. Значит, и потоки ему не нужны.

Состояния наверняка понадобятся в Проводнике или Модели. Где их лучше поместить, пока не понял.

[RXL]

При чем тут блокировка? Что фактически получается из функции с protothreads после обработки препроцессором? Никаких потоков - просто описание автомата: согласно текущему состоянию выполнится кусок кода и, возможно, сменится состояние на другое и возврат управления.
Автомат в обработчике прерывания может пригодится. Например, для получения данных через интерфейс Wiegand или 1-Wire (если нет аппаратной поддержки).

[Dimka]

RXL, обработчик прерываний как правило решает либо задачу установки флажка события/состояния, либо изъятие/добавление в очередь (на базе массива) каких-нибудь данных, либо и то и другое. Это обеспечивает максимально быстрый выход из обработчика и минимизирует период маскирования прерывания.

Вся остальная обработка осуществляется вне обработчиков. Там уже по более сложному алгоритму анализируются флаги и содержимое очередей.

[RXL]

Dimka, напиши без прерываний драйвер 1-Wire. Ссылку на описание я немного выше давал. В описании есть диаграммы и тайминги.

Кстати, не понимаю, чего вы боитесь. Десятка-двух тактов в обработчике?

Добавлено через 22 минуты и 50 секунд:
1-wite

Передача бита имеет 3 фазы (синхроимпульс, уровень бита, пауза после бита). Прием бита имеет 4 фазы (синхроимпульс, снятие импульса, определение бита и пауза до конца передачи, пауза после бита). Это хорошо описывается конечным автоматом.
Передача или прием байта, соотв., требует цикл.
Выполнение команды (передача команды и обмен данными) - тоже автомат+цикл.

Protothreads, особенно в варианте с goto, дает возможность записать алгоритм просто и линейно. При этом размер выполняемого за раз кода будет небольшой. Алгоритм выполнения команды можно вынести из прерывания и оставить в нем только передачу и прием байт.

[Dimka]

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

Поэтому твоё предложение про драйвер непонятно.

Либо есть какая-то система прерываний, либо контроллер работает в бесконечном цикле и периодически читает значения из АЦП. В последнем случае программист должен следить, чтобы длина цикла по времени соответствовала заданным тайм-слотам - т.е. учитывать количество инструкций и длительность в тактах каждой инструкции между моментами чтения значения из АЦП.

О чём речь?

P.S. Если по умолчанию предполагаются какие-то типовые контроллеры, я их номенклатуру и характеристики не знаю - это для меня надо более подробно проговаривать.

[RXL]

Дим, когда я приводил ссылку, я имел в виду только описание протокола, о чем написал рядом с ссылкой. Про схему в пункте 6 я ничего не говорил и в виду ее не имел.

АЦП тут тоже не при чем. Не знаю, почему ты о нем говоришь. Сигналы соответствуют уровням TTL.

Я говорил лишь о реализации протокола 1-wire, конечных автоматах (в частности, набора макросов protothreads для их удобного написания) и реализации драйвера на прерываниях. Детекция фронтов там не требуется (разве что в приеме сигнала presense), т.к. все фронты передачи данных задает мастер и требуется только выдерживать временные характеристики.

[Dimka]

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

Ну пусть.

А дальше ты говоришь про драйвер и конечные автоматы, и даже про макросы protothreads для C. И ещё говоришь, что нет портов.

Вот здесь для меня тёмный лес, я человек неграмотный. Как перейти от уровня абстракции "электронная схема" к уровню абстракции "вычислительная машина" (контроллер)? Должны существовать какие-то либо интерпретации, либо общие понятия.

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

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

[RXL]

И ещё говоришь, что нет портов.

Наверно мы друг друга не понимаем. Последние три дня о "портах" я ничего не говорил.

Если уж речь офизике 1-wire, давай расскажу сразу, что нужно об этом знать.

Уровни TTL. Тут все просто: менее 0.8 В - логический ноль, более некого порога (2.0...2.8 В - в зависимости от физической реализации) - логическая единица. Промежуточный диапазон - неопределенность.

Уровни CMOS. Тут еще проще: <= 30% от напряжения питания - логический ноль, >= 70% - единица, остальное - неопределенность.

В 1-wire работа драйверов (тут это не ПО, а выходная схема) с линией происходит по принципу "открытый коллектор" или "открытый сток": линия подтянута резистором к напряжению питания, а выходные транзисторы замыкают линию на землю. Своеобразное логическое "И".

При замыкании линии на землю фронт сигнала более резкий, чем при размыкании. Это переходные процессы, на которые нужно некоторое время. Они довольно малы, но они есть. Например, пусть емкость линии с входными устройствами 100 пФ (это очень много - обычно в несколько раз меньше), резистор подтяжки 5.1 кОм - время нарастания напряжения до уровня единицы TTL составит примерно 0.5 мкс, а до уровня CMOS - почти 1 мкс.

Особенность 1-wire - это питание ведомого устройства от сигнальной линии. Т.е. устройству для работы нужно подзарядить свой внутренний питающий конденсатор. Т.к. объем данных мал и время обмена данными измеряется единицами миллисекунд (1 байт команды и 8 байт данных), то предварительной зарядки вполне хватает. Но как следствие экономии энергии, электроника там медленная. Устройства работают в широких диапазонах температур (например, ключ iButton принесен с мороза или лежал в жару на солнце). Все это вкупе дает большой разброс временных параметров.

В общем, более ничего от физики тут знать не требуется. Все остальное сводится к логике и временным параметрам.


Добавлено через 26 минут и 41 секунду:

RXL, когда падение и  токи на регуляторе большие - на работе обычно ставим DC-DC преобразователи. это одна микросхема с внешней индуктивностью и емкостью. фактически ШИМ стабилизатор. КПД высокий. радиатор - достаточно термалпада на плате.

Тут прежде всего нужно понять потребление. Сам микроконтроллер в активном режиме требует мало - около 1 мА. Если есть нагрузка выходные на линии и резисторы подтяжки - это дополнительный ток. Драйвер RS485 в режиме сна кушает менее 1 мкА, в режиме приема - единицы мА, в режиме передачи - десятки мА, максимум - ток короткого замыкания (у одних драйверов есть защита, у других нет и ток может достигать порядка 250 мА). Зарядное устройство для аккумулятора можно настроить на максимальный ток зарядки (скажем, 50 мА).
Получается, что потребление колеблется от единиц мА до примерно 300-350 мА. С запасом это 400 мА. Если преобразователь будет способен работать в таком диапазоне - хорошо. Древний 7805 этот диапазон покрывает легко, но под большой нагрузкой греется.
Можно сделать раздельные стабилизаторы, если в этом есть смысл.
Но лучше все это отложить на потом, когда потребности схемы будут известны точно.


Добавлено через 44 минуты и 14 секунд:
http://www.maxim-ic.com/datasheet/index.mvp/id/4382
Чип интерфейса 1-wire. Со стороны м/к у него I2C.

Добавлено через 46 минут и 32 секунды:
А давайте таки начнем?

У меня по этому поводу важный вопроса: если мы делаем совместный обучающий проект, то с чего правильно будет начать разработку ПО?

[Dimka]

В 1-wire работа драйверов (тут это не ПО, а выходная схема)

Так бы сразу и сказал. Для меня драйвер - это всегда ПО. Если в данном контексте нет - мне тут делать нечего

Единственное, почему я посматриваю эту тему - это упомянутые protothreads. Но я так и не понял до сих пор, к чему они тобою упоминаются, если речь идёт об электронной логической схеме?

[RXL]

Дим, для кого-то драйвер - водитель. И еще не мало других значений
Но скажем вот здесь я имел в виду именно ПО. В противном случае стараюсь пояснять контекст.

Проект подразумевает аппаратно-программный комплекс открывания двери для ленивых.
Protothreads я предлагал как помощника в написании конечного автомата. Не раз это подчеркивал.

[Dimka]

RXL, так Dale с тобой не соглашался в пункте сочетаемости protothreads и прерываний. Поэтому я попытался выяснить, о какой конкретной "железяке" идёт речь (её архитектура как вычислительной машины и параметры быстродействия). А ты стал говорить про 1-wire, но это не относится к прерываниям и protothreads.

Конечный же автомат - это "безусловная ценность", он сочетается решительно со всем, кроме чистого функционального программирования, да и там умудряются применять, переопределив понятие "состояния". Поэтому про него я не спрашивал.

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

В общем, я ничего не понял.

Можно как-нибудь обобщить истекшие 5 страниц темы и выписать по пунктам принятые решения или высказанные идеи по поводу реализации типового домофона механизма открытия двери (выбор технологии, архитектуры, железа, алгоритма, пользовательские характеристики)?

[RXL]

Дим, не бери в голову - тут я привел микросхему интерфейса и на программную реализацию можно забить.

Главное - переливаем из пустого в порожнее и стоим на месте. Игорь, как инициатор темы, молчит, т.к. сам в м/к и схемотехнике не разбирается. А хотелось бы уже начать, пока еще не надоело.

Добавлено через 1 минуту и 47 секунд:

У меня по этому поводу важный вопроса: если мы делаем совместный обучающий проект, то с чего правильно будет начать разработку ПО?

Я в групповых разработках не участвовал - всегда проектировал и реализовывал сам. Хотелось бы узнать, как это делают в более "серьезных" конторах.

[Ochkarik]

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

PS это как я себе это вкратце вижу. обидно что наверняка по этому вопросу куча книг написана... кто бы подсказал - я бы даже прочесть не поленился бы... наверное) системное, блин, проектирование...

[Dale]

У меня по этому поводу важный вопроса: если мы делаем совместный обучающий проект, то с чего правильно будет начать разработку ПО?

Мое предложение:

http://readyset.tigris.org/nonav/templates/index.html
http://readyset.tigris.org/nonav/templates/proposal.html

[Dimka]

составление ТЗ, обсуждение с заказчиком, после чего начинаешь понимать, что то что написано и то что хочется - две большие разницы) в этот момент надо переписывать ТЗ но конечно это никто не делает)
потом обсуждение основных этапов, и примерные пути реализации.
потом чего у нас не хватает - разбивка проекта на этапы с четким прописыванием, что на входе каждого этапа и что должно быть на выходе. чем больше этапов тем лучше) и что делать если что то не удается.
разработка стыков между всеми участниками, лучше это сделать заранее. но для этого нужна полное представление о конечной схеме.

О, ты тоже ощущаешь.

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

Граждане, давайте порядок наведём: обобщим и выпишем по пунктам
- о чём договорились (уже) - какие требования и какие решения, вытекающие из этих требований;
- что (пока что) находится в стадии предложения к рассмотрению.

Тем самым отделив ядро от ветвей. Только сделать это надо в одном посте и вкратце (можно со ссылками на подробности).

После этого можно уже будет прикидывать план дальнейших действий.

[RXL]

Описываю железо еще раз:

1. Микроконтроллер семейства Atmel AVR с поддержкой следующих фич: SPI, I2C, 2 x UART, компаратор, AЦП, расширенное питание (1.8..5.5 В), режимы сниженного питания (>1 мкА), поддержка дополнительного кварца 32768 Гц для RTC.
2. Источники команд на открытие замка: интерфейс Wiegand-26, 1-Wire (на уровне "таблеток" DS1990), кнопка, команда по сети RS485.
3. Сетевой интерфейс RS485 для связи с управляющим компьютером, протокол Modbus (ведомый).
4. Интерфейс RS232 для настройки параметров и отладки.
5. Сетевой интерфейс I2C (ведущий) для подключения различных микросхем (например, 1-Wire).
6. Датчики: герконовый датчик открытой двери, опционально - датчики диагностики исполнительных устройств (срабатывание замка и исправность его цепи и т.п.).
7. Исполнительное устройство: управление питанием замка (постоянный ток, 12 В, 0.6-0.8 А, индуктивная нагрузка).
8. Блок питания контроллера и замка от сети 220 В.
9. Резервная батарея (только контроллер, для RTC и фиксации событий) и контроллер ее зарядки. Опционально возможно подключение силовой батареи для питания всего устройства, включая замок.

Функциональные требования (очевидные требования к замку и описанные выше - в железе - не описываю):
1. Хранить в EEPROM список доверенных кодов разных систем - беспроводных карт и ключей-таблеток. Управление списком на начальном этапе - через RS485, а в последствии можно добавить работу с "мастер-ключом".
2. Ведение лога событий, хранение его в EEPROM и выборка через RS485.
3. Возможность диагностики и настройки по RS485 и RS232.
4. На этапе тестирования на контроллере - вывод тестовых сообщений в RS232.


Dale, я это еще не читал - начну сегодня же.


Добавлено через 25 минут и 55 секунд:
http://readyset.tigris.org/nonav/templates/proposal.html
Все ссылки на этой странице - битые.

[Ochkarik]

RXL, не, это уже выводы из ТЗ... причем местами без обоснования.

почему я так считаю: например RS485 - почему? да, классный интерфейс. только интерфейсная плата - от 70$ а смысл? если есть альтернативы, то почему именно RS485? цена/сложность разработки?  при закладывании стоимости контроллера в 70уе, проще за 50$ готовый Paralell-to-Ethernet модуль взять. но это частности.

не пинайте сильно )

а само ТЗ наверное должно звучать примерно так... фиг с ней что на ОКР, близко

1 Вводные данные
1.1 Наименование ОКР
1.2 Основание для выполнения ОКР
1.3 Исполнитель ОКР
1.4 Срок выполнения ОКР
2 Преследуемые цели
2.1 Цель выполнения ОКР
2.2 Наименование и индекс образца:
3 Технические требования к изделию
3.1 Состав изделия:
3.2 Требования назначения
3.2.1 Назначение
3.2.2 Функции
3.2.3 Метрологические характеристики
3.2.4 Требования к электропитанию
3.3 Требования электромагнитной совместимости
3.4 Требования живучести и стойкости к внешним воздействиям
3.5 Требования надежности
3.6 Требования эргономики, обитаемости и технической эстетики
3.7 Требования к эксплуатации, хранению, удобству технического обслуживания и ремонта
3.8 Требования транспортабельности
3.9 Требования безопасности
3.10 Требования стандартизации и унификации
3.11 Требования технологичности
3.12 Конструктивные требования
4 Технико-экономические требования
5 Требования к видам обеспечения
5.1 Требования к метрологическому обеспечению
5.2 Требования к программному обеспечению
6 Требования к сырью, материалам и комплектующим изделиям
7 Требования к консервации, упаковке и маркировке
8 Требования к учебно-тренировочным средствам
9 Специальные требования
10 Этапы выполнения ОКР
11 Порядок выполнения и приемки этапов ОКР

пример разбивки по этапам :

1. Изучение существующих изделий подобного типа
2. Изучение элементной базы пригодной для построения требуемого изделия
3. Выбор элементной базы
4. Разработка оптической схемы прототипа изделия
5. Разработка структурной электрической схемы прототипа изделия
6. Разработка эскизов корпуса изделия
7. Согласование с заказчиком фактических технических характеристик и внешнего вида изделия
8. Разработка электрической принципиальной схемы изделия
... дальше в источнике

PS я вообще в последнее время задумываюсь что ГОСТЫ не дураки составляли)))

[Dale]

Сами по себе эти ссылки не нужны, это просто примеры (для проекта игрового сайта - ссылки на конкурентов).

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

[RXL]

Основной инструментарий разработки:
1. Трекер: http://redmine.shelek.su/projects/vu-lock-controller
2. Контроль версий: http://svn.shelek.su/public/VU-Lock-Controller/ (http://redmine.shelek.su/projects/vu-lock-controller/repository)
3. Автоматизация сборки нам вряд ли потребуется - проект небольшой.
4. Инструменты для сборки - WinAVR (avr-gcc и прочие avr-*). Желательно иметь возможность сборки в AVR Studio, пусть и не полностью идентично WinAVR. Для тестовых сборок подойдет gcc под x86.

Добавлено через 10 минут:
Ochkarik, я на 2-3-х последних страницах почти в монологе изложил результаты своих исследований.
RS485 потому, что: 1)  для связи с компом (или каким-то другим ведущим контроллером) выбран протокол Modbus; 2) RS485 позволяет подключить более одного устройства (если потребуется); 3) это распространенный промышленный стандарт, в том числе и для "умного дома"; 4) используется одна витая пара; 5) к компу подключается простым конвертером 232/485.
Modbus выбран по тем же причинам: 1) промышленный стандарт, в том числе для "умного дома"; 2) протокол прост и подходит для наших целей; 3) существует готовый софт и множество SDK для работы с ним.
Цена микроконтроллера в розницу порядка 200-300 руб, а то и дешевле. Весь контроллер (в расчете на штучное тиражирование) желательно уложить в 1000 руб. Цена разработки наверняка будет выше.

[Dimka]

С железом понятно. А какие всё же требования и как убедиться, что выбранное железо этим требованиям соответствует?

О чём я спрашиваю:

1) Функциональные требования в виде хотя бы user stories (т.е. сценарии взаимодействия пользователя с будущей системой).

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

- Сценарий открывания двери правильным ключом и сценарий неоткрытия двери неправильным ключом (нужна ли какая-нибудь индикация пользователю о том, какова реакция системы на его действия).
- Сценарий сбоя, отключения питания и т.д. (э/м импульса при ядерном взрыве ) - как система должна на это реагировать, как сигнализировать пользователю и т.д.
- Сценарий восстановления системы после сбоя.
- Сценарий настройки на новый ключ (что в каком порядке при помощи какого оборудования должен делать пользователь). Какова безопасность этого сценария на случай несанкционированных действий злоумышленников?
- Сценарий просмотра логов пользователем (что и при помощи какого оборудования делать).
- (добавить другие сценарии если надо)

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


И только после этого уже можно будет говорить, что то или иное железо подходит или не подходит для решения задачи. А также предлагать чисто архитектурные варианты тех или иных программно-аппаратных решений, комплексно оценивая их по функциональным и нефункциональным требованиям.

[Ochkarik]

RXL, пардон...  про конвертер я просмотрел) и... просто не люблю я COM-порт) да и чет отмирает он, зараза такая)
тут поставляли технику... а блин в компах ну нет его. и слотов нет- воткнуть некуда. и еще что то помешало. пришлось USB конверторы колхозить... а это зопа еще та... кстати FTDI  USB-UART 100рэ стоят)
но это все частности)
PS Dimka,  )

[RXL]

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

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

Ключ правильный: сигнализация "ок" (типично, зеленый светодиод и, опционально, звуковой сигнал), подача питания на замок и удержание его в течении N секунд, отключение замка, сигнал "дежурный" (выкл. звук, выкл. зеленый светодиод, вкл. красный).

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

Ключ неправильный: сигнал "фиг-вам" (в течении, скажем, секунды горит или мигает красный и выдается звуковой сигнал).

Сбой протокола обмена карты или таблетки приравнивается к неверному коду (если код передан, но неверный), либо просто игнорируется (неполный код, несоответствие контрольной суммы).

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

Это многогранный вопрос и всех деталей кратко не расскажешь.
Если очень кратко, то поведение при отключении питания предполагаю такое: если нет резервной силовой батареи, то м/к обнаружит, что он питается от собственной батареи. Он отключает всю лишнюю периферию и уходит в глубокий сон, пробуждаясь только по таймеру RTC, событиям от датчика двери и наличия сетевого питания. Занимается только RTC и логированием открывания/закрывания двери.
Внешний обвес м/к и всякие внешние резисторные подтяжки запитываются только от сетевого БП и потому сами вынужденно уходят в "сон". Соотв., м/к с сетью не работает (это энергетически накладно), сигналы не подает (хотя, подать короткий привлекающий внимание сигнал раз в минуту или реже - можно - опционально).

- Сценарий восстановления системы после сбоя.

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

- Сценарий настройки на новый ключ (что в каком порядке при помощи какого оборудования должен делать пользователь). Какова безопасность этого сценария на случай несанкционированных действий злоумышленников?

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

- Сценарий просмотра логов пользователем (что и при помощи какого оборудования делать).

При помощи компа и ПО. Этот вопрос требует проработки - сейчас ответить не смогу.

- (добавить другие сценарии если надо)

Конечно.


Добавлено через 1 час, 29 минут и 33 секунды:

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

Надежность:
1) Прежде всего, контроллер не должен открыть замок от случайного сбоя. Обычно это достигается управлением через несколько ног в нужной комбинации единиц и нулей и, желательно, на разных портах. Также управление разными ногами можно разнести по нескольким функциям. В итоге, самопроизвольное открытие возможно только при выполнении правильного (а не случайного) потока команд. Действуя и далее в том же духе можно существенно снизить вероятность сбоя. Но прежде всего - тестирование.
2) Устойчивость на нештатные воздействия: возможные КЗ внешних линий, воздействие высоких напряжений (220, статика, другие источники).

Безопасность:
1) Электротехническая: предохранители, заземление и пр. типовые решения.
2) Доверенные коды: снаружи никак не узнаешь эти коды, а изнутри можно и запаролить или еще как.

Быстродействие: определится в процессе разработки.

Конфигурация: небольшой ящик. Габариты будут известны в процессе.

Реализуемость: если не надоест.

Эксплуатационные ресурсы: незначительные.

Бюджет: очень скромный и волновать нас сейчас не должен. Я проверяю розничные цены на все приглянувшиеся микросхемы - ничего сверхдорогого, если не смотреть chipdip.ru.

О критериях "и т.п." ничего не могу сказать

[Dimka]

RXL, смотри, называется user story, а ты, к примеру, пишешь:

сигнализация "ок" (типично, зеленый светодиод и, опционально, звуковой сигнал), подача питания на замок и удержание его в течении N секунд, отключение замка, сигнал "дежурный" (выкл. звук, выкл. зеленый светодиод, вкл. красный).

Где ни одного слова про user нету

Давай для затравки попробую:

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

Вариант 1:
Я вижу (или не вижу?) в подъездной тьме приветливый слабый огонёк в том месте, куда надо приложить таблетку.
Я прикладываю таблетку (как попало к гладкой поверхности? вкладываю каким-то определённым образом в специальное углубление? или ещё как?) к этому месту и:

Вариант 1.1:
Вижу радостный зелёный огонёк, дружелюбный писк и щелчок замка.
Берусь за ручку двери и открываю её.
Вхожу.
Закрываю дверь.
Радостный зелёный огонёк сменяется приветливой слабой подсветкой, дружелюбный писк прекращается.

Вариант 1.2:
Вижу грозное красное мерцание, суровый гудок (или завывание сирены? или пронзительный звонок? ).
И обламываюсь.

Но если я честный хозяин этой гнусного глюкодела, то:
Вариант 1.2.1
(А кстати, что мне теперь делать?)

Вариант 2:
Я ничего не вижу в этом сумраке и холодею от недоброго предчувствия.
Я прикладываю таблетку (как попало к гладкой поверхности? вкладываю каким-то определённым образом в специальное углубление? или ещё как?) к этому месту и ничего не происходит - никакой реакции.
(И что мне теперь делать?)

[Ochkarik]

Dimka,
Вариант 1.2.1: лезу в карман за ключом, открываю дверь по старинке как ламер, подсвечивая зажигалкой) - там электромеханический замок.
Вариант 2: -----//------
Вариант 2.1: проверяю номер дома(название города) - иду в соседний подъезд(аэропорт)

[RXL]

Да, Дим, алгоритм прост как веник. Открывать пиво тебя же никто не учил. Тут тоже интуитивно ясно: приложил - реакция. Если нет реакции, значит что-то не так. Можно попробовать приложить еще раз и убедившись, что ответа нет, открываешь ключом.
От чего не работает, ты узнаешь, когда попробуешь включить свет: нет света - от того же не работает замок, есть свет - что-то в замке неисправно.

Для визуальной диагностики можно добавить в корпус контроллера блок из 2-3 светодиодов и кнопку: нажал - отображается диагностика (далее см. таблицу в мануалк).

[Dimka]

А где в перечне железа стоит "замок электромеханический - 1 шт."? Какой конкретно замок? А как у него с безопасностью? А он для всякой двери подойдёт?

А всё же, таблетка или карточка, или отпечаток пальца или что должно быть?

Нужны ли подсветки/пищалки?


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

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

Есть две цели:
- Сделать удобный и надёжный замок для людей (пусть даже это "свои" люди - не особо привередливые).
- Повозиться с железяками в своё удовольствие.
Понятно, что второе интереснее, но первое от этого страдать не должно.

IMHO, разумеется

[Ochkarik]

Dimka, +1! где надо подписаться?)
у нас на работе - по второму варианту... удовольствия море... но сплошные авралы и полная Ж.

[Sla]

я тут не очень местный...
Несколько вопросов...
Подразумевается что "замок" хранит информацию о ключе.

Замок хранит информацию о всех ключах в системе, или только о разрешенных в этом замке?
Ключ подходит ко всем замкам в системе?

Защита информационного потока (т.е шифрование) подразумевается?

[Ochkarik]

RXL, по моему стоит завести отдельную страничку с ТЗ, сценариями работы, и т.д. и править/дополнять в одном месте. иначе это расползается  на сто постов.

[RXL]

А где в перечне железа стоит "замок электромеханический - 1 шт."? Какой конкретно замок? А как у него с безопасностью? А он для всякой двери подойдёт?

Дим, это отдельный серийных компонент. Их много разных за разные деньги, на разные двери и разного функционала.
Постараюсь привести ссылку на "эталонный" замок.

А всё же, таблетка или карточка, или отпечаток пальца или что должно быть?

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

Нужны ли подсветки/пищалки?

Нужны. Подключать их или нет - дело вкуса.

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

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

Есть две цели:
- Сделать удобный и надёжный замок для людей (пусть даже это "свои" люди - не особо привередливые).
- Повозиться с железяками в своё удовольствие.
Понятно, что второе интереснее, но первое от этого страдать не должно.

IMHO, разумеется

Не вопрос, Дим. Сделаем детально. Просто времени не так много.


Добавлено через 7 минут и 3 секунды:

Замок хранит информацию о всех ключах в системе, или только о разрешенных в этом замке?

Только разрешенные - "доверенные". О "недоверенных" он ничего не знает, т.к. их нет смысла хранить.

Ключ подходит ко всем замкам в системе?

Как сконфигуришь.

Защита информационного потока (т.е шифрование) подразумевается?

Нет, никакой защиты нет.
Обмен карты или таблетки не защищен. Се ля ви или промышленный стандарт на бытовые устройства. Чтобы считать карту нужно расположить ее не далее 5-10 см от ридера. Чтобы прочитать таблетку нужен электрический контакт с ридером на пол секунды или меньше.
Обмен по RS485 не защищен, но и не требуется, т.к. он "внутри периметра".


Добавлено через 1 минуту и 26 секунд:

RXL, по моему стоит завести отдельную страничку с ТЗ, сценариями работы, и т.д. и править/дополнять в одном месте. иначе это расползается  на сто постов.

Не вопрос. Только с какого момента отрезать?