HART протокол - прошу совета

MIX14907 · 07.05.2014, 11:23

Добрый день всем. На форуме я новичок, но все же рискну спросить совета.
В кратце ситуация такая. Имеется некоторое устройство питающееся и управляемое от линии 4-20 мА. На данный момент у него управление только аналоговое, а вся настройка выполняется с кнопок на панели, информация отображается на монохромном графическом ЖКИ 128х32 пикселя. Так же есть 3 выходных канала с дискретным токовым сигналом стандарта NAMUR. Все хорошо, все работает, устройство выпускается небольшими сериями, но пора двигаться дальше. Решено - нужен HART. И задача эта ложится на меня как на разработчика ныне существующей версии прибора.
Собственно на данный момент стоят 3 проблемы: аппаратная реализация, программная реализация на приборе и программная реализация на ПК/коммуникаторе. В качестве аппаратной части пока смотрю на DS8500. Неплохая микросхема, легко доставаема, минимум обвязки и к тому же уже куплена. Но возникают сложности. В нынешней реализации электроника питается от 2,5 вольт и ограничение на потребление 3,8 мА. Сейчас все вместе у меня потребляет 2 мА. И того на всю коммуникацию остается 1,8 мА. Напряжение в принципе можно поднять до 3,3 В, но тогда тока останется еще меньше. Вторая сложность это соединение микросхемы модема с токовой петлей. В приборе фактически несколько внутренних источников питания включенных последовательно. Поэтому по всей видимости придется гальванически развязывать вход модема и токовую петлю. Даташит предлагает вариант развязки на трансформаторе, но не дает никакой методики расчета этого трансформатора. Собственно что может из себя представлять этот трансформатор? Примерная схема входных цепей во вложении.
Вторая проблема - программная реализация. Беглым просмотром интернета я не нашел никаких более ли менее внятных реализаций, библиотек итд. Как оценить требуемые ресурсы в МК? Сейчас в устройстве трудится Silabs C8051F410 на частоте около 1,3 МГц. По памяти после выкидывания Modbus RTU, который используется для заводской калибровки и настройки остается свободным около 6 Кб. Реально будет уложиться с хартом в этот объем или сразу переходить на камень помощнее (прошивка на С в Keil, операционка не используется)?
Ну а на реализацию на ПК пока я и не замахиваюсь, для начала хочу попробовать обойтись каким нибудь стандартным софтом.

SasaVitebsk · 07.05.2014, 14:11

Я разрабатывал HART модем. Для красивой, устойчивой работы в условиях промышленных помех с учётом длинных линий требуется приблизительно 11 мипсов на 8-ми битном контроллере типа AVR. Поскольку много математики, то x51 архитектура будет проигрывать процентов на 30. По тем же причинам в выигрыше окажутся архитектуры с большей разрядностью шины. На 16-ти битном контроллере потребуется 5-7 мипсов. На 32-ух битном и того меньше. Объём кода незначителен. Думаю что в 2к уложитесь с запасом.
Транс расчитывается исходя из размаха сигнала. Обычно используют 1:1. Поскольку я делал конвертор USB‹›HART, то я обошёлся без него. Использовал ADUM.

MIX14907 · 07.05.2014, 14:57

Сообщение от SasaVitebsk

11 мипсов на 8-ми битном контроллере типа AVR

я так понимаю, вы оцифровывали переменную составляющую токового сигнала, а потом уже программно выделяли из нее частоты 1200 и 2200 Гц. В модеме стоит именно такая задача. Я же планирую поручить это спец микросхеме. С нее я получу уже обычный UART на скорости 1200. И передавать в нее так же, простым уартом. Потому как на частоте для 11 мипс я не пройду по потребляемому току. У меня на контроллер остается всего около 1 мА и 2,5 В. По той же причине отпадают почти все 32 битные решения. Было бы нормальное питание можно было бы разгуляться. И вообще пока как то не очень хочется менять архитектуру. Можно попробовать вариант в течение какого то времени набирать данные в буфер при низкой тактовой частоте, а потом, используя энергию из конденсаторов на высокой тактовой частоте производить их обработку. К слову, максимальная частота для этого контроллера 52 МГц и может переключаться программно на лету. У меня стоит задача обработать именно логику харт протокола.

SasaVitebsk · 08.05.2014, 10:43

Вы несколько неправы, по-моему. Причём я заблуждался точно также. Давече решил одно изделие сделать с прицелом на потребление. Заюзал MSP430f6736. В общем-то считается что минимальное потребление у TI MSP. Все датчики на них делаются. У него 16 бит + умножение аппаратное. 24 бит АЦП. Довели изделие до полной реализации, но от сертификации отказались. Всё таки, моё личное ИМХО, сама архитектура устарела безнадёжно. Постоянно чувствуешь цейтнот. В процессе консультаций выяснилось что младшие Cortex-M0 вполне тягаются с TI по потреблению. Масштабы сопоставимы уже. Из новых изделий тоже наблюдаю картинку интересную. Так у меня одно изделие на lpc1765 и новое на STM32f407. По функционалу новое в 4 раза более функционально, а потребляет меньше. Так что не всё так однозначно. Я думаю что применение какого-нибудь stm32l младших моделей, при правильном управлении питанием обеспечит сопоставимое потребление. Я к тому пишу, что DS8500 тоже что-то потребляет. Кстати работаю с дисплеем 128х64. Получили несколько вариантов. У меня используется подсветка. Подсветка дисплея потребляет львиную долю потребления всего устр-ва. Обнаружил что синие потребляют в 2 раза меньше. Могу полную маркировку дать.

Теперь по вашему вопросу. Да, я писал про сам модем. Реализация протокола, зависит от устройства, с которым вы будете работать. В целом устройство может быть и очень сложным. Поэтому программа может быть объёмна. Поскольку вы об этом не писали, то непонятно. Одно дело с датчика данные читать, - совсем другое калибровать его либо указывать диапазоны и т.п. И третье ещё с более сложным устр-вом работать.
Короче вы как-то разделите вопросы, а то пока непонятно.

MIX14907 · 08.05.2014, 13:57

Сообщение от SasaVitebsk

зависит от устройства, с которым вы будете работать

Я делаю ведомое устройство (Slave). И с чем оно будет работать неизвестно, это может быть рабочая станция, плк, коммуникатор итд. Мне надо реализовать приличный функционал. Управление устройством по цифровому каналу, конфигурирование, заводская калибровка. Всего получается надо принимать и передавать порядка 100 параметров. Устройство - позиционер для пневмоприводов.
По потреблению у DS8500 заявлено 285 мкА, приемлемо если это соответствует действительности. Экран я применил TIC32A (чип на стекле, I2C) и подсветку TB1018S, белую, от питерской гаммы. При токе 3,5 мА экран хорошо читаем в темноте. Но если есть маркировочка вашего экрана и подсветки, посмотрел бы. Ничего менее потребляющего чем TIC я не нашел.
Относительно процессора. 51 архитектура была выбрана человеком, который начинал этот проект, а когда я принял эстафету кардинально переделывать схему не стал. Сейчас я пристально смотрю в сторону MSP430. Довольно интересная штука. И если я решусь переносить все на другую архитектуру скорее всего это будет MSP. А по поводу армов спасибо, посмотрю, я как то сразу откинул их, решив что у них высокое энергопотребление. Видимо зря. По быстродействию я действительно сейчас сижу почти на пределе. Спящие режимы не использую.

SasaVitebsk · 13.05.2014, 10:59

Мы используем индикаторы winstar. Мне I2C не требуется. Я использую обычный протокол. Малое потребление именно по подсветке у индикатора WG12864C-TMI-W#N. Тип подсветки кодирован. Расшифровка здесь: http://www.winstar.com.tw/products_d...v.php?ProID=98
По поводу быстродействия и архитектуры, я бы всё же попробовал на stm реализовать. Подкупает большое количество периферии и её мощность. Многое можно реализовать в обход ядра. Большое количество корпусов с тем же наполнением, и разные кристаллы по размеру флэши/ памяти. То есть выполнил на максимальном - определился - в серию поставил необходимый.
По поводу протокола, зависит от реализации. Думаю что в 6кб можно Ваш функционал всунуть. Надо только сначала детально иерархию продумать, чтобы единообразно всё было. Но в любом случае душится будете.
Я бы сделал так. Сделал минимальный функционал на текущем устройстве, и начал разрабатывать новое устройство с расширенным функционалом на новом проце.
Удачи.

MIX14907 · 13.05.2014, 11:52

Сообщение от SasaVitebsk

Сделал минимальный функционал на текущем устройстве, и начал разрабатывать новое устройство с расширенным функционалом на новом проце.

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