adnega

"В смысле не буде ли драйвер CAN мешать USB?" - конечно будет. Память у них общая... Когда работает USB, CAN будет простаивать. Допустимо ли это для Вашего случая? Судя по вопросу драйвера Вы планируете брать чьи-то. В случае самописных драйверов ситуацию можно разрулить (повторюсь, ценой простоя CAN; с учетом приоритета USB над CAN). На STM32F103T8 делал и CAN, и USB (но не одновременно) - ничего военного. Потом мне захотелось мост CAN<>USB (одновременно)... Переписал на 107 и получился мост CAN<>Ethernet ))

Полусофтовый вариант (на стр. 11 есть соответствующее предупреждение). Если нужен день недели (автоматически рассчитываемый по дате), то лучше делать иначе - в счетчике RTC держать и дату и время (аппаратно). Получать значения при необходимости. Формулы выше.

Есть смысл посмотреть Connectivity Line STM32F105/107 Хотя, можно завести питание с USB на ногу. Если напряжение есть, то активен USB, иначе CAN. CAN физически подключить на отремапленные ноги.

Если на вход какого-то элемента подать сигнал "x", то на выходе получим "X". Если "y", то - "Y". А если подать линейную комбинацию ax+by, где a, b - постоянные коэффициенты, то на выходе линейного элемента получим aX+bY. То, что Вы имели ввиду называется реактивный элемент) Вопрос определений, но мы друг друга поняли. Реактивный элемент позволяет накапливать энергию. Если добавить к типичному ШИМу дроссель, то можно довольно-таки неплохо поддерживать постоянный ток с пульсациями, зависящими от частоты ШИМ и индуктивности дросселя. Такой сигнал уже не страшно гонять по проводам. И яркость получается "честная" (уже интегрированная). Как Вы справедливо заметили, проблемы будут при управлении яркостью нескольких источников. Если автору темы интересно это направление, то можно обсудить детали (как калибровать диммер; повторяемость; стабильность от номиналов, температуры, питающего напряжения). Если же нужно управлять яркостью светодиода на плате (например, для индикации загрузки ядра, канала связи и т.п.), то в дебри можно и не вдаваться.

У понятия "линейный элемент" есть довольно строгое определение. Дроссель - линейный элемент. ШИМ это когда светодиод на полную катушку горит, а потом на полную катушку не горит? Если делать это быстро, то те фотончики, которые успел испустить светодиод разложат химию в нашем глазу не полностью, а частично. И часть эта зависит от времени испускания фотончиков. А от объема разложившейся химии наше восприятие яркости? Мне в этом контексте мыслить? А ничего страшного не случится при использовании типовой схемы и 10 метров провода? Просто, затеял подсветку потолка делать - помех боюсь...

Мучают смутные сомнения, но вряд ли "ток прямо пропрционален заполнению" со всеми вытекающими. Два дня назад экспериментировал со схемой: ШИМ включает NPN-транзистор (схема ОЭ). Эмиттер через 50 Ом на землю. Коллектор через дроссель на светодиод (6 светодиодов). Светодиод через еще 50 Ом на +12В. К коллектору анодом диод. Катодом диод на место соединения светодиода и второго резистора. При прямолинейном заполнении ШИМ, мультик показывает неравномерное изменение тока светодиода (типа, логарифм)! Впрочем, как и осциллограф.

ВАХ светодиода представляем мысленно. В нужном нам участке это как раз логарифм. При линейном увеличении длительности импульса ШИМ линейно увеличивается напряжение. А ток логарифмически. Моща, я так понимаю, будет ~t*exp(t). В некоторой степени яркость прямопропорциональна мощности (если КПД не меняется). Поэтому что-то логарифмическое и получается. По глазу: там где значительный динамический диапазон и сложная система АРУ без логарифмического масштаба не обойтись. Ощущение яркости управляемых светодиодов будет зависеть от яркости фона. Одно дело полумрак, другое прямые солнечные лучи. Сам сейчас озадачен ШИМ регулировкой яркости светодиодов. При малых токах, яркость регилируется ступеньками... При низких напряжениях вообще не горит... Хочу табличку набросать - графически оно всяко удобнее представлять. Потом табличку в софт. Табличка чисто субъективная получится. + Да. Еще ВАХ светодиода (полупроводник в конце концов) прилично зависит от температуры. Это тоже надо учитывать. В начале делал ШИМ-регулировку тока, в принципе и мощность можно посчитать... но хоца ведь по-лехше)

Эээ... походу это я всех смутил. Заветные три буквы фигурировали в коде, который выложил в посте #2. Правильнее будет заменить CRC на CS. Добавлю: опыт показывает, что говорить о CRC-16 без явного указания начального значения, порождающего полинома, и прочих преобразований, иногда не имеет смысла (ибо реализаций CRC-16 много). В соответствующее поле UDP заносится контрольная сумма. Посмотрел у Таненбаума ("Компьютерные сети"): "Контрольная сумма UDP не является обязательной. Если она не подсчитывается, ее значение равно 0 (настоящая нулевая контрольная сумма кодируется всеми единицами). Отключать функцию подсчета контрольной суммы глупо, за исключением одного случая - когда нужна высокая производительность." С http://www.opennet.ru/docs/RUS/tcpip/#c5_udp : "Если поле "Контрольная сумма" UDP-заголовка содержит нулевое значение, это означает, что источник UDP-пакета контрольную сумму не подсчитывал, и приемник выполнять ее проверку не должен. Некоторые реализации протокола UDP (например, в SunOS - клоне ОС UNIX от Sun Microsystems) контрольную сумму не подсчитывают в принципе, полагаясь на возможности контроля целостности данных, реализованные в протоколах сетевого уровня (например, в Ethernet)."

Яркости чего? Светодиода? Лампы накаливания?

Если в поле CRC будет 0, то windows-socket, вроде, примет пакет. Если CRC будет неверна, то пакет отбросится?

#define UDP_PACKET_SIZE 8 #define IP_UDP 17 // псевдозаголовок crc=UDP_PACKET_SIZE+sizeof(sAUDIO_PACKET)+IP_UDP +(((DWORD)dst_ip[0]<<8)|dst_ip[1]) +(((DWORD)dst_ip[2]<<8)|dst_ip[3]) +(((DWORD)src_ip[0]<<8)|src_ip[1]) +(((DWORD)src_ip[2]<<8)|src_ip[3]); // заголовок for(j=0;j<((UDP_PACKET_SIZE+sizeof(sAUDIO_PACKET)+1)>>1);j++) crc+=(bl0_data[j*2+1+ETH_PACKET_SIZE+IP_PACKET_SIZE] +((DWORD)bl0_data[j*2+0+ETH_PACKET_SIZE+IP_PACKET_SIZE]<<8)); crc=(crc+(crc>>16))^0xFFFF; http://www.opennet.ru/docs/RUS/tcpip udp->crc=SWAPBYTES(crc); В поле CRC UDP заносим 0. Сначала считаем сумму псевдозаголвка (тип пакета 17 + размер данных пакета IP (размер заголовка UDP+размер данных UDP)) + IP адреса источника и получателя. Потом к полученной сумме добавляем все данные IP пакета (т.е. заголовок UDP и данные UDP). Затем добавляем переполнение и инвертируем содержимое CRC bl0_data[ETH_PACKET_SIZE+IP_PACKET_SIZE] - начало пакета UDP Можно почитать http://www.opennet.ru/docs/RUS/tcpip/

Или eBOX какой-нить...

MAX3232. На меге8 я делал мониторилку сетевого напряжения с записью на карту. Дык, при скорости 16 байт в секунду все прекрасно работало. Железо-то есть какое под рукой? Могу поделится исходниками для меги8, правда, они на асме.

) Вряд ли он Вам подойдет. Без буферизации 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.