Многозадачность ПИД+1Wire+UART

[uwrtey]

тепло-инерционность самого датчика температуры забыли?

К сожалению, я этот параметр не знаю..

Не знаю что у Вас за система отопления, но период может измеряться даже часами

Я ни чего не могу ответить на этот вопрос. Приятель сказал, что "так надо" - Ему виднее.. Он парень далеко не глупый....
Говорит, что привод должен постоянно находится в колебании бжжж бжжж бжжж и так трижды в секунду...
Да ПИД будет скорее всего самопал.

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

Если будут предложения то я с удовольствием выслушаю ВСЕ без исключения... Ну и предложу ему...
Попробую убедить его тут зарегаться, может он подробнее объяснит.

[Z_h_e]

бжжж бжжж бжжж

Думаю это очень плохой режим.

тепло-инерционность самого датчика температуры забыли?

Если датчик будет в теплопроводной среде, наверно об этом не нужно думать. Типа в термокармане заполненный маслом. Есть другой нюанс, тут некоторые котяры говорили, что при слишком частом опросе датчика он начинает разогреваться сам. Не знаю, так ли это, но инфа об этом проскакивала.

Ну и предложу ему...

Сам то стесняется что ли тут помяукать?

[uwrtey]

Сам то стесняется что ли тут помяукать?

Где то на ардуфоруме якшается... Я ему говорю что бы сюда шел..
Но он больше любит читать мануалы и разбираться сам...

2) да разогревается... Но часто можно и не опрашивать... Данные то есть.. главное часто регулировать - ну я так понимаю...

[Z_h_e]

Но он больше любит читать мануалы и разбираться сам...

Респект Вашем товарищу.

Но часто можно и не опрашивать... Данные то есть.. главное часто регулировать - ну я так понимаю...

Может у нас какой-то инфы не хватает, но если регулирование только по температуре, какой смысл регулировать чаще чем измерять, и вообще, как это???

[uwrtey]

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

[Vov123]

Вероятно "бжжж бжжж бжжж" первично.
А вторично.... не важно, главное "бжжж бжжж бжжж".

[maxitch]

Играю сейчас как раз с DS18B20. Команду на преобразование температуры действительно можно дать всем датчикам одновременно, но считывать показания все равно придется по одному, а это тоже время, 1Wire неторопливый такой протокол... Постараюсь вечером замерить сколько времени уходит на опрос одного датчика.

[uwrtey]

С этими датчиками я уже игрался. Правда использовал чужую библиотеку, где все временные задержки организованы зависанием в цикле, что есть не рационально.

[maxitch]

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

[uwrtey]

Время можно экономить.
Быстродействие всей системы увеличить..

[Аlex]

временные задержки организованы зависанием в цикле, что есть не рационально.

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

А работа с датчиками вне прерываний (в основном цикле), даёт возможность вызываться своевременно прерываниям, которым это необходимо. Не такая уж это и важная работа, поработает и в основном цикле, спокойненько... .
По времени.
Команда на преобразование температуры всем датчикам - максимум 2-3 мс, вместе с ресетом.
Чтение температуры одного датчика с выбором ID - порядка 20 мс.
Между командами, в ожидании преобразования, можете заниматься чем угодно. Не обязательно сидеть и ждать эти 750 мс.
Посмотрите - http://forum.chipmk.ru/index.php/topic/ ... entry14293 Как раз для Дурины.

[Z_h_e]

Не обязательно сидеть и ждать эти 750 мс.

Да о таком простое тут и речи не велось. Непонятна частота регулирования 3 раза в секунду.

[Аlex]

Ну я просто процитировал этот пост :

С этими датчиками я уже игрался. Правда использовал чужую библиотеку, где все временные задержки организованы зависанием в цикле, что есть не рационально.

Плюс тут кто-то уже предлагал вынести обработку датчика в прерывание.
Вот я и заговорил о рациональности.

По поводу частоту регулирования. А почему бы и нет ? Хоть 100 раз в секунду, если в этом есть необходимость.

Вот, нашёл :

По мне так единственное что может давать задержку так это 1-Wire, уже очень он критичен к времени.
Я бы сделал так на таймер посадил бы 1-Wire, как написал,НАПАЛМ
http://easyelectronics.ru/avr-uchebnyj- ... tomat.html
А всё остальное оставил бы в главном цикле. С USART, не вижу особых проблем он хорошо подходит к конечным автоматам, там всего пару состояний получается (дождаться байт, и принять).

Человек советует то, что не надо делать.
Уарт наоборот нужно выносить в прерывания и укладывать в буфер по байтикам, а не сидеть и расчитывать, чтобы их не пропустить в основном цикле.
А опрос датчика - пофиг по времени. Не через 750 мс опросим, так через 800 дойдём. Да хоть через 2 секунды - ничего страшного не случится. Датчик не обладает такой инерционностью, чтобы с него снимать температуру так часто.
А для приёма байта, даже на скорости 9600 необходимо хотябы раз в полмиллисекунды обращаться к уарту. Не говоря уж о более высоких скоростях.

[uwrtey]

Хм.. Спасибо.. Буду щас это курить..
Мне если честно не понятен ход его мыслей... Залезть бы к нему в голову и изучить протокол от мозга ко рту...
Я теперь совсем запутался..

А ДуринА меня совсем не интересует. Я лучше на асме наверстаю, если пойму что нужно

[Мурик]

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

Настроить прерывания при приеме данных. Складывать данные в кольцевой буфер. И забирать оттуда по мере выполнения задач.

А ДуринА меня совсем не интересует. Я лучше на асме наверстаю, если пойму что нужно

И правильно сделаете. Для Arduino можно писать не только в ее IDE но и почти на чем угодно под тот контроллер что в ней установлен.

[Аlex]

Настроить прерывания при приеме данных. Складывать данные в кольцевой буфер. И забирать оттуда по мере выполнения задач.

А я о чем ? :

Уарт наоборот нужно выносить в прерывания и укладывать в буфер по байтикам

А ДуринА меня совсем не интересует. Я лучше на асме наверстаю, если пойму что нужно

Дык, это ж всё не Вам, а другу

[maxitch]

Все-таки не могу понять. Чего-то не складывается. "Приводы управляются через реле", три раза в секунду "в каком то диапазоне... бжжж бжжж бжжж"... Реле щелкает три раза в секунду или чаще? Обратной связи с приводами нет?

[Vov123]

Вероятно аналоговый привод (4-20ма) самопал.

[Satyr]

Ну а для понтов можно купить ОС реального времени ( пустяки, пару десятков килобаксов ) и влимонить ее в МК баксов за 20. Круть неимоверная!

Чем бесплатные не устраивают ?
Тем более для столь феноменальных применений

[Satyr]

Действительно, время преобразования датчика DS18B20 - 750мс., да умножить на "кучу датчиков" и в то-же время надо получить данные обработать и выдать "на гора" раз в 333мс.
Это где-же такие регуляторы воды продаются?

Просто люди абсолютно ничего не понимают в поставновке задачи.
Время преобразования 750мс при разрешении 0.0625°C на кой такой разрешение при точности датчика +-0.5С ?
Зачем частота регулирования 3Гц, когда инертность систем отопления такая, что там на десятую градуса минутами температура меняется ?
А типичные термоэлектронные термостатические головки имеют время открытия-закрытия 3-5 минут ?

А так, для поставленной задачи хватит любого МК с оперативкой байт от 256 и от килобайта на код