Jump to content

    

psyhologic

Свой
  • Content Count

    73
  • Joined

  • Last visited

Posts posted by psyhologic


  1. Здравствуйте.

    Бьюсь уже достаточно долго, пытаясь научится рассчитывать PI фильтр.

     

    Вводные данные:

    Бортовая сеть авто 12 - 24 V ( взял за основу предположение - Rs =  0.5 ом, Ls = 1uH ).

    Требования к EMI шуму: CISPR-25 Class 5 - 54dBuV

    SPICE модель: http://www.ti.com/product/LM53635-Q1/toolssoftware

    Buck преобразователь LM53635LQRNLTQ1 (LM536355QRNLTQ1). TI Webench предложил следующий дизайн фильтра:

    Спойлер

    1.thumb.png.3008cd0310fa7f8cac42c2c728c9cdc6.png

    Реальной платы пока нет, поэтому пытаюсь рассчитать аналитически, следуя вот этому документу http://www.ti.com/lit/an/snva489c/snva489c.pdf

    Period cycle T = 478.846 ns

    SW Freq = 1/T = 2088 354 084.6117 ~ 2.1 Mhz 

    ton = 184.615 ns

    Duty ON impulse = (184.615 / 478.846) = 0.38 = 38%

    Poutmax = Vout * Imax = 5V * 3.5A = 17.5 W

    RmaxLoadOut = Vout/Iout = 1.4285 Ohm

    Zdc-dc = Vin * Vin / Pout  = -10.413765 Ohm

    Ilmax = 3.8585 A и Ilmin = 3.1687 A

    Спойлер

    Steady-state transient response (без фильтра)

    2.thumb.png.78193e69d5eea0d16210533831a2e3ea.png

    3.thumb.png.61e3538f2a6249e290176fb0c130020c.png

     

    Спойлер

    Как пытаюсь посчитать ?

    4.thumb.png.2f9371802770495a632e2ef013678522.png

    Vp-p-noise = 20 * log (  (1.8478 / 3.14 * 3.14 * 2.1 * 10x6  * 20.094 * 10x-6 ) *  sin(3.14 * 0.38) / 1 * 10x-6 ) = 138 

     

    Мои вопросы (я новичок, не обессудьте. Мозг уже закипает.):

    1.) Видимо я где-то ошибся в математике. Как получилось 69.32 dBuV в Webench ?

    2.) Насколько я понял электролитические конденсаторы используются в CLC фильтрах из за высокого ESR и способности рассеивать AC помехи в тепло.

    http://forum.cxem.net/index.php?/topic/137843-параметр-ripple-current-электролитического-конденсатора/ 

    Если необходим миниатюрный размер, чем можно заменить ? Тантал / SF ?

    3.) Необходимо согласование сопротивлений между фильтром и DC/DC преобразователем. Пиковый импеданс фильтра должен быть меньше, пикового импеданса DC преобразователя.

    http://www.ti.com/lit/an/snva538/snva538.pdf

    PSpice умеет как-то считать их ? не смог разобраться как вывести :(

    Спойлер

    5.thumb.png.000b1e614756588864314e09eafcd892.png

    4.) Источник AC шума сам DC / DC преобразователь, соответственно фильтр должен быть "развернут".

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

     

    Заранее благодарю за помощь !

  2. 16 часов назад, Егоров сказал:

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

    Вопрос целесообразности фильтров / защиты зависит от стартовых данных.

    Если у ТС БП ATX и один потребитель - схему действительно можно упростить.

    "уродливая каракатица" - это решение скорее для бортсети DC / DC в машине, там всё это актуально.

  3. 15 часов назад, MementoMori сказал:

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

    Можете привести пример схемотехники необходимого в этой ситуации фильтра?

    DC-DC преобразователь - это "плотина" которая открывается, с частотой - 400kHz ~ 2.2MHz.

    Шум соответственно разноситься в обе стороны. До DC преобразователя поставьте CLC фильтр, подавляющий все частоты выше частоты регулятора. Смотрите AN-2162.

    Весь каскад защиты:

    DC -> TVS -> polarity protection -> CLC PI filter -> DC - DC -> Fuse (OCP) -> (TL431 + тиристор, OVP)

  4. В 08.04.2019 в 09:25, MementoMori сказал:

    Ваша правда. Не указывал я ток. Но думал, что указание на АТХ будет достаточно.

    Ток до 20 ампер. 

    А вот получится ли так, что при сгорании импульсника и открывании тиристора защита блока питания сработает раньше, чем сгорит предохранитель, я не знаю. Ведь даже если ток замыкания будет не в 5, а в 10 раз больше, на срабатывание защиты может потоебоваться меньше времени.

    Это зависит от вашего предохранителя.

    Вы реализуете эту OVP защиту после DC/DC преобразователя, зная максимальное потребление вашей нагрузки Iload и максимум Isource источника тока.

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

    Боюсь предположить как поведет себя PTC предохранитель, плавкий просто сгорит.

    https://en.wikipedia.org/wiki/Crowbar_(circuit)

    https://circuitdigest.com/electronic-circuits/crowbar-circuit-diagram

     

    У вас перед DC / DC конвертером нет EMI фильтра - будет шуметь "вверх" по DC шине, на частоте модуляции и гармониках.

    Соответственно, добавьте фильтр если потребуется пройти квалификации по conductive EMI. 

  5. В 06.04.2019 в 14:05, Aner сказал:

    Как скажите, наверное так и есть. Но молиться на их ANы не стоит. Я сам не раз ругался с их делателами в TI.

    imp_00041.png

    Да, так будет лучше. Ещё убрать лишний кусок 12V над U1. И как показано на этих скринах.

  6. 20 часов назад, MegaVolt сказал:

    Вроде бы в опциях я выбирал Flash чтобы были. Они разные по этому шьются по разному и нужно каждое семейство отдельно разбираться. Ну или кто подскажет.
    А обычно они используют те же пользовательские ножки но для программирования. Это если ножек мало может быть проблемой для перепрошивке в схеме. 

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

  7. 1 час назад, aaarrr сказал:

    ИМХО, в реализации Watchdog есть слабое место - "SoC загружается и переводит контроллер в режим watchdog". А если не загрузится?

    По опыту могу сказать, что всякие готовые внешние WD создают проблемы при производстве, т.к. во время тестирования и загрузки

    основного ПО таймер мешает. С учетом требований, если и найдется что-то готовое, то будет во-первых экзотично, а во-вторых,

    заметно дороже мелкого МК.

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

    в результате ужал "хотелки" и обошелся парой транзисторов.

     

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

    Боюсь транзисторами не обойдусь.

  8. 1 час назад, MegaVolt сказал:

    Устройство которое это делает не является проблемой. Можно даже поднимать трупик не один раз :))) Но тогда придётся ставить свой процессор со своей логикой обработки.

    Вот например https://www.analog.com/media/en/technical-documentation/data-sheets/ADM8316_8318_8319_8320_8321_8322.pdf
    Решает все вопросы кроме двойного способа оживления.

    Ещё тут https://www.digikey.com/products/en/integrated-circuits-ics/pmic-supervisors/691?FV=2dc09fb%2C3f0001b%2C3f002ce%2C3f002df%2Cffe002b3&quantity=1&ColumnSort=1000011&page=2&stock=1&k=watchdog&pageSize=25&pkeyword=watchdog

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

    Процики тут: https://www.digikey.com/products/en/integrated-circuits-ics/embedded-microcontrollers/685?k=controller&k=&pkeyword=controller&sv=1&sf=0&FV=3f003fa%2C3f00420%2C3f00425%2C3f00446%2C3f0001b%2C3f002ce%2C3f002d5%2C3f002df%2C3f002e0%2C3f002e6%2C3f002e9%2C3f00376%2C3f00393%2C4880065%2C4880013%2C4880003%2C4880041%2C488005e%2Cii4|2208%2Cii5|2208%2Cii6|2208%2Cffe002ad&quantity=1&ColumnSort=1000011&page=1&stock=1&pageSize=25

     

    Но вот на счёт программирования на лету watchdog таймера это нужно будет сильно подумать чтобы он не сбросил устройство во время перепрограммирования.

    Спасибо огромное, думаю эти чипы решат мои проблемы !

    А чем эти процики шьються на фабрике и дома поиграться ? они вроде не EEPROM.

     

  9. 1 час назад, Plain сказал:

    которое ведь тоже имеет право не помочь.

    Мудрая мысль... а если живы контроллер и модем, можно диагностировать проблемы с SoC. Надо думать.

    Те чипы, что прислал MegaVolt похоже решат на сейчас все мои проблемы с головой.

     

    2 часа назад, Plain сказал:

    сперва лишь "попробовать сбросить"

    FS sync / FS unmount / restart попробовать минимально выполнить.

  10. 30 минут назад, MegaVolt сказал:

    Это не проблема. Это задача которую можно решать массой возможных способов начиная от микропроцессора до чего нибудь аналогового на россыпи операционников.
    Проблема появляется там где наложенные ограничения не позволяют решить проблему имеющимися средствами.

    Вот ограничений я пока не вижу. Не нравиться проц значит делать на жёсткой логике. Нужен меньше объём и не проц то CPLD какое нибудь. 

    Т.е. где та проблема которую нужно решить???

    Разумеется, неразрешимой проблемы тут нет.

    Раздел вроде называется «В помощь начинающему», а так как я не являюсь специалистом по микроконтроллерам, я изложил своё видение «проблемы» и возможные варианты решения.

    То, что вам кажется очевидным, не всегда очевидно новичку.

     

    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 режим

    Давайте я переформулирую изложенное в вопросы:

    1.     Есть ли альтернатива контроллеру для этих 2 задач ?
    2.     Какой микроконтроллер лучше выбрать? Хочется программировать по UART, чтобы не заморачиваться с прошивкой на фабрике (лишний тех. процесс). Температурный режим -40 / +125
    3.     Задачу c watchdog наверняка можно решить готовым чипом, если да то каким ?
    4.     Задачу c standby наверняка можно решить готовым чипом, если да то каким ?
    5.     Возможно, кто то сталкивался с подобной задачей, если да - как вы её решали ?
    6.     Корректна ли вышеизложенная логика работы контроллера на ваш взгляд ?
  11. Здравствуйте

    Возникла следующая задача.

    Есть устройство, которое необходимо переводить в режим ожидания (фактически отключать все основные потребители - 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.

  12. С 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. 

  13. 15 часов назад, Alex-lab сказал:

    Матан это как таблица умножения. Без него никуда. Эти три года будут иметь мало смысла без матана.

    Смотря для чего, врядли человек только пощупавший STM станет заниматься дизайном новых полупроводников, лазеров или чем-то связанным с квант. мехом.

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

  14. Только что, AlexandrY сказал:

    А кто тут обсуждает UDP? 
    UDP по любому требует еще какого-то протокола сверху.
    TC же интересуется конечным прикладным протоколом. 

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

    ИМХО не стоит изобретать велосипеды, час программиста стоит ~35$

    Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT.

    У нас, "славян" прямо беда какая-то с излишней самодеятельностью / изобретательностью, которая потом часто выливается в "горе от ума" ...

  15. 12 минут назад, AlexandrY сказал:

    Сорри, ошибся. 

    70 Мбит/сек (не мегабайт!) - это скорость приема по TCP микроконтроллером.
    А скорость передачи по TCP у меня получилась 95 Мбит/сек.  Но у меня 100Base-T под рукой только. 
    Так что можем обсуждать дальше. 

    Так кто там предложит парсер JSON под ARM Cortex, чтоб он отъел не больше 10% производительности TCP стека?    
    И желательно с пруфами. 

    Здесь ещё множество подводных камней скрыто.

    В случае TCP они разруливаются на уровне самого протокола.

    Например, TCP остановит передачу, пока получатель не обработает предидущую порцию данных и не пришлёт ACK.

    Даже если "квантировать" UDP payload (как было предложено выше), чтобы уместить его в один UDP пакет.

    Где гарантии того, что пока получатель будет парсить / обрабатывать payload на слабом железе, не прилетят ещё 1000 UDP пакетов,

    из которых 500 попадут в буферы ОС, а остальные будут просто отброшены. 

    Это допустимо в некоторых архитектурных сценариях - ММО сервера, видео поток, etc ... 

  16. 20 часов назад, k155la3 сказал:

    За целостность информации отвечает Ethernet и IP/UDP, поэтому даже генерировать - проверять CRC не надо. 

     

    Пожалуйста, не вводите людей в заблуждение, IP / UDP не обеспечивают полноценного reliability. Для IPv4 даже UDP checksum - опция.

    Даже если ОС или приложение реализует механизм проверки checksum - не прошедшие проверку пакеты будут просто отброшены (без повторной передачи).

    А в случае высоких нагрузок (80 MBit/s как раз такой случай) и слабого железа, скажется отсутствие network congestion у UDP.

    Потери пакетов превысят все разумные пределы. 

    Вот почитайте на досуге - https://habr.com/ru/post/250227/

    2 часа назад, AlexandrY сказал:

    Протестил lwIP на MIMXRT1064 600 МГц с помощью iperf PC client
    На BM с -O3 в TCM получается не более 70 Мбайт/сек

    Что и требовалось доказать.

    123.jpg

  17. Только что, AlexandrY сказал:

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

    Согласен, MQTT лишь транспорт publisher / subscriber. Который хорошо вписывается в архитектуру микросервисов.

    В одном из последних проектов, на compute pi 3 based устройстве, mosquitto напрягая процессор максимум процентов на 5 - справляется с 250 событий в секунду (JSON payload).

    Правда мы не посылаем все эти данные в сеть, а агрегируем / кешируем, а только потом отправляем в облако по HTTPS пачкой.

    43 минуты назад, k155la3 сказал:

    Используйте UDP ( в одном пакете умещается не менее 1к байт). Т.о. Вы можете опросить Вашу периферию отправив один (!) пакет UDP на требуемый IP, и получив 1 (!) пакет ответа. Единственное, что надо будет контролировать - таймаут, после отправки запроса и максимального ожидания ответа. Все !

    Безусловно UDP самый шустрый. Но скажите пожалуйста, вам не надоели ещё эти "велосипеды" с custom протоколами.

    Я например, больше не покупаю устройства с самописными сетевыми протоколами. Почему ?

    Потому - что интегрировать их тяжко, ошибок в них много, документация худая, а время программиста стоит дорого.

    А потом как говориться - "вся рота идет не в ногу, один поручик шагает в ногу".

    Давайте дождёмся от ТС ответа, что же это за 10 MB/s телеметрии такой.

    Может из них можно сделать 10 KB/s и они прекрасно проскочат в MQTT и JSON.

  18.  

    7 часов назад, :-) сказал:

    (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux).

    Тот же mosquitto на Linux-based устройстве. 

    2 часа назад, AlexandrY сказал:

    Про реальное использование MQTT можно читать здесь - https://habr.com/ru/post/388343/

    Что я должен был тут почерпнуть ? имхо - пустая статья. Забейте в google: mqtt performance и увидите сравнение производительности разных брокеров под разными нагрузками.

  19. 1 час назад, AlexandrY сказал:

    Вы с MQTT сами работали или цитируете первые ссылки с гугли? 
    Про реальное использование MQTT можно читать здесь - https://habr.com/ru/post/388343/

    Во внутренней сети от MQTT толку мало, а тем более от HTTP. 

    Для того чтобы выбрать протокол надо ответить на несколько ключевых вопросов:
    -какая мощность платформы (Cortex-M, Cortex-A... , объем RAM, ...)
    -кто клиент трафика (аналитическая программа, пользовательский GUI, облака, сетевой накопитель...)
    -заходит ли в сеть публичный трафик,
    -предусматривается ли масштабирование сервисов у устройств,
    -предусматривается ли сеть аналогичных устройств и если сеть, то кто будет администрировать сеть. 

    С MQTT работал и много, но под Linux. Как он поведёт себя под RTOS, вам виднее.

    С такими объёмами «телеметрии» :crazy: request - response, нужен Xeon с TCP Offload’ом :sarcastic_hand:

    Шутка ли 80 Mbit/s payload...

  20. 33 минуты назад, :-) сказал:

    Сценарии использования видятся следующими:

    1. Запрос параметра - возврат параметра;

    2. Запрос телеметрии - непрерывный поток данных телеметрии до запроса отмены телеметрии.

    Соединение точка-точка.

    HTTP REST

     

    - Не забудьте подумать о многопоточности

    - Ограничены в количестве запросов в секунду

    - Можно пробрасывать через reverse proxy (устройство доступно в интернет из закрытой сети)

    - Nginx proxy сможет писать логи доступа

     

    А вообще датчики / телеметрию лучше через MQTT, но request / response модель придется реализовывать самому.

    3 часа назад, :-) сказал:

    Добрый день!

    Есть задача реализовать управление неким устройством через Ethernet-соединение (1G). Требуется управлять включением/выключением некоторых функций. Также требуется при необходимости получать телеметрию (скорость потока - 1..10 Мбайт/с, может и выше в перспективе). (На устройстве будет скорее всего FreeRTOS+lwip, но не исключен вариант и Linux).

    И тут возник вопрос - какой протокол использовать поверх UDP или TCP соединения (ещё не выбрано)? Придумывать что-то своё? Или есть что-то типовое, что всеми используется?

    1..10 Mбайт/с телеметрии ... не заметил, извиняюсь. Что это у вас за телеметрия то такая ?

    Все бортовые системы шатла, не иначе.