controller_m30

У меня ссылка не открывается, к сожалению (пишет у меня какой-то не тот доступ, или авторизация, хз). Но я записал своё видео, и фотку прилагаю. Пардон за не наилучшее качество видео, давно не записывал и разучился пользоваться фотоаппаратом. Но все главные моменты, по моему, там видны. Средняя скорость (Youtube) Малая скорость (Youtube) и фото всей схемы (за кадром остался ST_Link, от которого сверху тянутся провода) На средней скорости всё вроде-бы гладко. На малой скорости, там где видны магниты - заметно что они двигаются как-то рывками, не абсолютно равномерно. И на малой скорости обмотки греются гораздо сильнее, чем на средней. На ощупь, эдак, градусов 50-60. На средней может держать 40 градусов минут 5. А на малой буквально за минуту набирает 50-60 градусов.

Да-да, без редуктора. Только двигатели. Хитрость в том, что камера изначально уравновешена по осям всех трёх двигателей, и для её наклона или удержания не требуется больших усилий. Насколько можно верить китайцам, у них есть и новые. На Али можно много чего найти. Но фирменные ли они? Или действительно новые, а не с разборки? Но есть ещё вариант обратиться в сервисный центр, лучше авторизованный, там точно есть.

Немного про движки для Gimbal-стабилизаторов. В профессиональном Gimbal-стабилизаторе камеры для квадрокоптера, применяются BLDC-движки с навороченным шлейфом. Можно предположить что 5 тонких дорожек, это сигналы от трёх датчиков Холла, и питание к ним. Ссылка на движки Aliexpress

Датчиков тока и положения нет, только стандартная схема включения драйвера. Программа на Ассемблере, под этот конкретный процессор. Увы. Да и работать будет только с DRV8313. Но текст прикрепил, из полезного там есть таблица (хотя бы для первоначального тестирования может сгодиться). Видео не записывал. В Ютубе можно найти видео с совершенно плавной работой движков BLDC, а тут с рывками - это не интересно) BLDC_Asm_STM32F103.txt

Делал плавное управление BLDC мотором, от 0 Hz. Для хоббийной модели. Компоненты использовал такие: DRV8313 - драйвер мотора, с Aliexpress. STM32F103 - платка разработки (типа Arduino) из ближайшего радиомагазина. И, повышающий преобразователь до 12в, т.к. DRV8313 работает начиная от 8в и выше. Мотор как на картинке. МК использует таймер, с трёхканальным модулем сравнения, для генерации ШИМ. В памяти таблица синуса на 256 байт, скачанная откуда-то из инета, и программа просто движется по таблице, используя три указателя, отстоящие друг от друга на 1/3 размера таблицы. В DRV8313 сигнал заводится так, как это приведено в даташите на микросхему. Крутит от 0 до нескольких десятков оборотов в секунду. Можно управлять положением ротора как будто это шаговый двигатель. Недостатки. Обмотки ощутимо греются, возможно надо экспериментировать с ограничением тока, или рабочим напряжением. При полном проходе таблицы синуса движок делает небольшой рывок. Это заметно при сверхнизкой скорости вращения. В приведенном двигателе 12 катушек, и таблица позволяет плавно переместить ротор от одной катушки к другой. Всего на оборот получается 12 рывков. В чём причина пока не разбирался. Может скачанная таблица кривая, или я ею неправильно пользуюсь (например указатели должны отстоять точно на 1/3 длины таблицы друг от друга, а у меня таблица 256 байт, которая на 3 не делится).

С китайскими устройствами часто идут некачественные USB-кабели. 1. Попробуйте применить другой кабель USB. Судя по фото отладчика в инете, используется USB Type B. Такие кабели обычно применяются в принтерах. Займите этих кабелей несколько штук на время, и испытайте все. (некачественный кабель может плохо экранировать линии данных, или нестабильно питать отладчик, что, допустим, может проявляться на высокой скорости программирования) 2. Для связи с отладчиком, попробуйте другие USB-разъёмы на компьютере (может быть обычный износ). Если используете разъём USB 3.0 то попробуйте USB 2.0, и наоборот (у 3.0 и 2.0 разная нагрузочная способность для питания внешних устройств). Также не все устройства могут работать с USB 3.0 шиной, но с 2.0 работают нормально. 3. Если программируете со стационарного компьютера, попробуйте с ноута, и наоборот. (у ноутов и стационарных компов разная наводка помех на USB-периферию) 4. Попробуйте отключить от остальных разъёмов USB все лишние устройства (особенно с длинными проводами), и программировать своё устройство с "свободного" от проводов компьютера. (лишние провода могут создавать наводки, которые будут замедлять обмен данными) По поводу микросхем QSPI. Прозвонить обе микросхемы на предмет пробоя защитных диодов сигнальных пинов на ножки GND и VCC. Бывает защитный диод пробит не полностью, и таким образом создаёт постоянную "подтяжку" линии данных к GND или VCC, что замедляет формирование логического уровня на высокой скорости. Прозванивать все ножки относительно пина GND в прямом и обратном направлении (на МегаОмах). И тоже самое относительно пина VCC в прямом и обратном направлении. И сравнить данные для обеих микросхем.

Просто любая микросхема зарядки Li-Ion, настроенная на ток заряда 100mA (как выше сказали, USB без энумерации всё равно больше 100mA не отдаст). Без нагрузки будет заряжать, потребляя от USB <=100mA. И с нагрузкой будет потреблять от USB <=100mA, поскольку настроена на такой ток. Поэтому можно больше ничего не городить. Если же нужно зачем-то обязательно отключить зарядку на время нагрузки, то моё предложение токовый датчик, типа ACS712 и компаратор. Но МС зарядки должна быть с входом разрешения/запрета работы. Или может механически разрывать цепь питания от USB, с помощью реле - например если нагрузка индуктивная, и может навести помехи на цепи ПК.

Есть такие переходники для программирования ESP32: один, два.

Полагаю у светодиода нет существенной ёмкости (кроме десятка пикофарад). Обоснование. 1. Любая ёмкость имеет время заряда и разряда. Чем больше ёмкость, тем больше это время. Если бы у светодиодов была какая-то существенная ёмкость, то их было бы проблематично использовать в стробоскопичесом режиме, например для динамической индикации в световых табло. Светодиод долго и постепенно загорался бы, и так же долго и постепенно угасал. 2. Предполагаемый мощный пусковой импульс при включении светодиода, должен иметь и обратную сторону - разряд этой ёмкости при выключении, обратно в питающую схему. Вроде бы такой эффект в схемах не наблюдается.

Вопросы: 1. А по какой причине два сервера путают очерёдность временных меток? И насколько может запоздать любая метка от её истинной очерёдности (на 10, 100, 1000 мест в очереди)? 2. Массивы имеют фиксированную длину (напр. точно 1Мб), или заканчиваются на границе суточного перехода (с 23.59 на 0.00)? Во втором случае массивы на двух серверах будут иметь разную длину, из-за случайного положения завершающей временной метки. А КС двух таких массивов не совпадёт никогда. Если массивы фиксированной длины, то на границе массивов путаница очереди меток снова спутает всё. Например, границы двух массивов: Первый сервер: [...1,2,3,4]_______[5,6,7,8...] Второй сервер: [...3,4,5,6]_______[1,2,7,8...] И тоже получается несовпадение КС массивов, независимо от способа расчёта.

Гипотеза, почему могут отличаться программы с переменными типа volatile и переменными обычными, статья. Если смотреть на листинги, в той части где происходит отправка команды 0 на карту - так программы абсолютно одинаковые! Но, зная что программы одинаковые, и сравнивая осциллограммы - появляется мысль, что по программе с обычной переменной таки "прошёлся" оптимизатор. Почему этого не видно на листингах? Возможно потому, что в листингах приведен дизассемблер исходной программы на С, а не итогового машинного кода, который заливается в контроллер. Это только гипотеза, но в контексте приведенной статьи, мне она кажется очень вероятной.

Ещё варианты: 1. Добавить в конец программы какую-то команду, как в рабочем примере (в той программе после CS_HIGH есть ещё пара строк работы со светодиодом). Например, после CS_HIGH добавить ещё 2-3 команды записи байта - пусть их будет не 6 а 9. Посмотреть что будет с задержкой после 6-й команды. 2. В рабочем примере, в конце текста есть ещё команда Return 0 и кавычка - а есть ли они в переработанном варианте? Может это они влияют на завершение программы с такой задержкой. 3. Переключить в режим 3-pin SPI mode. Всё равно аппаратная нога SS не нужна в данном случае, но может здесь что-то изменится.

Попробуйте такие варианты: 1. Перед записью байта 0х95 сделайте упреждающее чтение регистра UCBxRXBUF, чтобы очистить флаг UCRXIFG, который установлен прошлыми принятыми байтами. 2. Замените все команды while (!(UCB0IFG & UCTXIFG)); т.е. проверку опустошения буфера записи на проверку заполнения буфера чтения: while (!(UCB0IFG & UCRXIFG)); с обязательным считыванием регистра UCBxRXBUF для того, чтобы флаг UCRXIFG сбрасывался. Идея в том, что UCTXIFG=1 уже в начале передачи данных, а UCRXIFG=1 только в конце SPI-транзакции. Замена команд нужна для того, чтобы гарантированно привязаться к моменту завершения каждой SPI-транзакции. Может это на что-то повлияет. 3. Вставьте команды CS_LOW; CS_HIGH; между каждым передаваемым байтом, чтоб посмотреть на время реакции процессора при передаче всех предыдущих данных. Происходит ли задержка 60 мсек каждый раз, или только в конце пересылки группы байт?

Мне кажется, в предыдущих моделях, DCO было настроено по умолчанию на 1MHz (или на 2MHz). Может и в этой традицию сохранили. Если по умолчанию 1MHz, то после деления на 8 как раз получается что-то близкое к 132KHz. Надо это как-то проверить. Для удобства, в некоторых моделях можно вывести сигналы MCLK, SMCLK, ACLK прямо на пины ввода-вывода (это на распиновке микросхемы есть, среди кучи остальных функций) В этой модели, MCLK можно вывести на P2.6; P3.0. Какие настройки пинов сделать чтоб вывести MCLK, приведено в документе на стр.98 (для P2.6), и стр.100 (для P3.0). И для остальных сигналов: SMCLK - P1.0; P3.4 ACLK - P1.1

Ещё такое соображение. Есть две команды UCB1CTLW1 = UCASTP_2; // automatic stop assertion UCB1TBCNT = 1; // TX only 1 byte of data Это счётчик автогенерации сигнала STOP, а значение UCASTP_2 разрешает его работу. Т.е. в данной программе сигнал STOP вырабатывается автоматически (скорее всего). В документации на модуль I2C этого контроллера пишут, что при использовании авто-STOP только с одним байтом, не надо устанавливать STOP из программы. Документ slau445i (стр.637) Почему именно для одного байта, хз. Но это даже выделено в тексте... Может установка STOP в обработчике приёма байта, что-то там сбивает в этом механизме? Закомментируйте её для пробы (и заодно узнаем, работает ли авто-STOP). Или закомментить саму инициализацию авто-STOP. Посмотреть что получится.

Не разглядел, что на картинке второй оранжевый блок это запись START+Addr+W. Но байта данных за ним нет... Пока видится два варианта: 1. Выключить прерывание Transmit в команде инициализации UCB1IE |= UCRXIE0 + UCTXIE0; //Enable RX and TX interrupt Потому что этот обработчик пустой, и может это как-то влияет на нежелание передавать байт данных. 2. Или прерывание не выключать, а перенести в обработчик этого прерывания команду UCB1TXBUF = Pointer; Может из обработчика данные всё-же отправятся.

Видно три цветных блока (Оранжевый №1, Синий, Оранжевый №2) 1. Первый оранжевый блок - START+Addr+R (вероятно это он) 2. Синий блок - считанный первый байт 3. После этого наступает прерывание по приёму байта (зеленый луч=0) 4. Второй оранжевый блок - считанный второй байт, и вероятно после этого состояние STOP. Причина чтения двух байт вместо одного - в обработчике прерывания флаг STOP устанавливается после прочтения регистра данных, а это запускает чтение следующего байта. А чтобы прочитался только один байт, нужно установить флаг STOP перед прочтением регистра данных. Т.е. в обработчике прерывания поменять местами строки

А если WEB-страницу поместить в spiffs уже после прошивки? Штатными средствами работы со spiffs её туда поместить (передать по UART с внешнего контроллера или с ПК), а потом по WiFi запросу штатными-же средствами её из spiffs считать.

Очень ускоряет разработку просмотр данных на USB-шине логическим анализатором. Копеечный клон Saleae Logic на Cy7c68013a, плюс программа анализатора с оф.сайта, умеющая разбирать LS\FS USB протокол. И тогда при отладке будет ясность, что именно и в какой момент идёт не так.

Есть и такой способ. Аппарат в течение недели "изучает" типовой режим работы, и в случае отказа датчиков воспроизводит его по накопленным данным. Что это за данные в пользовательской инструкции детально не пишут. Но можно предположить что время суток, и типовая продолжительность каждого процесса в это время.

Сначала проконсультироваться у юриста, можно ли в принципе составить такой договор с фермером (фарм-фабрикой, и т.д.), когда Ваша ответственность будет ограничиваться схемотехникой и программой, а состояние автоматики и продукции будет на ответственности фермера. Потому что рано или поздно какой-нить клапан обязательно заклинит (а его не Вы произвели и не Вы ежедневно эксплуатируете), или пробьёт провод на землю, ключи на плате, и т.д. - и удобрения таки выльются. Или хотя бы ограничить ответственность во времени - например 1 год, а затем всю аппаратуру на ревизию, все реле, клапана, и некоторые датчики в помойку (а некоторые на гос-поверку) и замена выброшенного на новое. А если срок профилактики просрочен - вся ответственность на фермере. Иначе это игра в футбол с одними воротами. Ничто не мешает фермеру самому открыть клапана и срубить "неустойку", например потому что в этом году прибыли от торговли почему-то нет (перепроизводство, цены упали, налоги поднялись). А тут подал 220 на две клеммы, и программист у тебя сразу весь урожай скупил, да ещё по самой высокой цене.

Точное совпадение по всем пунктам! DFPlayer mini, цена 50-80 рублей на Алиэкспресс. обзор, обзор2 1. Автономно проигрывает звуковые файлы с SD-карты. Есть внешний сигнал проигрывания/завершения трека. 2. Усилитель до 3Вт. 3. Один канал для внешнего динамика. 4. Всё собрано на мини-платке вместе с держателем карты, и готово к использованию. Управляется командами по UART или с клавиатуры. SD-карта доступна по USB. Нюанс тоже есть - китайцы их клепают с разными прошивками чипа (или даже с разными чипами), и, по-видимому, надо купить несколько "моделей", чтоб найти нормальный вариант.

Демонстрация технологии секвенирования ДНК на оборудовании Oxford Nanopore. Ролик YouTube от 3.11.2019. На русском языке. Студентка демонстрирует процесс работы с секвенатором (карманный вариант), программой идущей в комплекте, и интернет-сервисом для анализа ДНК.

А в чём принцип очистки ячеек напряжением обратной полярности? Что при этом происходит? Цепочка ДНК должна "вылезти" назад? Или в цепочке что-то разрушается до такого состояния, что ячейка становится пригодной (предположительно) для нового использования, без извлечения остатков прошлой цепи?

Может быть ПАИС и не нужна, а достаточно цифровой ПЛИС. Если вдруг можно сделать преобразователь "ток-частота" на такой малый ток - то уже частоту загоняем в цифровую ПЛИС, и заставляем принятые импульсы считать, сравнивать, и т.д. И даже, может быть, внутри ПЛИС получать вычисленные значения нуклеотидов. Без ИИ. Частоту можно гонять через цифровые мультиплексоры, а это ещё дешевле по сравнению с аналоговыми вариантами. Только я не специалист в таких чувствительных преобразователях. Полагаю что-то подобное применяется в радиосвязи (УКВ ЧМ связь, или что-то в этом роде). Может такой преобразователь ещё проще чем усилитель тока. Если кто-то в теме, просветите пожалуйста