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

uwrtey

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

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

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

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

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

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

Реклама

Z_h_e

uwrtey писал(а): бжжж бжжж бжжж

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

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

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

uwrtey писал(а):Ну и предложу ему...

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

Реклама

uwrtey

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

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

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

Z_h_e

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

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

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

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

Реклама

uwrtey

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

Реклама

Vov123

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

Реклама

maxitch

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

uwrtey

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

maxitch

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

uwrtey

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

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

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

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

Z_h_e

Аlex писал(а): Не обязательно сидеть и ждать эти 750 мс.

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

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

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

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

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

Вот, нашёл :

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

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

uwrtey

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

Я теперь совсем запутался..

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

Мурик

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

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

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

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

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

А я о чем ? :

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

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

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

maxitch

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

Vov123

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

Satyr

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

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

Satyr

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

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

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