В качестве демонстрации решения, соберем готовое устройство, как пример: набор датчиков в одном корпусе.
Почему в этот ряд статей «приплетена» статья про модем? При тестировании модема были использованы те же решения, про которые пишется сейчас, как то создание устройств из ПП разработанных с целью изготовления модуля с более-менее законченным видом и имеющего в своем составе набор относительно унифицированных плат.
Печатные платы, в отличие от ардуиновских шилдов, делаются под пайку. Т.е. технология слегка отличающиеся от «быстренько воткнул и заработало».
В частности в тестовой версии модема, что собирался для проверки идеи как таковой, были использованы плата процессорная, плата макетная и трех-юнитовый корпус. Как это выглядело можно посмотреть на картинках статьи об испытании модема.
Плата макетная для корпуса D3MG
Вернемся к датчикам. Поскребши «по сусекам» на столе оказались:
- DHT-22 — датчик влажности и температуры, интерфейс Single Wire (не путать с 1-Wire)
- GY-65 — датчик давления и температуры, интерфейс I2C
- GY-302 — датчик освещенности, интерфейс I2C
- GAS Sensor (MQ-135) — датчик на кучу газов, но самое интересное — CO2, аналоговый выход
В общем, всё из набора для ардуинки.
Набор датчиков, DHT-22 впаян на плату мезонинную
Сюда же добавим плату процессорную, плату крепления датчиков. Текущая версия платы мезонинной под датчики мне не нравится, будет переделана с целью унификации под большее число поддерживаемых, в том числе одновременно, датчиков. В нашем модуле оказались сразу два температурных датчика. Один показывает температуру внутри корпуса, другой — снаружи.
«Слабым звеном» в этом наборе будет GAS Sensor. У него диапазон рабочих температур -10 +45. Остальные компоненты, включая датчики -40 +85. Это температурный пром. диапазон.
Применение компонент для данного температурного диапазона делает несколько дороже стоимость изделия. Если у кого то появится желание, то можно подобрать компоненты совместимые с примененными, но попроще, допустим диапазона температур -10 +70. Так же, для снижения стоимости, печатные платы можно укомплектовывать не полностью. Платы спроектированы на применение в пром. условиях. В домашнем хозяйстве нет таких жестких требований к оборудованию, поэтому такие компоненты как монитор старта, защита CAN, внешний кварц для МК, многоуровневые гальванические развязки можно не устанавливать. Цена изделия будет ниже, но и сфера применения ограничена.
Модуль датчиков в сборе
Применительно к модулю датчиков, с целью посмотреть/оценить/протестировать ПО работы с каждым датчиком по отдельности и всех вместе, как и было упомянуто в предыдущей статье достаточно любой демо-платы с МК STM32F10x «на борту». На какие порты МК какие датчики цеплять — есть описание в архиве с исходниками.
Пример вывода датчиков, вывод данных на консоль.
DHT_t — температура, датчик DHT-22
DHT_h — влажность, датчик DHT-22
BMP085_p — давление, датчик BMP085
BMP085_t — температура, датчик BMP085
BHT1750 — освещенность, датчик BHT1750
CO2 — концентрация СО2 (вывод напряжения со входа АЦП, ppm более сложный пересчет)
Собранный модуль можно использовать для «автономной» работы, как тестовый или как мини-погодная станция. При тестировании, информацию с датчиков получаем через USB - UART. Питание модуля внешнее, DC 5V или 24V (мезонинные платы, для различного питания будут отличаться числом компонентов). При варианте работы через USB - UART перемычкой на плате МК можно запитаться от 5V USB.
Но, цель создания модулей по данной технологии это не развлечения с отдельной коробочкой, задача строить системы из подобных модулей, где каждый из модулей выполняет определенную функцию. Например уже созданный модуль датчиков. Для объединения модулей в сеть на плате с МК присутствует CAN интерфейс. Помимо CAN, в качестве эксперимента были построены небольшие беспроводные сети на основе ESP8266 и NRF24L01. Решение с использованием ESP8266 в то же время позволяет модулям самым простым способом подключиться к сети TCP/IP.
Но, вернемся к CAN. Наиболее разумное решение это один мастер, остальные подчиненные. Мастер с определенной частотой рассылает запросы, устройства?модули отвечают. Запрос?ответ асинхронны. Т.е. мастер не ждет, когда придет ответ от подчиненных. Но в то же время, если в заданный промежуток времени ответ от подчиненного модуля не пришел, то с этим модулем явно есть какие то проблемы. В то же время, в силу особенностей реализации CAN, любой модуль в произвольный момент времени может послать сообщение, напр об аварии или критическом событии, не дожидаясь запроса от мастера. Данное сообщение получат как мастер, так и все модули сети CAN.
CAN Bus дает возможность подключать наборы модулей к ПЛК различных производителей, в этом случае требуется написать библиотечные модули, напр. на языке ST, для поддержки промышленным контроллером протокола передачи данных для наших модулей. В этом случае ПЛК будет мастером.
Повторюсь, что в качестве мастера может выступать любой компьютер или микроконтроллер, такие как PC, Raspberry, Arduino, любой из наших модулей.
Например, для построения сети из модулей, на основе предложенной концепции, сделаем модуль USB?UART?CAN. Используем кусок платы, отрезанный от макетной. На этот кусок платы припаиваем плату с микроконтроллером и клеммы.
Модуль UART?CAN
Готовый модуль USB?UART?CAN
Заливаем в этот модуль прошивку CAN?Gate и можем работать, напр с нашими модулями датчиков по протоколу CAN, получая данные от модулей и управляя модулями. В частности, модуль CAN?Gate позволяет снифферить сеть CAN, посылать команды любым устройствам поддерживающих физическую реализацию данного протокола, не обязательно только нашим модулям. В то же время, как пример, из этого модуля я могу сделать мастера, поместив в него соответствующую управляющую программу. По сути этот модуль становится свободно программируемым ПЛК.
Пример сети CAN
Далее, если работать с CAN, то эксперименты с любой демо-платой закончены, ПО будет сильно привязано к разработанному «железу».
Подробнее про CAN, протоколе обмена и с чем их будем «есть» — в следующей части публикаций.
и… в связи с моим «неправильным поведением» местные «жители» заминусовали вусмерть, до невозможности дальнейших публикаций.
Посему статьи, в том числе продолжения буду публиковать на своем сайте.
Кому интересно, иногда заглядывайте…
Комментарии (155)
Vasia529
26.02.2017 07:29+21) Выкиньте MQ-135, используйте NDIR-датчик (Nondispersive infrared sensor), например MH-Z19 (или любой другой)
2) Какую практическую цель преследует измерение уровня концентрации углекислого газа в эл. щитке? Тем более таким хреновым датчиком?leocat33
26.02.2017 07:421) Выкиньте MQ-135, используйте NDIR-датчик (Nondispersive infrared sensor), например MH-Z19 (или любой другой)
Если купиите модуль с Mh-z19, то за ваши деньги любую прихоть:)
Mh-z19 CO2 датчик винзен датчик газа на Али стоит 1 915,36 руб, MQ135 в РФ 300 р. Показатели MQ в общем то стабильны. Калибровка каждого — да, нужна.
2) Какую практическую цель преследует измерение уровня концентрации углекислого газа в эл. щитке? Тем более таким хреновым датчиком?
Нигде и не написано, что монтаж модуля в шкаф. В шкаф в частности — да, но не этот конкретный модуль. В шкаф хорошо пойдет напр. модуль 8 каналов 0-20 мА, модуль 9 каналов 1-Wire, модуль 3 реле 220V 10 A, с датчиками тока по каждому,… Это все уже есть. А данный модуль вполне себе нормально и на стене смотрится. Монтаж либо на двусторонний скотч, либо на кусочек DIN-рейки в размер модуля. Монтаж-демонтаж намного удобнее, чем напр. маршрутизатор DIR-XXX от D-Link.gbg
26.02.2017 08:31+1Dir-XXX имеет отверстия для надежного крепления за два дюбеля. Что гарантирует практическую невозможность отвала и падения на голову.
Монтаж на «кусочек» чего-либо является кохлозом.
А скотч отваливается.
Выложите исходники на github. Чтобы посмотреть, что у вас нет watchdog и нелюбовь к циклам (зато тяга к копипасту), мне пришлось возиться с архиватором.leocat33
26.02.2017 08:59Как часто модули с DIN-рейки отваливаются? А «кусочек» как раз и имеет 2 отверстия под анкеры/дюбели/шурупы.
Вообще то watchdog есть, пока отладка — закомментирован. Копипаст чего/кого? Самого себя? Программы пишутся с нуля самостоятельно. Если есть возможность избегать циклы, то так и делаю. Работа в основном на прерываниях. Хотя циклов типа while — хватает. А насчет исходников: моя селедка, куда хочу, туда и повешу…gbg
26.02.2017 09:30+1Посмотрим на ваше измерение силы тока:
ADC_RegularChannelConfig( ADC1, 1, 1, ADC_SampleTime_1Cycles5 ); // канал 1 ADC_SoftwareStartConvCmd( ADC1, ENABLE ); // включить преобразование while( ADC_GetFlagStatus( ADC1, ADC_FLAG_EOC ) == RESET ); // ждем окончания преобразования adc_v1[i_cur] = ADC_GetConversionValue( ADC1 ); // возвращаем результат ADC_RegularChannelConfig( ADC1, 2, 1, ADC_SampleTime_1Cycles5 ); // канал 2 ADC_SoftwareStartConvCmd( ADC1, ENABLE ); while( ADC_GetFlagStatus( ADC1, ADC_FLAG_EOC ) == RESET ); adc_v2[i_cur] = ADC_GetConversionValue( ADC1 ); ADC_RegularChannelConfig( ADC1, 3, 1, ADC_SampleTime_1Cycles5 ); // канал 3; 5 на TST ADC_SoftwareStartConvCmd( ADC1, ENABLE ); while( ADC_GetFlagStatus( ADC1, ADC_FLAG_EOC ) == RESET ); adc_v3[i_cur] = ADC_GetConversionValue(ADC1);
Почему вы здесь не применили for? Код оказался бы в три раза компактнее. А лучше бы использовать прерывания, а еще лучше — DMA.leocat33
26.02.2017 09:34-4Есть один простой вопрос, который убил многие интересные начинания: а нафига?
Код открыт. Что не нравится — меняйте. Можете прислать патч, возможно включу в релиз.
Просто огульно хаять — …gbg
26.02.2017 09:41+8Я для этого и попросил вас выложить код в систему контроля версий. И это называется не «огульно хаять», а тратить мое личное время на написание вам рекомендаций по повышению качества кода. Если ваша публикация такой цели (получение советов и рекомендаций сообщества относительно ваших изделий)не преследует — я тем более не буду тратить свое время.
leocat33
26.02.2017 09:48-11Можно ли изнасиловать женщину на площади?
Ответ — нет! Прохожие достанут советами.
teleghost
26.02.2017 15:27+2leocat33, мне понравилось то, что Вы написали в статье, но я давно заметил, что хороший «электронщик» и хороший кодер — редкое сочетание. То, что Вы оставили в коде — это разбрызганные капли олова и разлитый флюс на конечном изделии. Поэтому либо закрывайте код совсем, либо, наоборот, выкладывайте на площадку с контролем версий и лучше сразу включайте заднюю, не газуйте:)
Да, полировать глюкало можно до бесконечности, но для того люди и придумали такую дисциплину, как рефакторинг кода, есть определённые основания и правила заниматься наведением порядка. Не могу сказать за «убитые начинания», но продуктов плохим кодом было убито тоже немало, а сколько ещё будет убито — и не сосчитать. Дьявол в деталях, и невнимание к ним — это глюки и уязвимости в IoT, от которых будут массово страдать наши современники и потомки, извините за пафос. Хорошего дня.
PS тем более, что это всё явно связано с управлением электропитаниемleocat33
26.02.2017 16:13Согласен, код не «причесан». Да и цели такой на этом этапе не ставилось. Задача показать, что железо работает. В коде кусков копи-пасте от собственных же разработок и закомментаренных блоков — более чем. Но уж если некоторые и начинают заниматься критиканством, то это в тех местах кода, где вообще нет ничего критического. Например float и большая часть sprintf исключительно для вывода информации UART, причем как тестовой. В реальном устройстве обмен данными по CAN. Консоль только для конфигурации. С конфигурацией, по тексту программы, надеюсь все понятно?
Да и в статье пока нигде не упоминается про программирование.
leocat33
26.02.2017 09:41Да, и это не измерение силы тока:) Это измерение НАПРЯЖЕНИЯ на АЦП:) Где то в программе function.c используется? Хвосты, от других программ, валяется себе, никому не мешает:) Этот фрагмент кода — тестовый, и от… 2014 года!
Респект, как очень внимательному читателю:)gbg
26.02.2017 09:48+4Так зачем вы мусор в проект кладете? Подчеркнуть низкое качество вашей работы?
Я фрагмент кода назвал по вашему же комментарию:
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Вычисление действующего значения переменного тока // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~leocat33
26.02.2017 10:41-4Поскакавши по верхушкам проекта насколько реальную оценку вы в состоянии дать?
Жду патчей!:)
olartamonov
26.02.2017 13:46Какой вы терпеливый человек…
Я вот почитал дискуссию, скачал архив, открыл архив, открыл main.c, прочитал первые строки:
int main() { float f1, f2;
Уверен, весь остальной код там оптимизирован на таком же уровне.leocat33
26.02.2017 14:10-2Ну — малаца! Первые 3 строчки прочитали. Не каждый осилил main.c открыть… Кто-то начинал смотреть «хлам» да еще с условной компиляцией:)))
И где вы тут дискусию нашли?!olartamonov
26.02.2017 14:20+3Вы так радуетесь, как будто в этих трёх строчках что-то хорошее написано.
У вас, извините, там float на STM32F1. И весь этот float сделан ради возможности сделать sprintf с десятыми долями.
Хотите, я вам открою страшную тайну, известную любому нормальному программисту, поднявшемуся выше уровня поделок на ардуине?
int x = SOME_VALUE_HERE; char buf[SOME_SIZE_HERE]; snprintf(buf, sizeof(buf), "%d.%d", x/10, abs(x%10));leocat33
26.02.2017 15:22-2И?
olartamonov
26.02.2017 15:25+3Да нет, ничего особенного. Просто ваш float — это сотни байт лишнего кода и падение скорости выполнения на порядок на ровном месте.
Но пока у вас ардуиноподобное изделие, в котором всё это крутится в while(1), изящно управляемое конструкцией delay_ms, ничего страшного. Обычный любительский наколенный говнокод.leocat33
26.02.2017 15:30-3Тот же DS18B20, или Single wire, как для них обеспечить необходимый интервал времени? Ах да, через nop-ы (классика жанра)
И, ну да, экономия целых 200 байт! команд. Сейчас программа, со всеми принтф-ами занимает 15к из 64. + 8 байт!!! ОЗУ.
И?olartamonov
26.02.2017 15:35+3Я же говорю, для вашей программы и вашего уровня — всё совершенно нормально. Орлята учатся летать.
Просто не надо на одной странице с этим употреблять слова «PLC», «демонстрация решения», «интернет вещей» и тому подобные.
Это должно называться «Я решил освоить STM32, подскажите, где у меня ошибки?».leocat33
26.02.2017 15:39-6вам сюда: Сайт
olartamonov
26.02.2017 15:42+3… сообщил мне человек со стремительно уменьшающейся кармой.
Я ведь серьёзно говорю. Ваш код — это очень-очень начальный уровень, плохо написанный, неэффективный. Вам надо учиться нормально писать, для начала.
Если же вы вместо этого просто будете бросаться на всех, кто этот код критикует, вы так и будете стряпать кривоватые наколенные поделки, которые будут способны заинтересовать разве что среднего ардуинщика.
Вот тот же float. Он у вас употреблён же не потому, что как-то серьёзно упрощает код, улучшает его читаемость, повышает точность вычислений и т.п.
Он у вас употреблён только потому, что вы даже не задумываетесь о последствиях его употребления.
Falstaff
26.02.2017 17:16+2Гхм. Я, пожалуй, рискну и побуду адвокатом дьявола. :) Мне кажется, что «неэффективный» — это далеко не всегда эквивалент «плохо написанный». Да, во встраиваемом ПО эффективность важна, но и там — не всегда и не везде. Питание не батарейное, ресурсов достаточно, задачи научить тонкостям embedded разработки статья, как я понимаю, не ставит.
Да, надо знать особенности своей системы и то, как писать эффективный код. Но я сторонник той точки зрения, что не стоит всегда писать эффективно ради эффективности. В первую очередь код должен быть ясным. Например, вверху gbg упомянул for — да, это может сделать код более читаемым. А вот использование целочисленной арифметики вместо float — это как раз ухудшает читаемость, это буквально стояние на голове и пляски вокруг ограничений платформы. Читаемость — это использовать float там, где его идиоматично использовать. В этом коде последствий скорее всего никаких нет с точки зрения решаемой задачи. У всего должна быть причина, в том числе и у неочевидных оптимизаций.olartamonov
26.02.2017 17:22+1Я в третий раз повторю: если у автора стояла задача «быстро сварганить на коленке из говна и палок», то он с ней прекрасно справился.
Проблема в том, что автор в своих текстах озвучивает совершенно другие задачи и совершенно другими словами.
В качестве демонстрации того, как надо делать, чтобы решить некую более общую задачу, этот код имеет глубоко отрицательную ценность — в нём практически всё сделано так, как делать не надо. Как только автор в этом коде захочет сделать хоть что-то отличное от «по кругу читаем имеющиеся сенсоры» — проще всего будет код выкинуть целиком и написать нормально.
Более того, человек с минимальным опытом написания хоть сколь-нибудь сложных систем так писать просто не будет.Falstaff
26.02.2017 17:34Я не читал весь код, признаться, поэтому не знаю, какую ценность имеет остальная часть кода. Поэтому я говорю об очень частных вещах, вот именно о заявлении «...float <...> не потому, что улучшает его читаемость...». Таки улучшает, и намного. Коленный рефлекс сразу использовать целочисленные фокусы вместо напрашивающегося float без оглядки на специфику проекта — это, мне кажется, такая профессиональная деформация эмбеддеров (не обижайтесь, я тоже эмбеддер, у меня она тоже есть). Можете пояснить, почему использование плавающей точки означает, что код не написан нормально?
olartamonov
26.02.2017 17:39+1Потому что этот код жрёт до черта места и процессора.
Батарейное питание, многозадачность, работа из прерываний — во всех случаях, кроме линейной простыни с гигантскими delay_ms, этот код будет работать плохо.
И так у автора написано, похоже, всё. Даже банальное желание снимать показания с датчиков с разной периодичностью приведёт либо к выкидыванию всего этого хлама, либо к эпическим костылям в нём.
И в итоге не очень понятно, зачем повторять уникальные возможности и стиль программирования Arduino на STM32, когда можно было, натурально, взять Arduino и получить ровно то же самое.leocat33
26.02.2017 17:50-1И так у автора написано, похоже, всё.
Не читал, но осуждаю
Да угомонитесь вы… Да, все, что сделано не лезет в ваши шаблоны.
Falstaff
26.02.2017 18:03+1До чёрта — это сколько? И сколько места и процессора вам в данном конкретном случае не хватает, чтобы всё это экономить ценой читаемости кода? Мне всегда казалось, что «до чёрта» — это весьма относительное понятие, сильно зависит от того, сколько у вас есть и сколько ещё вам надо.
В том, как вы говорите «линейная простыня», тоже чувствуется некая неприязнь. Ну да, в более реалистичном случае у вас будут не задержки холостыми циклами, а какой-нибудь vTaskDelay() или ожидание семафора, но в общем случае линейный код — это замечательная вещь, нет ничего плохого в том, чтобы к нему стремиться, если задача позволяет.
Вы почему-то стремитесь примерить этот код к намного более общим случаям — а если понадобится другая периодичность, а если перейдём на крохотную батарейку, а если понадобится ещё токарным станком из этого кода управлять, мало ли. Но суть в том, что здесь вряд ли понадобится. Да, смотреть в будущее нужно и важно, но есть и другая крайность — если в реальный проектах увлекаться «а если», то получается overengineering, плохо поддерживаемый код и сорванные сроки, и всё потому что вы решили сделать всё через DMA, прерывания и целочисленную арифметику, а потом это три месяца героически отлаживали, превращая код в нелинейные макароны и горы остроумно сделанного неопределённого поведения. Это часто необходимо, но если так получилось, что нет — мне кажется, это замечательный повод не идти на жертвы ради неясных целей.olartamonov
26.02.2017 18:09+1Вы почему-то стремитесь примерить этот код к намного более общим случаям
Я?
Это я автору в статью написал, что он будет делать универсальный программируемый логический контроллер?Falstaff
26.02.2017 18:16Ну, да. Единственное применение слово «универсальный» было в предыдущей статье, и то касалось железа. Плюс в следующем же параграфе была приписка: «… не буду рассматривать особенности и тонкости программирования МК. <...> Будут предложены готовые «прошивки» под конкретные задачи.» Вроде бы автор дал понять, что пишет под конкретную задачу и на универсальность прошивки не претендует.
olartamonov
26.02.2017 18:17+3Вы мне можете объяснить, чем этот цикл статей по своей сути отличается от «как я помигал светодиодом на Arduino»?
Если ничем — то он зачем вообще нужен? Про мигание светодиодом на ардуине написано уже более чем достаточно. Цель цикла какая?leocat33
26.02.2017 18:30-3Блин… Дошло до меня, как до жирафа, где там долгий
delay_ms( 5000 ); // Waiting for measure
Таак… Похоже датчики, особенно температурные вы только на картинках видели… Нельзя температурные датчики «дергать» чаще, чем раз в 3 сек. Он просто начинает разогреваться, вычисляя температуру. Да и процесс вычисления занимает 700-800 мс. Плюс инерция самого датчика. Вот и получается 5 сек. А загонять процессор в сон… При общем потреблении всех датчиков более 300мА, смысл? Останавливать датчики нельзя, ибо потом на разогрев 10 мин потребуется. Есть подозрение, что вначале нужно было таки разобраться, с чем мы работаем…olartamonov
26.02.2017 18:34+1Нарастает ощущение, что вы просто не понимаете слова, которые я пишу.
Вы хоть понимаете, что тривиальная задача «сделать опрос разных датчиков с разным периодом плюс опрос конкретного датчика по требованию» в вашей портянке решается с такими адовыми костылями, что лучше даже не браться?
Falstaff
26.02.2017 18:33Оно чуть более продвинутое, чем мигание светодиодом, но да, с программной точки зрения без особой претензии на что-то отличное от «… как я светодиодом помигал». Я так для себя понял, что цикл в основном о железе, на основе которого другие могут наколхозить своё, и со своей прошивкой.
Вообще, автор скажет точнее. Я-то комментировал на тему того, что садиться разрабатывать каждую прошивку так, как если бы у вас был каждый байт и такт на счету — это тоже не очень хорошая вещь. Не стоит ругать людей за всякий случай, когда они написали читаемый код вместо быстрого.olartamonov
26.02.2017 18:44+1Оно чуть более продвинутое, чем мигание светодиодом
Чем?
Я вот более чем уверен, что если я сейчас захочу, то на ардуино из готовых библиотек соберу прошивку ровно с такой же функциональностью за время раз в пять меньшее, чем автору на написание этой недлинной статьи потребовалось.
А если я в процессе про таймеры вспомню, то функциональность-то ещё и получше выйдет.
Я-то комментировал на тему того, что садиться разрабатывать каждую прошивку так, как если бы у вас был каждый байт и такт на счету — это тоже не очень хорошая вещь
Есть такая штука, как набор рефлексов хорошего разработчика. Железячник не будет задумываться, надо ли положить земляной полигон или поставить керамику по обе стороны от LDO — он это просто сделает, здесь не о чем раздумывать. Точно так же хороший программист под микроконтроллеры на тривиальных операциях даже не будет задумываться об использовании float — конечно нет, зачем он тут нужен? Ну и так далее.
Это шаги, не требующие вообще никаких измеримых затрат. В коде не становится на тыщу строчек больше, его читаемость меняется только для человека, который вчера начал Basic осваивать. Об этом не надо думать, сделать так — рефлекс. Не сделать так — потенциальный способ прострелить себе ногу на следующем же шагу. Зачем своими руками создавать себе пусть даже потенциальные проблемы, ради чего?
У плохого разработчика таких рефлексов нет. И именно поэтому он плохой. Потому что когда так сделать необходимо — он не сделает, он уже привык струячить код. Я сделяль, вот это вот всё.Falstaff
26.02.2017 19:26+1Чем?
Тем, конечно, что там не светодиоды и кода общения с периферией больше нескольких строк. Я не сомневаюсь, что вы сделаете на ардуино то же самое. Может быть быстрее, если вы уже знакомы с ардуино — не берусь судить. А какой функциональности вам не хватает здесь?
Есть такая штука, как набор рефлексов хорошего разработчика. <...>… хороший программист под микроконтроллеры на тривиальных операциях даже не будет задумываться об использовании float...
Почему? Мне действительно интересно. Если разработчик остановится и подумает, то он может вспомнить, что плавающая точка у него где-то в проекте уже используется по объективным причинам (и, значит, место во флэше он уже на это потратил) а эта тривиальная операция не находится на критическом пути выполнения, или что у него Cortex-M4 с аппаратной плавающей точкой, или что-нибудь ещё в этом роде, и что, с другой стороны, коллегам не придётся продираться сквозь целочисленные хаки. Разработчик, рефлекторно пишущий нечитаемый код просто по привычке — это плохой разработчик. Причём не имеет значения, пишет ли он бездумно float, или бездумно отказывается от него. Ключевое слово здесь — «бездумно».
Возможно, написать snprintf(buf, sizeof(buf), "%d.%d", x/10, abs(x%10)); не требует от вас много больших затрат, но вы не задумались о когнитивных затратах тех, кому этот код потом читать и поддерживать. Им придётся остановиться и задуматься, что же это вы такое остроумное сделали. Да, это займёт у них всего лишь несколько секунд, но таких мест у вас будет много. Зачем создавать им проблемы в виде нечитаемого кода, если проект от этого не выигрывает?olartamonov
26.02.2017 19:39Тем, конечно, что там не светодиоды и кода общения с периферией больше нескольких строк
Так кода для этой периферии готового — как говна за баней. И он в общем достаточно тривиальный, более того, как уже отмечалось выше — автор его стащил из пачки разных проектов и свалил в кучу, особо не разбираясь, где что.
Может быть быстрее, если вы уже знакомы с ардуино — не берусь судить
Лет десять назад что-то там делал.
Разработчик, рефлекторно пишущий нечитаемый код просто по привычке
Послушайте, если для вас этот код нечитаемый, ну или вызывает хотя бы двухсекундную паузу при чтении, есть же PHP там всякие, Javascript вот ещё можно освоить. В C вам рановато немного, зачем вы себя мучаете?
Им придётся остановиться и задуматься, что же это вы такое остроумное сделали
Ох ты ж боженьки. На snprintf — задуматься. А когда на следующей странице им встретится какой-нибудь кольцевой буфер, наполненный структурами с массивами указателей, они упадут на бок и засучат ножками, как те козы, у которых при любой опасности припадок случается?Falstaff
26.02.2017 21:15Хм. Да вот, захотелось помучаться, видите ли… Писал себе на Бейсике, горя не знал, верите. Но душа ищет приключений; понимаю, что не по зубам, IQ низок, никак не могу научиться рефлекторно писать код, всё время думать начинаю… Вообще, давайте не не обсуждать мою скромную персону, а то совсем меня застыдите.
Так значит, ваши коллеги должны читать два лишних выражения в коде только потому, что они это могут и у них много свободного времени, а вам захотелось отказаться от плавающей точки? Никакой мотивации отказа, обусловленной платформой/задачей/контекстом/требуемыми и доступными ресурсами вы не предлагаете?
Вы извините, что я ещё раз это спрашиваю, просто я никак не могу понять вашу мотивацию. Рефлекторно делая такую вещь, вы: a) тратите своё время; b) тратите время коллег, которым этот код читать; c) усложняете код, потенциально внося ошибки в целочисленной арифметике. Вы получаете, условно говоря, N килобайт свободной флэш-памяти и экономите M тактов в том месте, где вы написали этот код. Сами по себе эти килобайты и такты ничего вам не дают. Когда вы рефлекторно пишете то, что пишете, вы уже знаете, на что потратите эти килобайты и такты? Как они отразятся на потребительских качествах продукта?olartamonov
26.02.2017 21:24+1Так значит, ваши коллеги должны читать два лишних выражения в коде
Человек, у которого это вызывает затруднения, не имеет шансов стать моим коллегой. Вот вообще никаких.
Вы понимаете, что вы мне компостируете мозг вещью, которая для любого профпригодного программиста микроконтроллеров вообще не стоит обсуждения, даже трёх секунд не стоит, а вы пишете по три абзаца текста на каждую итерацию?
Мы тут с коллегами — настоящими, не вашими воображаемыми — смешной тест для собеседования придумали. Берутся два куска кода, один другому передаёт данные. Между двумя системами, интерфейс неважен, пусть хоть UART. В обоих описана одна и та же структура в полтора десятка членов, она передаётся и принимается одним бинарным куском, тупо побайтово. Одна система — MIPS, gcc. Вторая — x86, Visual C++. Всё описание, функции — всё идентично до последнего пробела.
Объяснить, почему на выходе вместо данных мусор.
А вы мне всерьёз пытаетесь сообщить, что snprintf(buf, sizeof(buf), "%d.%d", x/10, abs(x%10)) — это ух какая сложная конструкция, многих в тупик поставит.
Что особенно ужасно, вы это делаете на примере кода, от вида которого кровь из глаз сочится.
Вы там драйверы датчиков на I2C видели? Вы что, всерьёз считаете, что психически здоровый человек добровольно согласится ЭТО поддерживать?
Когда вы рефлекторно пишете то, что пишете, вы уже знаете, на что потратите эти килобайты и такты?
Весь смысл написания эффективного кода — в том, что вы не знаете, будут ли у вас через полгода лишние килобайты и такты.
И поэтому не тратите их уже сейчас, чтобы через полгода проджект-менеджер не начал вам делать больно.Falstaff
26.02.2017 22:02Ну, стоящий код писать не получается, поэтому пишу абзацы, чем богаты… Вопрос не в том, могут ли коллеги понять то, что вы написали. Вопрос в том, что вы не объяснили, зачем им это читать. Никого не поставит в тупик ни мусор в стуктуре (в конце-концов, даже если люди не помнят, что MIPS бывает big endian, они быстро разберутся на месте), ни ваши два выражения, но структуру вам нужно принять по объективным соображениям (и то не факт — могли бы взять protobuffers), то ваш snprintf может оказаться результатом вашей борьбы с призраками.
Код из статьи я до сих пор не читал, и, если честно, не очень хочется. :) Я очень даже верю, что там сущий ад. Но я изначально ответил на ваш комментарий не потому, что не согласен, что там ад (ну ад и ад), а потому, что вы конкретно использование float считаете признаком плохого кода — и, более того, считаете что хороший эмбеддер должен обходить float рефлекторно, не думая.
Весь смысл написания эффективного кода — в том, что вы не знаете, будут ли у вас через полгода лишние килобайты и такты.
Я возьму на себя смелость сказать что, если вы через полгода запланировали сдачу проекта, то вы обычно уже имеете представление, какая у вас будет в общих чертах функциональность, и где у вас могут случиться затыки. Откуда вы знаете что, если вы погонитесь за скоростью и начнёте переписывать редко исполняющийся алгоритм в целочисленном виде, вы не сорвёте сроки по другим задачам? Откуда знаете, что упрётесь именно в N килобайт и M тактов, и именно эта оптимизация позволит вам уложиться в срок?
Если я скажу, давайте перепишем всё на ассемблере, так мы ещё больше сэкономим — вы ведь назовёте это абсурдом, нет? Слишком много потратим времени, игра не стоит свеч. Чем тогда другие немотивированные оптимизации отличаются от этой?olartamonov
26.02.2017 22:13+1в конце-концов, даже если люди не помнят, что MIPS бывает big endian, они быстро разберутся на месте
Половина правильного ответа, думайте дальше.
Я возьму на себя смелость сказать что, если вы через полгода запланировали сдачу проекта
И поклялся никогда и нигде написанный для него код больше не использовать.
то вы обычно уже имеете представление, какая у вас будет в общих чертах функциональность
Всегда рад познакомиться с человеком, который в начале работы над прошивкой может уверенно сказать, впишется она в 16K RAM / 64K ROM — или надо в устройство контроллер на ступеньку выше закладывать.
И надо ли во втором случае разницу в стоимости контроллеров, умноженную на размер партии, вычесть из его зарплаты.
Чем тогда другие немотивированные оптимизации отличаются от этой?
Я в какой раз повторяю, в пятый, да? Тем, что вы не потратите на них никакого измеримого дополнительного времени.Falstaff
26.02.2017 22:51Думать — да ну, полно, я же не смогу. :) Вопрос code reuse — это уже отдельный вопрос. Вы всегда точно и достоверно можете сказать, что именно этот код будет использоваться в других проектах, и стоит его оптимизировать? Настолько, что рефлекторно начинаете с оптимизаций? Никто не придёт к менеджеру и не скажет — вот бы включить в план переписывание алгоритма пооптимальнее, вдруг мы его будем использовать где-нибудь ещё.
Всегда рад познакомиться с человеком, который в начале работы над прошивкой может уверенно сказать, впишется она в 16K RAM / 64K ROM…
Всегда рад познакомиться с человеком, который уверен, что его рефлексы гарантируют то, что он уложится в эти рамки. :) Откуда уверенность, что в конечном счёте именно плавающая точка вызовет переполнение доступной памяти? (И кстати, за сколько месяцев до производства партии вы хотите закупать контроллеры?)
Тем, что вы не потратите на них никакого измеримого дополнительного времени.
Вы ведь понимаете, что, чтобы удержать проект от использования плавающей точки, в большинстве случаев вам придётся менять не одну строку кода? Если ваш рефлекс позволит вам написать ваш snprintf в проекте, где нигде больше float не к месту — да, это быстро. Если у вас есть обработка данных, где float идиоматичен — тогда ваш проект с float и проект без float будут сильно отличаться, и целочисленная реализация займёт вполне измеримое время.olartamonov
26.02.2017 22:53+1и стоит его оптимизировать
Надо ли мне в шестой раз повторить, что эта «оптимизация» не стоит ничего, или у вас какой-то специфический случай выборочной слепоты?
в большинстве случаев вам придётся менять не одну строку кода
Изначально аккуратно написанный код не приходится менять. Менять приходится продукт «я сделяль».Falstaff
26.02.2017 23:07Надо ли мне в шестой раз повторить, что эта «оптимизация» не стоит ничего, или у вас какой-то специфический случай выборочной слепоты?
Которая, реализация алгоритмов в целочисленном виде, чтобы проект не использовал float? Вы всё повторяете, но я, хоть убейте, не вижу вашу аргументацию. Если вы разработали (или откуда-то взяли) алгоритм, использующий float, то вы либо реализуете его как есть (и при этом вам в большинстве случаев становится всё равно, будет ли ваш snprintf выводить float, потому что проект уже потянул soft float), либо вы переписываете алгоритм в целочисленный вид — и вот это уже будет тратой времени, а любая трата времени должна быть обоснована. И даже изначальное проектирование этого алгоритма в целочисленном виде займёт больше времени в том случае, если идеологически он должен работать с плавающей точкой. Вы не уйдёте это этого добавленного времени, вы его всё равно заплатите за выигрыш во флэше и времени выполнения.olartamonov
26.02.2017 23:24+1А, ну да, я забыл, что у современных программистов все алгоритмы копипастой со стековерфлоу берутся, а не руками пишутся.
Что характерно, выше у вас нагляднейший пример, к которому слово «проектирование» даже применять смешно, хотя вы уже полдня и пытаетесь это сделать.Falstaff
26.02.2017 23:35Отчего же сразу stackoverflow. Например, вы берёте алгоритм из научного исследования, где он приведён в псевдокоде. Или от разработан вашим отделом алгоритмистов, и они его вам дали в Matlab. Он ведь не появляется сразу оптимизированным для embedded, нет?
О нагляднейшем примере — не соображу, о чём именно вы говорите. Который?olartamonov
26.02.2017 23:36+1О нагляднейшем примере — не соображу, о чём именно вы говорите. Который?
На который вы в этом треде отвечать начали.
Спокойной ночи, мне надоело что-то это «на колу мочало». Рад за вас, если у вас хоть десять процентов реального кода под STM32 составляют алгоритмы, разработанные специальным отделом в матлабе.Falstaff
26.02.2017 23:41То есть мгновенный и беззатратный процесс превращения из скрипта Matlab или теоретического описания в целочисленную реализацию не опишете? Хм… Хорошо, давайте закруглимся; не обижайтесь, если я где слишком настойчиво спорил. Спокойной ночи.
olartamonov
26.02.2017 23:44+1Отсутствие такого алгоритма, вне всякого сомнения, даёт вам полное и абсолютное моральное право положить болт на любую оптимизацию кода вообще.
М-да.Falstaff
26.02.2017 23:58Нет, конечно. Не знаю, откуда взялась «любая». Просто я сторонник того, чтобы каждую оптимизацию в каждом случае взвешивать — много ли даст и стоит ли жертв. Мне нравится оптимизировать код, но при этом я хочу точно знать, что мне это даст и что я заплачу.
P.S.: Да, ваш пример со структурой. Чтобы сказать вам вторую половину, их надо видеть, но я догадываюсь. Они у вас не упакованные, нет?olartamonov
27.02.2017 00:00+1(в седьмой раз) В обсуждаемом случае у вас взвешивание займёт больше времени, чем сама оптимизация.
Они у вас не упакованные, нет?
Тепло. Не упакованные.Falstaff
27.02.2017 00:04Значит, выравнивание полей разное. И в обсуждаемом случае оптимизация ничего полезного не даст, а вред от неё будет нанесён. В другом проекте могло бы быть иначе.
olartamonov
27.02.2017 00:13+1Значит, выравнивание полей разное
Вау! Вау, вау!
а вред от неё будет нанесён.
(зевнув) Непоправимый.Falstaff
27.02.2017 00:16Увы, поправимый лишь рефакторингом. :) Но не буду больше терзать; спокойной ночи.
tronix286
01.03.2017 01:25-1Да ладно, это ж стм — где не уверен что буфера хватит для уарта и дма — множь на три, не уверен что затактировал правильно — множь задержки на три. Подключай все либы, тяни флоаты и даблы. За что мне стм нравиться — что потом этот ад как-то еще и работает. Но если не дай бг придется что-то поправить, все может рухнуть и навсегда.
tronix286
01.03.2017 10:57-1А великий знаток мипсов и биг эндиана даже не подумал, что цикл развернут для скорости. Все же мы знаем что такое команда перехода и что делает стмф1 если префетч не сработал? Шучу конечно, но в каждой шутке.
olartamonov
01.03.2017 11:28+1что цикл развернут для скорости
while( ADC_GetFlagStatus( ADC1, ADC_FLAG_EOC ) == RESET );
Да, скорость выполнения цикла тут будет очень важна.
lingvo
27.02.2017 09:39+1Чисто для справки — матлаб позволяет генерить автоматически код, оптимизированный под эмбедд. Причем флоат там можно как включить, так и выключить — это отразится только на сгенерированном коде, а не на исходном алгоритме.
Falstaff
27.02.2017 10:54Я помню, что для фильтров это можно было — а для произвольного кода уже тоже? Он учитывает при этом ошибки целочисленного округления, переполнения и прочие подобные вещи? Я просто не следил за этой частью.
leocat33
26.02.2017 18:16-5Это я автору в статью написал, что он будет делать универсальный программируемый логический контроллер?
Свободнопрограммируемый. Не путайте хер со звездой.
leocat33
26.02.2017 18:15-2Пытался объяснить… «До черта» это 200 байт на вычисления ряда (работа с float) вместо двух десятков команд целочисленной арифметики. Плюс 8 байт памяти для хранения двух значений float. Хотя памяти 2 * int32_t съест ровно столько же. Сейчас программа «ест» 15 кб из 64 кб «камня». 200 байт — ниочем. Критикан так же предлагает использовать stdio и string. А это сразу 4 кб. В чем выигрыш? Не понятно… Да, я предпочитаю линейную структуру программы. Но это действительно улучшает читабельность и понимание алгоритма.
Androniy
03.03.2017 14:30Вы все правильно говорите, однако «рефлексы» связанные с ограничениями платформ десятилетней давности приводят порой к неочевидным результатам. Завтра вам скажут, что сравнивать величину надо с точностью до сотых/тысячных и вы перепишете все случаи использования переменной x как-то так:
snprintf(buf, sizeof(buf), "%d.%d", x/1000, abs(x%1000));
Получите пачку проблем с единицами измерений везде, где встречается эта переменная.
А потом внезапно окажется, что исходное значение может быть немного больше, чем 2 000 000, и вашего int будет нехватать.
У float есть огромные преимущества, ради которых стОит его использовать.olartamonov
03.03.2017 20:28-1Не надо использовать float. И int не надо.
Только double и int64. А то мало ли что вам завтра скажут, особенно про датчик температуры с погрешностью в полградуса.leocat33
03.03.2017 22:58-1Присоединяюсь к мнению. Но и этого тоже не надо! Только bool! Только хардкоре!
tormozedison
26.02.2017 10:59Смотря какой «кусочек». Если у него запас с обеих сторон, достаточный для установки ограничителей, и они есть, «колхоза» не вижу.
leocat33
26.02.2017 11:10В общем то так и делаю. Запас ровно под корпус + фиксаторы. DIN-рейку не видно вообще. Монтаж намного проще, быстрее и удобнее, чем в упомянутом D-Link. Там еще как следует «прицелиться» нужно с разметкой под шурупы и потом минут пять «попадать» шляпками шурупов в отверстия D-Link-а. Да и из тех, кто "кохлоз" (цитата) использует пока недовольных нет.
Фиксаторы нравятся от феникса.
lingvo
26.02.2017 11:09Неплохо было бы фото модуля на стенке привести. За одно и подумать можно, как CAN к нему подвести.
leocat33
27.02.2017 18:26-1В профиль, или анфас? Отпечатки стоп модуля нужны?
lingvo
27.02.2017 19:15+3Вы писали:
А данный модуль вполне себе нормально и на стене смотрится. Монтаж либо на двусторонний скотч, либо на кусочек DIN-рейки в размер модуля.
Так приведите доказательство своим словам, вместо того, чтобы язвить. Или опять назовете критиканом, как всех остальных?leocat33
27.02.2017 19:22-1Кому? Вам? Вы в состоянии информацию анализировать? Судя по вашим прошлым постам не очень…
Да и нафиг электрику самодельный PLC? Он вааще с DIN-рейки постоянно отваливается! На голову.
proton17
26.02.2017 14:15+2DHT-22 то еще гуано, да и в МК нужно выделять отдельные ресурсы на работу с его интерфейсом. Лучше вместо BMP085 и DHT-22 взять один BME280 (200р на Али), тут вам и температура и давление и влажность + I2C интерфейс. И точность у него заметно выше. Вот хорошая статейка по сравнению этих, и не только, датчиков. Ну а про CO уже выше сказали, понятно, что MH-Z19 не бюджет, но MQ это скорее индикатор, а не измеритель ИМХО.
leocat33
26.02.2017 15:26По точности оно мало отличается… А по размеру — да, экономия. Да и по цене раза в 2 дешевле выходит. Закажу пару штук, для попробовать.
Про MQ могу сказать, что каждый — индивидуален, т.е. требует калибровки. Но ведут себя стабильно.
Гистерезис есть у всех… И у влажности, и у давления и MQ.
Leerooooy
26.02.2017 19:52+3Сначала я думал, что товарищ olartamonov просто
решил доебатьсяпридирается, а нет… Ради любопытства глянул код и наверное это одна из самых страшных писанин, что приходилось видеть.
Опрос датчиков, периферия, интерфейсы и тут невольно появляется вопрос: «А почему же не задействовать RTOS?» Читаемость улучшится, а размер кода(прости господи что назвал это «кодом»)уменьшился бы на порядок, а главное — пропали бы костыли, всякие задержки и прочий мусор. Но видимо уровень автора данной статьи не позволяет применять нормальный инструментарий.
Итог: а зачем вообще написаны эти статьи?leocat33
26.02.2017 20:16-2Не для вас! Гопота матом изъясняющаяся, вам ли критиканом быть?
Leerooooy
26.02.2017 20:24+2Нет конечно! Быть критиком для статей подобного уровня — такое же позорище как быть ее автором. Критики вроде нет, лишь констатация факта и 2 вопроса:
1) почему не RTOS?
2) зачем эти чудо-статьи?leocat33
26.02.2017 20:291. Мат на гитхабе уже разрешен? Это не хамство?
2. RTOS юзайте сами. В данном устройстве в RTOS нет потребности. НИКАКОЙ. Если для многозадачности в МК и использую ОС реального времени, то это NuttX.
3. Данные статьи не для вас. А материться идите в сад!Leerooooy
26.02.2017 21:571. На гитхабе? А там можно материться? В коммитах что ли? :D
2. «никакой» — действительно, опрашивать датчики через задержки это труЪ. Какую RTOS использовать вообще пофигу, но даже откинув данный момент — религия таймеры тоже не позволяет юзать?
3. Это говорит бомбящий клоун, который за одну статью слил все что мог и посылающий нахер других людей? Напоминает обвинения в оккупации со стороны США)
Zuy
26.02.2017 20:04+2Прочитав как возбудились товарищи выше, решил глянуть код.Это — шедевр! Автор, никого выше не слушай, ничего не меняй, сохрани свой стиль!
include ".c" серьёзно?!
А почему тогда SPL инклудится через .h?
А если серьёзно, то понятно что автор не занимается разработкой профессионально, видимо для него это всего лишь хобби. Решил в первый раз вместо Arduino сделать по-взрослому, но не всё получается.
leocat33
26.02.2017 20:14Попробуйте не добавить к проекту *.c SPL. И что получится?
Одними хидерами отделаетесь?
Придется все же или библиотеку подключать или в проект добавлять *.с, или include именно *.с делать.
Ну вы даете, программер! Не позорьтесь, подобными комментариями!leocat33
26.02.2017 20:47Минусаторам, фрагмент stm32f10x_adc.c:
/**
******************************************************************************
* file stm32f10x_adc.c
* author MCD Application Team
* version V3.5.0
* date 11-March-2011
* brief This file provides all the ADC firmware functions.
******************************************************************************
* attention
*
* THE PRESENT FIRMWARE WHICH IS FOR GUIDANCE ONLY AIMS AT PROVIDING CUSTOMERS
* WITH CODING INFORMATION REGARDING THEIR PRODUCTS IN ORDER FOR THEM TO SAVE
* TIME. AS A RESULT, STMICROELECTRONICS SHALL NOT BE HELD LIABLE FOR ANY
* DIRECT, INDIRECT OR CONSEQUENTIAL DAMAGES WITH RESPECT TO ANY CLAIMS ARISING
* FROM THE CONTENT OF SUCH FIRMWARE AND/OR THE USE MADE BY CUSTOMERS OF THE
* CODING INFORMATION CONTAINED HEREIN IN CONNECTION WITH THEIR PRODUCTS.
*
* © COPYRIGHT 2011 STMicroelectronics
******************************************************************************
*/
/* Includes ------------------------------------------------------------------*/
#include «stm32f10x_adc.h»
#include «stm32f10x_rcc.h»
эти инклуды именно для случая
#include <stm32f10x_adc.c>
Когда я не использую откомпилированную и собранную библиотеку SPL, и не включаю файл stm32f10x_adc.c в проект «вручную». случай, когда #include *.c не всегда рационален, ибо не все компиляторы компилируют инклуды отдельно, а не помнят, что obj уже есть. Но большинство, флагами настраивается не делать повторную компиляцию внешних *.c, если они не менялись.
leocat33
26.02.2017 21:04-1
*.c файлы — почти полный аналог #include *.c, с автоматическим применением флагов раздельной компиляции.
Почти, на самом деле это нечто среднее, между собранной библиотекой и #include *.c в main
#include *.h нужны как объявления без тела функций.
Ой — срам… критиканы…
Zuy
26.02.2017 22:45+2Хммм, вы наверно не поняли вопроса.
У вас вmain.cSPL через инклуд*.hфайлов, а свой собственный код вы подключаете через инклуд*.c.
Я даже не задаю вопрос зачем вообще инклудить*.cесли у вас есть к ним*.hв которых достаточно прописать интерфейсы и инклудить их. Видимо вы считаете это нормальным.
Но у вас код SPL поставляется в исходниках, почему бы тогда и его не заинклудить прямо вmain.cкак*.cи не добавлять в проект? Откуда такой радикально разный подход к своему коду и чужому?
Не считаете ли вы, что один из подходов верный и стоит только его и придерживаться?leocat33
26.02.2017 23:19-4Все три подхода могут быть использованы. Для понимания, как это работает читайте стандарт «С».
SPL я трогать не стал, по причине «Standart...» Ну раз так хотят, пусть будет стандарт.
Поначалу я использовал такую же концепцию. Потом сделал #include "*.c" в main, а компилятору приказ — раздельно их компилировать, или компилировать только те *.c, которые изменились. Таким образом меньше телодвижений по добавлению/убиранию блоков (функций) программы. Это сильно заметно при сборке проекта под GCC Linux. *.h остались как «хвосты». Вдруг кто-то захочет, чтобы было как в SPL, и в текущем проекте просто не используются. Вернее есть один файл gbl.h — секция глобальных переменных. Почему у него именно такая структура опишу намного позже, когда буду рассматривать архитектуру и программирование системы.
Ну и на будущее: не позорьтесь такими комментариями… Не стоит выпячивать как достоинство свое невежество.olartamonov
26.02.2017 23:29+1Боже, какая же у вас невероятная каша в голове.
Что характерно, настоящий практический смысл в #include «xxxxxxx.c» есть, только вы его не знаете. Он из той самой области оптимизации исполняемого кода, в которой вы как свинья в апельсинах. И к стандартам языка C отношения не имеет.
И вот уж что, а скорость компиляции на мегапроекте типа вашего вообще никого не волнует, сколько там, секунд пятнадцать на средней дохлости десктопе?
P.S. Какой конкретно из стандартов C читать надо, кстати? А то я несколько знаю…leocat33
26.02.2017 23:31-2О боже! Шо, опять?!
olartamonov
26.02.2017 23:35+2Вы не перестаёте меня поражать сочетанием вашей самоуверенности с глубиной ваших знаний.
Пишите ещё, я вас умоляю.
Прекрасное развлечение в процессе отладки DIY PLC для IoT, прошивка которого уже перевалила за 100 кб даже с -Os.leocat33
26.02.2017 23:37-2Н-да… Видать и в самом деле сильно на хвост наступил…
В контроллере всего 64к, однако.olartamonov
26.02.2017 23:45+2Боже упаси, ваш контроллер мне в страшном сне не придёт в голову использовать.
leocat33
26.02.2017 23:48-2Так разъясните, как получившуюся у вас 100к прошивку мне удалось залить в 64к микроконтроллер?! А то действительно у кого то каша в голове…
Да и боже упаси вам такой контроллер в руки давать!olartamonov
26.02.2017 23:57+2Вам удалось куда-то залить нашу прошивку?
Несколько сомневаюсь в этом, не помню, чтобы я вам к нашему рабочему репозитарию доступ давал.leocat33
27.02.2017 00:00-3Да! Прошивка отразилась от Венеры, и угодила без вашего ведома в какой то там контроллер — репозитарий!
( может хватит «дурака включать»? )olartamonov
27.02.2017 00:12+1Друг мой, у меня десктоп вот так примерно сейчас выглядит, это разве на какие-то ваши поделия похоже?
Мы тут — и под «мы» я не имею в виду вас — по ходу дела занимаемся прошивочкой под контроллер с радио, вполне вменяемым сетевым стеком, здоровенным набором драйверов внешних устройств, динамически подключаемых и пользовательских настраиваемых…
Вот сегодня поймал одну ошибку в алгоритме повторного обмена сессионными ключами после потери связи с базовой станцией, добавил поддержку модуля, работающего с BME280, на стороне MQTT-транслятора базовой станции, сделал настройку параметров драйверов локально через шелл, а не только через радио с базовки, ну и ещё вежливо интересовался у сотрудника, когда он допилит нормальную конфигурацию радиодиапазонов LoRaWAN, обещанную «на этой неделе».
А по ходу этого вы меня своим «я сделяль» немного развлекали.leocat33
27.02.2017 00:18-1Походу вас развлечение в понедельник ждет. На работе.
r00tGER
27.02.2017 09:24+4Прочитал обе статьи, заголовки, теги, комменты, заглянул в код…
Я с вами солидарен, вы очень многим людям и компаниям наступили на хвост. Целые отрасли поставили под угрозу.
Обязательно творите дальше и не слушайте бредни и критику завистников.
Но, лучше, никому не показывайте — видите, сколько агрессии.leocat33
27.02.2017 13:02-3А ну да, «жидкоядерное» г. это намного круче! Вот оно, где ноу-хау порылось!!!
r00tGER
27.02.2017 13:39+4Что, аж Intel подобные ядра выпускает…
Аж не верится, что взрослого человека может так сильно батхертить. Ощущение, что вам уже мерещились миллионы на горизонте, а их отобрали.leocat33
27.02.2017 14:07-2Что, аж Intel подобные ядра выпускает…
Ссылку, плиз! Наверное у вас патент купили?
Аж не верится, что взрослого человека может так сильно батхертить. Ощущение, что вам уже мерещились миллионы на горизонте, а их отобрали.
У кого что болит… Ваш комментарий по дедушке Фрейду…
leocat33
28.02.2017 07:20-1Ну так, что со ссылками то?
r00tGER
28.02.2017 08:39+1С ссылками все в порядке. Вот, например — https://habrahabr.ru/company/intel/blog/282570/ (у них прямо тут, на ГТ, блог, можете сразу им писать).
Неужели, вы реально сидели и ждали, пока я скину ссылку на то, что элементарно гуглится? Или, это всё дешевая игра на публику?
Надеюсь, вы понимаете, что я перед вами ничем не обязан. И, не имею ни малейшего интереса продолжать этот нелепый разговор.
leocat33
28.02.2017 08:42-2Да нет, просто любопытно. Гугль у меня не забанен. в поиске по жидкому процессору только одно соответствие:
IBM планирует разработку жидких процессоров — OSzone.net
www.oszone.net/16652/IBM_liquid_processors
20 нояб. 2011 г. — Новая идея касается сердца компьютера – центрального процессора. IBM предлагает создать модели с жидкими проводниками.
Остальное — жидкий стул.
leocat33
28.02.2017 08:52-3По предлагаемой ссылке на хабре — ну есть такие корпуса, где «классический» процессор + ПЛИС. Так их не только интел (после покупки Альтера, про что в ссылке и написано) делает. Таких полно. В чем ноу-хау то? От тех же Альтера есть более интересное решение, когда в ПЛИС я могу залить «прошивку» например ARM процессора и параллельно испльзовать возможности ПЛИС.
Ну а вам — полезный совет, уж коль вы прониклись базовыми знаниями о физической реализации бинарных операций, следующим этапом почитать про ПЛМ (Программируемые логические матрицы). Ну а потом и к ПЛИС можно будет «подобраться».
И… не стоит обсирать то, в чем вы не в зуб ногой!
sepulkary
27.02.2017 09:55Ну что вы всё ругаетесь? Автор делает классический MVP; потом, может быть, найдет инвестора, и весь проект приобретет более стройные формы…
leocat33, если делаете печатные платы под корпуса, сажаемые на DIN-рейку, лучше используйте «вывернутые» разъемы типа MSTBO 2,5/ 3-G1R и MSTBO 2,5/ 3-G1L, можно будет избавиться от межплатного разъема и получить бОльшую жесткость конструкции.leocat33
27.02.2017 12:06-3Да. И корпус другой нужно, тоже от феникс. А то взял «от балды» первый попавшийся… А лучше вообще собственного дизайну.
Так, насчет разъёмов: было перепробовано, в том числе по результатам промышленной эксплуатации, ну минимум десятка два различных вариантов, и именно от феникса. Ну и взял и просто так выбрал именно такие, чтобы жесткость конструкции уменьшить ( Вы о чем? Наверное выполняли прочностные расчёты? И так, для справок, толщина FR4=1.6 mm, попробуйте, сломайте плату такого размера:))) )
А потом, с целью «бюджетизации» были подобраны китайские аналоги, в частности DEGSON.
leocat33
27.02.2017 12:39-4Зашел на ваш сайт, посмотрел код… Шедевр! А тут мой критикуют:)))
Посмотрел схему: «Мощный бестрансформаторный блок питания»… Н-да… Откуда «содрали»?
Если и делаете емкостной делитель, то ставне пару емкостей, как по фазе, так и по земле.
Ну и потребляемая мощность вашего источника, считали? Получается 15 Вт реактивной составляющей. 10 источников — 150 Вт. Будем греть провода в квартире? И отчего только однополупериодный выпрямитель? Для «увеличения прочности»? Вообще, не схема, а бред…
Делал я подобные вещи, с целью «подешевле», там где не нужна гальваническая развязка… Пробовал на viper без трансформатора, 200 мА, 5V. По итогу стоимость штучного изделия получилась выше серийного 10 Вт-ного от MW. Забросил, дешевле купить гальванически развязанный MW…leocat33
27.02.2017 13:51-2Ах, да, минусуют, забыл видать упомянуть про ЭМП. Первый же выброс свыше 1300-1500V «склеит ласты» вашему источнику…
leocat33
27.02.2017 19:59-2Ну что-ж вы со своего сайта все поудаляли то? Я уже со знакомыми ссылками поделился. Пишут: нет ничего! Посмотрел и правда, всё пропало… А я вам посещаемость стал «накручивать»… Как то не вежливо это.
leocat33
27.02.2017 13:45-1Стёб? Или серьезно?
SNPopov
27.02.2017 14:12+1Не понял. Это вопрос на мой вопрос? Просто хочу понять что такое DIY PLC?
leocat33
27.02.2017 14:20-2Почему задал такой вопрос? Так тутошняя «публика» не читая статей, не вникая в суть, даже поверхностно, критиканит «в полный рост»… Вы задали неоднозначно понимаемый вопрос. Поэтому так и спросил…
В предыдущей статье писал, что смысл у этой аббревиатуры оказался двоякий:
- Power Line Communication — коммуникация, построенная на линиях электропередачи
- Programmable Logic Controller — программируемый логический контроллер
Цель и то, и другое.
Контроллер разрабатывался именно с целью возможного повторения практически всеми желающими.
2-х слойные платы, изготовление из того, что массово есть на рынке.SNPopov
27.02.2017 15:14+2Т.е., Вы разрабатываете PLC с коммуникациями по линиям электропередач? Надеюсь, Вы знаете, PLC (контроллеры) это строго определенная архитектура и стандартный (для PLC) набор языков программирования. Судя по всему Вы пытаетесь сделать не PLC, а PAC (Programmable Automation Controller) Для PAC набор возможных аппаратных и программных платформ не стандартизован. Многие фирмы выпускают PAC и на платформе PC и на базе микроконтроллеров. Пожалуй, существует только одно требование к ним — работа под операционной системой реального времени.
leocat33
27.02.2017 20:16-1Еще: видел PAC с Windows Embedded Compact 7 «на борту». Честно говоря не готов как то комментировать. Но глюковатость — имеет место быть.
SNPopov
28.02.2017 18:03+1Это у Вас просто эмоциональная реакция на слово — Windows. Windows Embedded COMPACT 7 — это операционная система реального времени, предназначенная в том числе и для промышленных контроллеров. Не имеет никакого отношения к Windows 7. Кстати, есть еще и Windows Embedded standard 7. Это компонентная ОС на базе Widows 7. Вы можете собрать свою ОС, содержащую только необходимые в данном проекте компоненты.
leocat33
03.03.2017 22:51-1Никаких эмоциональных реакций. Просто при плотной работе Windows Embedded COMPACT 7 с СОМ-портами можно наблюдать знаменитый «экран смерти»… Порты — USB-COM, через HUB несколько штук. Перепробованы разные чипы преобразователей интерфейса. Причем это происходит на дню по нескольку раз. На письма об этой проблеме служба поддержки M$ просто не отвечает. И это система реального времени?!
ЗЫ на ХР таких проблем не было.SNPopov
04.03.2017 09:28Ну это известная ситуация. Вы используете сторонние драйверы (MS их не поставляет) для специфичного преобразователя COM-USB и терзаете MS — почему не работает? Насколько я знаю, только FTDI поставляет драйверы преобразователя COM-USB для Windows compact 7. Вы к ним обращались?
leocat33
04.03.2017 13:09-1Да. Именно FTDI наиболее устойчиво работают. Обращался. Написали тоже самое: M$ игнорирует тиккеты. Повторю: назависимо от производителя чипов. Заниматься отладкой ядра для Windows Embedded я не умею, но при аналогичной ситуации в стандартной Windows 7, а там вылетает еще чаще, и точки вылета ( произвольные места ядра ) как раз на M$ код приходятся. Что-то связанное асинхронным вв/выв по устройствам. В конце-концов поставил свой контроллер с линуксом. Проблемы закончились. Но, люди, кто эксплуатирует пром решения навряд ли далее будут заказывать оборудование с Win «на борту».
SNPopov
04.03.2017 18:42Преобразователи COM-USB вещь в себе, в этом я с Вами полностью согласен. При нехватке физических СОМ-портов на хосте использую многопортовые серверы СОМ-Ethernet (www.moxa.com).
leocat33
27.02.2017 15:56-1Поправка: разработаны, архитектура, модули «расширения», Linux based контроллер.
Модули PowerLine в стадии адаптации решений / доводки / испытания.
Модули CAN интерфейса есть, и довольно много… Протестировано. Работает как пром.оборудование. Некоторые образцы эксплуатируются в сложных пром. условиях (высокий уровень ЭМП, агрессивная, но не взрывоопасная среда, ...). Некоторые образцы (из первых) эксплуатируются уже более 7-ми лет. Я бы их поменял, но это вопрос сложный. Там, где они эксплуатируются подход: работает — не трожь!
Вопрос про управляющий контроллер: сложно сказать, PAC или PLC. Дискутировали на эту тему в СО РАН. К определенному решению пока не пришли. Используется нетривиальная трактовка стандарта IEC 61131. Не касаемо языков программирования, я про архитектуру. Как языки программирования пока используются ISO/IEC 14882:1998 ( ”C” ), ISO/IEC 14882:2003 ( ”C++” ). Вот тут и возникают разнопонимания, PAC или PLC. С и С++ — тоже стандарты IEC… Хотя сама архитектура позволяет вести разработку на языках IEC 61131. В том числе программа (сценарий) может выполняться в режиме интерпретации. На текущий момент самое простое решение этого вопроса — использовать проект Beremiz. Но там на выходе будет промежуточный код C / C++.
Про реальное время: насколько жесткое? Если задачи жесткого реального времени, то решаемо установкой «примочек» к PLC, различные «инкарнации» Linux RT. Если жестких требований нет ( а в текущей практике не возникло ни разу ), то используя стандартное Linux ядро можно работать с минимальной частотой опроса 1 кГц. С учетом задержек на опрос внешних CAN модулей варируется от 10 до 500 гЦ. Зависит от количества модулей расширения, расстояния CAN, уровня помех,…
Описать все это «хозяйство» в одной статье невозможно в принципе. Но… во всяком случае — пытаюсь. Пока что вызываю только агрессию со стороны электриков и гоп-программистов… :(
Сайт только начал «рисовать». Текущая версия — по сути черновик. Но, что то там уже есть. Да и вообще, я не веб-разработчик. Как нарисовал, так нарисовал (не стреляйте в музыканта, он играет как умеет).
Все «железяки» разрабатывались под возможность повторения в плоть до ЛУТ технологий. Платы моей разработки — 2-х слойные. Но металлизацию отверстий делать все равно придется. Как вариант — заказать готовые платы, например у китайцев. В линукс-контроллере есть SOM внешних разработчиков. Увы, эту «деталь» дома не сделаешь… FBGA, 8 слоев. Все вышеизложенное касаемо пром. решений. Но… Данные идеи/наработки вполне себе позволяют создавать системы домашней автоматизации и IoT. В том числе «сделай сам».
Вот, очень кратко, примерно так.
leocat33
27.02.2017 21:33-1Если кому интересен Linux как система жесткого реального времени, то Ссылка
Время реакции на процессорах с тактовой 500 мГц 26-28 мкС. Это круче, чем RTOS.lingvo
28.02.2017 11:43+1Я так понимаю, что вы приводите время реакции для прерываний Xenomai(последний тест), которое хоть и является интересной, но не самой важной характеристикой в RTOS.
Так вот вшивая VxWorks 6.8 на 300Мгц процессоре выдает в данном случае аж 3,54мкс.
Не говоря уже о двух других тестах с вызовом задач из User и Kernel Space, где Xenomai выдает 105 и 62мкс, а VxWorks из тестов выше 25 и 8 мкс соответственно.
Вы действительно понимаете то, о чем пишите?leocat33
28.02.2017 11:53-1Да. Прекрасно понимаю. Мало того прекрасно знаю, что такое операционные системы жёсткого реального времени, и какие требования к ним предъявляются. То, что вы сравниваете это сравнение теплого с мягким (не буду выражаться грубо). И начинал я работать с подобными системами аж с RSX-11. Ну и как отвлечение, я не знаю ни одного компьютера, кроме DEC-овских, у которого системный таймер бы щелкал с частотой 1 мГц…
lingvo
28.02.2017 12:09+2Начали сравнение вы. Так почему вы пишете, что «Это круче, чем RTOS»? Чем круче? Будьте добры это разъяснить, как и сравнить теплое с мягким — benchmarking RTOS систем никто не отменял. А то получается, что стремительным домкратом орудуете Вы, а не я.
olartamonov
28.02.2017 10:20+4Слушайте, я, кажется, впервые вижу дискуссию, в которой у автора поста были бы заминусованы вообще все комментарии.
Но вообще затравили хлопца, с такой кармой он нам новых откровений не напишет.leocat33
28.02.2017 10:43-4Вашими стараниями! Чего уж прибедняться… А вообще то, адрес (ссылку) куда вам идти я давал.
leocat33
28.02.2017 11:13-2Я тоже впервые вижу, где у автора комментариев удаляют целые ветки! не будем показывать пальцем: olartamonov
Никакой желчи, предельно культурное общение!
А главное он — насяльника! жульмере-хешельбекельме-понаехалы…
lingvo
28.02.2017 11:51+4Это не удивительно.
Всех, кто его критикует и что-то предлагает, он называет гоп-программистами и критиканами, а статьи его так себе — то ли про Программируемые Логические Контроллеры, то ли про Power Line Communication, то ли вообще про умный дом.
Я бы лучше вообще не писал, чем писать такие статьи, что, собственно, geektimes-сообщество за него и решило.leocat33
28.02.2017 12:07-2Кучка из mail_Group под предводительством olartamonov и им подражающие это все сообщество?! Говорите уж — наиболее активная в плане обосрать его часть… Конструктивной критики не увидел. ВООБЩЕ
Воспринимается как низкий уровень профессианализма, компенсированный хамством.
Можете привести пример у кого бы, кроме olartamonov, модераторы удаляли бы целые ветки комментариев?olartamonov
28.02.2017 12:56+4Кучка из mail_Group под предводительством olartamonov
модераторы удаляли бы целые ветки комментариев
Вы совершенно зря пренебрегаете рекомендациями вашего лечащего врача.leocat33
28.02.2017 13:59-2О боже… Когда у вас диарея закончится то? Лечить болезнь нужно, однако. Хроническая форма уже…
olartamonov
28.02.2017 14:23+3У меня, собственно, всего два вопроса-то было:
1) какое отношение я имею к Mail.ru Group?
2) какую ветку удалили модераторы?
А то меня оба тезиса в тупик поставили, если честно.
P.S. Нет, серьёзно, феномен: мне приходит в почту уведомление, я его открываю, нажимаю на ссылку — а по ней комментарий уже заминусован.
lingvo
Неразумное решение — использовать протокол а-ля Modbus в сети CAN. Зачем тогда тот CAN вам нужен? Сделали бы RS485, и получили бы то-же самое за меньшие деньги.
Вся изюминка CANа в мульти-мастерности и возможности разрешения коллизий на физическо-транспортном уровне. Благодаря этому можно избавиться от периодических запросов и получить гораздо более быструю реакцию при минимальной загрузке шины.