Понимаете, без формальных схем нарисованных в какой-то стандартной среде, которые можно запустить и проверить возникает стойкое ощущение что вы свои диаграммы нарисовали уже после того как написали программу.
И зачем-то пытаетесь убедить, что применяли автоматное программирование.
Если работаете с IAR то должны знать их продукт IAR Visual State
Есть бесплатная триальная версия.
Я бы рекомендовал в ней вам создавать свои автоматы.
Тогда их можно было бы скачать и оценить трудоемкость и эффективность такого подхода.
А также быстро перепроверить насколько ваша реализация отклоняется от проекта.
А рисовать на бумаге диаграммы — это, извините, анахронизм и трата времени.
Заканчиваю уже занудствовать. Только напоследок скажу что оперативная память для DMA тоже за уши притянута.
При импульсе в 1 мкс можно данные и из SPI Flash читать или NAND. А уж это то подключаются к любым микроконтроллерам и размеры может иметь какие угодно.
Хотя сама идея заранее формировать импульсы для управления двигателем на интервале минуты без корректировки по обратной связи вызывает нехорошие чувства.
Наверно будет кому-то откровением, но частота APB шины у PI всего 350 МГц.
Это та шина через которую работает DMA.
А у STM32H7 есть четыре! шины AHB по 200 МГц. Чувствуете разницу?
Это значит что STM32 существенно быстрее работает с периферией чем PI.
Если учесть что STM32 работает не с DDR а с более детерминированной SRAM, то и вовсе по быстродействию при работе с большим количеством двигателей STM32 уделает PI.
Большой или не большой зависит от драйверов остального «фарша».
Самый большой поток DMA идет на дисплей, потом потоки DMA на несколько USB, потом DMA на SD карту, Если Ethernet есть, то DMA же нужен и для него…
А если еще кто нибудь задумает камеру подключить, то не удивлюсь если DMA на GPIO будет выдавать ошибку.
Автор скорее всего на свой Raspberry Pi даже не дышит чтобы он протянул минуту работы DMA без искажения сигналов.
Наивное заблуждение считать DMA этаким детерминированным автоматом не потребляющим ресурсы.
DMA делит ту же шину AHB что и процессор и они между прочим могут там конфликтовать.
DMA замедляет работу процессора. А еще каналы DMA конфликтуют друг с другом.
Поскольку Raspberry Pi не проектировался для систем реального времени у меня большие сомнения что его DMA работает достаточно детерминированно и без сбоев при большом количестве каналов.
В любом случае даже DMA требует рано или поздно прерываний и тут детерминизму в Raspberry Pi придет конец.
Ну и наконец писать такие программы на Python это очень странно. В Pythone нет никаких средств наблюдения за регистрами процессора и периферии в реальном времени. Невозможно увидеть никаких внутренних переменных драйверов, нельзя оперативно менять содержимое регистров и т.д. и т.п. Это язык абсолютно оторванный от реального времени.
Для управления моторами есть прекрасные микроконтроллеры STM32, Kinetis и т.д.
Специально заточены, гораздо более гибкий и контролируемый DMA чем у Raspberry Pi, полная доступность всех регистров периферии и процессора в реальном времени, даже трассировка прерываний и исполнения кода. Жесткая детерминированность.
Я открываю ваши тексты и вижу кругом функции и макросы от HAL предоставляемого ST.
И этого следует что вы делаете еще одну надстройку поверх HAL.
Функции socket(), listen(), sendto() это прикладной уровень. Если в вашем стеке TCP их раньше не было, то это проблема вашего стека.
А скажем в MQX, uCOS они всегда были.
К HAL т.е. к уровню аппаратной абстракции или платформо-независимости эти функции отношения не имеют. Это все равно что назвать платформо-независимой функцию printf
Индивидуалами я называю людей которые сами разрабатывают архитектуру системы, разрабатывают железо для нее и программируют его.
Никто софт для серьезной встраиваемой системы с нуля в наше время даже если захочет не напишет.
Просто я не согласен в одной мелкой детали во все этой истории, а именно с вашей презентацией полезности некоей кроссплатформенности построенной на концепции HAL от ST.
Это на мой взгляд пустая трата времени.
В вашей организации она нужна для реюзинга, а индивидуалам она вредна.
Мой подход, кстати, не уникален, я его подхватил у таких известных проектов как uCOS и Keil RTX. Минимализм и пропуск абстракции аппаратуры сильно экономит время.
Тут вы смешиваете в кучу фреймворк, промежуточное ПО и то что у ST называется HAL.
О роли фреймворков и middleware я наслышан.
Но HAL это прежде всего средство привязать пользователей к определенной платформе, а заодно и способ реюзинга во внутрикорпоративной разработке у самого ST.
Я не знаю как вы задокуметировали свой HAL, но документация на HAL от ST не намного легче того же мануала на чип или даташита. По сути в любом случае юзер должен изучать работу периферии чипа по мануалу, на если RTOS работает через HAL то он еще вынужден тратить время на изучение HAL.
От этого у разработчика падает производительность.
Я скажем доволен, что в своем фреймворке мне удалось RTOS MQX практически очистить от всяких абстракций и перевести на прямую работу с регистрами. Остались только нативные драйвера SD, USB и Ethernet.
Без HAL я могу быстро реализовывать и легко отлаживать до десятка задач с жестким реальным временем. Исходники получаются прозрачными и чистыми. Нет никаких длиннющих макросов. Нет сбивающего с толку переименовывания обращений к регистрам. Взяв любое имя регистра в текстах с легкостью можно найти его в мануале, не гуляя по дебрям HAL в попытках понять что есть что.
Также без HAL легче централизовать всю информацию о периферии в одном файле и т.д. и т.п.
Важно не то где разработчик находится, а в какую организационную схему он встроен.
И тут разница и проявляется.
У вас может быть архитектор сверху, кодер снизу и хардварщик сбоку. А может это все помещаться в вас одном.
И мне кажется ардуинщики, т.е. самая массовая аудитория — это люди где все в одном.
И только кажется, что платформы меняются быстро. Два три года всегда есть, прежде чем придумывают действительно что-то новое и стоящее.
Это все к тому что HAL придуман производителями чтобы быстрее плодить в своих недрах демки к своим чипам.
А конечный разработчик ориентирован на манул к чипу, а не на представление неких сторонних программистов как надо работать с аппаратурой.
Тут я вижу принципиальный конфликт интересов.
Индивидуальным разработчикам наличие мультиплатформенности в исходниках поддержки железа только мешает разобраться в коде и вынуждает дополнительно изучать некий чужой HAL.
Индивидуал не меняет платформы каждую неделю и не его проблемы, что разработчикам набора платформ нужен HAL чтобы быстрее переключаться с платформы на платформу.
К примеру я всегда избавляюсь от HAL-ов сторонних разработчиков. Они всегда хуже документированы и не настолько гибкие, как непосредственно работа с регистрами периферии.
Еще несколько странно выглядят отсылки к линуксу.
Почему подражание программному интерфейсу настольной системы может быль каким-то плюсом для малой RTOS?
Да, я пока не слышу.
Модуль работает максимум от 30В. Т.е. электробезопасность можем пропустить.
А вот с пожаробезопасностью интересней.
Какой вы видите сценарий, когда без «заземления», а по сути без подключения к раме велосипеда (если рама не из диэлектрика) увеличивается риск пожара?
Надеюсь вы понимаете, что заземлять можно только в одной точке.
Сложность — это чувство и одновременно проблема восприятия.
Взято из рекомендованной вами книги — «Путешествие по системному ландшафту»
Т.е. со сложностью можно бороться чисто психологически.
Еще известен такой феномен как возрастной кризис, ускорение субъективного времени и страх потери производительности.
Это все складывается и тогда возникают теории катастрофического разрыва Йадерлунда (взято из той же книги)
Я в это не верю. Тот же ИИ как раз и не допустит разрыва.
Рекуперация еще может производится обратно в аккумулятор.
С другой стороны чоппер может быть совершенно независимым узлом и подключаться отдельно.
Кстати модуль имеет специализированные выходы которые могут служить для управления чоппером если он действительно нужен будет.
Что вы называете заземлением в движущихся объектах вроде велосипеда?
Подключение общего провода драйвера на корпус? Да еще по углам платы?
Так вы создадите просто еще один источник излучения.
Я могу продать готовые модули. Но розничная цена будет в несколько раз выше pi.
Она не может быть сравнима с pi поскольку модули делаются небольшими партиями.
Поэтому это и полностью открытый проект.
Здесь тестируется концепция и юзкейсы. Предполагается на основе обратной связи совершенствовать проект.
Продать модули — не самоцель.
Спасибо за ценные советы. Все так и сделал в этом проекте https://habrahabr.ru/post/256611/
А этот проект удешевленный.
Его можно сказать смысл в том чтобы показать возможность работы в упрощенном варианте.
Обратные ЭДС моторов в приложениях модуля были изучены, необходимости в чоппере нет.
Насчет заземления я бы поспорил.
Заземление нужно для защиты людей от ударов током. Если пытаетесь заземлить общий провод платы силового драйвера, то получите огромную электромагнитную эмиссию в полосе 1...30 МГц и не пройдете сертификацию. Нужно будет ставить глухой качественный экран, просто металлический корпус не поможет.
А так без заземления можно повесить на все исходящие провода абсорберы и все будет нормально.
Частью сервы плату я не мог сделать, поскольку она еще выполняет кучу функций в оборудовании.
А DRV10983 слишком уж интегрированное решение, и не подходит для всех идей по применению которые есть относительно модуля.
Можно управлять и с помощью L298 и L293d, но их придется ставить два и все равно нужен микроконтроллер.
Есть же более совершенные решения, например DRV10983
И зачем-то пытаетесь убедить, что применяли автоматное программирование.
Есть бесплатная триальная версия.
Я бы рекомендовал в ней вам создавать свои автоматы.
Тогда их можно было бы скачать и оценить трудоемкость и эффективность такого подхода.
А также быстро перепроверить насколько ваша реализация отклоняется от проекта.
А рисовать на бумаге диаграммы — это, извините, анахронизм и трата времени.
При импульсе в 1 мкс можно данные и из SPI Flash читать или NAND. А уж это то подключаются к любым микроконтроллерам и размеры может иметь какие угодно.
Хотя сама идея заранее формировать импульсы для управления двигателем на интервале минуты без корректировки по обратной связи вызывает нехорошие чувства.
Это та шина через которую работает DMA.
А у STM32H7 есть четыре! шины AHB по 200 МГц. Чувствуете разницу?
Это значит что STM32 существенно быстрее работает с периферией чем PI.
Если учесть что STM32 работает не с DDR а с более детерминированной SRAM, то и вовсе по быстродействию при работе с большим количеством двигателей STM32 уделает PI.
Самый большой поток DMA идет на дисплей, потом потоки DMA на несколько USB, потом DMA на SD карту, Если Ethernet есть, то DMA же нужен и для него…
А если еще кто нибудь задумает камеру подключить, то не удивлюсь если DMA на GPIO будет выдавать ошибку.
Автор скорее всего на свой Raspberry Pi даже не дышит чтобы он протянул минуту работы DMA без искажения сигналов.
DMA делит ту же шину AHB что и процессор и они между прочим могут там конфликтовать.
DMA замедляет работу процессора. А еще каналы DMA конфликтуют друг с другом.
Поскольку Raspberry Pi не проектировался для систем реального времени у меня большие сомнения что его DMA работает достаточно детерминированно и без сбоев при большом количестве каналов.
В любом случае даже DMA требует рано или поздно прерываний и тут детерминизму в Raspberry Pi придет конец.
Ну и наконец писать такие программы на Python это очень странно. В Pythone нет никаких средств наблюдения за регистрами процессора и периферии в реальном времени. Невозможно увидеть никаких внутренних переменных драйверов, нельзя оперативно менять содержимое регистров и т.д. и т.п. Это язык абсолютно оторванный от реального времени.
Для управления моторами есть прекрасные микроконтроллеры STM32, Kinetis и т.д.
Специально заточены, гораздо более гибкий и контролируемый DMA чем у Raspberry Pi, полная доступность всех регистров периферии и процессора в реальном времени, даже трассировка прерываний и исполнения кода. Жесткая детерминированность.
И этого следует что вы делаете еще одну надстройку поверх HAL.
Функции socket(), listen(), sendto() это прикладной уровень. Если в вашем стеке TCP их раньше не было, то это проблема вашего стека.
А скажем в MQX, uCOS они всегда были.
К HAL т.е. к уровню аппаратной абстракции или платформо-независимости эти функции отношения не имеют. Это все равно что назвать платформо-независимой функцию printf
Индивидуалами я называю людей которые сами разрабатывают архитектуру системы, разрабатывают железо для нее и программируют его.
Никто софт для серьезной встраиваемой системы с нуля в наше время даже если захочет не напишет.
Просто я не согласен в одной мелкой детали во все этой истории, а именно с вашей презентацией полезности некоей кроссплатформенности построенной на концепции HAL от ST.
Это на мой взгляд пустая трата времени.
В вашей организации она нужна для реюзинга, а индивидуалам она вредна.
Мой подход, кстати, не уникален, я его подхватил у таких известных проектов как uCOS и Keil RTX. Минимализм и пропуск абстракции аппаратуры сильно экономит время.
О роли фреймворков и middleware я наслышан.
Но HAL это прежде всего средство привязать пользователей к определенной платформе, а заодно и способ реюзинга во внутрикорпоративной разработке у самого ST.
Я не знаю как вы задокуметировали свой HAL, но документация на HAL от ST не намного легче того же мануала на чип или даташита. По сути в любом случае юзер должен изучать работу периферии чипа по мануалу, на если RTOS работает через HAL то он еще вынужден тратить время на изучение HAL.
От этого у разработчика падает производительность.
Я скажем доволен, что в своем фреймворке мне удалось RTOS MQX практически очистить от всяких абстракций и перевести на прямую работу с регистрами. Остались только нативные драйвера SD, USB и Ethernet.
Без HAL я могу быстро реализовывать и легко отлаживать до десятка задач с жестким реальным временем. Исходники получаются прозрачными и чистыми. Нет никаких длиннющих макросов. Нет сбивающего с толку переименовывания обращений к регистрам. Взяв любое имя регистра в текстах с легкостью можно найти его в мануале, не гуляя по дебрям HAL в попытках понять что есть что.
Также без HAL легче централизовать всю информацию о периферии в одном файле и т.д. и т.п.
И тут разница и проявляется.
У вас может быть архитектор сверху, кодер снизу и хардварщик сбоку. А может это все помещаться в вас одном.
И мне кажется ардуинщики, т.е. самая массовая аудитория — это люди где все в одном.
И только кажется, что платформы меняются быстро. Два три года всегда есть, прежде чем придумывают действительно что-то новое и стоящее.
Это все к тому что HAL придуман производителями чтобы быстрее плодить в своих недрах демки к своим чипам.
А конечный разработчик ориентирован на манул к чипу, а не на представление неких сторонних программистов как надо работать с аппаратурой.
Тут я вижу принципиальный конфликт интересов.
Индивидуал не меняет платформы каждую неделю и не его проблемы, что разработчикам набора платформ нужен HAL чтобы быстрее переключаться с платформы на платформу.
К примеру я всегда избавляюсь от HAL-ов сторонних разработчиков. Они всегда хуже документированы и не настолько гибкие, как непосредственно работа с регистрами периферии.
Еще несколько странно выглядят отсылки к линуксу.
Почему подражание программному интерфейсу настольной системы может быль каким-то плюсом для малой RTOS?
Модуль работает максимум от 30В. Т.е. электробезопасность можем пропустить.
А вот с пожаробезопасностью интересней.
Какой вы видите сценарий, когда без «заземления», а по сути без подключения к раме велосипеда (если рама не из диэлектрика) увеличивается риск пожара?
Надеюсь вы понимаете, что заземлять можно только в одной точке.
Взято из рекомендованной вами книги — «Путешествие по системному ландшафту»
Т.е. со сложностью можно бороться чисто психологически.
Еще известен такой феномен как возрастной кризис, ускорение субъективного времени и страх потери производительности.
Это все складывается и тогда возникают теории катастрофического разрыва Йадерлунда (взято из той же книги)
Я в это не верю. Тот же ИИ как раз и не допустит разрыва.
С другой стороны чоппер может быть совершенно независимым узлом и подключаться отдельно.
Кстати модуль имеет специализированные выходы которые могут служить для управления чоппером если он действительно нужен будет.
Что вы называете заземлением в движущихся объектах вроде велосипеда?
Подключение общего провода драйвера на корпус? Да еще по углам платы?
Так вы создадите просто еще один источник излучения.
Она не может быть сравнима с pi поскольку модули делаются небольшими партиями.
Поэтому это и полностью открытый проект.
Здесь тестируется концепция и юзкейсы. Предполагается на основе обратной связи совершенствовать проект.
Продать модули — не самоцель.
А этот проект удешевленный.
Его можно сказать смысл в том чтобы показать возможность работы в упрощенном варианте.
Обратные ЭДС моторов в приложениях модуля были изучены, необходимости в чоппере нет.
Насчет заземления я бы поспорил.
Заземление нужно для защиты людей от ударов током. Если пытаетесь заземлить общий провод платы силового драйвера, то получите огромную электромагнитную эмиссию в полосе 1...30 МГц и не пройдете сертификацию. Нужно будет ставить глухой качественный экран, просто металлический корпус не поможет.
А так без заземления можно повесить на все исходящие провода абсорберы и все будет нормально.
Частью сервы плату я не мог сделать, поскольку она еще выполняет кучу функций в оборудовании.
А DRV10983 слишком уж интегрированное решение, и не подходит для всех идей по применению которые есть относительно модуля.
Есть же более совершенные решения, например DRV10983
Но есть технологическое оборудования где плата перемещается на платформах и вибрации измеряются не мотора, а платформ.