Форум РадиоКот

roman.com писал(а): МК 1 - К UARTу подключен GSM модуль
МК 2 - куча датчиков температуры.

Это время преобразования 0.75с, а обмен микросекунды.
Ничто не мешает хоть сотню (но уж не при паразитном питании -)) ) датчиков запряч на одновременное вычисление, а потом за миллисекунды считать с них всех результат.

И никогда не выбирайте кучу МК, когда можно сделать на 1 более жирным (но тут жирным совсем не пахнет).
Организация обменам между несколькими МК задача порой трудней, чем сама начальная задача.

Z_h_e писал(а):

pokk писал(а):По мне так единственное что может давать задержку так это 1-Wire

Для таких датчиков можно выделить какую-нибудь "тиньку", а эту тиньку опрашивать головным контроллером.

Дааа...
а, ну да, 8 бит - это не архитектура, это образ мышления -))

Когда то давным давно, когдя я имел дело с AVRами, почему то at90usb82 хватало и чтоб температуру снимать с 6 1-wire датчиков, и PWM управлять 6 вентияторами, и еще по USB выводить красивые графики температур и оборотов + по нему ж конфигурироваться. Причем никакого ассемблера - чего время в разы тратить, когда все и так в самый мелкий МК помещается и еще ресурсов завались ?

нынче что поменялось ? прерывания убрали, таймеры выпилили из АВРов ???


Ну уперлось 3 раза в секунду пересчитывать - запилите сразу все датчики на преобразование, засеките таймер на 0.75/4 секунды и спокойно обрабатывайте, что в буфер насыпалось с UART по прерываниям с него и спокойно себе регулируйте. как нарегулируйетесь - ждите таймера и мигом считывайте показания со всех и переходите к началу -))

Многозадачности тут нет никакой необходимости.

Satyr, какая была необходимость повторить все сказанное в этом топике , но уже от Вашего имени?

Satyr писал(а):никогда не выбирайте кучу МК, когда можно сделать на 1 более жирным...

Ну это зависит от задачи...

К слову сказать про прерывания... делал както что-то подобное. Сначало сделал всё на прерываниях - UART + INT0 + INT1...
Но вылезла проблемка... Когда в буфер UART насыпалось... уходим на прерывание UART ... А тут сработал INT0 ... Получил отложенное прерывание... Ошибка измерения 10 мкС - для меня критично! Можно было сделать вложенное прерывание... но помоему это извращение)) И всё равно будет ошибка... т.к. могут сработать UART + INT0 + INT1 одновременно!

Короче... сделал непрерывную проверку всех датчики в основном цикле, и спокойно себе регулировал, при этом периодически проверял буфер UART по флагу... Если насыполось в UART, то читаем, а если пусто, то идём дальше... Посчитал время, чтобы буфер UART не переполнялся.

А прерывание INT0 или INT1 оставил только для аварийного отключения. При перегрузки системы нужно немедленно отключить (!), а не ждать отложенного прерывания..)))

Так же скрутил два МК... один в радиомодуле, второй следит за системой. Обмениваются они между собой через буфер UART... когда МК1 свободен, то отправляет данные на МК2... А МК2 читает данные из буфера UART, только когда тоже свободен... Короче никаких прерываний по UART.

Зачем два МК? Потому что МК1 отвечал за связь - непрерывно принимал и отправлял пакеты данных по радиоканалу (режим радио ретранслятора). Некогда ему было ещё и за датчиками следить...

Думал SPI... но там один буфер, а в UART аж три ! ...)))

Както так...

А вообще... чтобы выбрать алгоритм, надо смотреть схему... что там критично, а что нет.

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

Vov123 писал(а):Меня вот тоже мучил вопрос, почему буржуйские авто-производители на своих машинах используют мультипроцессорную систему, дык под это ещё и протокол свой придумали- CAN (по-моему у каждого свой диалект), ну поставили бы один "жирный", к примеру Core i7.

там мульти не потому что мало одного, а потому что система распределенная.
а распределенная, чтоб 100кг проводов не тащить от каждой лампочки и выключателя к одному 'Core i7'

Кому мало одного - бывает 2 в 1 -))
Скажем, шустрый Cortex M4F и тупой M0, зато с коротким конвеером и малой латентностью для обработки прерываний в одном флаконе.

roman.com писал(а):И всё равно будет ошибка... т.к. могут сработать UART + INT0 + INT1 одновременно!

Как они сработают одновременно, если у них приоритеты разные. Причем у ИНТ0 наивысший ?

На тему УАРТа - ДМА, вроде если есть, то толко в хмега ? а как там с фифо ?

Вот и я про то-же. Если проще сделать мультипроцессорную схему, надо её и делать.
Года 2 назад для своего авто переделывал на контроллер вот такую штуку
http://primavistalab.com/myengine/
Формат кадра идёт около секунды, кадр начинается с пилот сигнала.
Надо принять, дешифровать, произвести вычисления, вывести на дисплей, ещё и кнопочки опросить.
Так и сделал, тинька снимала данные, а всем остальным занималась mega16.
Так вот ещё какая неожиданность вышла - по uart на столе работала классно, а на авто только 1 пакет из 10 приходил с адекватным crc.
Пришлось переделывать на SPI, хотя расстояние между процами было несколько сантиметров.
Для каждого свой случай. И каждый для себя делает как может, ведь главное в этом, чтобы исправно работало.


Во сколько букв набрал...

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

Что такое мультипроцессорность в данном контексте. Это модульная архитектура. Буржуи давно на нее перешли. При кажущийся удорожании и избыточности, получается надежность и простота в обслуживании. Проще, а в итоге и дешевле, менять неисправный модуль, чем держать штат высокооплачиваемых инженеров для ремонта устройства, тем более время ремонта (читай стоимость) неизвестно. Кроме того, при необходимости модернизации, значительно проще разработать один простой модуль, чем модернизировать один мегамозг.

Satyr писал(а):никогда не выбирайте кучу МК, когда можно сделать на 1 более жирным...

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

Vov123 писал(а):Если проще сделать мультипроцессорную схему, надо её и делать.

Если удастся обосновать, то конечно надо

Z_h_e писал(а): Что такое мультипроцессорность в данном контексте. Это модульная архитектура. Буржуи давно на нее перешли. При кажущийся удорожании и избыточности, получается надежность и простота в обслуживании.

Позвольте, вот у вас с телефоне сколько модулей ? Сколько плат ?

Модуль не значит плата. Например, объектно-ориентированное программирование - тот же модульный подход по сути. Satyr, я вроде не говорил что мультипроцессорный подход обязателен. Все зависит от задачи и других факторов. Это Вы его категорически отрицаете, при том что задачи в этом топике по сути озвучено не было.

Z_h_e писал(а):Предположим разработчик решил так же категорично как и Вы. Все собрал, потратив свои ресурсы и все работает. Но тут возникает необходимость заменить текущие датчики на совершенно новые. Пускай они будут супердешевые, не уступающие по характеристикам, но совершенно с другим интерфейсом, в том числе со значительной переделкой схемы. Ох, как он пожалеет что послушал Вас. Что будет проще, создать новый простенький модуль или создать новое устройство полностью?

Для этого существуют средства согласования... адаптеры... платы согласования... и модульность здесь никаким боком... А то можно пожалеть... что купил БМВ... вот на старую Волгу... колёса от трактора точно бы прицепились...

Я кажется понял в чем мой приятель "видит" сложность процесса.
Видимо тот самый сервопривод не может остановится в определенном положении.
Хотя можно посчитать сколько времени уходит на движение от начала до конца, но моторы то разные бывают и напруга в сети разная...
С датчика снимается температура например три раза в секунду ( ну я например говорю, и это возможно )
А дальше ПИД регулятор начинает крутить мотором. Ну вот собственно я вся его логика.
Измерили Т - крутим мотор, Измерили еще раз, если не изменилась - не крутим, а если изменилась - крутим обратно...
Просто система должна быть универсальная.
Если инерционность системы большая, то кажется, что можно выиграть еще процессорного времени...
А если инерционность малая? ( например малый контур ) То тогда нужно как-то поспевать регулировать..
Вот от сюда и требование как можно чаще ( три раза в секунду ) измерять Т и крутить мотор бжжжж бжжж бжжж

Я писал Вам, видно Вы не поняли, необходимо использовать, если, конечно денег хватит, аналоговый привод, наподобие этого http://ecovariant.ru/klapany-i-privody- ... s-010.html
От приложенного к нему тока 4-20мА или напряжения 0-10в (в зависимости от модификации) он устанавливает ось привода строго в определённый угол, максимальный угол открытия 90 гр.

uwrtey писал(а):Видимо тот самый сервопривод не может остановится в определенном положении.

А если попробовать снять с него напряжение, поди остановится?

uwrtey писал(а): Вот от сюда и требование как можно чаще ( три раза в секунду ) измерять Т и крутить мотор бжжжж бжжж бжжж

А чего не 30, чего не 300 ?
Ничего, что у всех этих кранов время от закрытия до открытия 120-300 СЕКУНД ?

Проскочит по инерции, если привод не самотормозящий (червячный, к примеру) .

Есть системы управления задвижками без обратной связи и не по управляющему сигналу типа 4-20. При необходимости на привод задвижки подается питание на долю времени и не чаще заданного. Если система вышла на заданную величину, задвижка остановлена. По сути получается интегральный регулятор.

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

В том то и дело, что они дорогие.

А чего не 30, чего не 300 ?
Ничего, что у всех этих кранов время от закрытия до открытия 120-300 СЕКУНД ?

Хм, увы, я этого не знаю. И о таком времени закрытия слышу впервые.. Нужно подумать.

Проскочит по инерции, если привод не самотормозящий (червячный, к примеру)

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

Есть системы управления задвижками без обратной связи и не по управляющему сигналу типа 4-20. При необходимости на привод задвижки подается питание на долю времени и не чаще заданного. Если система вышла на заданную величину, задвижка остановлена. По сути получается интегральный регулятор.

ВОТ О НЕМ РЕЧЬ И ИДЕТ. В самом начале сказал ПИД.