Jump to content

    

amiller

Участник
  • Content Count

    188
  • Joined

  • Last visited

Community Reputation

0 Обычный

About amiller

  • Rank
    Частый гость

Информация

  • Город
    Array

Recent Profile Visitors

2587 profile views
  1. Питание 3,29В. Температура конечно отличается от 25, так как сейчас лето, но не более 40. Перегрева практически нет, так как частота равна половине от максимальной для этого чипа. На холодную, сразу после включения всё то же самое. Ещё на этом датчике напряжение уменьшается при увеличении температуры. Соответственно напряжению 1,86В соответствует примерно -75 градусов.
  2. На картинке из документации видно, что 1,86В всё же далеко за допустимым диапазоном для этого кристалла. Т.е. отличие от номинала на 430мВ. Если это перевести в градусы, то будет примерно 100 градусов отклонения от нормы. Явно некоторая неадекватность показаний. Сделать калибровку несложно, но может быть это уже совсем нерабочий вариант.
  3. В одном из устройств применяю встроенный датчик температуры для приблизительной оценки температуры и для защиты по перегреву. В течение достаточно длительного времени всё было нормально. Но в какой то момент (новая партия контроллеров), напряжение на выходе датчика при комнатной температуре стало существенно больше номинального. На выходе примерно 1,86В или 2300 попугаев при номинале 1,43В при 25 градусах. Это сильно выходит из допустимого диапазона. Частота самого кристалла, напряжение питания (оно же опорное для АЦП), частота АЦП и время измерения для датчика, - всё в пределах нормы. Все напряжения на аналоговых входах тоже в разрешенном диапазоне. Та же прошивка в контроллере из старой партии дает вполне адекватные показания по температуре. Контроллеры приобретались у известного Российского поставщика в обоих случаях. Каких либо проблем в маркировке не обнаружено. Кто нибудь сталкивался с подобным поведением?
  4. Спасибо всем. Я всегда думал, что <> означают поиск в системных каталогах. Но если это позволяет исключить каталог, где находится текущий файл, то это как раз то, что мне нужно.
  5. Использую IAR 7.80.4. При работе с новым проектом решил использовать несколько исходников от старого проекта. Соответственно включил их в новый проект. Но физически файлы остались в каталогах старого проекта. В этих файлах есть строки типа: #include "define.h", где настраивается функционал. Соответственно нужные хидеры в новом проекте лежат в каталоге, который прописан в путях проекта в опциях "include". И я предполагал, что они будут взяты именно оттуда. Но выяснилось, что в каталоге, где находится подключаемый "*.c", лежит хидер с таким же именем. При компиляции был подключен файл из старого проекта, а не из нового (молча). Когда доступный хидер из старого проекта был переименован, то также молча был найден и подключен хидер уже из нового проекта. Естественно, что каталог, где находится подключаемый "*.c", в новом проекте нигде не упоминается. Вышел из положения, скопировав нужные файлы в новый проект, но это вроде как не совсем правильно. Что скажете, так и должно быть?
  6. Нет такого понятия, как полигон питания, и соответственно требований к нему. И редко когда на плате одно питание, обычно есть 5В, 3,3В, отдельно аналоговое питание, опорное напряжение. При многослойной разводке выделили один слой под землю, - хорошо. По остальным слоям максимальное количество площади под землю. Один слой выделяйте под линии питания. Питание ведете достаточно широкими, но отдельными проводниками. В полигонах здесь нужды нет. Если линия связи не имеет переходных отверстий, то проводите её сверху или снизу, если позволяет площадь платы. Если переходные отверстия есть, то уводите линию на внутренний слой (питания). Земляные полигоны в разных слоях часто сшивайте переходными отверстиями. При большом количестве пересечений, используйте географический принцип: в одном слое линии по горизонтали, в другом - по вертикали. А вообще есть на форуме специализированный раздел по разводке, почитайте. Разводка АРМов принципиально ничем не отличается. Если на плате есть силовые компоненты и управление, полезно деление полигонов земли на чистую землю и грязную, с соединением в одной точке. Это сильно помогает уменьшить помехи и шумы.
  7. Можно примерно так: Формируется набор флагов. Каждый флаг устанавливается отдельно в своем критичном таске или прерывании. С определенным интервалом происходит проверка флагов. Если хотя бы один флаг не установлен, то сброса WDT не происходит. А после успешного сброса WDT все флаги сбрасываются и снова всё по кругу. И неважно при этом задействован внешний таймер или внутренний.
  8. У меня кстати наоборот, не получается стереть залоченый STM8 через IAR. А через STVP пожалуйста: Открываю STVP, перехожу на вкладку Option Byte. По умолчанию там всё в дефолте. И нажимаю кнопку "Program current tab". В итоге получаю чистый кристалл, со всеми настройками по умолчанию. P.S.: Работаю через ST-LINK V2.
  9. Судя по всему в этой прошивке используется память в диапазоне 0x0000 - 0x3F80. Так как адресация 16 битная, то подразумевается, что базовый адрес равен нулю. А бутлоадер должен находится в примерном диапазоне 0xF000 - 0xFFFF. Такими адресами здесь и не пахнет. Вывод: Это прошивка пользовательской программы. Таким простым способом бутлоадер не достать. Советую посмотреть на программу, с помощью которой Вы читаете кристалл. Если микросхема не залочена, то где то в конфигах надо явно указать диапазон, который Вы хотите прочитать. И ещё: Есть уверенность, что секция бутлоадера , это flash, и её в принципе можно писать? Может это ОТР? Я никогда с такими микросхемами не работал. Но точно существует документация на семейство, где всё это подробно расписано.
  10. Похоже, что не совсем правильно Первая строка: 10 - количество байт = 16. 0FD0 - смещение относительно базы. 00 - признак данных Далее 16 байт, на каждый байт по 2 символа. Последние 2 символа в строке = BF, это CRC. Ещё где то ранее должна быть служебная строка, которая задает базовый адрес (старшие байты). И в самом конце массива должна быть строка, конец файла.
  11. Излишнее усложнение. Компоненты D1, U1, R4, R5, C3 можно заменить просто транзистором. А на стороне приемника достаточно входа АЦП контроллера. Но это всё хорошо, когда передаваемая мощность меньше 1Вт и допустимы пульсации 1В. А если надо по цепи питания передавать 100Вт и пульсации более 50мВ недопустимы? В этом случае понадобятся более сложные решения. я бы в таком случае не стал заморачиваться и выделил ещё один провод для связи между модулями.
  12. Извините, а вам действительно нужно знать, что именно нехорошего произошло на шине? Я обычно с этим не парюсь, а всегда перед чтением регистра данных читаю регистр статуса. Все биты ошибок при этом автоматически сбрасываются. А определение целостности данных производится на следующем уровне обработки. Там и CRC и таймауты и т.п. И работает такой алгоритм идеально на всех STM и не только.
  13. Из разряда легенд, которые появились в компании ещё до меня: В одном из узлов - гальваноразвязанный измеритель под потенциалом 60кВ и с возможностью высоковольтных пробоев на корпус для измерений стоит ATMEGA88. Было две попытки вкорячить туда STM32 для унификации - безуспешно, не живут. Причём и документацию внимательно изучали и дополнительных мер по защите было более десятка. Сейчас это уже действует как правило. В таких узлах только AVR. На мой взгляд причин две: 1. Более высокое напряжение питания. 2. Большая стойкость выводов по энергии. Хотя на уровне обычных напряжений и энергий помех работают STM32 без нареканий. Надо только соблюдать определенные правила. Например AVR мне не попадались с отгоревшими выводами, а STM32 сколько угодно. Кстати STM8 вроде тоже покрепче в плане стойкости к ЭМИ.
  14. Мне собственно тоже совершенно безразлично, что Вы пишете, если уж на то пошло. Единственное, что мне интересно, это оригинал стандарта. И не для того, чтобы Вас в чём то убедить, а в том, чтобы убедиться самому. Пока я этого не увидел, я считаю правильным такое утверждение: EIA-485 [TIA-485] Balanced (differential) interface; defines the Physical layer, signaling protocol is not defined. EIA485 is also called the RS485 standard, but the term RS485 is out-dated. EIA-485 specifies bidirectional, half-duplex data transmission. Эту фразу можно увидеть много где, в том числе и в переводе на русский язык. Одна из ссылок в моем предыдущем посте. А это означает, что RS485 - полудуплексный интерфейс, на что я и обратил внимание ТС. А любые допущения к делу не относятся.
  15. Я попробовал поискать. Яндекс дает на ключевые слова "RS485 full duplex" - 45 миллионов результатов. А на слова "RS485 half duplex" - всего 30 миллионов результатов. Поэтому Вам присуждается победа по очкам. Хотя с точки зрения интернета full более модно, чем half, поэтому преимущество гарантировано. Однако для установления истины нужен первоисточник, а не вторичные материалы. Я попробовал поискать действующий стандарт TIA/EIA-485. Странно, но быстро найти не удалось, по крайней мере бесплатно. Если у кого то есть, прошу поделиться ссылкой. То что я находил, не может претендовать на абсолютную истину, например: http://www.interfacebus.com/Design_Connector_RS485.html В этом источнике, а также в огромном количестве других материалов в сети в первых строчках описания RS485 явно указано, что это полудуплексный интерфейс. Я допускаю для организации дуплекса применение двух каналов RS485 и понимаю отличия такого варианта от RS422. Но отношу такой вариант скорее к нестандартному использованию RS485. По крайней мере в реальных устройствах такого способа организации связи встречать не приходилось. Может не везло просто. Или наоборот, повезло не встретить...