Jump to content

    

controller_m30

Участник
  • Content Count

    434
  • Joined

  • Last visited

Community Reputation

0 Обычный

About controller_m30

  • Rank
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

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