Arduino.ru

STM32

Кто ж вам даст совет, если вы и сами не понимаете, в каком месте упёрлись. Пропускаемости шины не хватает, расчёты медленно идут, параллельно операции не выполняются?

Да ладно... с 1С вроде история была - написали они серверную часть, а она всё на одном ядре считает. Ну, люди по привычке давай покупать сервера с процессорами на стотыщ ядер, а толку никакого. Потомушто анализа проблемы не делали, просто пришли в магаз за "сервером помощнее".

А там нет одного конкретного корня зла. Скажем, работа с MAX7219 и WS2812B занимает процентов 30-40 времени. Опрос раличных ADC и специализированных тараканов (MAX6675, MAX31685) c пересчетом результатов и выплевыванием их посредством железного Serial в сторону MAX485 - еще порядка 50 процентов. По отзывам, кстати, работа с Serial у arduino не быстрая, но конкретно именно ее я не замерял, смотрел общее время выполнения задачи. 

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

Поскольку операции разнесены по времени посредством millis(), я могу балансировать загрузку в рамках одного прогона loop, скажем так. Что-то сделаю 10 раз в секунду, что-то 30, что-то один раз. И уже вижу, что сделать все так часто, как мне бы хотелось - я физически не успеваю. 10 раз в секунду - успеваю. 30 - уже нет.

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

Не так много вариантов-то, если оставаться в рамках arduino.

Хтя работу с Serial я пожалуй посчитаю отдельно, самому интересно.

Вы просто не читали мой первый пост, или привыкли по линованной бумаге писать поперек? :) На данный момент мне бы не хотелось переползать полностью на другую архитектуру, моя фамилия не Маклауд, к сожалению.

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

Что за ерунда? Какое нафик переползание на другую архитектуру, если вы работаете в среде ардуино? Итальянцы же жизнь положили на то, чтобы юзер и знать не знал, что за архитектура у него под вызовами digitalWrite() или Serial.begin. Уверяю вас что многие программы средней сложности можно перетащить с АВР на СТМ32, не поменяв в коде ни одной буквы.

А уж про смежные проекты и вовсе не понял. Почему надо все проекты делать на одной архитектуре? Кто это решил?

Траффик между модулями интенсивный? Т.е., например, каждый замер АЦП обуславливает изменение состояния "блока" индикации или же в него данные суются редко, но он сам исполняется долго?

Я достаточно регулярно читаю в сети на предмет программирования STM32 из среды arduino, опять же и у моего любимого robotdyn есть подходящая плата. У меня сложилось впечатление, что связка получается достаточно не стабильная, и требует регулярных танцев с бубном. Но сам не пробовал. Возможно стоит попробовать, благо по железу вход копеешный. 

По смежным проектам - да все просто. У меня есть основная работа, никак не связанное с электроникой и работой основное хобби, и есть второе хобби, уже связянное с arduino. И личная жизнь еще. Изучать и использовать параллельно две разных платформы - у меня банально нет столько времени. И так-то с трудом хватает. 

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

Summit

Что значит для вас "оставаясь в среде Ардуино"? Пользование библиотечными функциями Wiring. типа digitalWrite(), analogRead() и, соответственно, библиотеками на их основе с типовой работоой с периферией и датчиками?

В таком случае, посмотрите в сторону Arduino DUE.

Далее, Вы пишете что используете float вычисления, которых у Мег нет как природного явления. Мега - целочисленный камень. Переход от float к разумной фикс. десятичной точке даже на базе long даст выигрыш в производительности примерно раз 10. Но тут, скорее всего, всю базовую математику придется писать самостоятельно.

Ещё далее. Отказ от Wiring в пользу прямой работы с аппаратурой и портами дает рост производительности тоже около 10 раз. Но, если этот этап пройден, то тогда да.. надо думать.

Ну и напоследок: переход к автоматному стилю управления, в т.ч. и интерфейсами: I2C, SPI, UART - все они заточены именно под этот автоматный стиль, а не "как в Wiring", хоть и добавляет накладные расходы но значительно повышает использование простоев для полезной работы. Используете аппаратные драйвера или "ногодрыговые" имитации?

А в целом, Вы не показали код, поэтому как-то сложно что-то советовать: непонятно о каких тормозах идет речь. То, что Вы пишите, на самом деле понятно лишь только Вам одному.

Замеры по АЦП делаются в зависимости от датчика от 1 до 30 раз в секунду.  Т.е. кто-то 1 раз, кто-то 10 раз, кто-то 30. Это фиксированно, зависит от типа датчика.  Результат замера сразу пересчитывается в понятный вид, как правило float.

В Serial (MAX485) выплевываю результат сразу после замера и конвертации в понятный вид. Длина пакета 20 байт. Теоретически я могу его уменьшить, практически это нежелательно, ибо усложнит жизнь принимающей стороне. Ибо кроме значения передается информация о параметре, достаточная для его обработки и показа принимающей стороной. Которая заранее не знает, что именно получит. 

На блок индикации (MAX7219 в количестве до 8 штук) вывожу 10 раз в секунду, чаще нет смысла. 

К этому хочу добавить запись на SD карту, с частотой замеров АЦП. Обрабатываются данные с ~20 датчиков, что-то через внешние АЦП (ADS1015), что-то через специализированные микросхемы (MAX6675,MAX31865).

Чечако, float не дает нужной точности вычислений. Он сам хранит в лучшем случае 6 знаков, а при использовании тригонометрии оно падает до 5 знака, а при неправильной схеме вычислений (порядке операций) легко можно получить ошибку уже в 3-4 знаке.

Это хорошо видно из учебных программок моделирования движения спутника по орбите: или падет или улетает и достаточно быстро.

В этом плане, первое о чем надо задуматься - это так ли нужен Вам float?

Ещё: выплевывание пакета в serial: можно кодировать имя параметра одним-двумя байтами. Или придумать свой формат посылки, чтобы не осложнять жизнь приемной стороне. Это может существенно сократить размер пакета. Ну и опять же: работа с serial у Вас ведется через аппаратный драйвер как в Cyberlib или Serial.begin()?

beginer - ну зачем вы это все ему пишете? ведь он же ясно обозначил свою позицию:

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

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

Смущает "зависит от типа датчика". Вам действительно нужны значения раз в 30 секунд или раз датчик столько позволяет, так часто и буду опрашивать?

Это цветомузыка какая-то? Если текст, то кому он 10 раз в секунду нужен?

analog.read или write не использую вообще, только digital. DUE меня не устраивает форм-фактором, не могу найти для нее компактного исполнения.  I2C, UART - аппаратные, SPI и аппаратный, и эмуляцию посредством библиотеки LedControl. Надо будет попробовать перевести на аппаратный и посмотреть, c ней я кстати не пробовал. Если LedControl это вообще может.

Выложить код - перебор будет, imho. 44 килобайта только моего кода, плюс библиотеки. В них я слабые места более-менее знаю, что мог - поправил. Кое что еще поправлю. 

Мне быльше интересен реальных опыт кого-то с M0 или с Teensy 3.5/3.6. Я реально не могу нагуглить каких-то замеров. По DUE проще, но формфактор не мой от слова совсем.

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

Использую Serial, но встроенный в мегу, а не SoftwareSerial. Что такое Cyberlib - не в курсе, погуглю. 

Update: Почитал про cyberlib, очень интерестно, спасибо! Попробую.

Похоже на то, отстал. :)

Чечако, я не знаю людей, кто бы плотно работал именно с Тенси или М0, но я знаю одного тутошнего автора, который показывал мне на что способна полноценная Мега в реальности.  Впечатлило, но .. этому надо учиться, а не "библиотеки юзать"... :)

В некоторых случаях - нужны. Для разбора полетов по логам как минимум. Секунда - это достаточно долго, знаете ли. :) Касательно вывода на экран 10 раз в секунду - к этой цифре я пришел опытным путем. Меньше я вижу заторможенность, она меня напрягает. Выше и правда смысла нет. 

Мошт делать вывод как полагается - не четко 10 раз в секунду, а когда изменилось значение?

Честно говоря, Вы прочитали видимо только последнее предложение. Очень жаль, ибо на этом форуме Вы один из тех, кто не чисто "поносится, поорать". :( 

Уважаемый, давайте чтобы было понимание - я с компьютерами больше тридцати лет. Программирование на низком уровне мне вполне себе знакомо, по мотивам некоторых  наработок были публикации в журнале "Информатика и образование" в девяностых, если это Вам о чем-то говорит. И доступ к тем же персоналкам у меня появился до того, как вышла первая книга Фигурнова. И демомейкингом я опять же в свое время занимался, если Вы знаете, что это такое и каких оптимизаций кода требовало в тех же девяностых.

Это все не в плане понтов, а чтобы было понимание моего базового уровня. Вот с микроконтроллерами - бегло познакомился года четыре назад, плотно - с этого лета. Что такое оптимизация кода - я знаю не по наслышке. И сколько времени она занимает - тоже знаю. Нет у меня этого времени. Жалко мне его. Я лучше с девушкой куда-нить схожу вечером, чем придя домой, буду до ночи пялится в монитор. Или c ребенком в выходной время проведу. С наемными исполнителями - я наелся, спасибо. Сначала программисты с радиокота, потом скиф местный. 

Если упрощенно, на решение любой проблемы обычно надо две ресурса - время и деньги. Какого и сколько уйдет - зависит от проблемы. Скажем, в девяностых я не мог решить некоторые вопросы за деньги, во первых их столько просто не было, а во вторых, техники такой не было. :)

Сейчас все проще. Сильно проще. И если мою проблему можно решить, увеличив стоимость базовой платы с контроллером с 1000 рублей до 2000 практически без затрат времени, то я не вижу в этом ничего плохого. Более того, вижу только хорошее, я найду, чем занять себя в свободное время. 

А Вы рубите с плеча, даже не вникая. :(

Можно так сделать, но это скорее отсрочка, а не решение. Я выносил всю работу с MAX7219 на внешную ProMini, это освобождало у меги в районе 30%. Нынешние потребности оно безусловно покроет, но запаса на вырост не будет, imho.

Но сегодня/завтра попробую так сделать, благо это не сложно и не долго. 

Вырост - явление нелинейное... 

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

хорошо, давайте не будем сраться:)

Просто оглянитесь назал и прочитайте свои же посты. Вы не замечаете, как сами себе противоречите. Почему-то перевод проекта на Дуе или на Тенси - архитектура которых имеет крайне мало общего с Атмегой и которая значительно ближе к СТМ32 - вы не считаете серьезным шагом, а вот переезд на СТм вас пугает.

Поймите, в рамках платформы Ардуино плат, занчительно превосходящих Мегу, но "с той же архитектурой" - ПРОСТО НЕ СУЩЕСТВУЕТ. Если вы хотите поменять платформу - вам в любом случае придется осваивать новое железо. Я абсолютно не пытаюсь рекламировать СТМ - хотите, берите Тенси, но ведь там тот АРМ...

Просто СТМ32 стоит 2 бакса , под нее тысячи проектов в инете и куча наработанных библиотек, а Тенси - 50$ и пока в силу цены далеко не так популярна - а это сразу означает, что если что и спросить не у кого

Вопрос в том, на сколько STM32 окажется быстрее, и сколько времени у меня уйдет на вникание в тему и переписывание под нее используемых библиотек...

С тем, что значительно превосходящих нет - соглаcен, да. Но и готовых решений по STM32 тоже не так много. Я использую готовые планы, разводить полностью полноценную плату с распайкой кристалла непосредственно не готов. По сути - из того, что могу попробовать малой кровью - вижу только вот это:

https://robotdyn.com/stm32-arm-arduino-mini-system-dev-board-blue-pill-w...

Считаете, стоит попробовать? :)

Опаску во многом вызывает то, что все обсуждения работы с STM через arduino ide, что я нагуглил, обычно кончались выводом о том, что это извращение, и правильнее использовать родную среду. Но, повторюсь, живьем и сам - не пробовал.

А если её не хватит, куда дальше расти? Да и непонятно, как она с  Serial работает?

Если хочется переплатить :)- берите Роботдиновскую (шутка). Хотя я все же взял бы классическую Блюпилл на Али:

Не из-за разницы в 1 бакс, а из-за опасений, что роботдиновская не вполне такая, как голубая. С голубой вы будете 100% уверены в совместимости с другими юзерами

когда вас интересует скорость и эффективность - точно такие же рассуждения можно прочитать и про классические ардуино на платах АВР. Народ пишет, что ардуино - отстой, надо работать через регистры и писать на ассемблере :)

У меня нет такого богатого бекграунда, как у Вас. Я занимаюсь ардуино порядка 2х лет. И буквально на второй месяц стал делать проекты на Стм32. Поверьте, это абсолютно не сложнее, чем писать, например, для Меги. Конечно, там есть свои особенности, некоторые библиотеки для АВР надо править , чтобы запустить на СТМ - но все это ровно так же справедливо для Дуе или Тенси.

Чтобы проиллюстрировать, что пугающая вас "смена платформы" - это вовсе не катастрофа, приведу пример.  Для одного проекта, чтобы выбрать правильную платформу - я портировал готовый код (довольно приличного размера) одновременно на Мегу, СТМ32 и ЕСП8266. Вся процедура заняла у меня несколько часов, причем основное время ушло на перерировывание интерфейса, потому что для каждого МК пришлось выбрать свою библиотеку для TFT-дисплея. Собственно логика программы, работа с датчиками и обработка данных перепозла с контроллера на контроллер практически без правки.

Стоит вспомнить надпись на двери уборной: "Если делать - то по-большому!".

То есть если ты занялся МК, то стоит заниматься этим серьёзно или не тратить свое... ну и наше тоже, время.

========================

Теперь по-сути:

1. В рамках платформы AVR нет ничего "круче" Меги... есть специальные вещи, не относящиеся к ардуине, но и они все те же 16МГц.

2. Все что "выше" - платформа ARM. Что дуе и подобные, типа зеро, что СТМ32. Все это нормально программируется под ИДЕ, но ближе друг-другу, чем к классике.

3. Попробуй четко ответить, можно не нам, а себе: в чем тебе поможет большая тактовая частота? Тормоза, которые ты наблюдаешь, насколько они связаны с нехваткой тактовой частоты и насколько с самим кодом?

Я не о том, что код неоптимальный, это само-собой, ты же не специалист. А просто с сутью кода. Например выгрузка в ленту 2812 на любом контроллере займет именно столько времени, если не сделать ее аппаратно, что не всегда возможно. Или обмен по UART - он такой какой есть на любом МК. С аппаратным UART на прерываниях можно сделать обмен неблокирующим, но, без обид, не с твоим уровнем.

То есть, твое решение это не замена контроллера на другой, с большей частотой, а перепроектирование системы, с выделением блокирующих модулей в другой контроллер. И тогда, возможно, не будет необходимости менять ядро. Но может и будет, тут уже сам решишь. Возможно, замена ядра будет просто опытом для повышения скилла? ;))

А можно попросить проверенную ссылку на ali? Собственно, на robotdyn я подсел из-за неплохох отзывов, хорошего качества внешне и очень удобного форм-фактора Меги в их исполнении (Mega 2560 PRO (Embed)). Впрочем, их SAMD21 я тоже закажу, ибо самому уже любопытно. Про Тенси - да, скорее всего тупиковая ветвь получится, если по ней идти, а значит оно того не стоит. Вычеркиваем. :)

Ну, сейчас я скорее всего по любому протестирую решение с передачей части функций на отдельную ProMini, благо они у меня есть и на столе уже опробовано. И посмотрю живьем на Блюпилл и M0, возможно все не так страшно. А там будет видно, да. 

Плюс изучу библиотеку cyberlib, в полном составе она мне не нужна, но кое что из нее надо будет потестировать, тот же UART например. Да и по мелочи. Ибо пять старушек - рубль. :)

А по поводу того, стоит лезть или не стоит, скажу так - основную задачу, ради которой я полез в мир МК, я уже выполнил. Нужный мне девайс сделан и используется каждый день. Даже если и не будет дальнейшего развития, уже как есть он вполне решает стоящие перед тим практические задачи. Получится большее - замечательно. Не получится - отрицательный результат, тоже результат. 

Пока сообразишь, что не хватает, там уже и эксафлопс подоспеет - думаю в 21-22 году будет. Во где с float'ами резвиться - на эксафлопсе-то :)

Ну так и задачи к 22-му году усложнятся - ацп нужно будет читать 60 раз в секунду(минимум), не говоря уже о других важных расчетах типа новых оброков. Вся производительность вернется на круги своя.

Производительность процессоров растет для того, чтоб программисты могли применять все более сложные и неповоротливые тулчейны для разработки приложений, разве не так? :)

это как с безопасностью - статистика утверждает, что у велосипедиста в шлеме шанс погибнуть под колесами автомобиля даже больше, чем у его собрата без шлема :)

Тогда не морочьте людям голову... Не хватает Меги и Arduino мешает??? Переходите на нормальные камни и пользуйтесь нормальными ИДЕ... Всё остальное - "а поговорить?"... и без единного практического решения...

Всё так. В каждой  шутке есть только доля шутки. А так - обычный человеческий взгляд на вещи. Пока производительность обходится дёшево, то оптимизировать процессы никто не будет. А вот как только приходит жаренный петух - тут и начинаются полеты в космос на полукилобайте памяти (или скоко там было).

Можете не верить... но это так и есть... Как и юзание на МК чужих готовых либ в 95 случаях из 100 тоже является извращением... Поэтому под СТМ на Ардуино вы мало что путнего для себя найдёте... а если и найдёте... то радости оно вам явно не принесёт... увы...

Не морочьте и Вы людям голову, пафосно написав что-то про неизвестные никому ИДЕ и не озвучив практического решения. ЕвгенийП предложил нормальный камень, не то что эти ваши... десять баксов за полкило. 

Ню-ню... )))))))))))))))))))))

Чушь горбатая... Производительность МК не равно производительности проца... и практически и теоретически... ибо задачи у них разные... Можно взять полкило нормальных МК и дешевле чем Мега... и пофигу что там за бортом останется нетронутым... А к крутому процу - хорошая материнка, видяха, памяти побольше, монитор под 8К... что никак не будет дешевле компа начального уровня...

И по поводу оптимизации... Значит она вам не нужна... совсем... Если была бы нужна... сами бы соптимизировали... а не ждали бы когда дядя-лох за вас соптимизирует... А вот когда рога смочите в этой оптимизации... тогда и поймёте... что проще и быстрее написать всё самому и заново...

Не тратьте на меня столько точек и общих фраз. Лично мне оптимизация действительно не нужна, топик открывал не я.

Да какбэ пофигу... типа совсем... Но подобные цифры...

основательно пугают... Полудохлые черепахи и то быстрее бегают...

MAX7219 - таймер+ДМА... хардварно... 0%... время загрузки буфера не в счёт...

WS2812B - несколько %... полухардварно... на таймере+ДМА...

Опрос раличных ADC - частые опросы хардварно... остальные полухардварно... единицы %...

MAX485 - тупо взять камень с хардварной поддержкой и не маяться... единицы %...

работа с SD картой - взять камень с SD интерфейсом и гнать через ДМА... и не париться...

Математика с числами с плавающей точкой (float) - проще сразу в дабл... и быстрее и точнее... времени вполне хватит... т.к. его и так валом остаётся... даже при тактовой МК в 16МГц...

Если нужнго покомпактнее, есть еще такой вариант: https://ru.aliexpress.com/item/Due-Core-SAM3X8E-32-bit-ARM-Cortex-M3-Mini-Module-Compatible-UC-2102-512K-Flash-96K/32681732855.html

Ну тупые админы, в виртуалке такие задачи надо запускать, кстати архикад старый тоже только одно ядро использует, по новому не скажу, не приобретали за ненадобностью

Сказки, даже оптимизированные швейцарские эфемериды под 5 мегабайт требуют, нормальные 400, наши не используют эфемериды, летают на рассчетном блоке ...и он точнее швейцарских эфемерид, проверено неоднократно на лунных и солнечных затмениях

Читал... читал... Сначала дико испугался "камня с хардварной поддержкой RS485".... КАК этот камень ускоряет то, что нельзя ускорить ?! Невозможно ускорить напряжение и ток :) 

Может подходить к вопросу по другому. Адресные диоды например поменять на какие нибудь APA102... Они быстрые, недавно убедился, там ваще задержек не нужно.

Опять не очень понятно как нужно юзать 7219, что бы они вместо пользы приносили вред....

Может как то подклутить чтение ADC ? Ну тут то где ресурсы теряюся ?

Ну возьмите ESP32,  там вообще два ядра. На изучение FreeRTOS по примерам нужно меньше часа, если конечно в "бантики", типа глубокого контроля над потоками, не углубляться. Нужно то пару тройку приемов понять.

ESP отлично ардуиной прикидывается. При работе из ардуино ИДЕ никаких проблем.

...и? 

Да товарища опять на ненависти к AVR так заклинило, что даже кушать не может. По его мнению нужно для домашних прожектов SOC брать и учить до посинения. Ну или то, чего он там сам разучил и форсит беспрестанно. 

1 ядро 20гигагерц мало?

На какой системе виртуализации?