jcxz

......или точно такой же глаз смотрит в RM, видит там несуществующий в данном камне регистр периферии, и точно так же программирование много дней "идёт поперёк борозды", теряя дни... PS: Честно говоря мне кажется странной ситуация одновременного программирования двух разных прошивок. Обычно всё-таки: сперва пишется какой-то блок кода в одной прошивке; и потом переключаемся на другую, где так же пишем блок кода. И "блок" - это более-менее функционально законченный кусок кода. А не одна строчка. Я тоже писал две разные прошивки примерно в одно время. Или прошивку, которая будет компилироваться на разных МК. Но это было не в стиле: "написали строчку для одной прошивки, через минуту - для другой". Особенно - в части программирования железа (низкоуровневое). Да, бывает отладка протокольного взаимодействия двух ПО идёт подобным образом. Но к этому моменту всё железо уже проинициализировано и код работы с ним написан и отлажен (по отдельности). Смешивать разбирательство с низкоуровневой периферией и протокольную обработку - само по себе не гуд.

Хм, странно... А зачем тогда производят и используют (на всех энергоподстанциях) масляные выключатели? https://ru.wikipedia.org/wiki/Масляный_выключатель Одна из главных функций которых - гашение дуги при отключении нагрузки? А уж видосов с долго горящей дугой на всяких ЛЭП на ютубе - вагон. Напряжение там конечно повыше, но ток - переменный. И сама дуга гаснет, только после полного сгорания и испарения проводов.

Всё равно ничего не понятно.... Зачем миллион раз то хеш считать? Если хацкеры взломали ваш exe-шник, то чем это поможет??? Думаете, что хацкеры умрут со смеху, увидев расчёт хеша миллион раз? И это обезопасит вас от них? PS: Кроме того - надёжность такого вычисления крайне сомнительна сама по себе. Имхо - она по надёжности не должна превосходить надёжность однократного вычисления хеша. Так как - количество входных комбинаций данных это не увеличивает, то думаю можно построить функцию, которая даст результат, идентичный результату миллиона проходов SHA256, но за один проход. Т.е. - функция будет тратить те же самые 3-7 тыс.тактов на вычисление одного хеша в степени миллион. Как думаете - как можно ускорить алгоритм сложения числа X самого с собой миллион раз? Правильно - просто умножить его на миллион.

Дурацкая документация. Идея - лепить общий документ на совершенно разные чипы - сама по себе дурацкая. Представьте если бы какой-нить Бош выпустил суммарную документацию на свои пылесос+стиралку+мультиварку+утюг. И вы, среди режимов стирки белья, искали бы как сварить суп. Или гадали бы: этот пункт "слив воды" относится к стиралке или к мультиварке или к утюгу? ....или и к тому и к другому и к третьему, но не к четвёртому? В RM не должно быть разделов не относящихся к данному МК! Нажав кнопку "Документация" на сайте производителя на странице конкретного МК, пользователь должен получить документацию именно на этот МК, а не на какой-то другой. Вы видимо всегда работаете только с STM, поэтому видимо не подозреваете, что можно сделать по-другому, по-нормальному. В RM-ах NXP, TI, Infineon я что-то не припомню такого бардака как у STM. У Infineon МК линейки XMC4xxx по периферии очень похожи. Некоторая прям один-в-один совпадает. Но при этом Infineon не лепит их в один документ, а выпускает отдельно RM для XMC4500, отдельно - для XMC4700. Очень удобно. Зачем мне винегрет из кучи процессоров если я работаю с конкретным МК, а не со всем винегретом сразу? А TI так и ещё дальше пошёл: для линейки Tiva например - для каждого корпуса МК (каждой аббревиатуры маркировки) - отдельный документ (даташит+RM)! И не надо гадать - есть эта функция в твоём МК или нет? Всё что описано - есть. PS: Да - и ранее (для линейки F4xx) в RM STM, хоть и лепил уже вместе винегрет из разных МК, но по крайней мере в заголовке описания каждой периферии указывалось к каким именно МК этот раздел имеет отношение: Сейчас получается даже такого не делают..... Почему я и ошибся с H743, потому как по привычке глянул в заголовок раздела HASH RM и не увидел там замечания об ограничениях на разные чипы линейки.

А, ясно блин - уродская документация STM... Я скачал и просмотрел RM и errata для H743. Там ни слова не сказано, что HASH-а нет и в помине. Но пишут про него (как будто он есть). К стенке нужно ставить за такую документацию....

Почему? Вроде в errata ничего нет про неработающий HASH.... Он что по факту - не работает? В какой-то конкретной вашей ревизии чипа или во всех? И честно говоря - я так до сих пор и не понял смысла вашей темы... Человек знает зашифрованное сообщение и результат его расшифровки? И хочет угадать пароль, которым шифровали? Но какое отношение длительность вычисления хеша от 8-байтной строки имеет к длительности решения этой задачи??? Что мешает вам дополнить эту 8-байтную строку слева или справа константой любой желаемой длины (которую угадыватель не знает) и считать хеш от этого суммарного массива? И тогда угадывателю нужно будет перебирать не все значения вашей ASCII-строки, а все значения SHA256. Что он будет делать до морковкина заговення даже имея миллион видеокарт. PS: Также я не понял - на кой вы, для генерации ключа AES из пароля, считаете миллион раз SHA256? Почему его нельзя посчитать один раз от "пароль+фиксированная_случайная_константа"? Ведь это будет в ~миллион раз быстрее, а не 6 секунд.

У меня: #define PIN_LED A, 3 ... Pclr(PIN_LED); Pset(PIN_LED); И работает без всяких классов и шаблонов. Чисто на одних макросах. Только скромно забыли упомянуть, что метод типа: компактным "сворачиваясь в пределе до одной ассемблерной инструкции" видимо может быть только при максимальной оптимизации. А если хотя-бы стоит "средняя" оптимизация, то результат будет ОЧЕНЬ далёк от одной инструкции. Скорее всего породит функцию. И вызывающая функция тоже утяжелится. А вот при макросе - функции не будет даже при полностью выключенной оптимизации.

Не забудьте только предварительно завещание написать.

А почему так медленно? Получается: 480e6*6/1e6 = ~2880 тактов на 1 хеш. Вроде по документации заявлено, что должно быть ~66 тактов на 512бит. Т.е. - должно быть в ~43 раза быстрее. Даже на моём XMC4500, не имеющем аппаратного вычислителя хеша, расчёт SHA256 от 128 бит данных занимает ~6548 тактов (без особой оптимизации). В вашем же МК есть аппаратный вычислитель. Неужто он так медленно работает??? PS: Или вы программно считаете? Но - зачем??? На МК, имеющем аппаратный вычислитель....

"ребёнок, небоскрёб" - не особо актуальны для нашего форума. А вот когда фильтр решит идти в ногу со временем и начнёт банить "master-slave" или "папа-мама" (для разъёмов) - вот тогда будет реальный ахтунг.

Открыть мануал на контроллер; прочитать раздел про EEPROM; проинициализировать её регистры конфигурации нужными значениями. После этого можно её читать/писать. Также проверить, что секция ".eeprom" ложится по физическим адресам EEPROM вашего МК.

Если "дёшево и сердито" и надёжно при этом (с защитой от бабаха), то: Поставьте возле батареи большой разъём. "Маму". 8 контактов. Подключите к его контактам 1...6 ваши 6 концов батарей. И сделайте два замыкателя "папы". У одного замыкателя соедините: 2-4; 3-5; 6-7; 1-8. У другого замыкателя соедините: 1-4-5-8; 2-3-6-7. Дальше просто воткнули один замыкатель или воткнули другой. Два одновременно воткнуть невозможно. Разъёмы можно взять любые на большой ток. Нагрузка подключается к 7:8. Без всяких дидов Шоттки, хитрых реле и пр. тряхомудрии. Кондово и надёжно.

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

Почему через 3-5 лет? Насколько помню из своего студенчества - устроиться на инженерскую ставку можно было уже после окончания 3-го курса. Причём - в гос.контору (т.е. - законно, по бумажкам). А судя по тематике "диплома" ТС-а - это уже как минимум 3-й курс. А если к тому-же это заочник, то он уже работает в какой-то конторе. И видимо хочет перепрыгнуть с нынешнего оклада какого-нибудь техника, на инженерский оклад. Даже не шевельнув извилинами. Так что если заочник - самое большее через несколько дней уже побежит в отдел кадров переоформляться. И может даже - на начальническую должность. И будет уже с полным правом рукамиводить другими инженерами уже через пару недель. Чего некоторые тут боятся.

Да - речь именно о д.Холла. Что существуют другие типы датчиков углового положения - я знаю и использую их. А насчёт тепла/холода и т.п. - думаете ваши магнитные энкодеры к ним не чувствительны? Если уж ожидаете, что перепады температур настолько велики, что влияют на внутренние д.Холла, так они точно так же будут влиять и на внешние датчики углового положения. И кстати (насколько мне известно) - аналоговые д.Холла (которые скорее всего стоят в ваших магнитных энкодерах) - они как раз очень чувствительны к изменению температуры. Если только в них не встроена какая-то компенсация. И как выше уже писал - разброс значений длительностей от минимума до максимума, который я наблюдаю на своём моторе - превышает 35% (даже доходил до 40%!). Чтобы причиной такого разброса была температура, мой привод должен телепортироваться с Плутона на Венеру и обратно. Вибрация тоже отсутствует - двигатель надёжно закреплён, а на роторе нет никакого дополнительного веса - соответственно нет эксцентриситета и болтанки из-за него. И двигатель новый - не разболтан, не изношен. К тому-же Вы пишете: "поставили 2 энкодера на один двигатель". У меня в устройстве всего 5 моторов. Т.е. - довольно много нужно датчиков. И моторы эти кстати - без валов. У них ротор (который вращается) - внешний корпус. Там не так просто закрепить датчик углового положения. Хотя это конечно вообще не относится к теме. У нас планируются исполнения как с внешними датчиками углового положения (только синус-косинусными) так и со встроенными д.Холла (более дешёвый вариант). Вот для 2-го варианта и хочется улучшить качество работы. При замене двигателя, скорей всего всё равно нужна будет настройка параметров (под новый двигатель). А калибровку у меня выполняет прошивка самого инвертора. Нужно только обеспечить холостой ход (отсутствие нагрузки на роторе) и дать команду калибровки. И подождать несколько секунд. Да и без этой калибровки он тоже будет работать. Просто КПД будет немного ниже и шум больше. Пока нормального стенда нет - мотор просто закреплён на столе, без возможности дать равномерную нагрузку на ротор. Когда стенд будет - попробую. Но даже сейчас я для тестового вращения устанавливаю минимальный уровень ШИМ-а, при котором ротор ещё вращается без пропусков эл.оборотов. А так как скорость вращения довольно высока (частота вращения поля = 40 Гц; соответственно механическая частота вращения = 40/14 = почти 3 об/сек) при предельно низком поле, то инерция даже пустого ротора должна более-менее сглаживать толчки.

BusFault в Cortex-M - это не прерывание, а исключение. Соответственно запрет прерываний влиять на него никак не может. И при запрете какого-либо fault-а (если его возможно запретить), согласно идеологии Cortex-M, должна выполниться эскалация до HardFault. Так что - fault-а не избежать, если уж подсистема памяти решила сгенерить ошибку. Да и причём тут прерывания или fault-ы? ТС ведь нужны не прерывания, а возможность прочитать память.

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

Ну так - с помощью виртуальных функций. Которые в конце имеют =0; (забыл как называются). Если они вам не нужны, так и чего страшного? - никакой таблицы виртуальных методов и не будет раз ни один объект не будет создан.

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

Сколько пробовал я моторов - везде неравномерность была такая, что алгоритм работал 100%-но чётко. Ни одного сбоя. Вот например делаю калибровку - сейчас кручу мотор равномерно, без ОС (просто синусом), без нагрузки на роторе с минимальным током при котором он ещё крутится (чтобы равномерно, без шажков): На участке "HALL 000 ... HALL 119" выполняется до 120 калибровочных электрических оборотов (из расчёта максимального возможного числа пар полюсов <=60) и измеряются неравномерности сигналов д.Холла. Каждый эл.оборот - 6 значений. Где каждое значение - это величина отклонения момента изменения фазы д.Холла в ту или иную сторону. Или в большую (>1.0) или в меньшую (<1.0). В конце дампа, по полученному дампу отклонений, алгоритм вычисляет число пар полюсов мотора (14 в данном случае). А затем запускается алгоритм поиска текущего положения ротора. И в сообщении "rK ..." печатается текущее найденное положение (номер эл.оборота внутри мех.оборота) и рассчитанная величина вероятности правильного вычисления. Как видно - вероятность растёт с числом оборотов (при равномерном вращении) и когда превышает некоторый порог - положение считается найденным. Эта табличка запоминается в энергонезависимой памяти и потом, при каждом старте, алгоритм запускается и ищет положение. Да по этому дампу даже на глаз видно - сколько пар полюсов у мотора. Неравномерность достаточная и повторяемая. И какие я бы моторы не смотрел - везде неравномерность была чётко видна. И повторялась от мех.оборота к мех.обороту. Это да - чтобы узнать, надо провернуть хоть немного. Но например если применение - улучшение качества управления, за счёт увеличения точности определения угла - этого вполне достаточно. Как видно по дампу - разброс значений д.Холла от самого минимального до максимального - составляет более 35%! Из-за этого точность векторного управления сильно страдает. А применив корректировку по такой таблице, можно существенно повысить КПД привода.

Нет. Я же написал: речь об абсолютном угле, а не относительном. Т.е. - не зависимом от момента старта ПО устройства и т.п. Скажем: угол ротора ==153.4° в данной позиции вала. Который всегда должен давать 153.4° именно в этой позиции и ни в какой другой. Нет - без дополнительных датчиков углового положения! Только по данным д.Холла на магнитах ротора. Возможно. И оно реализовано и работает. Просто мне кажется такой способ очевидным. Для тех кто много работал с реальными д.Холла. Не мне одному. И чую, что должны быть реализации. Но вдруг реально - открытие и хау ноу? Не нашёл в сети и ИИ похоже ничего не знает. Или придуривается.

И о чём вы беспокоитесь? Стирательного ресурса одной страницы хватит на: 68*5*10000/24/365 = ~388 лет непрерывной работы. Неужто этого вам мало???

Вообще-то это как раз - реализованное. Реализованные баги. Мимо кассы.

Но комментарии к исходникам - это же внутренняя документация? для коллег. А с ней ситуация точно такая же. Люди же не меняют мозг, когда изучают мануал или исходники - действуют точно так же. Так что - без разницы.

Не только это. Как показывает опыт - сейчас люди не читают даже документацию к реализованному пути разработки. Или комментарии к исходникам. Если они более одной строчки. Что уж говорить о нереализованных путях или невыстреливших идеях. Клиповое мышление. Вот скажем - много ли здесь участников, кто полностью прочитал мануал на свой микроконтроллер или используемые чипы? От корки до корки? есть хоть один?? А теперь представьте - если бы разработчики вашего микроконтроллера впендюрили в мануал не только реализованное, но и все забракованные решения? Представили? Скажем писали бы: Регистр статуса UART реализован так то, но так же был вариант сделать его ещё так-то (вариант_1) и так-то (вариант_2), но не сделали потому-то и потому-то. И так про каждый узел МК. Когда я изучал си++ (много лет назад), то у меня было два учебника: Первый толстый (сантиметров 5 книга в твёрдом переплёте) и дорогой. С кучей воды и лирических отступлений. И была вторая - тонкая синяя книжица, где были даны только сухие факты только касающиеся предмета. И причём - полезной инфы она содержала раза в 2-3 больше чем первая. И изучать по первой было совершенно невозможно. Тонул в море ненужной инфы и лирических отступлений. Зато вторая - просто на ура. PS: Слышал умную мысль: Если раньше (в предыдущие века) человек сталкивался с недостатком информации (и усилия мозга направлялись на максимальный сбор и накопление максимального количества информации), то нынче люди живут в условиях переизбытка информации (и усилия мозга больше тратятся уже на отсеивание океана ненужной инфы, чем на поиск дополнительной инфы).