Jump to content

    

kolobok0

Участник
  • Content Count

    1220
  • Joined

  • Last visited

Everything posted by kolobok0


  1. это подпись... типо колобок = круглый... удачи вам (круглый)
  2. Да, Вы правы... Согласно даташиту отсюда pdf страница 10 Адрес занимает с 1 по 7 бит. Согласно стр. 9 адрес A = 1000100 адрес B = 1000101 С пином R/W будет A/R = 10001000 = 88h A/W = 10001001 = 89h B/R = 10001010 = 8Ah B/W = 10001011 = 8Bh (круглый)
  3. Тут ещё пол копейки. Есть подход гитлаба (халява при поднятии своего, для мелких проектов - самое то) ну или заюзать вэб сервис от поставщика. Так вот гитлаб может отрабатывать pipeline скрипт которых настраивается как yaml файл лежащий прямо в репе (или даже группа файлов). При этом перенос очень прост - меняется именно этот файл при переносе в другую репу. Пайпа отрабатывается в ранерах гитлаба. По уму это разные тачки и ранеров может быть много. В пайпе можно делать параллельные и последовательные зависимости, ловить разные глаголы(не только мёрдж реквест), есть связи с мессэнджэрами, почтой, различными зоопарками. Немного глючноват, но терпимо. На пайпах можно вызывать отработку любых докер контейнеров. А что внутри них вы отрабатываете - фигня вопрос. Хоть баши, хоть питоны, хоть пых-пыхи и т.д. и т.п.. Можно собирать артифакты которые легко переносятся между ранерами автоматом (один билдовка например, а второй крутиться на таргет машине. направили на развёртывание в таргет машину - тут же раскатали в продакшен)... как то так (круглый) ЗЫ Гит флоу вытекает из ворк-флоу. Обычно на бранчах работа быстрая, без изменений исходников. Например простановка тэгов. Причём имя генерируется с указанием имени бранча и уникального счётчика(привет кастом атрибутам). Выставляем тэг. На данный тэг можно ссылаться внешней автоматикой для дальнейшей сборки-CI. На мёрдже реквесте(точнее при его подготовке) идёт проверка исходников = билдовка, прогон тестов, наращивание версии (если пушим в мастер или релиз), коммит изменений, выставление тэга. Можно прерывать пайпу и выходить на дальнейшее ручное проталкивание. Либо от настроек на проекте выставленные внешней автоматикой мы идём по нужным настройкам - например собирать ли, куда выкладывать, куда раскатывать и т.д. и т.п...
  4. сосредоточьтесь - речь шла НЕ об услышал-не услышал.... либо переформулируйте Вашу мысль...
  5. если чуток рядом посмотрите на сайте этом - там и без вентилятора есть то же самое... хотя вентилятор не показатель. например невесомость - там радиатор Вам не поможет. только активный отвод тепла...
  6. Может типо этого? * Samsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPUs* Mali-T628 MP6(OpenGL ES 3.1/2.0/1.1 and OpenCL 1.2 Full profile)* 2Gbyte LPDDR3 RAM PoP stacked* eMMC5.0 HS400 Flash Storage* 2 x USB 3.0 Host, 1 x USB 2.0 Host* Gigabit Ethernet port* HDMI 1.4a for display* Size : 83 x 58 x 20 mm approx.(excluding cooler)* Power: 5V/4A input не реклама, если что... (круглый)
  7. улучшить: чисто из опыта, - как минимум все опен библиотеки ( это относится и к lwip) надо проверять глазками. Хотя-бы схемотоз. А лучше перерыть. Звучит как минимум странно но увы, без контроля халявы можно нарваться совсем на костыли. В своё время приходилось править и lwip стэк, к сожалению. некоторые вещи пошустрее сделал, где то явный ляп подправил... на таком уровне. но это уже наверное устаревшая инфа - было не вчера... все мы родились не с клавами под мышками. сделать можно - диагностику добавить. Например сбор ключевых сетевых счётчиков и ответ собранной статистикой по запросу. рекомендую так-же сделать контроль стэков (глубину их использования. можно поставить на переключении, если многозадачная ось есть) и сбор как можно побольше инфы при падеже (пошёл по такому пути - запись во флэш и при рестарте проверка наличия свежего падежа и перенос уже на микро-сд в лог...).
  8. выше прозвучало не от Вас. (думаю не принципиально в контексте) т.е. разница лишь реализация ответной части от iperf либо свой огород (в профиль то же самое). и на писюке iperf или то же самое но самопальное... выбор(лично для мну очевиден). да и для Вас как я понял... ЗЫ С Вами завязалась беседа в струе ответа AlexandrY
  9. Читаю... "Нужно протестировать максимальную скорость обмена по этому порту" Поясните пожалуйста: заявленным характеристикам (тот кто проверяет) железки не верят(100Mbit), стандартным прожкам не верят(iperf, ping), но верят Вашим попугаям???? Или всё же воткнули устройство в сетку и прогнали стандартные тулзы типа pinga и iperf ? И используем эту методу дальше для поиска узких мест при эксплуатации. Что надо то? PS т.е. проверяют Вас или устройство???? ЗЫ ЗЫ Возможно ещё варианты - проверять скорострельность функционала, который реализует Ваше устройство. Ну тогда это вообще не на железке и свои типы счётчиков и свои методологии уже...кмк.
  10. "Открою большой секрет" наверное, но любой писюк на прямом подключении хост-хост покажет то же самое, что Вы сказали 98Mbit. Однако такие тесты (я описал один из примеров применения таких тестов), имеют смысл в сетевом мире и юзаются и в хвост и в гриву. Более того ровно 98Mbit в реальных пром. сетях маловероятно. Будет цифра в зависимости от ситуации, от загрузки, от настроек...ну и т.д...(речь про сотку в частности). Мессага от ТС - "Нужно протестировать максимальную скорость обмена по этому порту" , т.е. нужно проверить разработчика, что рисуемые им цифры круто выглядят и нет лишних циклов вставленных в код дабы ухудшить скорость. Возможно Вы и правы... Но тогда реализовывать ничего и не нужно, кроме вывода крутых цифр на экран... (круглый) ЗЫ Я исходил из жизни. Возможно ТС нужна показуха...Тогда опс...
  11. С точки зрения целесообразности точности измерения, или правдивости измерений - это всё условности в сети. Потому как ситуация может поменяться в любой момент времени. Исходя из этого, делать что то своё в плане диагностики - путь тупиковый, т.к. вызывает больше вопросов чем даёт ответов. Правильнее, как тут прозвучало выше (типо iperf, ping), поддержать стандарт утилит которые а) понятно как использовать любому линуксоиду б) понятен результат выводимый ими. Измерять более честно, правдиво и иже - зачем? Чтоб чтобы что? погордиться, что в момент икс была скорострельность канала 5 попугаев? Обычно те, кто занимаются сетями действуют по следующей цепочке => детектирование проблемы, быстрая проверка возможных причин, детектирование причины проблемы, устранение. Так вот, "быстрая проверка возможных причин" достигается применением и осмыслением полученных результатов стандартных утилит. Подозрение на маленькую скорость? прогнали iperf между узлами, увидели порядки чисел около 9xx мегабит в секунду - значит данный канал 1 гигабит выдаёт... Кстати при реализации поддержки стандартных протоколов, можно собирать и выдавать свою статистику - которая на Ваш взгляд может более полно ответить на те вопросы которые помогли бы в решении практических задач либо по узлу либо по связи. Например собирать статистику по "плохим" IP пакетам, или там кол-ву всего принятых пакетов и т.д.. Но как правило всё уже придумано до нас, и инфу по всевозможным счётчикам Вы сможете найти на любом управляемом свитче или роутере. с уважением (круглый)
  12. как было сказано выше... 1) они не имеют адреса, что упрощает пусконаладку. 2) они чувствительны к помехам. не везде и не всегда и достаточно редко. по первости мы их меняли(в одном, на целую линейку изделий) , потом изменив схематику детектировали переход в термостат и возвращали обратно в режим датчика.с тех пор головняка нет. 3) их действительно к сожалению сняли с производства. аналогов нет...увы. ЗЫ Попробуйте подключить его с управлением по питанию и программно скинуть в режим термодатчика. очень большая вероятность что это этот случай...но как понимаете - без изменения схемного решения к вам будут периодически обращаться с этим головняком.
  13. видел и такие, и немного другие. через ключи подключают инверторно ёмкостную нагрузку и вход АЦП мк (через согласующую развязку и иже). получается что с мк можно задавать разную частоту переключения. По мне - вот этот подход даёт шире манёвр при эксперименте. я смотрел уже готовые буржуинские платы парогенераторов. можете туда глянуть. там очень активная среда (не только вода бывает в баке). по поводу перходников на большое давление - лучше всего то, что под это заточено... например свечи автомобильные эээээ наверное дизельные если 25атм...
  14. ну вот это не понятно. (может не так понял я - хз). обычно, при решении любой задачи изучается для начала ранее накопленный опыт человечеством. а уж потом, пропуская через свои знания чужие решения - либо учишься учитывать те аспекты которые пробежали мимо, либо понимать что ты первый обратил внимание на что то новое... возвращаясь к баранам. как тут сказали выше - как правило используют не один штырь. но...(куда уж без него? :) ) подают не одно полярное напряжение. либо это переменка с БП, либо своя схема переключения полярности - по разному бывает. и чем агрессивнее среда и ниже требования к материалов зондов - тем, как я понимаешь это актуальней. даже при микро токе ключа сработки. как то так (круглый)
  15. Нет не нормально. 1) Как тут прозвучало - объективные средства контроля (ваершак в данном случае, будет более правильным средством) 2) Смотреть программку по обслуживанию UDP. Профилировать код, если своё или сваливать временные поинты в лог. 3) Что говорит пинг на этот комп? Используется ли асинхронный доступ к сокету? Наверное (если свой код) имеет смысл сделать минимум-миниморэ балванку и выложить на профильных форумах. как то так, для начала... (круглый)
  16. У Вас тактовая камня сколько? Если предположить, что большинство МК это сотни мГц, а писюк - единицы гигагерц...то вот Вам и есть этот порядок просадки. Если Вы пихаете в передатчик изернета не в рукопашную, а полуавтоматом - то расходы на подготовку пакетов минимальна(по секрету - вы можете отправлять с железки и по максимуму 65к :) на IP уровне. правда это немного не по фэншую но явных ограничений в RFC не было вроде как.) (круглый)
  17. инженер-электроник STM 32

    хз. ЧИССО по опыту... скажу так - нормальный инженер сможет всё. Есть только предпочтения и скорость вхождения в тему. удачи вам (круглый)
  18. Пока пишешь на одном писюке, один проект, с одним функционалом - не заметно. как только вылезаешь из штанишек - то начинаешь упираться в компиляторы, оси, инструментарий и прочую хрень. Лучше уж один раз изучить инструментарий и "забыть его", чем всякий раз дописывать очередной костылёк под ту или иную изменившуюся хрень. Более чем один комп, выросла команда - кто под форточками сидит, кто предпочитает линукс. Кто пафосно запускает студии кто правит в нотепаде код. Кто то возится с отладкой - кто то "пишет без багов", кто то предпочитает TDD - кто то об этом даже не задумывался. В cmake вы указываете что вам нужно получить, а как - это проблемы cmake. Он корректно всё подготовит для "любой" оси. И собственно в окружении по использованию инструментария у вас ничего собственно и не измениться. что уменьшает человеческий фактор и экономит часы... как то так ЗЫ По началу я так-же скептически относился к этому. Попробовал - профит очевиден. Проект под форточки и линукс...
  19. make или cmake(для универсальной, под разные оси) предназначен как раз для операций компилирования, задания рабочих каталогов, зависимостей файлов от результата, вызов команд на сборку и других операций - всё это позволяет делать. попроще make конечно же, точнее сказать он прост в настройках - всё ровно как лом. но cmake более прост в запуске если понять логику по сэмплам. т.е. если с программированием на ты или около - то можно смело поюзать cmake. какие-то настройки cmake (более глубокие) - имхо покопаться немного придёться. Но зато он много чего делает интуитивно на автомате. 1) ищит все компиляторы что у вас есть на машине 2) понимает почти на автомате что прилинковывать и как собирать. 3) и т.д. ... знакомиться лучше с любым опен-соурс мультиплатформенным проектом собираемый cmake. вам понравится :) В не зависимости make or cmake основные вехи 1) описание в текстовом файлике зависимостей исходников от таргет целей(получаемых объектников и уже объектники от бинаря) 2) настройка правильных вызовов необходимых компиляторов-линковщиков 3) дополнение необходимых телодвижений по ходу пьесы - копирование, создание, удаление...make только у вас будет заточен на конкретную ось - например форточки...
  20. +1 ну.... в общем-то да. я что то воспринял как более фундаментальный заход на тему... make или если универсальный - cmake так-же не плохая игрушка = справится с перечисленными ТС задачами...
  21. То что Вы спрашиваете относится к части девопса и должно по идее интегрироваться в общий схемотоз работы разработчика-коллектива-подразделения с учётом интеграции до и после этого процесса. Т.к. ваша задача сборки не висит в воздухе - то нужно исходить из того что Вы юзаете в качестве хранения исходников, планы на развитие, общее понимание этой механики внутри коллектива и ... и много чего ещё. Например если у вас гитлаб - то наверное можно рассмотреть его родное CI/CD (правда халявный вариант имхо - сыроват). Если нужна просто молотилка которая на все случаи жизни - то возможно имеет смысл заюзать CI типа Jenkins-а или похожее. Но это не сам компилятор или скрипт, это больше облочка над шэлами-мавами-скриптами-батч_пакетами и прочая шняга. Причём за минимум телодвижений можно сделать сразу понты - печать, натификация, интеграция, графики, логи, артифакты и прочая хрень. Но надо вникнуть в дух этой фигни, с наскока не получиться увы... И ещё... То что Вы перечислили - мааааалая часть того, что пои идее должно происходить на фазе до-во_время-и_после_сборки. Если почитать популярные словосочитания TDD, CD, CI и т.д. и т.п. то сама по себе эта ниша досfтточно глубокая и широкая. Не использовать опыт ранее накопленный - проигрывать на рынке. Использование - траты на изучение или получение как результата. тут вот всё индивидуально. и ещё... Если Вам кажется, что всё что написал выше это перебор - то прочтите этот пост через 5-10 инсталяций вашего продукта у крупных заказчиков, когда возрастут объёмы, время сократиться а функционала будет нарощено на порядки). Думаю Вы уже не будете столь категоричны :)
  22. Frontend<->backend interface

    Смотреть в сторону REST, JSON, Web-Socket
  23. Я бы смотрел в стандартные возможности этого свича. Если он умеет посредством вэб морды общаться - там делоффф на пару дней(или есть доки на его API). Прелесть - Вы ничего физического из допов не ставите. Минус - заточка на этот свич(протокол). (круглый)
  24. Подозревать - это не одно и то-же что "быть уверенным". Посему выскажу следующее мнение: - лучше всего это подключиться к интерфейсу самого счётчика (или заменить его на такой счётчик (типа "меркурия 230")). Обычно это RS485. Сразу оговорюсь - обратите внимание, что питание интерфейса внешнее т.е. помимо линии данных, необходимо озаботиться и питанием самого интерфейса (делали явно дилетанты эти счётчики - апсолютно НЕ практично). - обычно энергетические компании не используют дистанционное сканирование. Хотя если такое есть - то интегрироваться в их систему будет проще (имхо конечно-же). - если сами захотите сканировать, то в гугле куча инфы по интерфейсам подобных счётчиков. - если лень самим или нет спецов - то можно обратить внимание на готовые интерфейсные решения на рынке - см. bolid и иже (вплоть до крохоборов с "облаками" и другими обдуриловки клиентов). Кстати счётчики отдают гораздо больше инфы чем ток-напряжение по фазам. Рекомендую глянуть юайные софтинки которые умеют работать со счётчиками. С уважением (круглый)