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

    

kolobok0

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    практикующий тех. волшебник

Контакты

  • Сайт
    http://www.6461530.ru
  • ICQ
    0

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

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

    Смотреть в сторону REST, JSON, Web-Socket
  5. Я бы смотрел в стандартные возможности этого свича. Если он умеет посредством вэб морды общаться - там делоффф на пару дней(или есть доки на его API). Прелесть - Вы ничего физического из допов не ставите. Минус - заточка на этот свич(протокол). (круглый)
  6. Подозревать - это не одно и то-же что "быть уверенным". Посему выскажу следующее мнение: - лучше всего это подключиться к интерфейсу самого счётчика (или заменить его на такой счётчик (типа "меркурия 230")). Обычно это RS485. Сразу оговорюсь - обратите внимание, что питание интерфейса внешнее т.е. помимо линии данных, необходимо озаботиться и питанием самого интерфейса (делали явно дилетанты эти счётчики - апсолютно НЕ практично). - обычно энергетические компании не используют дистанционное сканирование. Хотя если такое есть - то интегрироваться в их систему будет проще (имхо конечно-же). - если сами захотите сканировать, то в гугле куча инфы по интерфейсам подобных счётчиков. - если лень самим или нет спецов - то можно обратить внимание на готовые интерфейсные решения на рынке - см. bolid и иже (вплоть до крохоборов с "облаками" и другими обдуриловки клиентов). Кстати счётчики отдают гораздо больше инфы чем ток-напряжение по фазам. Рекомендую глянуть юайные софтинки которые умеют работать со счётчиками. С уважением (круглый)
  7. Сразу оговорюсь: 1) эпоксидка 2) НЕ пром вариант 3) Есть ПОБОЧНЫЙ эффект Про пузырьки все уже высказались - тут вряд ли, что либо новое добавлю. В авиамоделизме применяется - вакуумирование - центробежная сила По поводу разжижения(в том числе и снижение рисков саморазогрева) - очень замечательно подходит(для ЭПОКСИДКИ) это спирт. до 50% можно вливать. Да, сначала побелеет (есть вода естественно в спирте), далее после интенсивного размешивания становится менее тягуч до состояния воды. Время отвердевания увеличивается (не намного). Но при этом побочный эффект - усадка (естественно). Ну и отгезия. Кстати эпоксидка имеет отгезию и усадку до месяца (это по паспорту). С уважением (круглый) ЗЫ Стаж работы с ЭДП более 30 лет, если что...
  8. Корова немного не моя :) Пока фаза сбор инфы. И одна из них - возможно ли изготовить магнит с радиальной намагниченностью. Вот тут выше подсказали, что да возможно. Буду благодарен за посыл по общему вектору... или любую другую инфу наполняющую копилку знаний ... С уважением (круглый)
  9. Да похоже оно. Спасибо! С уважением (круглый) ЗЫ Вот первым делом стал ломится на форум - моя ошибка. а надо было как всегда в гуглю :)
  10. Добрый день! Всем известны как устроены обычные динамики. Формат их магнита - плоский тор, полюса которого располагаются на широких его сторонах (если положить на стол = сверху и снизу). Вопрос: Возможно ли изготовить магнит, полюса которого будут располагаться с торцов такой геометрии (один полюс внутрь, второй наружу) ? С уважением (круглый) ЗЫ Возможно не в ту ветку форума. Поправьте пожалуйста, если так :)
  11. Странная проблема при оптимизации

    +100500 2TC странно когда программист говорит компилятору - а теперь сделай красиво как хошь... а потом требует на отладке все стэпы которые ему казались что должны быть. Не находите? Если вы хотите дебажить выхлоп оптимизатора - то ТОЛЬКО(!) на уровне азма. всё остальное будет от лукавого.
  12. Схема OpenIMU300ZA

    мдя...поспешил начеркать... там модуль с гулькин хвост. сколоть ---дцать минут работы... из за чего сыр бор - хз.. имхо - пиар темы... (круглый)
  13. Схема OpenIMU300ZA

    ну вот у гугля навалом...все ссылки на сайт openimu.readthedocs.io забежав туда натыкаетесь на схему (круглый) ЗЫ это такой стёб типа?
  14. LwIP на STM32F4: потери UDP-пакетов

    ошибка в 55 строке... мало данных. начинайте пилить проблему на составляющие. включите-загляните в статистику lwip. Он показывает приём ваших потерянных пакетов? Если нет - сетевой уровень, плюс взаимодействие. Если ему пофигу и приём успешен - значит затык далее. И ещё. У вас в одном потоке или что то многопоточное прикручено? Используется ли пдп, он же дма :) ? аллокатор памяти какой юзаете? Правильно ли используете сам lwip? удачи вам (круглый) PS Если траблы с lwip-ом - то переносите, заводите топик в сетевов разделе вопросов. Там по сети толковые ответы получите быстрее.