Size: a a a

2020 December 19

P

Ponytale 🇷🇺 in Embedded Group
jon pedro
Есть опенсорс проект, может слышал vesc. Они силовой привод для bldc замутили и есть какие-то коммерческие решения. Вот у них ещё выложена терминака на гитхабе, но в силу своего скудоумия я не до конца раскурил как она работает, но смотрится шикарно. Если интересно, могу поискать и скинуть ссылочку на гитхаб
space vector PWM? векторное управление? на каком процике?
источник

jp

jon pedro in Embedded Group
Ponytale 🇷🇺
space vector PWM? векторное управление? на каком процике?
Ну, если я ничего не путаю в bldc не используют векторное управление. Там же тупо смотрят переключение фаз эдс и включают нужные ключи, и по одному из модуля шимят
источник

КП

Крылатый Пегас... in Embedded Group
shadowsoul
у нас таки был алмазный напильник, внушительного размера
сверкал сука как меч эльфийский!
Вечный изумрудный...
источник

s

shadowsoul in Embedded Group
Крылатый Пегас
Вечный изумрудный...
да муху тебе в пиво)
источник

КП

Крылатый Пегас... in Embedded Group
shadowsoul
да муху тебе в пиво)
Сам такой!
источник

P

Ponytale 🇷🇺 in Embedded Group
jon pedro
Ну, если я ничего не путаю в bldc не используют векторное управление. Там же тупо смотрят переключение фаз эдс и включают нужные ключи, и по одному из модуля шимят
значит space vector PWM, скалярное управление. ну ок)
источник

jp

jon pedro in Embedded Group
@P0nytale какой проц уже не вспомню, да и не смотрел на это. Знаю что от st
источник

s

shadowsoul in Embedded Group
jon pedro
@P0nytale какой проц уже не вспомню, да и не смотрел на это. Знаю что от st
значит F3 серия небось
источник

P

Ponytale 🇷🇺 in Embedded Group
Крылатый Пегас
Вечный изумрудный...
пегасий?)
источник

КП

Крылатый Пегас... in Embedded Group
Ponytale 🇷🇺
пегасий?)
Конечно!
источник

P

Ponytale 🇷🇺 in Embedded Group
лол
источник

P

Ponytale 🇷🇺 in Embedded Group
Alexander
0xAA55 (или что-то похожее) в качестве заголовка ставь, а в конце пакета фиксированного размера контрольную сумму. )
оу. подумал и вспомнил. как-то в той беседе несколько недель назад все больше думал о синхронизации битрейтов и фаз приемо-передатчиков на физическом уровне - и почему-то переубедил себя, что 0xAA/0x55 лучше всего юзать в качестве начала пакета. и что я, осёл, когда-то по глупости сделал признаком начала 0xFF.

Ага, ща! Не нужно никаких 0xAA/0x55 и вообще ничего, кроме 0xFF не следует использовать. Т.к. на аппаратном уровне всем приемникам вполне достаточно одного (ну пусть даже через многа байт) перепада из 1 в 0 и обратно, чтобы подстроить свои часики. Это вполне обеспечивается последовательностью: стоп-бит, старт-бит, первый бит байта в единичке. Все, засинхронизировали частоты/фазы на много байт вперед.

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

Спасибо, я кончил)
источник

s

shadowsoul in Embedded Group
Ponytale 🇷🇺
оу. подумал и вспомнил. как-то в той беседе несколько недель назад все больше думал о синхронизации битрейтов и фаз приемо-передатчиков на физическом уровне - и почему-то переубедил себя, что 0xAA/0x55 лучше всего юзать в качестве начала пакета. и что я, осёл, когда-то по глупости сделал признаком начала 0xFF.

Ага, ща! Не нужно никаких 0xAA/0x55 и вообще ничего, кроме 0xFF не следует использовать. Т.к. на аппаратном уровне всем приемникам вполне достаточно одного (ну пусть даже через многа байт) перепада из 1 в 0 и обратно, чтобы подстроить свои часики. Это вполне обеспечивается последовательностью: стоп-бит, старт-бит, первый бит байта в единичке. Все, засинхронизировали частоты/фазы на много байт вперед.

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

Спасибо, я кончил)
если это не хуйня при запуске той стороны прилетела...
источник

s

shadowsoul in Embedded Group
при ините перефуррии
источник

P

Ponytale 🇷🇺 in Embedded Group
shadowsoul
если это не хуйня при запуске той стороны прилетела...
так в том то и смысл. хуйня с той стороны прилетает неизбежно. на самом деле если глянуть насколько часто самописные терминалы начинают вместо осмысленных символов гнать пургу в приеме...

так вот: этот первый дефектный пакет, начатый не с начального символа, т.к. приемник еще не засинхронизировался с передатчиком не пройдет по CRC. Но первый же встретившийся символ 0xFF (а посылки идут одна за другой и он в начале каждой) все железно засинхронит, и даже протокол поймет что начался пакет. С этого момента - стабильность 👌
источник

s

shadowsoul in Embedded Group
я сейчас с ecc на нанде мучаюсь и уже нервно от осмысления любой коррекции)
источник

P

Ponytale 🇷🇺 in Embedded Group
а что там за коды коррекции?
источник

s

shadowsoul in Embedded Group
BCH, но пидарасы лютые
источник

P

Ponytale 🇷🇺 in Embedded Group
binary coded hex?)
источник

s

shadowsoul in Embedded Group
не
источник