std

Не обходится. Стандарт CAN, 485 указывает и требует наличие общего провода. Стандартов выходило несколько. Для 485 нужны поздние стандарты TIA/EIA, в них это указано. В ранних нет. Для CAN нужны стандарты "физики" ISO 11898-2, ISO 11898-3, которые не являются частью спецификации BOSCH. Можно привести аргументацию а зачем изолированным трансиверам GND на ISOL стороне? или зачем трансиверам GND на входе? отладки с GND на клемниках, референс схемы на которых указан GND, спец.кабели с тремя проводниками, NMEA2000, земли дифсигналов USB/SATA/PCIE.. Но я попробую объяснить иначе. 485й - это дифференциальная передача, диф.сигналирование. По двум проводам работает, потому что входной дифф.усилитель как побочный эффект измеряет разницу уровней между двумя своими электрическими входами. Диф. сигналирования в данном случае нет, это всего лишь сигналирование положительным и отрицательным уровнем между входами, удвоенным по амплитуде. Диф. сигнал это два противофазных сигнала. Как два противофазных сигнала (два электрических тока) одновременно передаются по двум физическим проводникам? Одновременно два никак. Нужен третий общий проводник. Вот поэтому 485/422 без третьего проводника способен работать, но работает не в дифференциальном режиме. Отсюда возникают проблемы с помехозащищенностью, скоростью и прочие.

Как нет? А как в итоге в реальных условиях, на расстояние сигнал передаете? Корпус машины/заземление/экран?

Обратите внимание что у LTM2881 передатчик способен отключаться, т.е. он "бросает" линию. И это происходит в точности в конце передачи посылки, по-идее после стопового бита, но может быть всякое (баг управления на самом деле, не заметный до поры-до времени, пока A/Y был pullup, B/Z был pulldown или когда драйвер линии был другим, вариант - неверно заданный режим работы как 485). Однажды я использовал DSLogic для анализа происходящего на SPI у STM32. Очень удобный софт. Логический анализатор показывал мне нечто странное. Хотя, казалось бы, чисто цифровые сигналы, это ж SPI в чем проблема? И только подключив осциллограф я увидел вместо длинной полки сигнала нечто странное - цифровой сигнал эдак пи-и-и-у-и-ть, затянуто изменялся. А дело оказалось в том что SPI периферал STM32 после выдачи импульсов переводил выход в Z-состояние, т.е. передав пачку "бросал" выход. И на высокой скорости это работало, линия еще не успевала "уплыть". Решилось подтяжкой, конечно. Я эту тему увидел сразу же, но написать смог вот только сейчас. Так вам не кажется, что происходящее видно на экране? "Стоповый бит" это реальный бит, ему соответствует ПОЛНОЕ напряжение/ток линии. А у вас четко видно - после короткого импульса линия приняла среднее состояние, дрйвер "бросил" или "отпустил" линию. (Её уровень - не верхняя полка, не нижняя - как это было у предыдущих бит) На мой взгляд, неверное управление драйвером, баг. Который либо не был обнаружен, либо нивелировался A/Y-pullup и B/Z-pulldown резисторами на линии. Правильное подозрение. Только почему "интерпретируется", если осциллографом видно что это происходит на линии. Правильно решить проблему - управлением драйвером линии, временем отключения. "Закостылить" - подтяжками A/Y pullup, B/Z pulldown (ну или промерить лучше, что там в IDLE, а то бывает путаница с обозначениями), линия не будет отключена и не будет принимать неверное состояние. Проблема уйдет. P.S. Сегодня прочитал тему, уже поздно написал сообщение. Извините. Тут всё написали и вы сами всё уже сделали. Гипотеза: Поищите, не исключено что на передающей стороне одноплатника есть настройка режима работы передатчика: 422 и 485. Отличие может быть в том что для 485 после передачи передатчик отключается от линии, а в 422 возможно и нет.

"Полюсов" при циркулярном намагничивании нет. Иначе оно называется бесполюсное. Google: циркулярное намагничивание. циркулярное и полюсное намагничивание Часто это литература по магнитной дефектоскопии.

Быстрые итерации это лишь один из аспектов разработки ПО. Вы сильно ушли от темы, интересны все-таки архитектурные вопросы, проблемы из-за игнорирования архитектурных принципов и их решения. Советую глянуть The Progmatic programmers "Test-Driven Development for Embedded C" James W. Grenning. Это автор тестовых C фреймворков. ST HAL в своей идее зародился и поддерживается как слой для Demos & Examples, реализован малокомпетентным персоналом. Строки и сериализация? Вряд ли. (полагаю у вас Javascript прошлое и отсюда такие идеи). Самое простое для вас это ознакомиться с реализацией сообщений в WinAPI, AmigaOS или погуглить "osCreateMesgQueue". (чистый C).

Третий способ, вручную, без к-л. математики, анализа и прочего. Заработает везде и исправит любые искажения. 1. Вручную выставляем по клеточкам сетку вершин, для чего ваяем примитивный редактор, либо берем готовые софты. 2. Исходная картинка - текстура. Сетка вершин задана. 3. Софтварно текстурируем полигончики на экран в равномерную сетку. Опционально, можем гладить сетку вершин сплайном непосредственно во время движения по сетке. Произойдет (de)warping с вручную заданной картой варпа.

Мнение правильное. Встроенные механизмы вытесняющей многозадачности OS следует использовать только для системного уровня. Для меня хорошим примером всегда была оглядка на старших товарищей, например построение игровых систем инженерами Silicon Graphics для игровой консоли N64. Я не буду описывать её крайне интересную и последовательную архитектуру, отмечу лишь только что вместо примитивов синхронизации всегда используется Message Passing и вся многозадачность используется исключительно для системного или сопоставимого с системным уровня. Хотя это и возможно, но "бизнес" логика (она же игровая) или она же USER логика примитивы многозадачности OS целенаправленно не использует. Хотя внутри себя несомненно постоянно использует кооперативную многозадачность. Это называется не "асинхронность" для бедных, а кооперативная многозадачность. Подобную кооперативную многозадачность (кооперативную многопоточность) избегать не надо. Она отличается от примитивов многопоточности OS (которой, как раз, следует пользоваться только для системных задач). К коперативная многопоточность это очень, очень, очень часто используемый метод вычисления мелкими "квантами" с быстрым возвратом , избегать его никак не надо. Некая часть системы в результате работы может изменить своё состояние. И тот кто сверху это может увидеть и может изменить своё состояние. Которое на верхнем уровне логики может являться неким "супер-основным и глобальным". (Но об этом никто из модулей не знает и знать не должен). Почему так - потому что инкапсуляция (см. ниже) и никто о ком-то другом знать в принципе не должен. И тогда, раз состояние модуля изменилось и стало по факту иным, это будет обнаружено и в следующий раз будет отрабатывать уже иная сущность (поток исполнения будет мультиплексирован в другой "слот", будет "переключена" логика). Возможно, и оно тоже вернет своё новое состояние, и снова это будет обнаружено, и т.д. тем самым в будущем произойдет "цепочка действий". Состояние именно что прямое понятие определенных парадигм программирования. Например в функциональном программировании (ФП) как можно больше стремятся избегать понятия "состояние". Его, как раз, лишены так называемые "чистые функции" (pure functions). В том смысле что код у функциональщиков должен работать так - сколько бы его не запускал с одним и тем же параметром, он всегда вернет один и тот же результат (ну оно и понятно, т.к. состояние вообще нигде не сохраняется). Зато код должен быть парметризован или если можно на это посмотреть под таким углом - постоянно принимает состояние в качестве параметра извне (и нигде его не хранит). Ясное дело, это прямая противоположность ООП, где состояние повсеместно напрямую сохраняется в объектах. (Или модулях СИ). Отладка в ФП тем самым очень сильно упрощена, а системы в целом более предсказуемы и более легко проверяемы (одно из основных стремлений ФП к тому чтобы системы были вычислительно проверяемы, т.е. чтобы в принципе не было и не могло никак оказаться неких непроверяемых состояний системы). И еще о состояниях в ООП или простом процедурном программировании. Одна из рекомендаций - не "размазывать" состояние по всему коду и модулям. Размазывать состояние системы вообще сильно чревато. Тем более, по выделенной malloc-памяти и переменным. К сожалению, концентрация состояния в одной единственной структурированной композитной переменной, пусть модули даже и никогда не имеют доступа к ней ко всей зачастую противоречит принципу инкапсуляции, т.е. сокрытия у себя своего собственного состояния. Поэтому я лично постоянно балансирую между инкапсуляцией и концентрацией всего в одном месте в одной комплексной структуре. И то и другое обладает своей собственной красотой. Задачи инкапсуляции решаются через указатели, тем более анонимные. Эта проблема понятна, давно известна и ее единственно верное решение тоже давно известно. Никакой модуль системы никогда не должен знать о других. Точка. В рамочку - и на стену. 🙂 (шучу) Т.е. все модули должны быть всегда строго изолированы (разделены) друг от друга. Думайте при построении системы о микросхемах. Стройте систему также, как строится система из микросхем (или на более высоком уровне из плат, из модулей, блоков, стоек). Разве какая-либо микросхема внутри себя как-то учитывает другие? Нет конечно. Еще, микросхема хоть и может содержать внутри себя массу состояний, но никто изменить извне их может. Микросхема - "закрыта в корпусе". Это и есть инкапсуляция. В т.ч. (очевидно) и её состояния. Еще, инкапсуляцию можно интерпретировать как "пиши код модуля так, чтобы модулей можно было легко и безболезненно сделать N раз". И при этом ничто бы не изменилось и не сломалось. Понятно что при таком подходе никакого "я сам произвольно вызываю кого-то или меняю чужое состояние" быть не может. Ибо это свяжет модули, пристегнув к модулю допустим некий глобальный, куда он лезет и меняет его состояние вместо того чтобы изменить только своё состояние. Такого быть не должно. На самом деле у полного разделения и изоляции существует масса достоинств, одно из которых - тестируемость модуля. Для этого никакой взаимной связки конечно быть не должно. Вообще, стоит вплотную подойти к TDD (Test Driven Development). Следование этой парадигме само по себе сильно поменяет подход и таких вопросов как в этой сообщении не возникнет. К большому сожалению я бы хотел видеть книги по TDD электроники вообще, включая Embedded программирование, а то попавшаяся мне книга TDD по Embedded к сожалению оказалась о embedded software. Это всё сильно упрощено. Существует масса вещей (действующих и в C и при желании хоть в ASM) которые полезно учитывать чтобы проектировать системы адекватно и не мучаться вопросами странности происходящего: Inversion of Control, Dependency Injection, SOLID. Обычно эти вещи ошибочно атрибутируют к ООП и обходят стороной, но это не более чем принципы разбиения софта и построения его архитектуры. И они не софтовые на самом деле. Софт-архитекторы сами того не зная переизобрели то, что давным-давно само-собой работает в электронике. Всё описано выше. Ни голова о ногах знать не должна, ни ноги о голове. Но вообще, дополнительно полезно знать о некоем глобальном принципе "ожидание". Принцип готовности. Всё это снова можно подсмотреть на микрухах. Некто может захотеть дать команду. Но ждет пока что-либо придет в известное состояние. Исполнитель, соответственно, тупо игнорирует команду если не готов. Считается что это личные проблемы того кто дал команду/сигнал не проверив состояние (по крайней мере микрухи именно так себя и ведут) . Также полезно знать о таком паттерне как очередь команд (Command List). Они бывают вполне себе хардварные. А там среди команд может быть ожидание (WAIT). Отображение данных, серечь GUI нормально ложится и на кресты и на си. Возможно, будет полезно изучить принцип сообщений (message). Не OS примитивы. Пойдет вместо системы event'ов. Кроме того, messages (с очередями сообщений) - архитектурное решение для асинхронщины вообще, советую присмотреться, авось избавит от головняков events. Самопальную очередь и свои сообщения в виде структур. И обработку сообщений из очереди. Но без конкретики, исходя из общих слов можно говорить ни о чем бесконечно. Сериализация в целом это тривиальная вещь, ничто не мешает не заниматься синтаксическим сахаром который якобы обеспечит какое-то мифическое удобство и всегда писать serialize() руками. Вообще, действует принцип (один из принципов Python) явное лучше скрытого. Тут возможны и совсем другие решения. Например БЛ с её потенциальной сериализацией вполе возможно скриптовать. Всё очень сильно зависит от того какие данные и сколько их. Но вот с адресами (никакими) работать вручную точно не надо. Как вариант - это избегается подходом авто-инкремента адреса (он же квази-"стек").

Дисторсия от "Distortion", искажение. Distorted - искаженный. 1. Возможно идеальное решение методом цифровой бработки сигнала и цифровой 2D фильтрации. С изучением исходной системы единичными функциями Дирака, сверткой, и получением полного отклика. Подготовкой требуемой матрицы 2D фильтра, и далее в каждом кадре покадровой быстрой сверткой. Но для микроконтроллеров это вычислительно слишком сложно. Поэтому обсуждать это далее бессмысленно. 2. Brown–Conrady, а лучше Division Model. Идём сюда https://en.wikipedia.org/wiki/Distortion_(optics)#Software_correction Далее смотрим на формулу в статье Wikipedia, сразу обращая внимание что в большинссве случаев мы имеем дело с радиальной дисторсией и "division model" (вторая ф-ла) более точна, её и советую использовать. Я это писал ~30лет назад и это работало, только оно не исправляло, а вносило искажения. Общая схема алгоритма такова: Используются 2шт. Двумерных буфера (двумерных [y][x] массива). В первом, назовем его Src[y][x], лежит исходная (искаженная) картинка. Во втором, назовем его Target[y][x] строится неискаженная (целевая) картинка. Попиксельно, в двух. вложенных циклах для каждой x,y координаты пиксели переносятся из Src в Target. Координаты пикселя Target[y][x] известны, т.к. алгоритм "бежит" по ним, тогда как Src-координаты, откуда для каждого Target-пикселя взять из Src - вычисляются. Это известно как reverse-transform. Как это указано формула для direct transform, она отыскивает выходные Target-координаты Xu, Yu для известных Xd, Yd Src-координат входного искаженного изображения. Такое пойдет только для первичного теста, так как если отыскивать координаты Target пикселей в итоге останутся дыры и дубликаты. Итоговое решение в том что мы вычисляем и программно записываем пары [Xu, Yu] и [Xd, Yd], с некоторым оверсэмплингом чтобы избежать дыр и потом чисто программно произведим реверс, чтобы для одной пары Target-координат отыскивалась одна пара Src-координат попутно программно устраняя дубликаты. Замечания по реализации. а) Xc,Yc можно принять в центр, т.е. 0,0 и отбросить. б) Координаты со знаком. Т.е. центру картинки соответствует [Xd=0, Yd=0]. Euclidian Distance r есть радиус, т.е. просто расстояние для текущего пикселя от центра картинки. в) Если есть желание зачем-то использовать не Division Model, а Brown-Conrady, то Коэффиценты Pn и члены соответствующие тангенциальной дисторсии можно попробовать отбросить, можно также попробовать отбросить все коэффициенты K2 и старше K2 (т.е. отбросить четвертые и более высокие степени), оставив для начала только вторые степени, т.е. r^2, это будет работать, тем более что для Division Model: Using this model, a single term is usually sufficient to model most cameras[9] г) Вычисленные кооординаты потребуется клиппировать. Примерный упрощенный псведо-код выполняющий direct transform коррекции дисторсии прямиком по упрощенной Division Model с single term. // K1 задано. for Yd = -1 to 1 with enough small step { for Xd = -1 to 1 with enough small step { r = sqrt(Xd*Xd + Yd*Yd); Xu = Xd / (1 + K1 * r*r); Yu = Yd / (1 + K1 * r*r); Xu_ClippedScaled = Clip( width * Xu, 0, width); Yu_ClippedScaled = Clip( height * Yu, 0, height); plot ( Xu_ClippedScaled, Yu_ClippedScaled, GetPixel(width * Xd, height * Yd) ); } } // вместо plot() вестимо StoreTableToMemory(....) . В конечном итоге для трансформации каждого кадра используется только очень быстрый код с вычисленной Transform-таблицей: Target[index] = Src[ TransformTable[index] ] . При этом таблица симметрична в квадрантах, т.е. сохранять можно всего один квадрант.

Есть фирменный J-link EDU V10.1 Rev. A LPC4322 На что можно перепрошить этот EDU? v11? J-Link PLUS?

Умеют KEIL и IAR. В STM32CubeIDE не нашел, View/Консоли не умеют. P.S. Предположение о том что "лень" неверно, вопрос я задавал в рабочей командировке. Отдал JetLink Flasher Pro, решив что удастся за полчаса перейти на запасной ST-Link. Естественно, я предпринял усилия, но ничего не добившись, посчитал что на форуме помогут. Ну-ну... Каждый раз, стоит только обратиться на форум за помощью, подтверждается закономерность, наблюдаемая с 95-го, еще когда был FIDO-поинтом: Лучше либо а) Решить вопрос самому б) Задать вопрос англоговорящим, так как они отвечают по существу. И только у нас просьба о помощи заканчивается чем угодно. Гипотезами о тебе, предположениями что тебе надо было сделать, неуместной иронией, стебом или высокомерием. До сих пор не знаю точно, что тому причиной, но это повторяется из раза в раз. Вместо технической конкретики вектор неизменно переносится на человека. Итог общения с соплеменниками в том что ты и помощи не получаешь и всякий раз выслушиваешь о себе бред.

Проблема довольно дурацкая, поэтому пишу ее в раздел "для начинающих". Возникла необходимость получить используя STLink/v2, ITM/SWO ( ITM_ReceiveChar(void) ) ввод командных строк, который ранее успешно работал через UART или используя Segger RTT. С выводом проблем нет, логгинг работает. Не могу найти где вводить строку в популярных IDE, например Atollic True Studio или STM32CubeIDE или какой инструментарий предназначен для этого.

Спасибо! Буду знать. Правда если я буду подсчитывать импульсы в прерывании (я же правильно понял что каждый импульс STEP - прерывание?), то прерывания в режиме микростеппинга 1/32...1/256 идут очень часто и будут все равно грузить процессор. А я хотел этого избежать, целиком полагаясь на аппаратуру таймера. Подсчитывать импульсы необходимо, поскольку в новом конструктиве хоть и будет угловой энкодер, часть старых конструкций в начале калибруется по оптическому датчику и затем поддерживает положение ротора ШД, полагаясь только на количество шагов.

Ну, в общем, всё перебором закончилось А вот это интересно. С таймерами STM32 я доселе дело имел поверхностно, сигнал генерировал, но без тщания. Количество импульсов сигнала STEP и управление "полками" было реализовано программно. Прерывание по таймеру, все остальное программно. ISR всегда приводило уровень на выходном порте в гарантированно известное состояние, так как недопустимо потерять пол-импульса (полку), а также необходимо останавливать двигатель строго в определенных фазах микростеппинга и на определенной полке. Хочется выдавать STEP полностью аппаратно. Иной кандидатуры кроме как аппаратный вывод таймера пока не усматриваю. В связи с чем и вопрос. Таймеры STM32 это целая вселенная. Тщательная вычитка документации, изучение либ типа Marlin сама по себе задача не на один день. Мне бы для экономии времени получить бы добрый совет, на каком именно типе таймера сосредоточиться, какие есть методы управления и подводные камни? Может быть на что-то глянуть, короче, нужна какая-то отправная точка с таймерами и предсказуемым управлением выходом таймера для того чтобы получать строго определенное колчество импульсов STEP ШД и приводить вывод в известное состояние.

У меня есть мно-о-о-ого что сказать насчет Ali :) © "Оставь надежды всяк сюда входящий". Это не "адекватный продавец" (все-таки мы очень наивные). Это их хитрая схема работы. Они высылают брак или подделку cознательно подмешивая на десяток нормальных 1-2 бракованных/поддельных позиции. Надежда у китайца на то, что покупатель по статистике не обратится. Доказательство - выше. Если обратится - то китаец вежливо извинится и заменит брак. Обращаются в арбитраж по статистике небольшой процент, поэтому бизнес цветет. Поразвлекаться можно тем что скармливать поиску image.google.com запросы "поддельные радиодетали али" или "поддельные конденсаторы", "поддельные <впишите сюда радиодеталь>". Вплоть до резисторов. После изучения в течении минут 20-30 придет полное понимание. Я долго ржал, наткнувшись (в картинках) на поддельные "керамические" конденсаторы с али. Если разломить - внутри SMD !!!

Цена в ST MCU Finder за 10 000 штук. За 1шт обычно в 2-3 раза дороже. Т.е. нормальная цена должна быть в пределах $6...