Woodoo

Как сделать газовый чайник автоматически отключающимся при закипании? Может существуют проекты, и я зря ломаю копья.... Подскажите. На данный момент вижу решение следующим образом: Есть газовая варочная поверхность с контролем подачи газа по термопаре. Соответственно внутрях существует электроклапан, который рубит подачу газа. Гугл говорит что это делается так: Вроде все просто - коротим термопару (эмуляция погасания пламени) и газ отключается. Соответственно тут будет микроконтроллер. Также есть газовый чайник, нержа. Планирую в стенке, ближе к нижней части, просверлить отверстие и впаять (pb-free) ds18b20 в стальном колпачке (на али за 1usd). Вывод как-то термоэкранировать от тепла, идущего снизу. Контроллер поместить повыше, где-то около ручки. Далее связать эти два контроллера по nrf24l01. Вроде все просто. Хотел бы услышать советы по: 1. Внедрению датчика в чайник 2. Способу питания (естессно автономного) контроллера на чайнике Заранее спасибо.

Доброго времени суток. Собстно вопрос такой: какова максимальная индуктивность SMD катушки любого исполнения? Если кто знает SMD индуктивности порядка 100 мГн - подскажите. Проблема, вобщем, в том, что надо построить режекторный LC фильтр, работающий на частоте 750 Гц на SMD.

Пользуйте AMD Athlon без радиатора:) Точно не замерзнет.

Выше было сказано, что: "Приехавшие упирали на высокую помехоустойчивость мк ST. " Есть ли у кого опыт, который говорит о том, что данный тип контроллеров действительно обладает высоким уровнем помехоустойчивости? Я нерешаюсь выбрать для проекта этот микроконтроллер, т.к. нигде ненашел практических доказательств его помехоустойчивости... только лишь сама фирма пишет "ST6 MICO IS EMC CHAMPION"... ... специфика проекта такова, что первой, и самой важной особенностью проца должна быть его высокая устойчиваться к воздействию помех. С нетерпением жду comments

Я писал выше, что код "HAS NO EFFECT" (как любит выражаться компилятор:) ).

Уухх, разобрался. спецификация Си не декларирует порядок выполнения посдикрементов при выполнении конструкций подобного рода. Оставляет на усмотрение компилятора. Поэтому и матерился компилятор. Спа за ответы! Тема закрыта. :) П'ятныця... это хорошо :cheers: :cheers: :cheers:

Доброго времени суток! странное поведени компилятора заключаеться в неверном интерпретировании оператора пост-дикремента. Почему так происходит - непонятно. //Header file __near __no_init volatile struct { unsigned int Result; enum {K2 = 2, K4 = 4, K8 = 3, K16 = 4, K32 = 5, K64 = 6, K128 = 7} PS : 3; unsigned char IE : 1, IF : 1, FR : 1, SC : 1, EN : 1; enum {ADC0, ADC1, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, VBG = 0x0E, GND = 0x0F} MUX : 4; unsigned char : 1, LAR : 1; enum {AREF = 0, AVCC = 1, Internal = 3} REF : 2; } ADC @ 0x24; //Source file ADC.MUX = 3; Array[ADC.MUX++] = ADC.MUX; // почему? [3] = 4 ADC.MUX = 4; Array[ADC.MUX] = ADC.MUX++; // [4] = 4 mux = 5 тут ок Код составлен для тестирования. Смысла в нем искать не надо. Проблема заключаеться в том, что компилятор некоректно выполняет вторую строчку src. файла (Array[ADC.MUX++] = ADC.MUX;), в результате чего в третьем элементе массива записывается значение 4! Я уж потерял веру в Си, пока разбирался с проблемой. Может подобное свойство - следствие использования облости ввода-вывода? НО! замена переменной ADC.MUX на DDRD(к примеру) приводит к нормальной работе: Array[3] = 3, Array[4] = 4. при этом компиялтор, как по мне, безосновательно выругался, когда компилировал этот код: Замечу вуругался на оба варианта, с ADC.MUX и с DDRD (точнее PORT.D.DIR.Value :) ), но второй, повторюсь, скампилировал верно! В чем проблема? Кстати, может кому понравится такой подход - организация регистров перефирии в смысловые структуры (ах как не хватает классов си++)? Если кто использует такой подход - поделитись опытом.

Может кто достаточно хорошо знаком не с одним-двумя типами МК, а с побольше. Может кто сможет рекомендовать контроллер, который стоит использовать в системах с жесткой ЭМ обстановкой? Может какие-нибудь военные или для космических разработок или еще что. В ближайшем будущем проведу исследования (может уже существует???) всех наиболее распространненых марок контроллеров на их ЭМС. Нехорошее у меня предчуствие, что малопотребляющие современные контроллеры (AVR MicroPower, MSP и др) намного менее устойчивы к ЭМ помехи чем старые, более токопотребляющие МК.

2Serega Doc: Возможно немного погоречился со словами "Еще как могут", но всетаки считаю что могут. На правтике 100%-ой достоверности такого факта наблюдать не удавалось, но исходя из проанализированных сбоев(специфика работы такая) приходили к выводу, что кроме как изменением содержимого озу объяснить факт сбоя не удастся. Могу точно сказать, что ЭМ помеха может привести к некоректной работе программы, тоесть, спонтанному переходу ядра на выполнение иной инструкции, нежели следующая, что может привести к фатальному исходу. Достаточно сильная помеха в первую очередь повлияет на вывод сброса МК. Это несомненно. 2SasaVitebsk: интересно, насколько энергичную помеху вы создавали, и в каком диапазоне, испытывая озу МК? Не могли бы вы меня убедить в нецелесообразности проведения подобных тестов? (дело в том, что в скором времени буду заниматься именно этим) 2автор топика: Ну так, как на счет более подробной информации о вашей проблеме? Или же уже все разрешилось? Сообщите, интеренсо.

не согласен с предыдущим постом: Еще как могут. Вы не шутите? 30 ампер комутируете возле камня? У вас нет индуктивностей ни в нагрузке ни в проводниках? ... уверен что есть. а это чревато гиганскими выбросами напряжения. согласен , что первым делом страдает ресет, но данные могут измениться еще как! 2 автор топика: на счет ЭМС - опишите ЭМ обстановку вокруг камня.

или я чтото не понял или так: под словом "определить что мы приняли" пониметься алгоритм поиска совпадающего номера/илиЧегоЕще в базе данных. Если так, то подтвердите это, так как без надобности неахото описывать алгаритм поиска в базе данных.

может и дождемся... извеняюсь за оффтоп, просто вспомнил фильм один, до ужаса глупый, но местами смешной - "Миллион лет до нашей эры". Вождь грязноволосых говорит: - у меня есть план! ... что вы об этом думаете? - но вождь, Вы же ничего не сказали? - как не сказал? ... (молчание) Что вы об этом думаете? P.S.: уже даже интересно стало, что же автор имел ввиду

Цитата: ... и определить что мы приняли... Однозначно: 10 байт приняли. :) А если серьезно, что Вы имеете ввиду под словами "определить что приняли"? Поподробнее плз.

имел опыт с воспроизведением аудио используя шим, но он был програмный, и написан на х86. Воспроизводил не голос, а музыку в формате 11050 Гц, 8 бит. Вывод на ПК-спикер. + элементарная р-ц цепочка = очень приемлемое качество как для ШИМа. Так что мой совет: поднимите частоту, хотябы вдвое + элементарный фильтр, а уж потом усилитель (ни как не наоборот, импульсы усиливать не стоит). Для голоса этого должно хватить с избытком. P.S.: Так как в кампе небыло звуковой карты, слушал таким оброзом музыку довольно долго, ставил Электроника У-101-стерео + S30 = супер!

Доброго времени суток. Есть необходимость собрать анализатор шини I2C. Анализатор должен собирать всю информацию о шине, т.е. все возможные временные параметры, такие как длительность единиц, длительность нолей, частота следования клока, качество старт и стоп условий, нарастание-спад уровней, время удержания акнолоджеса ведомым, возникновения коллизий на шине (хотя едвали получится, из-за специфики работы мультимастера). Так же вся собранная информация + сами данные должны передаваться в компьютер по рс-232. Ничего сложного нет, как говорится: бери да пиши... НО Аппаратный I2C AVR не обладает всеми нужными ф-циями, им можно только данные собирать. Следовательно нужен програмный I2C. Но сильно сомниваюсь, что програмный и2ц сможет отслеживать шину, работающую на полной скорости (до МГц или хотя бы до 400 кГц клока). Вопрос: что посаветуйте, может стоит воспользоваться более скоростным камнем? Или может собрать часть анализатора на жесткой логике? Может у кого был подобный проект?