Evgeny_CD

ADF7021

Статейки в журналах - это хорошо. Когда их пишут люди, не имеющие интереса в последствиях влияния изложенного в статье на кошелек пишущего :yeah: Перечитайте ветку. У Xmega против STM32 есть немало козырей. * потребление при работабщем RTC выского разрешения, когда Вы можете поставить прерывание на любой тик 32768 * внешняя шина * система поддержки events * PWM от быстрой PLL По "лобовой" производительности, конечно, проигрыш (было бы странно, если бы было наоборот), но в реальных проектах не все так однозначно...

Конфа MIPS была создана по моей инициативе достаточно давно :) Потом случилась продажа AMD Алхимии, и я так и не занялся мипсами по серьезному. Тем не менее, считаю, что эту конфу надо сохранить, т.к. MIPS - это отдельная архитектура, стараниями Microchip претендующая на заметное место на микроконтроллерном рынке. Что касается обсуждения PIC32 среди всех остальных PIC'ов, то это вопрос непростой. С одной стороны, периферия та же, а с другой стороны, тонкости программизма на С и ASM под PIC32 заметно другие. Пусть эта конфа живет.

Ура! ATXMEGA128A1-AU в каталоге Mouser появились. Самих чипов на складе нет, когда будут - непонятно, но цены довольно разумные: 100 - $5.63. Для чипа с таким набором фич - просто отлично! www.mouser.com

1. Errata. Вроде как все пристойно на современные чипы. Уж не знаю, нет ли там такого фокуса как с STM - типа работайте с периферией только через нашу либу, в которой все баги и маскируются http://caxapa.ru/123682.html но внешне все смотрится пристойно. 2. Грамотная работа с RTC и таймерами. 32 битный таймер 32768, два регистра совпадения, независимое питание на RTC и 256 байт памяти, 24 битный "таймер ядра" - все очень продумано и удобно. 3. Ethernet -> http://caxapa.ru/123930.html Вообще вне конкуренции 4. Хорошая поддержка для работы с движками - квадратурные декодеры, PWM и пр. 5. Обидно, что IO питание от 3.0В, напрямую при питании от Li-Ion батареи часть емкости оной останется неиспользованной, но жить можно. По большому счету, только DMA и параллельной вншней шины не хватает. Но самое интересное в этом семействе другое. Технология 0.25. Это на заметку всем орущим "вот нету у нас в стране фабрик 0.0001 мкм, посему и нету своей электроники". Народ собрался с мыслями, взял очень "дубовый" и распространенный процесс, и сделал замолодь. За счет меньшей стоимости подготовки выпуск масок в случае бага вполне решаемая задача даже для небольшой фирмы, а грамотное использование фич 0.25 процесса дает своим преимущества - 5В совместимые входы и т.д. (на 0.18 это тоже можно, но ведет к большому расходу дефицитной площади кристалла). За счет полного выделения RTC части в свой домен питания вполне можо гасить питание на все остальное, и работать в покое от CR2032 с током 16 мка, тем более, что поддержка автоматического переключения на батарйку там есть, включая детектор "умирания" батарейки (правда, его не довели, там какие-то баги с этим связанные есть, но, уверен, допатчат). Интересно, как у них финансовые успехи? Что-то их не сильно слышно в последнее время - проблемы, или наоборот, вышли на расчетный уровень и спокойно работают.

Поясните, плиз, что это такое в контексте темы.

В этом и состоит копперация! :) Чтобы процесс "генерации идей" не забывал про реальную жизнь. И соизмерялся с ней. Не противопоставляясь ей, но и не упуская ее из виду. Иначе как с создателями зигби получится :)

История ZigBee еще ждет своего Карамзина :) Тут есть несколько моментов. Есть психологический парадокс - самоуспокоенность. Т.е. народ, приступив к делу правильно, SDL и все такое, уверовал, что он прав именно от того, что использует SDL. Забыв, что это инструмент, а не цель. Кроме того, отцам основателям, вероятно, показалось - "ну а фигли там - задачка то вроде простая, GSM сделали - и это как-нибудь заломаем". И недооценили размерность задачи. В том же GSM, который дико сложен, сотик юзера не является маленькой базовой станцией. :) В результате количество юзеров, которые могут помешать друг другу по эфиру, в GSM довольно мало - сотня макс (находящихся в одной соте на одной частоте, включая активных и слушающих). В этом сила синхронных систем. А тут с учетом ретрансляции в ZigBee эффектов может быть просто море. Я никогда не вчитывался детально в спецификацию ZigBee. Там хоть глобальный сихнронизм есть в масштабах всей сети? Т.е. чтобы поведение каждого устройства было детерминировано? Или старый добрый persistence algorithm? http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf Вообще, сдается мне, что именно вся эта возня вокруг ZigBee подстегнула технологию моделирования радиосетей. Это сейчас, куда не плюнь, везде симулятор радиосети. А в 2000 году это было экзотикой (понятно, что это было, но в те времена это было настоящим "тайным знанием"). Опять же, "истина где-то рядом". И упование на UML, и полное его отвржение одинаково вредны. А промежуточных тулзов нет! Типа того, что я тут пытаюсь (и вроде как получилось!) нащупать. Что-то руками, что-то автоматом - человек+ машина пока что еще очень эффективная связка! Так что гибче надо быть, гибче! Вот я долбанутый на всю голову. Признаю :) Три дня из 4 потратил на "глубокое погружение" в любимую тему. Что-то новое осознал. Потом "всплыву", и в обычной жизни буду примитивными тулзами обходиться. Но последовательного стремления к цели это не отменяет. Просто не надо все на карту ставить.

А TDD там нет в принципе? Запустить тесты над куском кода, посмотреть и их результат, затем другой кусок протестить т.д. А затем уже снаружи устройство тестами мучить - чтобы понять, что в ТЗ было упущено.

Сайт проекта Linux Router уже закрылся, но вот тут что-то можно узнать http://www.linuxjournal.com/article/5826 Когда в описании freesco увидел ядро серии 2.0 - то подумал, что это из тех времен, когда Linux Router рулил. Но увы, проект закрылся. В моей конторе юзался Linux Router - очень хорошо показал себя.

Это бывший Linux Router что ли?

Я рад, что Вы когда-то изучали дифференциальную геометрию. Можете освежить свои знания. и подумать над тем, что Вы тут написали. (ссылки для желающих) гауссова кривизна http://ru.wikipedia.org/wiki/%D0%9A%D1%80%...%B7%D0%BD%D0%B0 Гомеоморфизм http://ru.wikipedia.org/wiki/%D0%93%D0%BE%...%B8%D0%B7%D0%BC Изоморфизм http://ru.wikipedia.org/wiki/%D0%98%D0%B7%...%B8%D0%B7%D0%BC А по существу можете чего добавить?

Быть может. Это отражение моих старых идей.

Есть такое. Меня удивляет, что никто не сделал "полуавтоматический" инструмент. (Полностью автоматический инструмент - утопия, тут и спорить не о чем). Есть изначальный граф - описание алгоритма. Генерируем код. Код разбиваем на блоки (хоть чезер маркеры в каментах, хоть еще как). В кажом блоке описываются его характеристики: * export - чем из этого блока можно пользоваться снаружи * import - чем он сам пользуется * config - заивсимость от параметров конфигурации * OS - какие средства ОСи блок использует. Все связи между блоками прописываются на уровне графа и только так! Далее на уровне блока проверятся - блок соотвествует своему дескриптору или нет? Есть блоки более-менее отлаженные. Их фризим, что означает, что они не перегенерируются при генерации программы. Т.е. мы можем для этих блоков только изменяеть использование их export сущностей. Далее берем блок кода и начинаем глазками/ручками/мозгами доводит его до совершенства. Полной автоматической кодогерации делать смысла никакого нет. При герерации заготовки блока генерируются заготовки его export сущностей и import данных, с которыми он работет. Ну и словами - что этот блок сделать должен. Блоки могут быть вложенными. Далее верификауция идет в два этапа. На уровне формальной верификации проверяем, что блок соотвествует дескриптору. На уровне функуциональном прогоняем тест и убеждаемся, что блок делает то, что нам надо, а не ему. На уровне безопасности - смотрим в код глазками и ищем, нет ли там стремных C конструкций. Я с трудом верю, что можно написать верифкатор для этой части, не ограничив искусственно сибкость С. Вот и вся автоматизация. Никакого "искусственного интеллекта" и пр. шняг не предвидится. Все просто и тупо, в моем понимании на год неспешной работы пары толковых программистов. Вопрос в том, почему так никто не сделал???

Написал же. В процесс отладки девайс напишет в лог - типа он тут заснуть пытался. А вот тут у него случилось прерывание, которое его разбудит. Потом анализируем логи и, зная сколько девайс жрет в каждый момент времени (вводим его в такой режим отладочным монитором и тупо меряем тестером), вычисляем, сколько он проживет от CR2032. Кайф ATxmega в том, что я выкину все аппаратные отладочные навороты, поставлю нужный define, чтобы отладочые "засечки" отключить, и все! Больше ничего в программе не изменится! Вероятность, что при столь малых модификация в боевую прогу будут внесены ошибки, пренебрежимо мала. Тут возразить нечего. Такого нет - но, надеюсь, потом добавят.