Научу программировать на С++

[alamer]

Есть компактные. выбор большой. причем есть как с регулируемым диффузором, так и клапаны откр/закр (по типу тех, что на стиральных машинках стоят).
Про датчики дыма и прочие датчики, согласен, это неотъемлемый элемент УД.
Но как только вы начнете собирать данные с датчиков, вам захочется эти данные использовать
Кстати, как то подключал датчик дыма от охранных систем к микроконтроллеру. Устал подключать
Такое чувство, что конструкторы охранных и противопожарных систем - переученные участковые милиционеры.

Использовать данные я конечно буду, сначала просто для сбора в базу,построения графиков и выдачи предупреждений.
Это уже отработанный механизм который я писал для серверов. Правда не на основе микроконтроллеров.
Вот интересно было бы для одной квартиры накопить статистику, провести корреляционный анализ и на основе этих данных уже проектировать систему.
С пожарными\сигнализационны� �и датчиками сталкивался только с двухрежимными. Есть сигнал\нет сигнала.
Вы многорежимный аналоговый подключали?

[Zanginsan]

Вот интересно было бы для одной квартиры накопить статистику

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

[voID]

Причем здесь C++?))) Cи изучается максимум за 3 часа(основные конструкции языка C, http://rutracker.org/forum/viewtopic.php?t=2388601 - 292 страницы - весь язык)!!! Микроконтроллеры все на свете?))) Рисунки на полях японии?)))

Умение программировать и понимание того, что происходит за строчками вашего кода - почти не пересекающиеся области знаний (это так специально сделано). Может показаться, что последнее и не нужно совсем, но, как показывает практика, всегда наступает момент, когда программист, полагаясь на прикладную абстракцию, реально не вдупляет почему его программа ведет себя не так как надо. И это не из-за ошибок в коде.
Не знаю как сейчас в Паскале, в мое время в нем была невозможна передача переменного количества аргументов в определенную пользователем функцию. Это в отличие от C. Вопрос ко всем: почему?
Я очень надеюсь, что Zanginsan дает своим слушателям понимание.

[Zanginsan]

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

В языке С (и тем более ассемблере) границы абстракции определяются программистом.
Для наглядности восприятия этой мысли я подготовил вот такую картину мира:





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

[voID]

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

[Zanginsan]

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

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

С другой стороны каждое средство хорошо для своей цели.

[Zanginsan]

развиваю свою мысль на тему "О полезности понимания устройства микроконтроллеров и умения их программировать"...

Большое количество автомобилей на дорогах Иркутска (и не только) и постоянные пробки меня не расстраивают ни капли. Я смотрю на это как на возможность.
Безаварийное движение в интенсивном потоке автомобилей - умение, которое приходится отрабатывать годами. И овладеть этим умением под силу многим.
Но чтобы перестать орать на чайников и неуклюжих водителей требуется гораздо больше работать на собой.
Я встречал, пожалуй, лишь двух водителей, которые умели предугадывать ситуацию на дороге на 2 шага вперед, видеть на 360 градусов, не борзеть, почти совсем не нарушать правила, оставаться вежливыми к детям и старушкам и при этом всегда сохранять полнейшей душевное спокойствие и равновесие.
Вот бы мне так научиться, мечтаю с тех пор... И уже почти не ору вслед дебилам.

Но, это лирическое вступление. Вернемся к круговому зрению и прогнозированию ситуации на дороге.
Почти все современные автомобили оснащаются парктрониками. Удобно. Но при стоянии в пробке приходится отключать их. После этого они уже бесполезны.
Заставить работать парктроник не только при постановке автомобиля на стоянку (парковку), но и в пробке - очень годная идея. А добавить к передним и задним сенсорам еще и боковые - вообще отличная мысль. Что нам это даст ?
Ультразвуковой датчик расстояния (та часть парктроника, которая встроена в бампер) хорошо работает на коротких расстояниях (чем меньше расстояние, тем меньше пятно отражения) и на точности его почти не сказывается туман/пыль/грязь. Подключив датчики к собственноручно разработанному устройству, можно реализовать систему, помогающую маневрировать в плотном городском потоке:



Обработав данные сенсоров расстояния, учтя скорость движения строим "зеленый коридор" и с помощью простой индикации выдаем подсказки, типа "Правее и вперед"