Jump to content

    

TMX

Свой
  • Content Count

    100
  • Joined

  • Last visited

Community Reputation

0 Обычный

About TMX

  • Rank
    Частый гость
  • Birthday 07/29/1974

Контакты

  • Сайт
    http://www.teamix.ru
  • ICQ
    312516037

Информация

  • Город
    Москва
  1. Цитата(Porty @ Aug 3 2015, 10:09) предложение актуально за безнал можно приобрести?
  2. Москва. м. Крылатское Группа компаний "Цезарь Сателлит" В связи с увеличением штата конструкторского бюро ищем молодых специалистов - программистов микроконтроллеров. Быстро обучаемых и ответственных. Направление: Автомобильная электроника, средства охраны. Области: 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
  3. Цитата(SWT-RUS @ Feb 17 2013, 13:18) Я видимо еще не все знаю по этой теме поэтому слово "обнижение" меня поставило в тупик. Объясните что это. Теперь вроде понял - пуклевка в тонком металле для резьбы. Переднюю панель, насколько я понял, крепите винтами, под наклейкой не должно быть видно. Обнижение - это снятие части материала с поверхности. В данном контексте - фрезерование передней панели по центру, с оставлением буртика по краям, чтобы наклейка была заподлицо с ним. В общем, не буду умничать. Спасибо за наводку, будем иметь ввиду.
  4. Цитата(SWT-RUS @ Feb 10 2013, 18:28) Кто-то с Юрьев-Польского завода (ЮПЗ) прочел этот пост и сам с нами связался. Потом его нам assy33 посоветовал. Но к тому моменты мы уже с ними процесс запустили. Спасибо Тоже с заказом корпусов 19" пришлось повозиться. В итоге сделали в Питере - ПК Антей, красили в Подмосковье, лазерная гравировка в Москве. Выглядят как Т-34, заказчик был впечатлен. Что характерно - половина производителей о конденсаторной сварке даже не слышала. Еще пару вопросов: пуклевка для стоек на наружной стороне дна нормально выглядят? Для пластика на передней панели обнижение делали?
  5. Если не секрет, чем закончился поиск производителя корпусов?
  6. State machine

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

    Цитата(Dog Pawlowa @ Mar 13 2009, 17:59) Понятно ... Где-то рядом ходим, только я меньше теорией интересуюсь, потому как следующий шаг - RTOS- в общем то напрашивается. А я не хочу. Если автоматы по опросу (т.е. циклически вызываются), то можно сделать так: Код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! получаем кооперативную многозадачность.
  8. State machine

    Цитата(Dog Pawlowa @ Mar 13 2009, 12:21) Не понял, как привязываются функции к состоянию. Поясните, плз. Зачем этот список состояний, если ниже : Просто мы используем несколько реализаций машин состояний: Для фоновой задачи, где много состояний - контроль оборудования, взаимодействие с пользователем и т.п. используется реализация с возвратом указателя (описана в раннем посте), она удобна для отладки. Поскольку обычно требования меняются по ходу разработки. В прерываниях или в случаях ограниченных ресурсов (маленький аппаратный стек, например) используется реализация с помощью switch. Ну а для меню написали специальную библиотеку и приложение под windows, которое генерирует уже инициализированную таблицу меню. Цитата(Dog Pawlowa @ Mar 13 2009, 12:21) Померялись Дело в том, что при с ростом сложности задачи, генерация и реализация автомата становится рутинной операцией. Проблемой становится выбор правил моделирования. На данный момент меня интересуют следующие вещи: 1. преимущества и недостатки моделей управляемых событиями и по опросу. Пока ясно, что модель по опросу менее требовательна к ресурсам в прерываниях. 2. организация взаимодействия между автоматами. Возможно, в некоторых случаях выгоднее применять иерархическую модель с управлением по событиям. В принципе, я давно этой темой интересуюсь. Многие иностранные книжки по этой теме у меня в бумажном варианте. Но кроме Samek'а ничего оригинального не предлагается - почти везде switch + UML модель по опросу.
  9. State machine

    Цитата(Dog Pawlowa @ Mar 11 2009, 16:46) Мне важно иметь механизм, а с недостатками можно смириться. Для сведения - в устройстве более 100 состояний. Странно люди относятся к инструментам, которыми пользуются. К примеру, просто машину (не состояний) они тщательно выбирают, взвешивают все за и против, смотрят на внешний вид и удобство посадки. Тратят на это немало времени, читают журналы, просматривают интернет. Пожалуй, стоит взять на вооружение фразу "мне важно иметь механизм, а с недостатками можно смириться, для сведения - я проезжаю 100 км за раз" В то же время, с помощью методов и средств программирования мы зарабатываем деньги, в том числе, на автомобили. Почему бы не потратить время на поиск удачных решений? По поводу списка: в случае switch все состояния тоже переименовываются с помощью enum. Так что, вот и список (1 шт.). Кстати, для основных автоматов я использую не switch, а возврат функцией состояния указателя на следующую функцию состояния. Там тоже список прототипов функций (1 шт.). В одном из устройств у меня в фоновом процессе крутилось параллельно около 10 взаимосвязанных автоматов от 10 до 60 состояний в каждом. Плюс протокол обмена - порядка 100 состояний.
  10. State machine

    Цитата(Dog Pawlowa @ Mar 11 2009, 13:12) Состояние не должно реагировать на все события, тут Вы не правы. Возможно, я не совсем понял про функции опроса событий. Если они работают как написано ниже, то я был не прав: Все события обрабатываются однократно - функция опроса возвращает номер каждого события один раз. По окончании обработки переменная сбрасывается в ноль. При следующем опросе функция возвращает ноль - т.к. событие уже было отослано. Фактически, это модель с монитором однократных событий. Сложно сказать, какие преимущества и недостатки у моделей. А вот насчет вашей реализации - похоже на реализацию Gomez, но event driven, и те же недостатки. Простой switch по состояниями имеет меньше источников ошибок, поскольку там нет нумерации и перечисление событий только в одном месте. Цитата(_Pasha @ Mar 11 2009, 14:40) Здесь и далее - плюспицот за каждое слово К тому же, состояний, критичных к пропаданию питания, не должно быть много. В приличных девайсах надо закладывать раннюю диагностику пропадания питания. А "много" это сколько? "Плюспицот" - это много? Тестировали атомарность записи в eeprom? А если да, то как? Я имею дело со всякими девайсами и разными процессорами. В различных средах разработки, кстати. Поэтому молиться на IAR как-то не тянет. Например, были готовые серийные девайсы с внешней EEPROM на программном SPI. Именно с проблемой восстановления. Я - за рациональные решения. Объясните, пожалуйста, зачем нужна ранняя диагностика питания и как она сказывается на приличности? Если результата можно добиться программными средствами - это красиво и целесообразно. Уточняю - это не для всех случаев. Я не против диагностики, я даже за резевный ионистор в НЕОБХОДИМЫХ случаях. А вопросы о приличности оставляю на рассмотрение депутатов.
  11. State machine

    Цитата(Diz @ Mar 11 2009, 11:24) Пример взят из реальной задачи - нужно было при каждой смене состояния сохранять его во внешней eeprom, чтобы восстановить при пропадании питания. Лог переходов писать смысла нет, так как не важно, каким путем мы попали в данное состояние - важен сам факт попадания. Индекс - один байт, пишется атомарно. При загрузке легко его проверить на попадание в диапазон разрешенных состояний. Если будет восстановлено неверное состояние, неприятно, но не так разрушительно как вызов функции по неверному указателю. Еще одна особенность - прошивка могла быть обновлена, и обработчики могли бы лежать на других адресах. я не уверен в содержимом eeprom, если запись ведется в момент пропадания питания. В свое время тестировали - операция записи атомарна с точки зрения программирования. А так она занимает довольно большое время и содержимое слетает. К тому же eeprom может быть внешним. Поэтому писали лог (из двух последовательных состояний) - запись на входе и на выходе. Тут даже проверка может быть очень простой - значения совпадают, значит состояние валидное. Не совпадают - брать предыдущую пару. Цитата(Dog Pawlowa @ Mar 10 2009, 20:36) Да все тупо... то есть, если надо убрать одну функцию из центра списка, придется перенумеровывать все последующие? с событиями не совсем ясно: насколько я понял, функции опроса событий возвращают 0, если события нет и номер события, если событие есть. Как происходит нумерация событий? Получается, что события имеют приоритет, в порядке которого они опрашиваются. Из этого следует, что в любом состоянии приоритет событий одинаков. Более того, каждое состояние должно реагировать на все события. А если, допустим, первое событие - кнопка нажата, а второе - таймер сработал. Тогда при нажатой кнопке даже в состоянии "ждать таймер" система не будет не него реагировать.
  12. State machine

    Цитата(Dog Pawlowa @ Mar 10 2009, 19:14) Индекс проще проверит на валидность. Всего лишь на максимум. Индекс удобно использовать при генерации события по смене состояния. Индекс удобно использовать для возврата в старое состояние. Кароч, я использую индексы и массивы функций. Иногда двумерный массив functions[state][event] в каком-нить менюшном сервисе. с первым согласен. Только какой смысл в такой проверке? Проверка в рантайме - от какого бага она спасает? Если на этапе отладки - использование только поименованных констант не позволит вызвать неописанное состояние. С другой стороны, где гарантия, что индексы идут подряд. со вторым и третьим - не могу ничего сказать. Не могли бы вы написать пример реализации поподробнее? Для одномерного и двумерного массива? Особенно, для functions[state][event], что является индексом массива? я считаю, что удобство понятие не только субъективное. Удобно - когда логическая ошибка проявляется как можно раньше. Например, на этапе компиляции (стоимость обнаружения) Удобно - когда при введении нового состояния его надо прописывать как можно в меньшем количестве списков (связность). И компилятор следит за правильностью (стоимость). Неудобно - когда в нескольких списках описание состояния должно быть с одинаковым номером (связность). Цитата(-=TRO=- @ Mar 10 2009, 19:47) Внутри программируемой логики собирают микропроцесоры и пишут для них программы. На микроконтроллерах пишут программы эмулирующие логику(конечные автоматы). Походу использовать компоненты по назначению сегодня не модно. насколько я знаю, в 70-х годах было мнение, что наиболее перспективная парадигма в программировании - автоматный подход. "Лучше забивать молотком шурупы, чем закручивать отверткой гвозди"
  13. State machine

    Недостатки прямого присваивания значения переменной состояния, типа Код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:         ...   } } кроме некоторого контроля за присваиванием, такой подход не дает никаких премуществ. Просто на практике не всегда бывает возможно обеспечить полноту тестов.
  14. State machine

    Цитата(Diz @ Mar 6 2009, 16:20) Наверное, jumptable может быть полезен для сохранения текущего состояния в eeprom и восстановления после сбоя. Пишем лишь индекс, а не потенциально опасный указатель. сомнительно. все равно потом по указателю функция вызывается, для таких случаев обычно пишут лог переходов в том или ином виде, ну и список разрешенных переходов (собственно, он у Гомеса есть). реализовать кооперативную многозадачность с помощью конечных автоматов - собственно, этим я хотел закончить про реализации.
  15. State machine

    Цитата(_Pasha @ Mar 5 2009, 20:50) no comment Возможно, я не совсем понятно выразился - 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. А что? Дорого? Зато может способствовать уменьшению количества функций 2.Например, для повышения уровня языка реализации до проблемно-ориентированного http://www.citforum.ru/internet/xml/graphml/ 1. За счет чего? C использованием switch вообще одна функция. 2.Обычно проблему снаала описывают, а потом реализуют. если еще есть интерес, могу продолжить про реализации...