Перейти к содержанию

    

psyhologic

Участник
  • Публикаций

    67
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о psyhologic

  • Звание
    Участник
  • День рождения 23.09.1983

Информация

  • Город
    Винница

Посетители профиля

322 просмотра профиля
  1. Watchdog и Supervisor

    Остановился на STM8, так как их банально намного проще шить. Ещё раз, спасибо вам большое за подсказку с ADM8316 !
  2. Watchdog и Supervisor

    А подскажите что-то из недорогих контроллеров automotive класса с выделенным UART для перепрошивки (dev board) до 5$ ? Для production ATtiny - "не в бровь, а в глаз", смотрю пока как их шить.
  3. Watchdog и Supervisor

    Про производства / отладки да - проблемы с watchdog актуальны, подумаю как. На дев борде можно вместо мосфета R0 перемычку бросить для отладки я думаю. Боюсь транзисторами не обойдусь.
  4. Watchdog и Supervisor

    Спасибо огромное, думаю эти чипы решат мои проблемы ! А чем эти процики шьються на фабрике и дома поиграться ? они вроде не EEPROM.
  5. Watchdog и Supervisor

    Мудрая мысль... а если живы контроллер и модем, можно диагностировать проблемы с SoC. Надо думать. Те чипы, что прислал MegaVolt похоже решат на сейчас все мои проблемы с головой. FS sync / FS unmount / restart попробовать минимально выполнить.
  6. Watchdog и Supervisor

    Разумеется, неразрешимой проблемы тут нет. Раздел вроде называется «В помощь начинающему», а так как я не являюсь специалистом по микроконтроллерам, я изложил своё видение «проблемы» и возможные варианты решения. То, что вам кажется очевидным, не всегда очевидно новичку. 1.) Реализация пробуждения устройства из standby режима по сигналу IMU. a.) Программируем IMU на отклик по акселерометру b.) Сообщаем контроллеру, что устройство переходит в standby. c.) Контроллер следит за INT2_XM и когда видит там HIGH – открывает mosfet питания. d.) Контроллер переходит в standby режим e.) SoC загружается 2.) Реализация watchdog. a.) SoC загружается и переводит контроллер в режим watchdog b.) Каждые N секунд, SoC должен послать контроллеру keepalive (I2C/UART) c.) Если контроллер видит X пропусков keepalive сигналов – подаёт LOW на EN вход SoC d.) Контроллер переходит в standby режим Давайте я переформулирую изложенное в вопросы: Есть ли альтернатива контроллеру для этих 2 задач ? Какой микроконтроллер лучше выбрать? Хочется программировать по UART, чтобы не заморачиваться с прошивкой на фабрике (лишний тех. процесс). Температурный режим -40 / +125 Задачу c watchdog наверняка можно решить готовым чипом, если да то каким ? Задачу c standby наверняка можно решить готовым чипом, если да то каким ? Возможно, кто то сталкивался с подобной задачей, если да - как вы её решали ? Корректна ли вышеизложенная логика работы контроллера на ваш взгляд ?
  7. Watchdog и Supervisor

    Обе. Использовать как watchdog, им же ловить interrupt от IMU и запускать загрузку SoC.
  8. Watchdog и Supervisor

    Здравствуйте Возникла следующая задача. Есть устройство, которое необходимо переводить в режим ожидания (фактически отключать все основные потребители - SoC, периферию, etc..) 1.) Когда устройство переходит в режим ожидания (by software). Нужно разбудить устройство по толчку (на борту есть LSM9DS0), пока думаю прицепиться к CTRL_REG3_XM. То есть физический толчок -> прерывание -> GPIO High -> контроллер или супервайзер -> загрузка SoC. 2.) В активном режиме работы, SoC должен по I2C / UART перепрограммировать таймер сброса(watchdog), каждые N секунд. Если этого не происходит - считаем устройство зависшим и делаем аппаратный рестарт. Было бы неплохо, сначала попробовать мягкий software рестарт (GPIO / I2C / whatever), подождать N секунд и рубануть уже EN или питание. Я понимаю, что проблему можно решить выделенным микроконтроллером. Так же хотелось бы его шить по UART прямо с SoC. Взываю к коллективному разуму, в поисках оптимального решения / микросхемы / возможных подводных камней. P.S. Микроэлектроника, SMD, температура -40 ~ +125.
  9. С MBED у меня опыта не много, а вот с ООП высокоуровневых языках предостаточно. Позвольте вставить свои 5 копеек. SerialPort - инкапсулирует всю логику работы с портом, скрывая все потрошка работы с железом. Дальше дробить скорее вредно. AlexandrY подсказал про возможные проблемы. CycleBuffer - класс / структура представляющая результаты чтения / записи. Можно вдохновиться здесь - http://nginx.org/en/docs/dev/development_guide.html#buffer ProtocolParser - работает с SerialPort / CycleBuffer, реализует разбор и копирование данных на специализированные Packets. Прячет всю работу с SerialPort от остального приложения. Packet и наследники Packet - фрейм вашего протокола разложенный на структуры / классы. MyProtocol - логика разбора и обработки пакетов протокола. Содержит instance ProtocolParser. Может быть построен по разным шаблонам проектирования. P.S. ViKo вы забыли упомянуть какую событийную модель использует ваше приложение. Request - Response / Publisher - Subscriber / etc.
  10. Смотря для чего, врядли человек только пощупавший STM станет заниматься дизайном новых полупроводников, лазеров или чем-то связанным с квант. мехом. А вот базисы теории электричества, да надо понимать и любить, без них увы ничего не выйдет.
  11. Интересно почему выбрали такую интересную схему энкодера для счётчика. В чём собственно её выгода ?
  12. ИМХО не стоит изобретать велосипеды, час программиста стоит ~35$ Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT. У нас, "славян" прямо беда какая-то с излишней самодеятельностью / изобретательностью, которая потом часто выливается в "горе от ума" ...
  13. Здесь ещё множество подводных камней скрыто. В случае TCP они разруливаются на уровне самого протокола. Например, TCP остановит передачу, пока получатель не обработает предидущую порцию данных и не пришлёт ACK. Даже если "квантировать" UDP payload (как было предложено выше), чтобы уместить его в один UDP пакет. Где гарантии того, что пока получатель будет парсить / обрабатывать payload на слабом железе, не прилетят ещё 1000 UDP пакетов, из которых 500 попадут в буферы ОС, а остальные будут просто отброшены. Это допустимо в некоторых архитектурных сценариях - ММО сервера, видео поток, etc ...
  14. Пожалуйста, не вводите людей в заблуждение, IP / UDP не обеспечивают полноценного reliability. Для IPv4 даже UDP checksum - опция. Даже если ОС или приложение реализует механизм проверки checksum - не прошедшие проверку пакеты будут просто отброшены (без повторной передачи). А в случае высоких нагрузок (80 MBit/s как раз такой случай) и слабого железа, скажется отсутствие network congestion у UDP. Потери пакетов превысят все разумные пределы. Вот почитайте на досуге - https://habr.com/ru/post/250227/ Что и требовалось доказать.
  15. Согласен, MQTT лишь транспорт publisher / subscriber. Который хорошо вписывается в архитектуру микросервисов. В одном из последних проектов, на compute pi 3 based устройстве, mosquitto напрягая процессор максимум процентов на 5 - справляется с 250 событий в секунду (JSON payload). Правда мы не посылаем все эти данные в сеть, а агрегируем / кешируем, а только потом отправляем в облако по HTTPS пачкой. Безусловно UDP самый шустрый. Но скажите пожалуйста, вам не надоели ещё эти "велосипеды" с custom протоколами. Я например, больше не покупаю устройства с самописными сетевыми протоколами. Почему ? Потому - что интегрировать их тяжко, ошибок в них много, документация худая, а время программиста стоит дорого. А потом как говориться - "вся рота идет не в ногу, один поручик шагает в ногу". Давайте дождёмся от ТС ответа, что же это за 10 MB/s телеметрии такой. Может из них можно сделать 10 KB/s и они прекрасно проскочат в MQTT и JSON.