[dac 0]

А не могли бы рассказать какой был период опроса всех датчиков, как вы определяли где какой датчик стоит и к каким процедурам прибегали когда хотели заменить хотя бы один датчик?

период опроса 1 или 2с кажется, уже года четыре прошло, точно не помню.

для замены была предусмотрена следующая процедура:

1. отключается гирлянда

2. подключается новый датчик

3. вход в режим определения датчика

4. выбор его лог. номера

5. сохранение (адрес пишется в еепром)

6. ставим датчик на место, цепляем всю гирлянду.

 

меню на семисегментных индикаторах,

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

 

потеря датчика от частотников была решена программным фильтром, длительность тех. процесса позволяет. всякий изврат вроде RC не помогал.

первый вариант был на pic16f877 - что в хламе валялись, потом из-за пары хотелок в голову пришлось ставить pic24fj64gb002 - тоже из тех что под руками были. в 16 программа не лезла.

 

 

 

 

[kolobok0 0]

...Придется наверное опять ковырять гильзу штатного датчика, извлекать NTC и устанавливать DS18B20...

 

вот ставить датчик в гильзу не есть гуд. реальную температуру получите спустя 5 минут. и это чистая шизика, чистого датчика (т.е. распространение передачи тепла среда-пластик-терморезистор). так что при разогреве или остывании будет запаздывание как минимум в 5 минут от "эталонного" внешнего.

 

 

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

Тут уже прозвучало - девайс с гирляндой плох в обслуге. Спецам не от эклетроники просче переткнуть датчик с нужной длиной кабеля в разъёме и включить ОН(а то и на ходу менять - такое часто бывает). Чем, что то там прописывать, манипулировать, процедуры, епромы... Нет, отговаривать не буду. Значимость сих действий высока, типа магия от специалиста :)

 

По поводу дружбы РТОС и 1Wire - надо уметь их готовить просто господа. Всё номано разруливается. Где то уже писал - на 51 с тактовой в 2мипса без проблем разруливается 8 датчиков как с куста. на АВРках ещё просче. На стм32 с ртос - проблем практически никаких.

Изменено 27 июня, 2013 пользователем kolobok0

[AlexandrY 3]

На стм32 с ртос - проблем практически никаких.

 

Ну так и я делал 1wire на всем что шевелится. От Z86, MSP430, I51, PIC, AVR до ARM9 и Cortex.

 

Вопрос не в том кто на чем делал 1wire, а в сравнении с другими технологиями цифровых датчиков.

Сколько времени и ресурсов микроконтроллера потребовалось чтобы реализовать 1wire на RTOS в STM32?

 

Например я использовал таймера. К чему это приводит.

Во первых в мелких STM32 таймеров не так много. Во вторых у того таймера жестко задается делитель и его оставшиеся два компараторных канала становятся ограниченно юзабельными.

В третьих сами процедуры работы с 1wire на физическом уровне получаются объемными и требуют событий, которых в RTX RTOS к примеру не так уж и много.

Как ни крути 1wire сложнее в написании по сравнению с I2C.

Но хуже, что он сложнее в поддержке и повторном использовании. Переходя на другую платформу скажем с STM32 на LPC или Kinetis вызовет необходимость переписывания на низком уровне хитрых процедур инициализации таймеров.

[kolobok0 0]

...ресурсов микроконтроллера потребовалось чтобы реализовать 1wire на RTOS в STM32?...

 

таймер и нитка(если на борту есть РТОС) - для "медленной" обработки полученных данных. функции элементарные и их не так уж много - хотя зависит от применяемого алгоритма. собственно в вашем посте это прозвучало. а вот по поводу необходимости событий - тут, что то я не совсем понял. событие одно - таймер :) да, им придётся пожертвовать. Хотя и тут опционально :) по поводу перехода на другое железо. собственно не только инициализация таймера, но и инициализации переферии(пинов) потребуется другая естественно. да и способ общения с портами другой скорее всего - думаю лучше вынимать все плюсы железа, а не получать тормоза в угоду универсальности.

 

[dac 0]

Но хуже, что он сложнее в поддержке и повторном использовании.

согласен полностью. кроме этого есть еще недостатки - на длинной линии сплошной гемор и скоростью поиграть невозможно.

в общем применять можно, но ограниченно, т.к. проблем больше чем пользы.

лучше бы сделали с LIN или 485 :) правда там уже заморочки с поиском новых датчиков, но, имхо это надуманная проблема, т.к. датчик все равно логически обозначать надо, чего он собственно измеряет.

 

[AlexandrY 3]

таймер и нитка(если на борту есть РТОС) - для "медленной" обработки полученных данных. функции элементарные и их не так уж много - хотя зависит от применяемого алгоритма. собственно в вашем посте это прозвучало. а вот по поводу необходимости событий - тут, что то я не совсем понял. событие одно - таймер :) да, им придётся пожертвовать. Хотя и тут опционально :) по поводу перехода на другое железо. собственно не только инициализация таймера, но и инициализации переферии(пинов) потребуется другая естественно. да и способ общения с портами другой скорее всего - думаю лучше вынимать все плюсы железа, а не получать тормоза в угоду универсальности.

 

Таймер вызывает прерывание, а в процедуре прерывания вызывается событие RTOS.

А как еще сообщить задаче (в данном случае задаче драйвера 1wire) о том что пришло время следующего действия не используя циклов ожидания?

Причем даже так нужно очень побеспокоиться чтобы задача драйвера была самой приоритетной.

А вот это уже серьезный подводный камень, поскольку всегда когда вы будете возвращаться к этому проекту надо будет вспоминать о расстановке приоритетов.

Т.е. слишком много низкоуровнего контекста надо иметь в голове чтобы поддерживать повторное использование такого кода.

 

С интерфейсами которые имеют FIFO все намного проще и надежней.

В конце концов я стал ставить на 1wire I2C мост DS2482S

Либо делаю на отдельном микроконтроллере шлюз 1wire-CAN поскольку держать рядом с драйвером 1wire хотя бы еще с десяток задач в реальном времени очень сложно именно из-за сложности управления приоритетами.

[kolobok0 0]

..Таймер вызывает прерывание, а в процедуре прерывания вызывается событие RTOS...как ..сообщить задаче (... драйвера 1wire) ..что пришло время следующего действия ..?Причем ..нужно ..чтобы задача драйвера была самой приоритетной.

...

 

ага понятно. а теперь вопрос:

 

Можно ли временные кванты развязать от "задачи которой сообщаете (приоритет и дальший гимор)", т.е. точно ли необходимо каждый раз узнавать "следующее действие" с верхнего уровня?

 

и наводящий вопрос:

 

Изменяется ли формат взаимодействия с 1Wire во время всего цикла работы устройства?

 

вот если решите - то и большинство озвученных проблем = надуманные проблемы. :)

 

 

[Слесарь 9]

вот ставить датчик в гильзу не есть гуд. реальную температуру получите спустя 5 минут. и это чистая шизика, чистого датчика (т.е. распространение передачи тепла среда-пластик-терморезистор). так что при разогреве или остывании будет запаздывание как минимум в 5 минут от "эталонного" внешнего.

5 минут не показатель, нагрев так или иначе продолжается значительно дольше.

Проблема в другом, в штатной гильзе цифровой датчик регистрирует всегда в минус, чем выше температура воды, тем больше минус. При реальной температуре воды 90, датчик будет регистрировать около 84 градусов. Просто половина гильзы не в воде и тепло улетучивается в окружающую среду. Решается или программно или более удлиненной гильзой как на водогрейках.

 

Как ни крути 1wire сложнее в написании по сравнению с I2C.

Но хуже, что он сложнее в поддержке и повторном использовании. Переходя на другую платформу скажем с STM32 на LPC или Kinetis вызовет необходимость переписывания на низком уровне хитрых процедур инициализации таймеров.

Делая первое 1-wire устройство, написал несколько функций и сохранил в отдельной файле. Во втором устройстве использовал тот же файл и отладил 1-wire еще лучше. Для третьего устройства вообще не вижу проблем. Ближайшие годы для простых устройств с 1-wire, платформу менять не планирую.

[Слесарь 9]

И еще пока неясно, если делать шину 1-wire с прокладкой в одном жгуте с силовыми проводниками на расстояние чуть более метра, как лучше организовать защиту от ЭМИ ? Раньше использовал ключевые транзисторы как развязку с микроконтроллером или оптопары если нужна была гальваническая развязка. Можно ли ограничиться одним на десятки Ом резистором? Использовать только одну ножку МК для организации 1-wire.

 

Смотрел как другие делают K-line, там используют ключевые транзисторы.

[Слесарь 9]

Кажется я все таки понял зачем нужен цифровой датчик температуры. Он более линейный во всем диапазоне измерений!

Надо же будет рассчитывать время до окончания стирки и выводить на дисплей в часах-минутах. Для того чтоб более точно рассчитать время прогрева стирального раствора до требуемой температуры и требуется достаточно линейный датчик. Несколько условий, напряжение питающей сети скачет от 170 до 230, температура окружающей среды различается +5 ... +35, температура заливной воды +4 ... +40. Как понимаю, потребуется делать два измерения температуры за определенное время, по тенденции прогрева рассчитывать оставшееся время до достижения заданной температуры.

[=AK= 12]

Кажется я все таки понял зачем нужен цифровой датчик температуры. Он более линейный во всем диапазоне измерений!

 

Линейность датчика не играет никакой роли. Единственный недостаток нелинейного датчика - для преобразования отсчетов в температуру для него требуется немножко больше вычислений, чем для линейного. В конечном счете что линейный, что нелинейный датчик после перерасчета выдадут температуру. С какой точностью они выдадут температуру - вот в чем вопрос. Цифровой датчик или полупроводниковые аналоговые, при всей своей линейности, обеспечивают точность измерений порядка 1..2 С, а NTC - в несколько раз лучшую точность и намного меньшую тепловую инерционность при той же цене.

[Слесарь 9]

а NTC - в несколько раз лучшую точность

это те которые применяются в быту или платиновые NTC ?

[=AK= 12]

это те которые применяются в быту или платиновые NTC ?

Не путайте термисторы (в частности, NTC - термисторы с отрицательным темп. коэффициентом) с термометрами сопротивления, платиновыми или медными. Это совершенно разные сенсоры.

 

Когда я в этой теме говорю о NTC, то подразумеваю так наз. "взаимозаменяемые NTC", ссылку на которые я давал ранее для примера: http://www.ussensor.com/products/thermisto...ble-thermistors

 

[Слесарь 9]

Когда я в этой теме говорю о NTC, то подразумеваю так наз. "взаимозаменяемые NTC", ссылку на которые я давал ранее для примера:

Но дело в том, что когда я смотрел паспортные данные на промышленные приборы к которым можно подключать NTC датчики, погрешность по паспорту выше чем у DS18B20. А вы говорите обратное, причем отличающееся в несколько раз. Я в замешательстве, кому верить?

[kolobok0 0]

...погрешность по паспорту выше чем у DS18B20...

 

погрешность по паспорту у всех DS18xxx 0,5 или 1 градус. разрешающая способность 0,065(DS18x20) или 0,01(DS1821)

 

линейность как у терморезистора, т.к. именно он и применяется. без коррекции.