Jump to content

    

controller_m30

Участник
  • Content Count

    432
  • Joined

  • Last visited

Community Reputation

0 Обычный

About controller_m30

  • Rank
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

5364 profile views
  1. Есть такие переходники для программирования ESP32: один, два.
  2. Полагаю у светодиода нет существенной ёмкости (кроме десятка пикофарад). Обоснование. 1. Любая ёмкость имеет время заряда и разряда. Чем больше ёмкость, тем больше это время. Если бы у светодиодов была какая-то существенная ёмкость, то их было бы проблематично использовать в стробоскопичесом режиме, например для динамической индикации в световых табло. Светодиод долго и постепенно загорался бы, и так же долго и постепенно угасал. 2. Предполагаемый мощный пусковой импульс при включении светодиода, должен иметь и обратную сторону - разряд этой ёмкости при выключении, обратно в питающую схему. Вроде бы такой эффект в схемах не наблюдается.
  3. Вопросы: 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...] И тоже получается несовпадение КС массивов, независимо от способа расчёта.
  4. Гипотеза, почему могут отличаться программы с переменными типа volatile и переменными обычными, статья. Если смотреть на листинги, в той части где происходит отправка команды 0 на карту - так программы абсолютно одинаковые! Но, зная что программы одинаковые, и сравнивая осциллограммы - появляется мысль, что по программе с обычной переменной таки "прошёлся" оптимизатор. Почему этого не видно на листингах? Возможно потому, что в листингах приведен дизассемблер исходной программы на С, а не итогового машинного кода, который заливается в контроллер. Это только гипотеза, но в контексте приведенной статьи, мне она кажется очень вероятной.
  5. Ещё варианты: 1. Добавить в конец программы какую-то команду, как в рабочем примере (в той программе после CS_HIGH есть ещё пара строк работы со светодиодом). Например, после CS_HIGH добавить ещё 2-3 команды записи байта - пусть их будет не 6 а 9. Посмотреть что будет с задержкой после 6-й команды. 2. В рабочем примере, в конце текста есть ещё команда Return 0 и кавычка - а есть ли они в переработанном варианте? Может это они влияют на завершение программы с такой задержкой. 3. Переключить в режим 3-pin SPI mode. Всё равно аппаратная нога SS не нужна в данном случае, но может здесь что-то изменится.
  6. Попробуйте такие варианты: 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 мсек каждый раз, или только в конце пересылки группы байт?
  7. Мне кажется, в предыдущих моделях, 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
  8. Ещё такое соображение. Есть две команды 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. Посмотреть что получится.
  9. Не разглядел, что на картинке второй оранжевый блок это запись START+Addr+W. Но байта данных за ним нет... Пока видится два варианта: 1. Выключить прерывание Transmit в команде инициализации UCB1IE |= UCRXIE0 + UCTXIE0; //Enable RX and TX interrupt Потому что этот обработчик пустой, и может это как-то влияет на нежелание передавать байт данных. 2. Или прерывание не выключать, а перенести в обработчик этого прерывания команду UCB1TXBUF = Pointer; Может из обработчика данные всё-же отправятся.
  10. Видно три цветных блока (Оранжевый №1, Синий, Оранжевый №2) 1. Первый оранжевый блок - START+Addr+R (вероятно это он) 2. Синий блок - считанный первый байт 3. После этого наступает прерывание по приёму байта (зеленый луч=0) 4. Второй оранжевый блок - считанный второй байт, и вероятно после этого состояние STOP. Причина чтения двух байт вместо одного - в обработчике прерывания флаг STOP устанавливается после прочтения регистра данных, а это запускает чтение следующего байта. А чтобы прочитался только один байт, нужно установить флаг STOP перед прочтением регистра данных. Т.е. в обработчике прерывания поменять местами строки
  11. А если WEB-страницу поместить в spiffs уже после прошивки? Штатными средствами работы со spiffs её туда поместить (передать по UART с внешнего контроллера или с ПК), а потом по WiFi запросу штатными-же средствами её из spiffs считать.
  12. Очень ускоряет разработку просмотр данных на USB-шине логическим анализатором. Копеечный клон Saleae Logic на Cy7c68013a, плюс программа анализатора с оф.сайта, умеющая разбирать LS\FS USB протокол. И тогда при отладке будет ясность, что именно и в какой момент идёт не так.
  13. Есть и такой способ. Аппарат в течение недели "изучает" типовой режим работы, и в случае отказа датчиков воспроизводит его по накопленным данным. Что это за данные в пользовательской инструкции детально не пишут. Но можно предположить что время суток, и типовая продолжительность каждого процесса в это время.
  14. Сначала проконсультироваться у юриста, можно ли в принципе составить такой договор с фермером (фарм-фабрикой, и т.д.), когда Ваша ответственность будет ограничиваться схемотехникой и программой, а состояние автоматики и продукции будет на ответственности фермера. Потому что рано или поздно какой-нить клапан обязательно заклинит (а его не Вы произвели и не Вы ежедневно эксплуатируете), или пробьёт провод на землю, ключи на плате, и т.д. - и удобрения таки выльются. Или хотя бы ограничить ответственность во времени - например 1 год, а затем всю аппаратуру на ревизию, все реле, клапана, и некоторые датчики в помойку (а некоторые на гос-поверку) и замена выброшенного на новое. А если срок профилактики просрочен - вся ответственность на фермере. Иначе это игра в футбол с одними воротами. Ничто не мешает фермеру самому открыть клапана и срубить "неустойку", например потому что в этом году прибыли от торговли почему-то нет (перепроизводство, цены упали, налоги поднялись). А тут подал 220 на две клеммы, и программист у тебя сразу весь урожай скупил, да ещё по самой высокой цене.
  15. Точное совпадение по всем пунктам! DFPlayer mini, цена 50-80 рублей на Алиэкспресс. обзор, обзор2 1. Автономно проигрывает звуковые файлы с SD-карты. Есть внешний сигнал проигрывания/завершения трека. 2. Усилитель до 3Вт. 3. Один канал для внешнего динамика. 4. Всё собрано на мини-платке вместе с держателем карты, и готово к использованию. Управляется командами по UART или с клавиатуры. SD-карта доступна по USB. Нюанс тоже есть - китайцы их клепают с разными прошивками чипа (или даже с разными чипами), и, по-видимому, надо купить несколько "моделей", чтоб найти нормальный вариант.