adnega

) Вряд ли он Вам подойдет. Без буферизации 115200 бод при полной нагрузке "ниасились". Готовьтесь к тому, что часть данных от станка может быть потеряна. Кроме этого, у автора статьи очень не хороший подход: "...микросхема MAX232 рассчитана на напряжение питания 5 В, однако, как показала практика, сохраняет работоспособность при 3.3 В...". Даташит на MAX232 регламентирует: напряжение питания 5 Вольт! Будьте бдительны. Желаю скорейшего разочарования (без обид).

Из литературы: Мартин Тревор. Микроконтроллеры ARM7. Семейство LPC2000 компании Philips. В сети легко найти, если что у меня тоже есть (могу на почту кинуть). Прелесть книжки, что она тонкая. Однако есть опечатки, неточности. Контроллер прерываний не тот, который теперь в LPC2478. Читать интересно. Лучше любой книги даташит на конкретный контроллер) Правда, они на английском. Есть "типа перевод даташитов на русский" от Редькина, но его тут крепко ругают) Если нужно срочно, то можно прямо сейчас поставить среду разработки Keil uVision (www.keil.com) - там неплохой симулятор. Поднять консоль, поморгать светодиодом сможете достаточно быстро.

Только не надо думать, что это монстр какой-то. По сути любой МК это ядро и периферия. Периферия на Меге Вас же не пугает. В АРМах даже еще проще - регистры, как правило, 32-битные. Например, для настройки таймера в Меге надо выбрать делитель битиками в регистре (степень двойки, причем не всякая), затем записать младший байт счетчика, после этого старший (или наоборот?). В АРМе пиши 32-битный делитель в один регистр, 32-битный счетчик в другой - все просто. С ядром проблем быть не должно, ибо весь код на C. Помню как запустил первую моргалку светодиода на LPC2148 - радости не было предела. По личному опыту: самое "страшное" в АРМах, это питание 3.3В! Но к нему быстро привыкаешь) При мне три человека так или иначе перешли на АРМ (правда с моим участием). Один аж с PICов)... как говорится "ушел и не вернулся" + Да, и корпуса у АРМов "сложные" - хотя для них платы дома тоже можно сделать

Зачотное объяснение! "Чисто конкретно" согласен на все 100. Интересно, должна ли эта система стоить дорого? Окупаемость возможна? Будет ли доступна подобная система широкому кругу потребителей?

Ради интереса взгляните на http://starterkit.ru/html/index.php?name=s...p=view&id=5 (и цену). При этом Вы получаете и RS-232, и SD-карту, и буфер RAM (96k + 32M), и USB-функция/хост (можно на флешку писать), и Ethernet (удаленный сбор логов по сети), и удобство 32-битника! Что такого есть в Mege, чего нет в этом кристале?! - писать все равно будете на C; - новую периферию (SD-card) придется осваивать в любом случае. Гораздо проще, эффективнее и интереснее делать логер не на Меге. Если будут сложности с новой архитектурой, то на форуме Вам помогут. Кстати, могу поделиться исходниками логера как раз для LPC2478. Меги хорошие камни, но не для таких задач (хотя сделать можно). Японская мудрость гласит: "всему свое место".

Несложное устройство, но есть некоторые тонкости: 1. SD-карта на запись может "курить" порядка 200мс. Все это время Вам нужно буферезировать трафик. На вскидку получается, что 115200 б/с -> 11520 Б/с -> ~44мс на 512 байт (сектор). Т.е. для буферизации нужно не менее 5 секторов (по 512 байт) - почти 2/3 всей RAM меги. 2. Записав гиг или два логов очень тяжело переносить их на комп (по последовательному каналу). Тут лучше заранее отформатировать карту (FAT), записать на нее файл data.txt, найти первый кластер этого файла и писать начиная с него. После снятия логов файл вычитывается обычным карт-ридером, и очень быстро. 3. Карту лучше брать новейшую. Бытые, отремапленные сектора могут серьезно мешать. 4. Если во время логирования пропадет питание, то необходимо найти место окончания предыдущего. Для этого файл можно заполнить каким-нить фиксированным заполнителем (например, 0xCC). При старте двоичным поиском найти первый сектор содержащий в начале, скажем 16 заполнителей и продолжать логить начиная с этого сектора. 5. Средняя скорость записи менее 2мс на сектор, т.е. можно писать до 22 потоков (115200) или на каждый символ навешивать до 21 байта обвязки (штамп времени и т.п., переход в текстовый вид), но в этом случае и RAM памяти нужно в 22 раза больше. Я делал аналогичное устройство и на LPC2468, и на STM32F103T8. Вот пример лога: #014 .963 81 .964 02 .965 F0 #013 .978 81 .979 03 .981 F0 #013 .994 81 .995 04 .996 F0 +067887 #014 .010 81 .011 05 .012 F0 #013 .025 81 .026 01 .027 F0 #014 .041 81 .042 02 .043 F0 #014 .057 81 , где #XXX - простой на шине в мс (от 10 до 999) ! - простой на шине более 999мс .XXX - счетчик миллисекунд +XXXXX - счетчик секунд Протокол текстовый, выровненный на 8 байт.

Если строго, то Вам нужен "ряд Котельникова". В этом-то и суть теоремы: если соблюсти условие (все его прекрасно знают), то по полученным отсчетам можно в точности восстановить исходный сигнал! Если ряды с синками считать не хочется, то можно перед выводом в ЦАП пропустить через специальный цифровой фильтр - те же яйца, вид сбоку.

Если нет ни одного пакета из пары, то заменяю существующим с уменьшенным уровнем

Сложность реализации это одно, более остро стоит вопрос обслуживания системы. Как правило, разработчик сложной системы "живет" на объекте годами ( Общался с ведущим разработчиком подобных систем. В неформальной переписке поинтересовался, есть ли у него самого УД. Ответ шокировал: "Ни за что!" и какой-то текст про задницу... (причем задница как и в плане работоспособности, так и в плане "мне не трудно ее оторвать от дивана"). Бегать и крутить ручки отопления, как меня уверяют, никто не будет. Если заказчик заплатил кучу денег, он считает, что все должно крутится само - причем запросы такие, что система должна обладать не то что интеллектом, а скорее разумом с двумя высшими. И я уже предлагал на 10% суммы за систему накупить "ручек", а на оставшиеся нанять китайца, который эти ручки крутить будет. Реально интеллектуальная система получается)

"Все надо делать самому". Документация у STM хорошая, правда "тонкости" раскиданы по разным документам, но это не проблема. С битиком GPIO - было такое. В самой старой доке он был описан, потом была дока в которой его уже не было, затем все поправили. Я не попался, а у знакомого "не взлетело" с первого раза - сравнили мануалы: в его более свежем битика не было. Заодно уж если теребить выбор, то хотелось бы поинтересоваться. Своим "паябельным" корпусом привлек LM3S102. Но насколько я понял у него есть особенность: для запуска нужен внешний кварц, после программно можно переключится на IRC. Это так? У новых тоже?

Целью создания УД могут выступать: - экономия энергоресурсов; - "понты". Богатые дядьки любят второе, совсем не парясь о первом. Штаты и Европа наоборот. Управление лампочками в УД, конечно же удобно, но только ради этого систему строить никто не станет. Можно автоматизировать дом по системам (объемник в коридоре, защита от протечек и т.п.) независимо - для этого не надо ничего придумывать. А вот чтобы все было в единой системе... Для себя во главе ставлю задачу безопасности, а уже на второй план удобства, которые в обычном доме не создать. Для удаленного мониторинга нужна связь через Интернет, управление по GSM. + Да, и расходы экономить по максимуму (в идеале, чтоб у системы появилась окупаемость)

У STM понравилось CSS, но неудобно, что таймеры 16 бит. В STM32F107RCT при задействовании Ethernet уж больно много периферии "съедается". Есть LPC1766 с интересной багой (из тестовых образцов NXP): Ethernet память доступна только когда прошил проц через JTAG, после сброса хоть пиши, хоть читай - всегда ноль. Жертвы "наколенок" есть как с той, так и с этой стороны. Есть LPC2368 у которого кварц стартует через раз, а стортовавши - уход частоты значительный (уровни напряжений тоже сильно отличаются от других). Есть STM с битыми ногами JTAG, жрет много, сильно греется, но работает (словила 220 с незаемленного компа). Хотя все это лирика) Попробовал STM-библиотеку. Запустил USB довольно быстро, но увы так и не нашел, где поменять частоту кварца( В итоге плюнул, написал за выходные с нуля, без всяких библиотек. На STM делал программную развертку VGA: с UARTа выводит на моник) Сейчас в основном сижу на STM (103, 107), нравятся цены. Из LPC смотрю в сторону LPC11.

Вот так //------------------------------------------------------------- // int date_to_int(int y, int m, int d) //------------------------------------------------------------- int date_to_int(int y, int m, int d) { if(m<3) { m+=12; y-=1; } return ((y*1461)>>2)+((m*306+7)/10)+d-730533; } //------------------------------------------------------------- // void int_to_date(int jd, int &y, int &m, int &d) //------------------------------------------------------------- void int_to_date(int jd, int *y, int *m, int *d) { *d=jd+730533; *y=((*d<<2)/1461); *d-=((*y*1461)>>2); *m=(((*d*10)-7)/306); if(*m==0) { *m+=12; *y-=1; } *d=jd-date_to_int(*y,*m,1)+1; }

Реализовывал, но в пределах от 2000 до 2099 года. Если устроит, есть функции перевода из секунд в дату, из даты в секунды.

"Проводов будет много. И ставить его в комнате негде.") Проводов будет как в обычной квартире. (может больше, но порядок тот же) Жить в микроволновке? Радиомодулям тоже нужно питание (выключатели, например). Радио саботировать легче.

Делал. Правда микрофон у меня не спец и терять пакеты можно. ЦАП работает с частотой дискретизации чуть выше требуемой (точнее ближайшей возможной выше требуемой). Заполняет некоторый буфер. Компандируется, вычисляется энергия, максимумы и проч. Буфер расщепляется на два: один содержит все четные отсчеты, второй - все нечетные. Буфера маркируются инкрементным счетчиком и по UDP отсылаются. Приемная сторона накапливает принятые пакеты в кольцевом буфере. Если потерян один из пакетов пары - происходит копирование из существующего пакета (эквивалентно снижению частоты дискретизации). Если потеряны оба, то копируется предыдущие существующие (ослабленные). Если кольцо заполнено больше чем на половину, то воспроизвожу на один отсчет меньше (один пропускаю), иначе - на один отсчет больше (проигрываю один лишний). При сильном отклонении число отбрасываемых/дополняемый отсчетов пропорционально отклонению. При малом отклонении - корректировку не производим.

Все ли согласны, что слейв должен быть простым устройством? А не будет ли самым верным решением сделать, скажем, "контроллер комнаты"? В контроллер сходятся все провода от всех выключателей и лампочек одной комнаты (порядка 16 входов и 16 выходов; если больше, то можно в комнату поставить несколько контроллеров). Контроллер берет на себя все функции управления электрооборудованием только этой комнаты. Если что-то надо передать в другие "комнаты" или получить из других "комнат" - использует общую сеть. При таком подходе комнаты локально-живучи, сеть не нагружена неактуальным трафиком, все устройства одинаковые по сложности (просто - одинаковые). Я бы предложил следующие критерии: - число "комнатных" контроллеров и места их расположения выбирать с позиций оптимизации кабельных трасс и удобству эксплуатации. Пусть вся проводка комнаты сходится в один щиток (коробку), в котором установлен контроллер, защитные цепи (автоматы, УЗО), резервные цепи (перевод Умного Дома на ручное управление). - в сеть должны передаваться только те сообщения, которые точно будут использоваться другим контроллером/и. При этом надежность передачи высокая не нужна - подумаешь, не выключил свет в ванной из спальни. Попробуй второй раз, в конце концов сходи ножками и выключи. К сети можно подключить "комнатный" контроллер с функцией Ethernet (имея реализацию Ethernet и CAN, скрещивание производится в считанные часы). Риторический вопрос: уважаемый All менял ли когда разбитую лампочку в люстре, управляемой Умным Домом? Нельзя быть уверенным, что ток сейчас не появится. Отрубать автоматы - остаешься без света. Дилемма еще та)

Или, к примеру, DMX512. Есть и UART, и RS-485, но... верхушка другая - называется одним словом "DMX512".

Замечу, что это не доработка, а необходимая надстройка. Система должна решать: - как передавать данные больше 8 байт; - как распределять идентификаторы/приоритеты. Спорить тут действительно не о чем. Любую более-менее реальную систему можно построить и на CAN, и на RS-485 (или еще чем-нить). Вопрос не в физике, вопрос в сложности разработки. В RS-485 относительно "тупые" слейвы и суперсложный Мастер (содержит в себе практически весь функционал системы). Благодаря этому можно клепать дешевые слейвы, а на Мастера можно и раскошелиться. В CAN все одинаковые как по цене, так и по сложности (суперсложность Мастера раскидана по слейвам). "Каждый выбирает для себя". Я придерживаюсь пути: лучше сделать десять сложных вещей, чем одну супер-сложную. Автору ветки (с atmega`ми) конечно быстее будет разобраться с RS-485, но я советую "идти другим путем". Всем Мира и удачи в делах) :cheers: PS: интересно, на чем он будет делать? Без конкретных цифр не интересно. Судя по тому, что все прекрасно ожило через Инет - постоянная времени гораздо больше упоминаемых 100мс. Моя CAN-система может). (с переходником Ethernet-CAN, конечно) Могу по сети поуправлять любым контроллером, поменять параметры, перепрошить в конце концов. Делал управление по TCP/IP - можно заходить на страничку с УД. Хоть в локалке, хоть в Инете, хость с мобилки. Кстати, и RS-485 не проблема прикрутить. (Я надеюсь понятно, что не к CAN-шине).

Хорошо. А attiny13 подойдет? Как никак 64 байта ОЗУ. Хватит ли хранить информацию о всех слейвах? Или atmega8? Уже 1024 байта - под стек, перемнные, буфера, состояния слейвов... atmega128! Дык, это дорого ;) С ПК сразу облом. Скорее всего ОС Windows, а это означает что про миллисекунды можно забыть, иногда, на минуты. Делать в одном потоке - загрузка под 100%. В разных - можешь управление раньше чем через ~14мс не получить. К тому же ПК грузится долго, вирусы, шум, пыль, электроэнергия, а самое главное - он будет дороже контроллера с аппаратным CAN!

Если делать сеть на RS-485, какой контроллер можно взять для Мастера?

Мне кажется, что автор ветки под Мультимасеровостью понимал: //---------------------------- // Контроллер номер раз #define lamp_1 (0) #define lamp_2 (1) #define lamp_3 (2) #define lamp_4 (3) #define button_1 (0) #define button_2 (1) #define button_3 (2) #define button_4 (3) void main(void) { init_all(); while(1) { if(click(button_1)) invert(lamp_1); if(click(button_2)) invert(lamp_2); if(is_message(button_3)) invert(lamp_3); if(click(button_4)) send_message(button_4); } } С CANом is_message и send_message очень просты. Все контроллеры одинаковы, за исключением содержимого while(1), которое пишется под конткретный контроллер и не зависит от других контроллеров. Не нужен дополнительный (или выделенный) контроллер.

Почему же? Звук по домовой шине для меня актуальная реальность. Эдак и про домофон можно сказать, что не надо. Если в доме всего-то 5 выключателей, да 5 лампочек (10 слейвов), 50 метров кабеля, и ничего более, то автоматизировать тут НОЛЬ. А если нужна сложная система? Я как пользователь хочу пойти в магазин, купить коробочку, подключить ее к 4 проводкам, и что бы все что работало ранее - продолжало работать; после настройки событий - заработал новый модуль с новым функционалом. Писать программу для Мастера даже не вздумайте предлагать. А заложить в Мастера весь функционал, который когда либо может быть - утопия. Забыли обсудить еще X10... или 1-wire... )

А если источник звука слейв_1, а приемник слейв_2. Да и общение идет двухстороннее.

16 бит на команду - будем считать, что для передачи полезной информации от устройства к устройству нужно всего два байта. Теперь понятно? То, что можно прокачать по шине трафик не вызывает сомнения. (хотя трафик будет зависеть не от происходящих в системе событий, а от числа слейвов - не айс) Мультимастер получается не нужен - молотим опросом. С кнопками, лампами, воротами... понятно. А я хочу звук! ) В посте 58 описывал рабочую систему. В принципе все можно сделать на RS-485 (если добавить Мастера-бездельника-молотильника). Все, кроме звука.