nuttx я знаю давно, еще когда она была только для AVR.
Ее ценность тогда была в TCP стеке.
Но теперь TCP стек есть практически у всех.
А теперь достоинств nuttx по сравнению с MQX я не вижу. Да и поддержки Kinetis там нет.
Если искать альтернативу для Kinetis, то я бы рекомендовал uCOS for makers или mbed OS
Я скажем приведу такой сценарий зависимости:
Программному модулю нужно получить данные из другого программного модуля.
Простейший путь — объявить их публично доступными и обращаться к ним из всех других модулей.
Это создание зависимости.
А ее ликвидацией будет реализация кода явной передачи данных нуждающимся в них модулям неким дополнительным механизмом.
Но хороший редактор вам покажет все зависимости по месту объявления этих данных. Так зачем делать лишнюю работу?
Хотя может тут стоит спорить о термине «зависимость».
Я честно в контексте статьи перестал его понимать.
Но хороший редактор может упростить прослеживание зависимостей до такой степени что даже можно от них не избавляться.
Опять же зависимости укорачивают код.
Не факт что более длинный код без зависимостей будет читаться лучше чем короткий с зависимостями.
Можно ведь еще сказать все что не помещается на один экран — это код с неявными зависимостями.
Значит чем больше экран редактора тем меньше неявных для читателя зависимостей.
Опять упираемся в редактор.
Почему когда начинают про хорошесть кода, не говорят об IDE и просто редакторах?
А мне кажется, что именно IDE и определяет как будет писаться код и почему он выглядит у других так или иначе.
Точно обороты модуль измеряет с помощью энкодера встроенного в мотор или внешнего.
С некоторой погрешностью модуль может измерять обороты измеряя ток и напряжение на обмотках.
Да, модельные моторы это одна из задач этого модуля.
30А это ток который допустим без радиатора.
С радиатором допустим ток 80А и больше. Сейчас ведутся испытания по определению максимальных режимов.
Обратная связь конечно же есть. Это все будет описано в следующей статье.
Модуль уже нашел свое применение. От инвертеров он отличается большей интегрированной функциональностью.
Проект инвертера на 320В я публиковал вот здесь https://habrahabr.ru/post/256611/
А понял, по скриншоту угадывается MACH3.
Это немного странновато для робота использовать простую пошаговую программу как для станка.
А где же гибкая логика обхода препятствий или планирования траектории?
Понял, управляющий софт так называется — MACH3
Нет, не вижу каким образом такой софт может нивелировать люфты, это может делать только привод на двигателе.
У вас есть еще куча возможностей для удешевления.
Например контроллеры PLD330 можно вполне заменить своими контроллерами и разместить их прямо на двигателях. Соединить их сетью CAN или даже EtherCAT, это сейчас очень не дорого.
Уберете эти кошмарные разъемы, упростите отладку и ввод в эксплуатацию.
В том что вы выложили нет никакого намека на управляющий софт. Что вы используете для создания программы движений?
Я не путаю, а я и говорю только о шаговых двигателях.
В современных сервах стоят BLDC и 3-х фазные холлы.
Я сам такие проектирую и делаю.
Но наличие холлов в сервах не избавляет от необходимости иметь точный внешний датчик угла поворота. Упрощенно я называю его энкодер, хотя там все сложнее.
BLDC двигатель с тем же моментом что и шаговый будет дешевле раза в полтора.
Свой разработанный магнитный энкодер с 15-и битным разрешением обойдется где нибудь в 20 Евр и меньше.
Почти в такую же цену можно сделать и индуктивный энкодер. У него разрешение будет более 16 бит.
Системщикам неплохо бы помнить, что C является основным языком при программировании встраиваемых систем и узлов IoT на малых микроконтроллерах.
И там совсем другие подходы.
Поэтому статьи по C надо начинать с дифференциации.
Т.е. сразу предупредить, о программировании каких платформ идет речь и о каком организационном подходе к проектированию.
Например проблема сопровождения для малых микроконтроллеров у многих программистов отсутствует в принципе. Код пишется только для себя и не для кого больше.
Отсюда проистекает бессмысленность большинства советов в статье.
К примеру не надо зацикливаться на правилах названий функций и переменных, программист делает рефакторинг своего кода каждый день. Какая нибудь функция или переменная может поменять свое название десятки раз за время жизни проекта.
Постоянный рефакторинг на самом деле лучше закрепляет в памяти понимание работы программы, чем бесплодные попытки с самого начала дать правильные имена.
Более того, когда возвращаемся к старому проекту, то и тут можно сразу начать с рефакторинга. Это поможет быстрее восстановить в памяти структуру программы.
Соответственно код должен быть адаптирован к рефакторингу, вместо того чтобы подчиняться неким соглашениям об именованиях.
Ну и конечно о рефакторинге бессмысленно говорить не упомянув в какой среде разрабатывается код и в какой компилируется.
Ее ценность тогда была в TCP стеке.
Но теперь TCP стек есть практически у всех.
А теперь достоинств nuttx по сравнению с MQX я не вижу. Да и поддержки Kinetis там нет.
Если искать альтернативу для Kinetis, то я бы рекомендовал uCOS for makers или mbed OS
Я скажем приведу такой сценарий зависимости:
Программному модулю нужно получить данные из другого программного модуля.
Простейший путь — объявить их публично доступными и обращаться к ним из всех других модулей.
Это создание зависимости.
А ее ликвидацией будет реализация кода явной передачи данных нуждающимся в них модулям неким дополнительным механизмом.
Но хороший редактор вам покажет все зависимости по месту объявления этих данных. Так зачем делать лишнюю работу?
Хотя может тут стоит спорить о термине «зависимость».
Я честно в контексте статьи перестал его понимать.
Опять же зависимости укорачивают код.
Не факт что более длинный код без зависимостей будет читаться лучше чем короткий с зависимостями.
Можно ведь еще сказать все что не помещается на один экран — это код с неявными зависимостями.
Значит чем больше экран редактора тем меньше неявных для читателя зависимостей.
Опять упираемся в редактор.
А мне кажется, что именно IDE и определяет как будет писаться код и почему он выглядит у других так или иначе.
С некоторой погрешностью модуль может измерять обороты измеряя ток и напряжение на обмотках.
30А это ток который допустим без радиатора.
С радиатором допустим ток 80А и больше. Сейчас ведутся испытания по определению максимальных режимов.
Обратная связь конечно же есть. Это все будет описано в следующей статье.
Да, модуль продается.
Проект инвертера на 320В я публиковал вот здесь https://habrahabr.ru/post/256611/
Это немного странновато для робота использовать простую пошаговую программу как для станка.
А где же гибкая логика обхода препятствий или планирования траектории?
Нет, не вижу каким образом такой софт может нивелировать люфты, это может делать только привод на двигателе.
Например контроллеры PLD330 можно вполне заменить своими контроллерами и разместить их прямо на двигателях. Соединить их сетью CAN или даже EtherCAT, это сейчас очень не дорого.
Уберете эти кошмарные разъемы, упростите отладку и ввод в эксплуатацию.
В том что вы выложили нет никакого намека на управляющий софт. Что вы используете для создания программы движений?
Поэтому без хорошей механики чисто программно с точным управлением не справится.
В современных сервах стоят BLDC и 3-х фазные холлы.
Я сам такие проектирую и делаю.
Но наличие холлов в сервах не избавляет от необходимости иметь точный внешний датчик угла поворота. Упрощенно я называю его энкодер, хотя там все сложнее.
Свой разработанный магнитный энкодер с 15-и битным разрешением обойдется где нибудь в 20 Евр и меньше.
Почти в такую же цену можно сделать и индуктивный энкодер. У него разрешение будет более 16 бит.
Обратная связь по положению.
И там совсем другие подходы.
Поэтому статьи по C надо начинать с дифференциации.
Т.е. сразу предупредить, о программировании каких платформ идет речь и о каком организационном подходе к проектированию.
Например проблема сопровождения для малых микроконтроллеров у многих программистов отсутствует в принципе. Код пишется только для себя и не для кого больше.
Отсюда проистекает бессмысленность большинства советов в статье.
К примеру не надо зацикливаться на правилах названий функций и переменных, программист делает рефакторинг своего кода каждый день. Какая нибудь функция или переменная может поменять свое название десятки раз за время жизни проекта.
Постоянный рефакторинг на самом деле лучше закрепляет в памяти понимание работы программы, чем бесплодные попытки с самого начала дать правильные имена.
Более того, когда возвращаемся к старому проекту, то и тут можно сразу начать с рефакторинга. Это поможет быстрее восстановить в памяти структуру программы.
Соответственно код должен быть адаптирован к рефакторингу, вместо того чтобы подчиняться неким соглашениям об именованиях.
Ну и конечно о рефакторинге бессмысленно говорить не упомянув в какой среде разрабатывается код и в какой компилируется.