Jump to content
    

grau

Участник
  • Posts

    61
  • Joined

  • Last visited

Reputation

0 Обычный

About grau

  • Rank
    Участник
    Участник

Контакты

  • ICQ
    Array

Recent Profile Visitors

1,935 profile views
  1. В каждой шутке - доля шутки:) В масштабах страны, конечно, энергозатратненько получается - а вот чтоб свой датчик запитать уже нормально Ведь думаю сейчас о том, как распространенные (дешевые) компьютерные технологии использовать для этой модернизации (искробезопасность) Первой идеей было беспроводную зарядку туда приделать - и питание есть, и данные передаются и разъемов нету вообще Но пока непонятно, как эту штуку потом сертифицировать: ведь база будет своя по требованиям коструктива, и получается такой неслабый радиопредатчик - в лоб ЕМС не пройдет, а спец-регламента на такие зарядки не могу найти И второй вопрос, который потом придется решать, это шифрование канала. Можно, конечно, сколхозить свое проприетарное изделие, но хотелось бы совместимости со всем остальным миром - где брать ключи и сертификаты, референс дизайн для изделия, как эту крипту реализовывать...? >> Сергей Борщ >> отличается от действительности. Маркеры предусмотрены стандартом, но их наличие необязательно, как и поддержка USB PD. Речь, очевидным образом, идет не о работе в режиме совместимости - а об использовании _всех_ возможностей стандарта TYPE-C для решения конкретной технической задачи.
  2. >> Топикстартер по ходу уверен, что взрыв вызывает нагрев в месте КЗ. Это не верно. Честно говоря, пока руководствуюсь именно этим предубеждением:) Все напряжения низкие, катушек нету >> Type-C практически гарантировано при КЗ даст искру с энергией, достаточной для взрыва. На чем основано подобное утверждение? Питание устройства 5В, ток до 300мА Сейчас смотрю ГОСТ 31610 - Табл А1 - Допустимый ток короткого замыкания в зависимости от напряжения и группы запас по току КЗ, вроде, на порядок получается, а дальше срабатывает ограничение общей энергии по протоколу PD
  3. >> 1) какая среда для датчика? Метан? Водород? Углеводороды? Эфиры? Про среду ничего сказать не могу - мне это пришло уже в виде II 2G Ex ib IIA T3 Gb >> 2) Вид взрывозащиты исходной? "Взрывонепроницаемая оболочка?" Исходно было - пластиковый корпус IP54 - сейчас предлагается его целиком засунуть в алюминиевую сертифицированную коробочку >> 3) А чего хотим? тип защиты "Искробезопасная электрическая цепь?" Да, именно так Т.е. вопрос - что надо сделать, чтобы готовый беспроводной датчик можно было продолжить эксплуатировать в взрывозащищенной среде. Главная беда - как менять аккумулятор (сам датчик приклеен) - для этого требуется вскрытие корпуса. Пока основной вариант - это батарейку спаять последовательно с резистором и стабилитроном, а потом залить все компаундом - и уже этот блок вынимать/вставлять И основную плату тоже залить Могу изложить в моем понимании:) Связь по Type-C подразумевает наличие электронных маркеров на концах кабеля и пакетному обмену с ними на 300кб/с Все операции по смене профиля питания и его направления проводятся через этот протокол PD - в частности извлечение кабеля ведёт к отключению питания линии (SOP пакеты и K-коды) В моем разумении - детектирование перепотребления тока по сравнению в профилем ведет к такому же отключению нагрузки по протоколу с разъемом кабеля
  4. Еще раз: это и есть моя задача - модернизация существующего устройства! Естественно, что когда изменения будут реализованы - железяка пойдет на сертификацию - потому и ATEX. Изначальный вопрос чисто технический, про питание из разъема, а не как правильно жить надо
  5. Само устройство является герметичным датчиком с автономным питанием и радиолинком. Трудности возникли с заменой батарейки в защищенной среде - крышку-то теперь нельзя открывать для этого! Вот меня и спрашивают - что надо поменять, чтоб продолжать эту железяку пользовать в таких условиях. Пока рассматриваются два варианта: или переделывать электронику под искрозащиту и жить с батарейкой как раньше, или втыкать внешнее питание, от повер-банка к примеру
  6. Приветствую! Недавно задали вопрос, который лично меня озадачил - может кто уже имел опыт в этой области и подскажет.. Нужно запитать измерительное устройство с соблюдением требований искрозащиты. Предварительно чтение стандарта (пока, наверное, по диагонали) содержит требование на ограничение энергии замыкания и на механику: втыкать без промаха, земля по бокам, расстояние между контактами.. Но получается, что формально, можно подключится через type-c - ведь там каждый коннектор, фактически, содержит в себе электронный предохранитель - любой коротыш приведет к отключению на передающей стороне. Т.е. перегрева при аварии невозможно в принципе! Смущает - что будь все так просто - все бы так уже давно делали:) Сергей
  7. Приветствую! Очень удобно, когда железяку, типа телефона, бросаешь на стол, а забираешь с полной батарейкой Вроде и сами микросхемы для таких зарядок сейчас доступны - развести ее с катушкой - и замена штекеру готова Но ведь получается, что эта штука вжаривает ватты мощности на десятке мегагерц! А как это штуку потом сертифицировать вообще? Только в составе с заряжаемым прибором? Так же очевидно, что одним приемником распространение ЭМИ не ограничится - как проходить камеру с антенной? Доводилось ли кому слышать об активности в этой области? С чего вообще начинать?
  8. Так это, как бы и был вопрос:) - чего надо подкрутить в сгенерированном кубом проекте Просто, в моем понимании, код на выходе генератора должен быть заведомо работоспособным, чтоб начиная с этой точки настроить его под свои конкретные нужды. А по-факту, получается, это всего лишь морда лица над дефайнами библиотеки, которые все равно руками потом править. А ребятки откровенным очковтирательством с рюшечками занимаются
  9. MEM_SIZE увеличивал, пока не перестали сообщения об ошибках аллокации сыпаться MEM HEAP avail: 80000 used: 66676 max: 76128 err: 0 так понимаю, что куча общая, а дальше из нее все откушивают потому что получил в лог altcp_tls: TCP_WND is smaller than the RX decryption buffer, connection RX might stall! и оно в само деле подвисало, пока размеры всех массивов и число буферов не поднял. В конкретных значениях пока не уверен - просто увеличивал всех сразу по два раза, пока не запустилось
  10. Стек - там просто математика крутится Под сеть - там есть функция, которая говорит сколько было реально использовано и дефайны, которые предупреждают, что в определенных ситуациях может не хватить а вообще говоря, сам конечно подивился таким запросам - ведь это простейший случай, с самоподписанным сертификатом и два байта переслать
  11. Ладно, сам спросил - сам ответил Сто кило для стека надо было выдать, и еще 80к на буфера сетевые - и все запустилось из коробки.
  12. Приветствую! Есть плата nucleo-f767zi. Очень хочется сделать из нее удаленный датчик для IoT. Для начала генерируем проект из Cube для этой железки и включаем LwIP и FreeRTOS. Встроенный MQTT клиент прекрасно взаимодействет с локальным Mosquito. А теперь еще хочется передать данные по защищенному соединению. В том же Cube жмакается галочка MbedTLS и... ничего: нагенеренный проект даже не собирается, инициализация LwIP тоже изчезла из кода. Собственно дальше начинается изучение влияния всех имеющихся дефайнов и зависимостей, чтоб хоть как-то запуститься. Пока так понимаю, что надо заставить работать функцию altcp_tls_create_config_client_2wayauth, но что-то дальше все виснет где-то в потрохах либы. Может подскажет кто, как правильно надо перенастроить проект, чтоб секьюрность заработала? Или может встречалась готовая инструкция?
  13. Приветствую! Хочется попробовать использовать iostream под keil. Для начала взял стандартный пример Examples\C++\Example1\OstrStl Все собралось замечательно, но при заглядывании в map файл обнаружил, что ios.o отъело 7к оперативки Подробное разбирательтсво показало что-то вроде std::__rw_cin_databuf 0x20000090 Data 512 ios.o(.bss) std::__rw_cout_databuf 0x20000338 Data 512 ios.o(.bss) ... std::__rw_wcerr_databuf 0x20001460 Data 1024 ios.o(.bss) std::__rw_wclog_databuf 0x20001900 Data 1024 ios.o(.bss) т.е. память ушла на буфера, которые, в принципе, в таком размере и не надобны. Как уменьшить размер буферов ввода/вывода для потоков стандартной библиотеки?! Мне сначала наивно подумалось, что переписать //#define STDIN_BUFSIZ (64) /* default stdin buffer size */ //#define STDOUT_BUFSIZ (64) /* default stdout buffer size */ //#define STDERR_BUFSIZ (16) /* default stderr buffer size */ в файлике stdio.h будет достаточно, но эффект оказался никакой
  14. И в самом деле глючит! при выходе из редактирования страницы теряются данные, плагин внешнего редактора тихо падает при загрузке страницы, макрос для word работает только в версии 2003.. Интерфейс, конечно, можно настраивать, но вариант из "коробки" ужасен. Так что задумка на отлично, реализация - неуд. P.S. Сам не ксенофоб, но французы писать код не умеют:)
  15. могу порекомендовать обратиться в http://redmine.net.ua/forum/
×
×
  • Create New...