jcxz

Пришлось довольно много поработать с д.Холла в качестве датчиков положения ротора в PMSM-/BLDC-электродвигателях. Понимаю как их использовать для управления э/двигателями с ОС. И как повысить точность такого управления, расчётом промежуточных углов с помощью таймера и знания текущей скорости. Тема не об этом. Но вот если возникает необходимость знания не только электрического угла, но и механического, а других датчиков, кроме д.Холла в системе нет? Использует ли кто-либо где-либо д.Холла для определения правильного механического угла положения ротора э/двигателя? Речь о тех д.Холла, которые реагируют на поле магнитов ротора. Т.е. - изменяют своё состояние 6 раз на один электрический оборот. Как-то (несколько лет назад) в одном из проектов на д.Холла, я реализовал такой алгоритм. Вычисления механического угла на основании исключительно данных д.Холла встроенных в двигатель. Придумал и реализовал это сам. А не потому, что где-то в сети нашёл информацию о таком способе. Но вот берут сомнения - неужто кто-то где-то ранее уже не додумался до такого? Может кто-то слышал о подобных алгоритмах? И даст ссыль? Так как подозреваю, что скорее всего изобрёл велосипед. PS: Пытал чатГПТ на эту тему, но ничего путного от него добиться не удалось. Он строит из себя дурачка. PPS: Да - речь об абсолютном механическом угле. А не относительном. Т.е. - таком, который неизменен от одного запуска двигателя к другому.

У меня нет ответа на этот вопрос. Да, думаю, что простого решения в этом вопросе и не существует. Волшебной пилюли. К сожалению. Но я много раз замечал, что работать под руководством начальника, разбирающегося в тематике (хоть немного) - гораздо приятнее. И эффективнее. И результат лучше и быстрее получается. PS: Может издать какой-то указ , что на должности руководителей разработчиками, допустимо назначать только людей, которые ранее сами хоть немного поработали разработчиками? А не чистых рукамиводителей? Может тогда и все эти скрамы будут не так нужны? PPS: На исключительную истину не претендую.

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

Если это не применяете лично вы, то из этого не нужно делать выводы, что не применяет никто.

Да, он привёл неудачный пример. Может он не совсем понял о чём речь?

Указатели на члены класса - это то же, что обычные указатели, но в адресном пространстве класса (если таковое представить). У вас же не возникает вопросов в нужности обычных указателей? Вот теперь представьте такой же случай, в котором нужны обычные указатели, но происходит это в адресном пространстве класса. Именно так.

Именно так. Объединить в массив, кэп. Но можно и через указатели на члены. Если хочется.

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

Вы издеваетесь?? Объединить в массив - это вы предложили. Я же уже 100500 раз сказал что: не всегда можно обрабатываемые однотипно данные объединить в массив. И конкретные примеры привёл. НЕТ ИНДЕКСОВ. нет массива членов == нет индексов. Члены - несмежные. Уже несколько примеров привёл. Это ж как можно их не заметить??? PS: Всё ясно. "Чукча не читатель - чукча писатель".

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

Начните уже думать наконец! Если есть члены класса: x1, x2, x3, x4, x5, x6, x7, x8, x9. Но цикл должен пройтись только по: x1, x3, x5, x9? Как их объединить в массив? А если часть этих членов - унаследована от родителя? Как их объединить в массив?

Вы похоже и сами думать не хотите, и читать не желаете. Даже много раз повторенное:

Я вроде написал в самом начале: Если нужно однотипно (например - в цикле) обработать несколько логически не связанных и не смежных член-данных. Второе применение: нужно сослаться на член из const-массива.

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

Неудачный пример. Так как здесь все переменные - логически связаны, расположены рядом и поэтому - ничто не мешает заменить их массивом и проходить циклом по нему. Указатели на члены тут как раз не нужны. Такой пример - это довод как раз против использования указателей на члены. Я же не зря уточнял: И что же посоветует нам гуру "правильного" программирования для такого случая (когда нужно однотипно обработать несколько членов класса)? Как задать такой список? (члены логчически не связаны и расположены не рядом). PS: Если что-то критикуешь, то нормальным вроде является предложить альтернативу?

Видимо речь шла о молнии. Может и поболее 40А быть.

Странный вопрос... Например - если имеется много переменных-членов, которые сами по себе независимы (логически), но в какой-то момент их нужно обработать однотипно, все сразу. Как быть в этом случае? Самое логичное и оптимальное: создать массив указателей на члены класса и с помощью него обработать. Например: В классе есть много разных указателей на объекты, созданные в динамической памяти (простые, без деструкторов). В деструкторе класса их нужно удалить. Вот с помощью массива указателей на члены класса это сделать удобно и оптимально. Другой вариант: На вход некоторой член-функции класса нужно подать const-массив, описывающий способ обработки чего-то. В этом массиве нужно сослаться на какие-то член-данные или методы класса. Здесь тоже нужны указатели на члены класса.

Зачем все эти мучения??? Вы же (как говорите) умеете самостоятельно работать с периферией. Без Калов. Так и работайте. Кал - он для тех, кто самостоятельно не умеет.

Вам уже и написали выше про наиболее вероятную причину - зачем нужна эта задержка: но вы ведь всё равно не поняли. Предпочитаете пинать колёса, а не вникать. Как только какой-то код, не важно где откопанный, вы влепили в свой проект, он стал вашим кодом. Когда ваше устройство вдруг перестаёт работать, вы тоже заказчику говорите: "Это проблема не у меня, а в той либе, которую я влепил в свой проект. А я не при делах." Так?

Я ТС-у об этом писал в другой теме. Только думаю, что он всё равно ничего не понял. Так как не знает и не желает знать - что делает какая часть его же кода.

Почему любите? боитесь что иначе скрытые баги полезут? Вот например такая ситуация: Есть две задачи ОС. Стартуют выполнение одновременно (от какого-то события), потом выполняются паралельно, независимо. Задача1 - вычисляет какие-то данные, а задача2 должна эти данные забирать. По уму - задача2 должна ждать пока задача1 не подготовит данные. Но программист забыл сделать эту синхронизацию. И так случилось, что задача1 всегда выполняется немного быстрее, поэтому успевает подготовить и записать данные до того, как их начнёт читать задача2. Баг несомненно есть. Но он не проявляется до поры до времени. И проявиться может очень не скоро (когда по каким-то причинам время работы задачи1 немного увеличится). Когда программист уже забудет что и как он здесь писал, и заниматься будет совсем другой частью кода. И найти такой баг будет непросто. А вот если бы программист по всякому перетряхивал свой код, заставлял его выполняться с разными времянками, с разным распределением памяти - то баг мог вылезти сразу. Ну и само собой - баги с порчей памяти (всякие переполнения стека и других массивов) они выявляются тем быстрее, чем чаще перемешиваешь код.

Да, бес попутал - по памяти писал. Для LoRa там всего 37.5 кбит/с максимум

Что-ж вы SEMTECH то не предупредили! А то они не знали этого и сделали свои SX1276 и SX1279 со скоростью 500 кбит/с в LoRa-режиме. Причём - в субгигагерцовом диапазоне.

Чем оно лучше простой ОЗУ? Зачем именно BKP? BKP только хуже простой ОЗУ. Так как в МК ТС-а (который нам не известен) доступ к регистрам BKP может быть многократно медленнее, чем к обычной ОЗУ. А значит - вносить задержки в отлаживаемый код. И значительно изменить поведение программы с отладкой и без. А при отладке важно, чтобы отладочные вставки минимально влияли на отлаживаемый код.

И как они помогут? PS: Ещё можно перекреститься перед отладкой и код перекрестить. Польза для отладки примерно такая же.