toksoft

Тогда уже имело наверное смысл вместе с кристаллом запаянным заказывать ? Самостоятельно долго, и в общем достаточно затратно. Да, это в корпус на DIN рейку. Одна из 4 плат. На счет 90 градусов в курсе,- но ВЧ тут нет, расстояния небольшие, а плату после сборки я еще вскрываю хитрым лаком (не цапоном).

Шикарно,- даже шелкография присутствует. Сами разводили ? У меня несколько попроще:

dip, а каких собсно результатов вы ожидаете ? Все вдруг метнутся публиковать свои схемные решения и коды программ ? Вряд-ли... Все те, кто умеют и могут,- работают себе тихонечко, и не "светяться", чтобы значит конкуренты идею "на лету" не сперли. Я как Daletу, так и вам (и всем остальным) предложил помощь. Как в схемотехнике, так и при написании программы. Единственное условие - публикую на форуме. Для всех. Скажите что именно вас "мучает". Начните хоть что-то, возникнут вопросы - попробую ответить. Бесплатно, и для всех.

Я этот самый фильтр увидел "живьем" только через год, кода была выкачка, и я его достал промыть. Похоже сам фильтр склеен из 2х частей труб,- есть шов. Прочный. Чем-то напоминает капроновую нить, с какой-то пропиткой. По размеру частиц на предмет фильтрации, "на глаз" - 200. Плюс минус. Промывать пробовал гипохлоритом путем мягкой щетки. Осветлять конечно осветляет, но как на счет "вымывания изнутри" частиц - не уверен. По большому счету, поскольку это 3й колодец, то твердого осадка там по идее быть не должно, или должно быть немного, если конечно не перестараться с залповыми выбросами. Поисками "с пристрастием" не занимался. Если найдете раньше- маякните.

Фильтр на картинке похож, но у моего стенки раза в 2 толще. Сам мерял и рисовал. После реализации уже не корректировал. Размеры (высота) поплыли, на всех переливах тройники, а не уголки. Поищу, кажется чертеж в Visio остался. Не подскажете, где бы подобный фильтр "на всякий случай" выкупить можно ?

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

Когда-то уже постил: www.stroimdom.com.ua/forum/showthread.php?t=173232 На картинке есть некоторые неточности, это я так хотел изначально, но прораб таки уговорил меня внести некоторые коррективы. Обычный переливной септик имени 3х колодцев. Дно у всех 3х - цементное. Из последнего колодца - труба наружу (110) - в графы. 3 колена по 90 градусов. В последнем колодце - труба чунь ниже боковой переливной направлина вертикально вверх, и вот туда вставлен фильтр такой, длиной под 2 метра. Не вплотную, с небольшим люфтом. На счет материала фильтра,- сказать сложно. У меня тогда было не особо много времени, и я просто отправил спецификации прорабу. Забыл спросить из чего. Материал явно тверже чем полипропилен (который например в BB). Уже столкнулся с тем, что сейчас такой фильтр найти проблематично, подозреваю что искать нужно отнюдь не по критерию "фильтр". Отмачиваю, очищаю раз в год, пока работает.

Графы работают, но только вот сбрасывать через них твердый осадок - чревато... Свой септик проектировал сам, 3 колодца, в 3м полипропиленовый фильтр, длиной метра под 2, который в 110й трубе (вертикально). Через этот самый фильтр, все распрекраснейшим образом уходит в 3 блока (не тоннеля). Песок. Подсыпка - сантиметров 10 - гравий, кажется фракции 30. Геотекстиль - сверху, с заходом на боковые стенки. УГВ от дна графов, в разное время года - 50 - 100 см. 4 года - проблем нет. Думаю, внукам еще хватит. Фильтр правда такой чистить немного морочливо, или новый искать. Длина выбрана из соображений "снять крышку колодца и вытащить".

Одна из самых главных функций современных микропроцессоров - это отсчитывать время. Имеется в виду не календарь, а именно временные интервалы (например 20 миллисекунд). Для этого используются некие внутренние ресурсы, например прерывания, которые происходят с заданной частотой (например 1000 раз в секунду, т.е.каждую миллисекунду). В этом случае, в обработчике такого прерывания может стоять всего одна команда, например counter++. Программа пользователя может анализировать счетчик, и зная что его значение увеличивается 1000 раз в секунду, выполнять некий анализ и последующие действия. Очень часто, в программах, которые публикуются на просторах интернета используется простой вызов - например delay(100). Этот вызов предполагает задержку 0.1 секунду. вроде бы все просто, и удобно, но ... Выполнение всей вашей программы приостановится на 0.1 секунду, и в этот период времени, кроме "внешнеинициируемых воздействий" - прерываний, процессор будет делать ничего. Это уже получается совсем не real time, а если таких задержек несколько, то спрогнозировать временные интервалы предсталяется достаточно проблематичным. Если программа предназначена для "real time" управления,- например PWMить моторчик, то добавление одного или более вызова delay можно будет услышать "невооруженным ухом". Для того, чтобы избежать таких задержек, можно перед, или после вызова необходимой вами функции, зафиксировать значение counter, а затем проверять и, в случае если 0.1 секунда не прошла - выполнять другие задачи. Альтернативный вариант - это использование например RTOS. Достаточно компактная OS, которую в общем можно использовать например на DUO. Литературы в сети достаточно, можно ознакомиться, но в общем "порог входа" для начинающих тут достаточно высокий, нужно представлять себе сколько стека нужно выделить каждому потоку, как исользловать mutexы, ... В общем "сел и душа полетела в рай" так просто не получиться, придется изучать и экспериментировать. Ранее, когда минитюризация кристаллов еще "не достигла таких высот", измерители интервалов времени реализовывались как отдельные модули, а разработчики вынуждены были глубоко изучать ассемблер конкретного кристалла, с пониманием того, сколько тактов занимает каждая команда. В общем это и сейчас не лишнее, т.к. позволяет более точно понять какой именно кристалл подходит для ваших задач. Например MEGA, имея тактовую частоту 8 или 16 mHz, будет выполнять 8 или 16 миллионов тактов в секунду. Одна команда "mov" - это 2 или 4 такта. "jmp" - 2 такта. Это означает, что MEGA может выполнить 8 000 000 / 2 = 4 000 000 операций mov в секунду. Однако и тут есть проблема,- прерывания. 1000 раз в секунду, происходит сохранение регистров в стеке, увеличение счетчика на 1, а затем восстановление регистров из стека. Предположим что все это "съедает" 80 тактов. Попробуйте для себя посчитать какая будет "реальная" частота процессора, учитывая дополнительную прогнозируемую нагрузку. Имея тольго "голый" счетчик counter, уже можно задумываться о создании "часов", отсчитывающих секунды, минуты, часы, дни и месяцы. Но и тут ведь "засада": Размерность практически всех счетчиков - 32 бита. Предполагая что этот самый счетчик увеличивается на 1000 каждую секунду, этот самый счетчик рано или поздно переполнится,- например через полтора с хвостиком месяца. В зависимости от того, насколько часто пользовательская программа анализирует состояние counter, можно будет понять "перевернулись мы или еще нет". "перевернулись",- это когда новое значение counter будет меньше чем старое. В этом случае посчитать сколько времени прошло с момента предыдущего чтения значения counter все еще можно. Чего нельзя узнать,- это сколько раз перевернулись. Может один, а может уже и больше. Нужно либо делать отдельную обертку на millis (и как можно чаще ее вызывать и анализировать "переворот"), либо брать 64 битную переменную, и написать свой обработчик прерывания. Если вы не ограничены в месте, то можно использовать специализированную плату таймера - с батарейкой, которая продолжает отсчитывать время даже при отсутствии питания. На некоторых кристаллах изначально присутствует возможность подключения батарейки, чтобы значит не пришлось городить дополнительный огород с платами. Иногда возникает необходимость мерять даже ни милли, а микросекунды. Разницы в общем особой нет кроме того, что уже можно начинать обращать внимание на тактовую частоту кристалла, чтобы понять "хватит" его или нет.

Похоже затихла немного тема,- либо никто не заморачивается, либо не считает нужным делиться опытом. Попробуем исправить. Наверное у многих возникают часто обоснованные сомнения вида "какой нафиг C++ в 32к flash, и 8к оперативки" ? А легко, причем с увеличением количества строк кода на плюсах (желательно "разбросанных" по скажем cpp и h файлам), размер скомпилированного модуля начинает увеличиваться нелинейно. Давайте попробуем посмотреть на примерах. Предположим что у нас есть некий класс class LED { public: bool GetStat () { rerturn bStat ; } void SetStat ( bool bS ) { bStat = bS ; } private: bool bStat ; } ; На первый взгляд кажется необоснованно громоздким, правда ? А вот и нет. Если просто объявить bStat как скажем глобальную переменную, то скомпилированный код как для случая с глобальной переменной, так и для случая с классом, будет занимать совершенно таки одинаковый объем. Это будет 1 или 2 mov оператора (4 или более байта), причем практически на любом кристалле. Так для кого тогда такая красота нужна ? Для вас, как для того, кто хочет что-либо изменить без превращения вашего кода в большой мусорник. В случае с классом, во первых компилятор "не пропустит" код, который "напрямую" захочет изменять значение переменной класса. Есть конечно условия когда может пропустить (friend или унаследованный класс например), но для этого нужно специально постараться. То есть например test.bStat = false ; не сработает. Не скомпилируеться. Если например вам понадобиться еще и включить/выключить светодиод, помимо установки статуса, то не нужно будет переворачивать вверх дном весь ваш код, а достаточно будет например добавить команду записи в соотв. порт в методе класса и, собсно все. С bool пример наверное несколько неудачный, т.к. этот самый bool, несмотря на всего 2 возможных значения (true и false), в самом коде превратиться в байт (8 бит), а отнюдь не бит. Если память поджимает, то можно сразу объявить uint8_t bStat, и тогда вместо одного, мы имеем целых 8 бит, которые можно использовать, а можно и неиспользовать. Как "взвести" бит ? Очень просто: bStat |= 1 ; Сбросить bStat &= ~1 ; Изменить состояние бита на противоположное: bStat ^= 1 ; Так же можно взвести 2,4,8,16,32,64,128 бит (radix=10), ну или например 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80 (radix=16). Итого, по финалу имеем 8 бит вместо обного, при совершенно одинаковом объеме памяти. Хорошая практика использовать не 0x80, а скажем LED_ON, который можно предварительно определить путем #define. Скомпилированный код от этого не изменится никак, т.к. еще до самого процесса компиляции, препроцессор пробежится по тексту, и заменит все LED_ON на его значения. Чуть хуже обстоят дела с виртуальными классами, наследованием и прочей классикой плюсов. Если вы попытаетесь использовать все возможности языка, компилятор может таки "не переварить", и тогда часть логики (например в случае с dynamic binding), когда компилятор на этапе компиляции не может определить какая именно функция с сигнатурой (возвращаемый тип, и тип операндов), должна будет вызываться, тогда этот анализ "уползет" в сам исполняемый код, и ваша программа может увеличиться сразу байт на 200. Не всегда оправдано использование std контейнеров, хотя конечно есть порты map, vector, list, queue, ... Здорово увеличивает объем памяти, хотя конечно делает программу брлее универсальной и простой для внесения изменений. У Arduino уже как правило в поставке включен класс String, штука конечно удобная, но попробуйте использовать char * вместо String, и вы сразу заметите как ваша программа "похудеет" (скомпилированный код). Еще очень "прожорливые" sprintf. В "больших" компиляторах, где можно "развернуться", к скомпилированному модулю либо прилинковывается, либо используется внешняя универсальная библиотека, которая занимается разборкой строки форматирования, например вида "%02u:%02u:%02u %s-%s". Для большинства "маленьких кристаллов", включая Arduino Duo, Cortex M7, и прочих "монстриков", gcc озадачится каждым вызовом sprintf индивидуально (без универсальной библиотеки), добавляя изрядный кусочек кода для каждого отличного от остальных sprintf, а не за счет статических строк (формат вывода), как кажется некоторым. Имеет так же смысл "с осторожностью" пользоваться рекурсией, т.к. например 8кБ ОЗУ, сакжем MEGA использует для хранения переменных, кучи и стека. Помимо ваших вызовов процедур, которые "съедают" минимум 4 байта от стека, есть еще и прерывания, которые могут "глотнуть" 64+ байта стека. В какой-то момент, стек пожет просто "наползти" на данные, и это бует очень грустно, т.к. такую ошибку будел достаточно тяжело вылавливать. Если вы не используете глобальные (static) переменные, то все те переменные, которые вы используете в ваших функциях/методах, будут так же размещены в стеке, и "умрут", в точности перед возвратом из функции/метода. Если используется класс, структура, или указатель, то в стеке будет именно указатель, а не "пеленка" переменных класса. Пример: class config { public: uint8_t nByte ; uint16_t nWord ; uint32_t nDword ; uint64_t qWord ; uint32_t test ( uint64_t ) { ...} } testc ; если попробовать например записать все это хозяйство скажем в eeprom, то запишется 1 + 2 + 4 + 8 + 2, или 1 + 2 + 4 + 8 + 4 байт. То есть 17 или 19 байт,в зависимости от архитектуры кристалла (16/32 бита адрес), причем неважно сколько десяток или сотен строк кода будет содержать метод test. Это кстати не самый лучший вариант, лучше всего выравнивать по границе 2х, или даже 4х байт, то есть дополнить этот самый класс 1 или 3 байтами (до 20), путем добавления например uint8_t reserved1 или/и uint16_t reserved2 ; Сразу неочевидно, но в будущем здорово поможет при переходе на более мощный кристалл, где скажем запись во flash может выполнятся в терминах 2 или 4 байт (16 или 32 бит). По этой самой причине рекоммендую избегать "общепринятых" объявлений переменных типа int, unsigned, short, long, и long long. У разных кристаллов (8/16/32 бита архитектуры), и эти самые типы могут, и имеют совершенно разную размерность. У кого-то int = 4 байтам, у кого-то 2.Если у какого-нибудь кристалла (компилятора и инклудов) нет include, в которых определены uintxx_t (не встречал), то тогда лучше скажем typedefом объявить, тогда ваш код можно потом относительно безболезненно перенести на практически любой кристалл.

Даже не знаю ... А если скажем меандр от какого-то старого UPS ? Хотелось красиво и универсально, но получается сложно и громоздко. Операционник более универсально, можно даже частоту посчитать и искажения "нащупать", без дополнительных комплектующих. Хотя в общем детектор 0 - это 3-4 детали ...

В общем конечно так, но Dalet ведь хотел мерять именно мощность. Одним измерителем тока тут не обойдешься, нужно еще знать напряжение. Скажем в течении 1 секунды, напряжение может "танцевать" от 160 до 240 вольт. Нужно определиться с периодом, за который планируется подсчитывать. Например одна секунда для 50Hz. Нужно выловить некий массив значений RMS тока и напряжения, потом обработать. Если с током вроде-как вопросов нет, то с напряжением есть, причем они достаточно серьезные. Просто мостом и резисторным делителем для более или менее достоверных результатов тут действительно не обойдешься. По сути, нужно "уложить" синусоиду, или нечто подобное, в диапазон напряжений, допустимых для аналоговых входов кристалла. Я предложил операционный усилитель с обвязкой, может конечно есть какое-то более элегантное решение. Так вот сходу без помощи google ничего другого в голову не приходит ...

Если true RMS, то я бы "запихнул" синусоиду, или сигнал схожей формы в диапазон до 3.2 или 4.9 вольт (по модулю). Ток можно мерять например обобщенными аллегровскими чипами. Потом считаем,- ничего военного. Если мы знаем что на входе 50-60Hz, то частоту сэмплирования можно взять 150-1000Hz, в зависимости от того что нужно "ловить". Если нужно 6 каналов, то это 6 напряжений, и 6 значений тока. Итого 12 каналов. Есть еще тонкости с шумами, и температурой, так что наверное нужна готовая плата имени 12 ADC, со связкой I2C или SPI. Замена контроллеров сетевого напряжения в планах, посему когда-то искал датчики холла, находил и более "породистые", но нужно заказывать, т.е. в Киеве нет. Колечки - это чтобы значит быстро и не морочиться. Dalet,- вы давно платы разводили ? А компоновка в корпусе ? Это нужно все бросить, и только этим заниматься. Понятно что рассчитать и собрать на макетке или собачнице проблем не вызывает. Предположим что прошивка готова, и нужно это все ведро с деталями и пару метров монтажных проводов уложить на одну или более плат. Воодушевляет ? Хорошо хоть что сейчас плату можно в Киеве заказать. А потом "вдруг" оказывается что дорожки, по которым тактируется I2C или SPI слишком близко к силовым. Ну "завтыкал" orcad. Выкидываем нафик полуавтоматическую трассировку,- и полностью вручную. Еще пару дней, и это в лучшем случае. Если говорить об обвязке самого камня, то да, я в общем тоже проблем не вижу,- нужно увеличить количество часов в сутках, тогда появятся шансы. Ну Ок, все готово, платы разведены перепаяны, пару циклов тестирования прошло, теперь нужно как-то "облагородить" корпус, хотя-бы названия выводов на корпус нанести. Можно вместо orcad скажем diptrace использовать,- там попроще, но это практически все ручная работа. DIN рейка это хорошо, но в замкнутом объеме еще неплохо посчитать, или хотя-бы прикинуть тепловыделение, иначе уже через пару часов железка начнет работать уже совсем иначе. Сама программа и отладка,- это 1/4 часть задачи, причем не самая сложная. Взять сами датчики (не платы) имени allegro, наверное какую-нибудь обвязку из 10-15 деталей на каком-то операционнике для "упаковки" входного напряжения в нужный диапазон, потом все это "склеить" и начать рисовать программу. Только потом можно начинать эпопею с WiFi, причем учитывая времянки, схема измерения и рассчета на одном кристалле, а визуализация и передача на другом. В случае если дисплей простой, то визуализацию можно попробовать оставить на основном кристалле. "разорваться" на несколько частей, а именно алгоритмы и программы + схемотехника и упаковка, достаточно сложно. Где-то так...

О WiFi временно забудьте,- это потом. Для того, чтобы измерить напряжение, его таки нужно будет выпрямить. Поскольку диапазон напряжений у вас я думаю известен (скажем 160-250V AC), то можно обойтись делителями. Матчасть (пример): accrochages.drone.ws/en/node/125 Выпрямить можно одним, двумя диодами, или мостом. Для упрощения можно взять готовую диодную сборку, например DB207. До выпрямления, можно озадачиться измерением тока. Для этого нужно купить 6 датчиков, фактически ферритовых колечек с десятком-другим витков. Можно сделать самому, из феррита магнитной проницаемостью 50 или 100 и, скажем, провода, выдернутого из сигнального кабеля. Если делать самому,- будет дешево, но придется калибровать - это морочливо. У меня была такая задача, нужно было быстро, нашел старую экономку, достал оттуда 3х обмоточный дроссель (маленькое такое колечко), мотнул кажется 15 витков провода, а потом пару дней калибровал. При кажущейся простоте, и доступности комплектующих, задача не такая простая. В качестве платформы для разработки можете "окинуть взглядом" STM32F103,- это более "взрослая" штука, занимает меньше места, стоит менее 100грн (понадобится еще "свисток" для программирования), и есть хороший инструментарий. Экран, если "простой", скажем 4*20, проблем не представляет. Если захотите с графическим, +2 месяца. Уже после того, как будет готов прототип, можно озадачиваться WiFi. В принципе, можно конечно сразу взять 8266, пару сдвиговых регистров, плату ADC, но это затянется на год, или может даже больше. Изучать "как" на примере 8266 мне кажется не самая лучшая идея. Каждая итерация по кромпиляции и заливке новой прошивки может занять минут 5. Дебаг, чтобы значит понять "где мы",- светодиодами или экранчиком. В общем так просто вы не отделаетесь. Если хотите чтобы получилось,- лучше всего найти толкового электронщика, который будет заничаться схемными решениями и платами, а сами сосредоточьтесь на концепте и программинге. Это пожалуй самая большая проблема. У меня не получилось,- по прежнему ищу. Проводил "кастинг" у 7,- бесполезно. "старички" не знают современной элементной базы, а "свежевыпущенные" знают как сделать то, что они знают, а не то что вам нужно. У Arduino может не хватить памяти, если у вас разгуляется фантазия (а она разгуляется,- поверьте), и вы поймете что можно "добавить еще, ...". Можно взять Mega или Duo,- но там очень негуманный форм-фактор. Обращайте анисание на уровни сигналов для каждой платы - 3.3V или 5V,- если не угадаете, придется еще заморачиваться согласователями.

Я когда-то кажется месяц или чуть больше назад, "встрял" в дискуссию касательно setup & loop + main. Наверное все-таки слегонца переборщил, удалили сразу, посему на всякий случай решил попросить. У меня есть минут 30 пару раз в неделю, поделиться с форумчанами знаниями, посему и упомянул. :-)

Diver, я извиняюсь за offtop, немного увлекся, но попробую компенсировать. [offtop] Ув. Модераторы,- пожалуйста не удаляйте сообщения, я как бы коммерческих целей пока не имею, и с удовольствием готов поделиться с местной аудиторией некиим опытом,- бесплатно. [/offtop] Большинство считают Arduino "игрушкой", которая не предназначена для разработки "серьезных" приложений. Это большущая ошибка. Кому-то не нравится setup() & loop(), кто-то считает что "можно иначе". Иначе - можете исполнить самостоятельно, main (int argc, char *argv []) никто не отменял,- это всего лишь такой себе programming convention, который приняли в качестве стандарта. Концептуальной разницы нет, и мнение тех, кто утверждает обратное, мне кажется можно смело игнорировать. Компилятор - это такая штука, которая преобразовывает ваши самые смелые фантазии, в машинный код. Основная задача компилятора,- это "зажать" вас в некоторые рамки, которые позволят компилятору формализовать ваши "хотелки" в машинный код. Помимо компилятора, есть еще такая штука как linker. Это такая утилита, которая компонует уже готовые, ксомпилированные в машинный код в единый EXE файл. Расширение приведено в качестве примера, т.е. в общем совершенно пофиг какое оно будет. Расширение,- это не более чем признак для какой-либо утилиты, которая собственно либо занимается прошивкой кристалла, либо операционной системы, которая загружает код в память, и передает на него управление. Почему я уделил внимание linkerу: эта самая утилита, помимо компоновки кода, имеет еще несколько достаточно важжных задач, без которых ваша программа не заработает: 1. Настройка относительных и абсолютных адресов. Каждый кристалл (в том числе и Intel C5, 7 или какие уже они там по счету), имеет свою систему адресации, т.е. программа загружается в вполне конкретную область памяти, и нужно чтобы все переходы (скажем Jump, в терминах Basic), знали куда собсно они должны "прыгать". В случае Intel архитектуры, jmp может быть как абсолютный (на конкретный адрес физической памяти), так и относительный,- например "отсюда + 120 байт". 2. Когда вы пишите свою программу, там 100% есть процедуры, функции и переменные, которые в вашей программе вполне себе могут и не использоваться, т.е. например вы написали большущую кучу кода, а реальные вызовы - это 2-3 функции. Да, так вот именно linker занимается тем, что собирает в готовый ".exe" только то, что используется в вашей программе. Остальные функции компилируются (преобразуются в машинный код), но не будут являться частью исполняемого файла (или прошивки кристалла). Да, так вот gcc комилятор (вместе с linker - компоновщиком),- это "сердце" вашей системы. Именно он преобразует скажем "a = 24" в "mov r1,0x18", а затем в 1 или 2 байта инструкций (нули и еденички), которые впоследствии исполнит выбранный вами процессор. Нужно запустить нкую цепочку команд, включающую в себя собсно компиляцию, сборку, настройки, и прошивку кристалла. Эта штука называется toolchain, и представляет собой такие себе строчки текста, с кучей непонятных символов, т.е. набор команд (для command.com в windows, sh, ksh, ... для unix), которые исполнят все необходимые действия. Преимущество Arduino в том, что разработчики этой штуки сделали некий визуальный редактор (Java), при помощи которого вы можете редактировать исходный файл, а так же большущая куча настроек и готовых команд, которые будут выполнены "втихаря", когда вы нажмете нужную кнопку в среде Arduino. Помимо Arduino, есть еще куча разных "frameworks", которые как правило базируются на gcc, в который упрощенно говоря, внесли некоторые модификации для того, чтобы получался максимально оптимальный код для данного конкретного кристалла, с учетом особенностей его архитектуры. Это например Keil, IAR, Eclipse, Cocox, Visual GDB, и еще парочка не столь "знаменитых". gcc, который каждый свободно может скачать, самый "гуманный". Он "прощает" многое. И обращение к неициализированной области памяти, и переменные которые "типа должны быть 0 при инициализации, но забыли проинициализировать". Добрая и гуманная штука. Компиляторы в оболочках, названия которых я привел выше, не столь "гуманны". Они предполагают чтто персонаж не учится программированию, а точно знает что он делает (коммерческое приложение например), и пытаются уоптимизировать вусмерть, с целью экономии опреативной памяти и flash. Они (компиляторы), как правило так же построены на основе gcc, но имеют некоторые "хитрые" настройки и изменения, позволяющие им "упаковать" вашу буйную фантазию, заключающуюся например в 2000 строк c++ кода, в ~10-15 килобайт машинных команд, которые впоследствии будут выполнены процессором. Обычный gcc, при равных условиях (скажем без -o1, -o2, или -o3), скомпилирует этот же исходный код в 25-30 килобайт, но при этом "простит" вам многие ошибки. Что касается вопросов "чистый C или чистый C++",- для embedded приложений это не работает. Нужно хотя-бы чуть чуть понимать арзхитектуру выбранного вами процессора, и избегать некоторых моментов. Самое "больное место" - это аллокация и деаллокация памяти. В 32, 48 или 64kB памяти, достаточно сложно "вписать" управление памятью аналогичное тому, как это делает скажем Visual C на Intel платформе. Самое лучшее - избегать free() или delete []. Могут быть варианты. Есть так же нюансы касательно всем известной calling convention, когда например переменной типа uint64_t присваевается значение, скажем uint8_t. Очень часто бывает так, что меняются только младьшие 8 бит, а остальные 56 остаются заполненные хрен знает чем. Если говорить о конкретно кристалле 8266, поищите книжку "Kolban's_Book_on_ESP8266.pdf", в которой достаточно детально описываются все известные на данный момент функции, интерфейсы, и архитектура кристалла. Книжка еще в тираж не вышла, есть только бета, которая доступна для скачивания. Да, совсем забыл,- если вы услышите от кого-то что-то типа "main это круто", а "setup & loop - отстой" - гоните нахрен такого "специалиста",- он нихрена не понимает, и, скорее всего не поймет.

Возмите шахтную сирену. Это такая штука, размером с обеденную (или десертную) тарелку, толщиной сантиметров 20, и весом килограмм 5-6. Перед включением рекомендую отойти на расстояние минимум метров 10. Вой кошмарный. Посмотрите на olx, это старая совковая штука, но если найдете - не пожалеете. У меня было несколько, все на 220V.

Так. Давайте делить мух и котлеты. 1. WiFi (или ZigBee) имеет смысл использовать, т.к. есть уже готовые протоколы обмена, которые можно использовать, в том числе и с "обычного" компьютера. Вы хотите использовать какой-то другой дипазон/радиоканал ? А сам протокол обмена кто разрабатывать будет ? Это очень морочливо и долго. Я как-то особым желанием не горю писать свой TCP stack, или нечто подобное. 2. Я использую наверное штук 50 разных LEDов в доме но, честно говоря, вопросами диммирования не заморачивался. Когда-то игрался с RFDEL-71M, но как-то не нашел применения "нафига оно нужно". Кажется пол-года назад подгорел драйвер на t8 имени максус (официально недимируемом), пока чинил прикинул что таки можно задимировать. Опять же, не нашел ответа на вопрос "зачем". Есть еще пару экономок, доживающих свой век, их точно не представляю как диммировать, без преждевременной кончины схемы управления лампы. Ламп накаливания кажется уже нет,- нужно будет провести ревизию. 3. Перестаньте упираться и комплексовать. Рассматривайте 8266 как процессор, с частотой 40 или 80mHz, без WiFi, с 512-1024kb память, и digital io.. Его (WiFi) можно просто и тупо не использовать. Вы ведь не используете например одновременно PWM, ADC, ... когда выбираете кристалл для разработки приложения ? Так же и здесь. Можно взять Cortex (в нужном форм-факторе), но это стрельба из пушки по воробьям для данной задачи. 4. Мощность. Это важно, т.к. от этого зависит размер, в который все это хозяйство должно поместиться. 5. Для задачи именно димирования, я бы предложил совсем и напрочь отказаться от реле. Это можно реализовать иначе, если конечно вы не планируете киловатную нагрузку С или LC. 6. Если делать на заказ, то собсно кому это нужно ? Какой рынок потенциальных клиентов ? 1-5 шт в месяц ? Подсветка промышленных объектов ? 7. Можно отказаться от радио, и остановиться на ethernet или can. Можно управлять по электропроводке (до 1го трансформатора). Это в планах, но пока руки не дошли. Это не основной вид моей деятельности. Я как бы делал все под себя, сразу отказавшись от GSM, Audio, диммирования, и еще некоторых, на мой взгляд нерелевантного для моих задач функционала. Многоканальный универсальный таймер (все CRMы + немного от Shneider, ну и + то, что решалось несколькими модулями, а теперь можно в одном, по результатам "нескольколетней" эксплуатации) на все случае жизни, с экраном и программированием "a la" Siemens, контроллеры освещенности, температуры и влажности, тоже с экранчиком, кнопками, программингом и разными установками в разных видах и комбинациях (под все датчики, с возможностью задания параметров практически любых подключаемых датчиков). Измерители уровня воды, расход воды, в общем все такого типа. Все на DIN рейках, счастливо живет и работает. Задачи вполне "земные", и как на моем примере, и примере моих коллег, наиболее востребованные. Ессно понадобилось все это связать в одну сеть, чтобы не тянуть кучу проводов, и не бегать к каждому модулю. Ethernet не влазит, да и проводов столько нет, я на такие расклады раньше явно не рассчитывал. Если теперь нужно что-либо добавить,- то +2 или 3 места на DIN рейке и, собсно все. Может на майские выделю денек и попробую отказаться от 3х местных, попытаюсь уложиться в 2х местные. Ради интереса закажу разных диммируемых LEDов в Китае, на очередной поставке. Посмотрим, может действительно полезно и актуально ...

dip - что диммировать будем ? Лампочку накаливания ? C ? LC ? А если лампочка недиммируемая ? У меня кстати ни одной димируемой не стоит. Как то не довелось. WiFi это не для мобильного телефона. Зачем эти "понты для приезжих" ? Посмотрите reference ради на OASIS имени Elko, причем не на панели, а именно на функционал (актуаторы). Справитесь ? Я уже, причем совсем не за ту цену (концепция правда немного сместилась). Можете еще посмотреть скажем на RFSG-1M и RFSA-11B. Я думаю по описанию вы догадаетесь что к чему. Когда отключается grid, у меня есть необходимость адресно "заглушить" прожорливую нагрузку, согласно орпределенным правилам, зависящим от времени, положения солнца, и состояния луны. Да, да, реле приоритетов, конечно, пренепременно. С его прибитой гвоздями логикой. Когда-то я покупал такие (RF модули) за 700+ грн, го сейчас они стоят совсем несуразных денег. Таких примеров применения у меня около 10, и продолжают появляться. Поскольку на рынок со всем тем что я понаделал я выходить пока не имею времени и сил, сравнение с Siemens несколько некорректно. Как минимум по причине усилий, и workforce, которые использует Siemens, и использую я. Повторюсь еще раз, "породистое оборудование" требует "породистых доходов". Кончились породистые доходы,- с большой долей вероятности попрощайтесь со своей системой. Будет работать до первого дорогостоящего ремонта или замены. Сейчас я это могу расценить только как "пир во время чумы". Что касается WiFi, то вы почему-то в большинстве своем считаете что это все "для управления путем мобильного телефона". Wrong. Это централизованное управление, и сбор данных. И все. Да, я конечно нарисовал странички для того, чтобы можно было вмешаться в работу автоматики, но как-то за год с хвостиком воспользовался кажется 1 раз. Все остальное - это просто такой себе способ связи по воздуху, чтобы не тянуть новые провода. Более того, набрав 10 устройств, я таки обнаружил что эфир я испоганил вполне конкретно, и пришлось выдумывать как их "диммировать" и выводить из эфира, чтобы значит не постоянно фонили. Отладка схемы и программы, ясен пень присутствует. Куда ж без этого ? И даже бета-тестеры есть. Тестируют "вживую" у себя. Я по мере возможности исправляю баги, и перезаливаю прошивки. Тут все путем. Что вы все зациклились на Siemens ? У вас что, доход 5000+$ в месяц ? Если нет,- то поищите более дешевую альтернативу.

1. Собрать схемное решение на модулях особых трудностей не вызывает Вызывает. 2. Больше всего времени отнимает именно процесс отладки программы Чтобы писать и отлаживать, нужно вначале четко понимать что хочется получить на выходе. Если конкретные "хотелки" размыты на момент насала написания м отладки,- то тогда да,- вечность. 3. Либо сидеть и придумывать алгоритмы с нуля Что именно нужно придумать "с нуля" ? Давайте рассмотрим простой пример. Например "засунуть" WiFi контроллер в подрозетник. Вопрос зачем ? А типа "управлять". А как собсно управлять ? Что именно должно получиться в результате ? Предположим есть желание сделать дистанционный выключатель. Это уже 2 WiFi модуля, либо один модуль, и домашний маршрутизатор, предполагая что 8266 будет работать в режиме Station/AP. Как Station соединяться с домовым маршрутизатором, получать IP адрес из вашей подсети, и обеспечивать некий (можно визуальный) интерфейс мониторинга и управления. Если захотите 2й, 3й, ..., то уже вначале нужно предусмотреть как они будут взаимодействовать друг с другом. Наиболее как мне кажется "общий" вариант использования, это собсно управление (включалка/выключалка реле), путем некого алгоритма зашитого внутри, а так же как результат внешнего воздействия (WEB интерфейс например). Может оказаться что дом большой, и какой-либо из WiFi "не дострелит" до домашнего маршрутизатора. Тогда можно организовать некую mesh network,- это когда WiFi точка пытается достучаться до ближайшей доступной такой-же точки, а та уже маршрутизирует дальше, и так до самого домашнего маршрутизатора. А что должно происходить если пропало питание на одной из WiFi ? А на домашнем маршрутизаторе ? Вот все эти хотелки нужно как-то сложить вместе, можно даже нарисовать прототив WEB интерфейса, как вы его на данный момент представляете. Когда нарисуется "картина мира", т.е. окончательный на данный момент вариант хотелок, можно попробовать оценить возможность физической реализации оных. Например в подрозетник заведено только 2 провода, новый тянуть не хочется, хочется стать в разрыв. Ну Ок, можно и так. Потребление схемы в этом случае составит приблизительно 300mA по 5 вольтам (с обвязкой), или 1.5Wt. Вас это устроит ? Например светильники будут все время "в 1/10 часть накала". Можно импульсно, т.е. основной режим - до 50mA, а если событие - то тогда до 300. Тогда лампочки будет весело помигивать. Можно побороть ? Можно конечно, есть масса вариантов, реализация которых зависит например от типа установленных лампочек, и автоматики управления оными (диммер например). Или например с 10 люминисцентных ламп. Это достаточно серьезная индуктивная нагрузка, и нужно смотреть поместится ли реле нужного номинала в подрозетник. Или например есть желание сохранять текущее состояние контакта, и восстанавливать при пропадании/появлении питания. А собсно где ? Да, га борту 8266 есть flash память, где эти самые значения можно хранить, но у flash есть ограничения на количество перезаписей, и сохранение состояние контакта в этой самой flash чревато скорой кончиной flash. Можно побороть ? Конечно. Какая-нибудь обобщенная SRAM на батарейке, толоько вот нужно ли ? Да, 8266 можно поставить в режим WPA2, но вдруг захочется большего ? TLS ? Да, можно. Access list с IP, с которых можно ? Не проблема. Дополнительный логин/пароль для мониторинга/конфигурирования ? Элементарно. Вот только после выяснения всех подобных деталей, имеет смысл садиться и что-то писать. Для любителей BDSM можно конечно и на ассемблере (у 8266 кстати RISC архитектура), но лучше все-таки на плюсах. Ассемблерные вставки уместны, но только там, где нельзя или проблематично решить стандартными средствами. Всего-то делов. Не нужно отчаянно "шариться по интернету" в поисках "у кого бы срдрать", можно и нужно неспеша "сделать под себя". Или "на продажу",- как кому захочется.

Как все сложно.... Давайте попробуем развенчать мифы. Поехали: 1. ESP8266 - вожделенная мечта многих - полноценный WiFi. Есть разные модификации, 01, 03, 07, 12, 13, 14. На борту - процессор, по командам схожий на 8051, flash с 512 - 1024 килобайта памяти. Антенна, в некоторых моделях светодиод, в общем полный набор. 2. Как включить ? В интернете валом схем,- можно выбирать, но учитывая разнообразие моделей, нужно все-таки понимать что вы делаете. Питания, даже имени FTDI недостаточно, нужен дополнительный стабилизированный источник 2.9 - 3.3V, который вклюбчается совместно с FTDI или СР340. 3. Ой, а я боюсь что сгорит ... Нифига не сгорит. За год работы, даже с учетом первоначального непонимания, и веселых "ляпов", мне так и не удалось спалить ни одной платы. Даже если вы забудете поставить ограничивающие диоды или резисторные делители - ничего не будет. Просто не заработает. Думаю что точно сгорит если запитать от 5В (или подать на управляющие входы). Диапазон 2.9 - 3.6V. Меньше напряжение - меньше греемься, но и радиус уверенной зоны приема при этом уменьшается. 4. Выбор модели. 1, 3 модели обладают некоей глючностью, выражающейся в том, что иногда теряется connect, и происходят перезагрузки. Лечится тяжело, в зависимости от модели и партии. Я по финалу остановился на 12й модели, которая имеет на борту "чистых и незадействованных" 7 GPIO, ADC, и мегабайт flash, который впаян совместно с кристаллом под экранирующим металлическим корпусом. При некотором усердии, можно "откусить" GPIO2 и GPIO0, но это достаточно морочливо. В конце концов, 7 портов хватит как для клавиатуры, так и для управления 1-2 светильниками, или аналогичными нагрузками. 5. "чем" программировать Arduino, или любой другой приемлимый инструментарий. Keil к сожалению не заработает, уточнял у производителя. IAR тоже. Можно воспользоваться Visual Micro и Microsoft VC 12 или выше. В конце концов, вам от Arduino нужен только toolchain. Для ленивых. Неленивые способны сами. 6. На чем программировать. C/C++. Можете на ассемблере, но это будет достаточно трудоемкий процесс. Примеров валом, например github: github.com/esp8266/Arduino/blob/master/doc/libraries.md Не знаете C ? Извините пожалуйта, но тогда действительно Эпицентр или aliexpress. Вариантов нет. lua и прочее "приближение к массовой аудитории" думаю ваших вопросов не решит. Посмотрите например на SimpleWebServer. Все просто, доступно, понятно, и повторить как мне кажется, не составляет никакого труда. 7. Стабильность работы. 1й и 3я модели - никакая. Только путем морочливого тюнинга, персонально для каждой партии. Перезагрузка приблизительно раз в 30 минут. Конечному пользователю это как правило незаметно, только если именно этот момент не совпадет с активностью пользователя, ну или крайне кратковременным миганием. Сама перезагрузка занимает менее 0.2c, так что обычное реле как правило сработать не успевает. Поиск и присоединение к сети может затянуться секунд на 10, но при грамотно написанном коде, это отразиться только на невозможности управления черз WiFi. С 7й моделью чуть полегче, но она крайне требовательна к питанию. При работе уже на 3.1V могут наблюдаться совершенно неожиданные "спецэффекты". 8. Нагрев. 7, 12 и 13я модели, я не смог нагреть выше приблизительно 50 градусов. Это кстати стоит учитывать (тепловыделение), если хотите устанавливать в кормус на DIN рейку,- там вентиляция никакая, да еще и соседние модули греют. Если хотите снизить нагрев, есть режим deep sleep, который правда "съедает" один GPIO. При таком режиме нагрев не превышает 40 градусов (температура тела, если верить моему пальцу, и простому пирометру с "лазерным прицелом", которым я пользовался). 9. Шара. Ее нет. Те кто знают, или способны сделать что-либо дельное, вряд-ли будут выкладывать свои знания и кропотливый труд "за просто так". Как правило такое исполняют энтузиасты, которые путем экспериментов, проб и ошибок, медленно но уверенно делают железку все более доступной для массовой аудитории. Еще раз хочу напомнить, - минимальный порог входа - C/C++. C отладкой на этих платах есть определенные проблемы, так что методом "проб и ошибок" совсем без знаний, так просто решить поставленную задачу не получится. 10. Энергопотребление. до 300mA в пиках (зависит от модели). Это стоит учитывать при выборе источника стабилизированного питания. 11. Как подключить реле ? Через оптическую развязку, оптопару. Можно прямо от 220V, через ограничивающий резистор. Схемы можете нагуглить. Стоимость обвязки (4-5 элементов),- до 20 грн на текущий момент. Реле можно твердотельное, можно электромагнитное. Стоит совсем недорого. Если реле на 3.3, 5 и 12V. Потребление тока на 3.3 (для электромагнитного реле) самое "негуманное", так что лучше 12 или 5V. 12.Что будет в доме, если стоит 10 или более WiFi AP или клиентов. Будет невесело. Для streaming applications придется использовать 5gHz. Диапазон 2.4 пудет слегка "подзабит". Не смертельно конечно, но уже критично для например, просмотра HD video "по воздуху". Это кстати обратная сторона медали, с которой большинство я думаю еще не столкнулось. ZigBee в этом плане выигрывает,- но что-то направление подзачахло. 13. Как состыковать с Arduino или STM. UART или SPI. Оба варианта распрекраснийшим образом работают. Можно конечно придумать еще несколько способов, но я предложил, как мне кажется, наиболее распространенные и простые для понимания. 14. Что можно уместить в 1Mb flash памяти. 3 умных дома. Вместе с сигнализацией, управлением светом, котлами, измерителями температуры, влажности, и прочими удовольствиями. Основным ограничением тут будет оперативная память (память под переменные), которая как правило закончится гораздо быстрее, чем вы сумеете заполнить своим кодом flash. 15. Стоимость. Менее 100 грн за кристалл. FTDI еще 50 - 80 грн. Блок питания 20 - 100 грн. Стоимость обвязки я упонинал выше. Пожалуй все. Ну паяльник еще в общем-то не помешает, проводки там разные припой, желательно заниматься при "недрожащих руках",- оно там все мелкое и хрупкое. Лучше конечно с большой паяльной станцией и прочей аттрибутикой, но в общем можно и так. Где-то так. Если у кого-либо возникнут вопросы,- постараюсь на них ответить.

Да, sorry, слегонца зарапортовался. Я мобильник рассматриваю не как микрокомьютер, а скорее как телефон, с возможностью почитать почту, и поброузить интернет. Аудитория, которая пишет приложения под IoS, Android, или еще чего там сейчас на рынке есть, достаточно обширна, и тут пожалуй проще зааутсорсить. QNX, VxWorks и прочие, это конечно круто, но мне кажется немного не для задач автоматов, в DIN корпусах. На VxWorks когда-то CISCO строились, сейчас не знаю, может изменилось чего. Нужно так же учитывать то, что "профессиональные" железки, которые ставят на DIN, имеют такой интересный параметр, как ток, который оные потребляют (например по 220, 24, или 12 вольтам). Добавление Ethernet или WiFi, несмотря на все ухищрения, downsteppingа, отключения всего что на ни есть лишнего, + screensaver, сразу же дают * 1.5 или * 2, и это не есть good. Можно конечно питать автомат путем POE, но из своего опыта могу сказать что это не самая лучшая идея, т.к. например перезагрузка POE router, может вызвать самые неожиданные и непредсказуемые последствия. После установки всей самой необходимой обвески в корпус, можно интереса ради посчитать тепловыделение, это кстати тоже важно. В общем конечно морочливо, но значительно дешевле и гораздо функциональней железок, которые есть на рынке.

На arduino обычно есть несколько COM портов, есть возможность отлаживаться. Только вот баловство все это, с такой отладкой. На STM свои способы, в общем не проблема. Я с трудом себе представляю "неправильную адресацию". Что это значит, и какой язык (или языки) программирования вы планируете использовать ? Я кажется где-то даже видел Pascal для AVR. Если вы хотите true real time, это когда учитывая производительность кристалла и переферии, приложение гарантированно получает доступ к ресурсу в запрошенный интервал,- то тогда да, вопрос стоит рассматривать. Если же вы готовы в своих приложениях допускать задержки например +/- 20млс, то зачем так заморачиваться ? Мы наверное по разному понимаем термин "debug". RJ-45 проблем в общем-то не представляет, можно вывести 4 выхода на клемники корпуса, и не заморачиваться. Только вот учитывая отсутствие 2х уровневых корпусов, выводов тупо не хватает. Можно полюбопытсвовать что именно вы планируете исполнить на blackberry ? P.S. На старых (кажется до 2004г) tomahawks был embedded linux, с памятью 128kb (оперативка + flash). Вы наверное что-то под марсианскую миссию разрабатываете ?

1. 3 месяца с хвостиком. Спросите меня через 9 месяцев. 2. ??? 3. Индивидуально. 4. Я думал над проводным подключением, но не хватило места и понимания куда "засунуть" RJ45 разъем, поэтому WiFi. https. Я конечно понимаю что это недостаточно для "крупной промышленности", но для домашнего использования более чем. Меня эти мысли одолевали неделю. Остановился на 10 IP/подсетях, которым "можно", и которые можно уконфигурить на самом модуле. DDOS да, взлом - маловероятно.

Зачем ? И сколько кстати обойдентся "профессиональный"/"промышленный" (нужное подчеркнуть) например годовой таймер на 4 канала, с возможностью мониторинга и управления по WiFi ? На ассеблере писать морочливо, хотя в некоторых случаях необходимо, а C/C++ - самое оно. Слабо представляю себе как это можно реализовать на FBD/LAD. В любом случае, возможности ARM для таких задач более чем избыточны. Можно конечно и 20, или даже 50 программ таймера реализовать, только вот программировать на самом модуле будет уже достаточно проблематично. Нужен какой то клиент, который нужно разрабатывать и сопровождать. Можно кстати через WEB, но есть определенные ограничения по памяти, т.е. набору "фишек", которые можно засадить в этот самый интерфейс. Ну и еще добавить WEB interfaces для запросов роботов. Если есть необходимость (пока не вижу). Термин "Arduino" штука достаточно "размытая", и под нее "ложатся" и например Freeduino, и Olimexino, и STM и еще дофига чего. А там у них разновидностей море, есть железки с 512k памяти например. И переферия, I/O включая например CAN и RS485. В чем задача то ? Комплектуха "правильная", прошивка, и приемлимый для конечного потребителя внешний вид (и, кстати, функционал). Все. Понятное дело, что на собачнице доп.компоненты паять нехорошо, ну так разработайте и закажите платы. Можно кстати с уже запаянной комплектухой. У Китайцев например. И все собсно. Будет "очень профессионально" Главное в этом деле задача, т.е. "зачем и для кого весь этот тюнинг" ?