TMX

за безнал можно приобрести?

Москва. м. Крылатское Группа компаний "Цезарь Сателлит" В связи с увеличением штата конструкторского бюро ищем молодых специалистов - программистов микроконтроллеров. Быстро обучаемых и ответственных. Направление: Автомобильная электроника, средства охраны. Области: GSM, GPS, IEEE802.15.4, IEEE802.15.3, ISM 433, CAN, LIN Платформы: текущие - JN51xx, XC2xxx, STM32xx. Cледующие - TI СС13хх, Linux, ОpenCPU. Среды программирования: LabWindows/CVI, Eclipse, LabVIEW. Обязательно: опыт программирования микроконтроллеров на С и ассемблере (любом). Чтение схем. Работа с осциллографом и паяльником. Англ.яз. для чтения документации. з/п на испытательный срок - 50-60 т.р. t.halfin{}csat.ru

Теперь вроде понял - пуклевка в тонком металле для резьбы. Переднюю панель, насколько я понял, крепите винтами, под наклейкой не должно быть видно. Обнижение - это снятие части материала с поверхности. В данном контексте - фрезерование передней панели по центру, с оставлением буртика по краям, чтобы наклейка была заподлицо с ним. В общем, не буду умничать. Спасибо за наводку, будем иметь ввиду.

Спасибо Тоже с заказом корпусов 19" пришлось повозиться. В итоге сделали в Питере - ПК Антей, красили в Подмосковье, лазерная гравировка в Москве. Выглядят как Т-34, заказчик был впечатлен. Что характерно - половина производителей о конденсаторной сварке даже не слышала. Еще пару вопросов: пуклевка для стоек на наружной стороне дна нормально выглядят? Для пластика на передней панели обнижение делали?

Если не секрет, чем закончился поиск производителя корпусов?

это я показал round-robin с постоянным приоритетом, но разным доступом к ресурсам процессора. т.е. автоматы с низким приоритетом (большим значением priority) вызываются реже. Можно, конечно, и динамические приоритеты реализовать. Можно смешанные. Вопрос в организации запросов к ресурсам и ожидания.

Если автоматы по опросу (т.е. циклически вызываются), то можно сделать так: struct auto_struct { void *auto_ptr (void); int priority; int cnt; } automata_list = { automaton_1, 1, 0, automaton_2, 2, 0, automaton_3, 3, 0, }; while (1) { for (i = 0; i < sizeof(automata_list) / sizeof(struct auto_struct); i++) { if (--automata_list.cnt == 0) { automata_list.auto_ptr(); automata_cnt = automata.priority; } } } добавляем общие состояния ожидания с возвратом в предыдущее состояние и Voila! получаем кооперативную многозадачность.

Просто мы используем несколько реализаций машин состояний: Для фоновой задачи, где много состояний - контроль оборудования, взаимодействие с пользователем и т.п. используется реализация с возвратом указателя (описана в раннем посте), она удобна для отладки. Поскольку обычно требования меняются по ходу разработки. В прерываниях или в случаях ограниченных ресурсов (маленький аппаратный стек, например) используется реализация с помощью switch. Ну а для меню написали специальную библиотеку и приложение под windows, которое генерирует уже инициализированную таблицу меню. Дело в том, что при с ростом сложности задачи, генерация и реализация автомата становится рутинной операцией. Проблемой становится выбор правил моделирования. На данный момент меня интересуют следующие вещи: 1. преимущества и недостатки моделей управляемых событиями и по опросу. Пока ясно, что модель по опросу менее требовательна к ресурсам в прерываниях. 2. организация взаимодействия между автоматами. Возможно, в некоторых случаях выгоднее применять иерархическую модель с управлением по событиям. В принципе, я давно этой темой интересуюсь. Многие иностранные книжки по этой теме у меня в бумажном варианте. Но кроме Samek'а ничего оригинального не предлагается - почти везде switch + UML модель по опросу.

Странно люди относятся к инструментам, которыми пользуются. К примеру, просто машину (не состояний) они тщательно выбирают, взвешивают все за и против, смотрят на внешний вид и удобство посадки. Тратят на это немало времени, читают журналы, просматривают интернет. Пожалуй, стоит взять на вооружение фразу "мне важно иметь механизм, а с недостатками можно смириться, для сведения - я проезжаю 100 км за раз" :a14: В то же время, с помощью методов и средств программирования мы зарабатываем деньги, в том числе, на автомобили. Почему бы не потратить время на поиск удачных решений? По поводу списка: в случае switch все состояния тоже переименовываются с помощью enum. Так что, вот и список (1 шт.). Кстати, для основных автоматов я использую не switch, а возврат функцией состояния указателя на следующую функцию состояния. Там тоже список прототипов функций (1 шт.). В одном из устройств у меня в фоновом процессе крутилось параллельно около 10 взаимосвязанных автоматов от 10 до 60 состояний в каждом. Плюс протокол обмена - порядка 100 состояний.

Возможно, я не совсем понял про функции опроса событий. Если они работают как написано ниже, то я был не прав: Все события обрабатываются однократно - функция опроса возвращает номер каждого события один раз. По окончании обработки переменная сбрасывается в ноль. При следующем опросе функция возвращает ноль - т.к. событие уже было отослано. Фактически, это модель с монитором однократных событий. Сложно сказать, какие преимущества и недостатки у моделей. А вот насчет вашей реализации - похоже на реализацию Gomez, но event driven, и те же недостатки. Простой switch по состояниями имеет меньше источников ошибок, поскольку там нет нумерации и перечисление событий только в одном месте. А "много" это сколько? "Плюспицот" - это много? Тестировали атомарность записи в eeprom? А если да, то как? Я имею дело со всякими девайсами и разными процессорами. В различных средах разработки, кстати. Поэтому молиться на IAR как-то не тянет. Например, были готовые серийные девайсы с внешней EEPROM на программном SPI. Именно с проблемой восстановления. Я - за рациональные решения. Объясните, пожалуйста, зачем нужна ранняя диагностика питания и как она сказывается на приличности? Если результата можно добиться программными средствами - это красиво и целесообразно. Уточняю - это не для всех случаев. Я не против диагностики, я даже за резевный ионистор в НЕОБХОДИМЫХ случаях. А вопросы о приличности оставляю на рассмотрение депутатов.

я не уверен в содержимом eeprom, если запись ведется в момент пропадания питания. В свое время тестировали - операция записи атомарна с точки зрения программирования. А так она занимает довольно большое время и содержимое слетает. К тому же eeprom может быть внешним. Поэтому писали лог (из двух последовательных состояний) - запись на входе и на выходе. Тут даже проверка может быть очень простой - значения совпадают, значит состояние валидное. Не совпадают - брать предыдущую пару. то есть, если надо убрать одну функцию из центра списка, придется перенумеровывать все последующие? с событиями не совсем ясно: насколько я понял, функции опроса событий возвращают 0, если события нет и номер события, если событие есть. Как происходит нумерация событий? Получается, что события имеют приоритет, в порядке которого они опрашиваются. Из этого следует, что в любом состоянии приоритет событий одинаков. Более того, каждое состояние должно реагировать на все события. А если, допустим, первое событие - кнопка нажата, а второе - таймер сработал. Тогда при нажатой кнопке даже в состоянии "ждать таймер" система не будет не него реагировать.

с первым согласен. Только какой смысл в такой проверке? Проверка в рантайме - от какого бага она спасает? Если на этапе отладки - использование только поименованных констант не позволит вызвать неописанное состояние. С другой стороны, где гарантия, что индексы идут подряд. со вторым и третьим - не могу ничего сказать. Не могли бы вы написать пример реализации поподробнее? Для одномерного и двумерного массива? Особенно, для functions[state][event], что является индексом массива? я считаю, что удобство понятие не только субъективное. Удобно - когда логическая ошибка проявляется как можно раньше. Например, на этапе компиляции (стоимость обнаружения) Удобно - когда при введении нового состояния его надо прописывать как можно в меньшем количестве списков (связность). И компилятор следит за правильностью (стоимость). Неудобно - когда в нескольких списках описание состояния должно быть с одинаковым номером (связность). насколько я знаю, в 70-х годах было мнение, что наиболее перспективная парадигма в программировании - автоматный подход. "Лучше забивать молотком шурупы, чем закручивать отверткой гвозди"

Недостатки прямого присваивания значения переменной состояния, типа state = NEW_state в том, что при большом количестве ветвлений можно случайно пропустить присваивание. Одним из методов контроля на этапе компиляции является следующий: функция состояния возвращает значение следующего состояния void main (void) { static char state = STATE_X; while(1) { state = state_function(state); } } char state_function (char state) { switch(state) { case STATE_X: if (event) { return STATE_Y; } else return STATE_X; case STATE_Y: ... case STATE_Z: ... } } кроме некоторого контроля за присваиванием, такой подход не дает никаких премуществ. Просто на практике не всегда бывает возможно обеспечить полноту тестов.

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

Возможно, я не совсем понятно выразился - Gomez забивает не всю таблицу переходов автомата, а только одномерный массив jump table, указателей на функции состояний. Там в самом начале листинга можно ее увидеть. В любом случае это не дает преимуществ по сравнению с прямым присвоением: void(*state_pointer)(void) = RED_state; void main (void) { while(1) { state_pointer(); } } void RED_state (void) { if (timer_flag) { output_control(RED_LAMP, OFF); output_control(GREEN_LAMP, ON); start_timer (GREEN_DELAY); state_pointer = GREEN_state; return; } if (button_flag) ...................... } Преимущества: работает быстро, фактически как вычисляемое GOTO Недостатки: требует стек для вызова функций, при реализации в прерываниях вызова по ссылке компилятор обычно сохраняет весь контекст, это долго и требует много стека. По поводу объема: в 8-битных процессорах если указатель занимает 2 байта, то каждое присвоение требует 2 команды ассемблера. Соответственно для автомата на 50 состояний и 150 переходов потребуется 300 команд в ПЗУ (600Б для AVR), для switch с переменной состояния типа char потребуется 300Б ПЗУ на переходы, для Gomez-технологии потребуется 300Б на переходы и 100Б на jump_table, итого 400Б. Для 16-ти и 32-х битных объем switch и присвоения указателей практически одинаков, а для Gomeza все равно дополнительно требуется место для jump table. 1. За счет чего? C использованием switch вообще одна функция. 2.Обычно проблему снаала описывают, а потом реализуют. если еще есть интерес, могу продолжить про реализации...