Перейти к содержанию
    

Evgeny_CD

Свой
  • Постов

    2 058
  • Зарегистрирован

Весь контент Evgeny_CD


  1. Статейки в журналах - это хорошо. Когда их пишут люди, не имеющие интереса в последствиях влияния изложенного в статье на кошелек пишущего :yeah: Перечитайте ветку. У Xmega против STM32 есть немало козырей. * потребление при работабщем RTC выского разрешения, когда Вы можете поставить прерывание на любой тик 32768 * внешняя шина * система поддержки events * PWM от быстрой PLL По "лобовой" производительности, конечно, проигрыш (было бы странно, если бы было наоборот), но в реальных проектах не все так однозначно...
  2. Конфа MIPS была создана по моей инициативе достаточно давно :) Потом случилась продажа AMD Алхимии, и я так и не занялся мипсами по серьезному. Тем не менее, считаю, что эту конфу надо сохранить, т.к. MIPS - это отдельная архитектура, стараниями Microchip претендующая на заметное место на микроконтроллерном рынке. Что касается обсуждения PIC32 среди всех остальных PIC'ов, то это вопрос непростой. С одной стороны, периферия та же, а с другой стороны, тонкости программизма на С и ASM под PIC32 заметно другие. Пусть эта конфа живет.
  3. Ура! ATXMEGA128A1-AU в каталоге Mouser появились. Самих чипов на складе нет, когда будут - непонятно, но цены довольно разумные: 100 - $5.63. Для чипа с таким набором фич - просто отлично! www.mouser.com
  4. Luminary рулит.

    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 мка, тем более, что поддержка автоматического переключения на батарйку там есть, включая детектор "умирания" батарейки (правда, его не довели, там какие-то баги с этим связанные есть, но, уверен, допатчат). Интересно, как у них финансовые успехи? Что-то их не сильно слышно в последнее время - проблемы, или наоборот, вышли на расчетный уровень и спокойно работают.
  5. В этом и состоит копперация! :) Чтобы процесс "генерации идей" не забывал про реальную жизнь. И соизмерялся с ней. Не противопоставляясь ей, но и не упуская ее из виду. Иначе как с создателями зигби получится :)
  6. История 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 потратил на "глубокое погружение" в любимую тему. Что-то новое осознал. Потом "всплыву", и в обычной жизни буду примитивными тулзами обходиться. Но последовательного стремления к цели это не отменяет. Просто не надо все на карту ставить.
  7. А TDD там нет в принципе? Запустить тесты над куском кода, посмотреть и их результат, затем другой кусок протестить т.д. А затем уже снаружи устройство тестами мучить - чтобы понять, что в ТЗ было упущено.
  8. Сайт проекта Linux Router уже закрылся, но вот тут что-то можно узнать http://www.linuxjournal.com/article/5826 Когда в описании freesco увидел ядро серии 2.0 - то подумал, что это из тех времен, когда Linux Router рулил. Но увы, проект закрылся. В моей конторе юзался Linux Router - очень хорошо показал себя.
  9. Я рад, что Вы когда-то изучали дифференциальную геометрию. Можете освежить свои знания. и подумать над тем, что Вы тут написали. (ссылки для желающих) гауссова кривизна 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 А по существу можете чего добавить?
  10. Есть такое. Меня удивляет, что никто не сделал "полуавтоматический" инструмент. (Полностью автоматический инструмент - утопия, тут и спорить не о чем). Есть изначальный граф - описание алгоритма. Генерируем код. Код разбиваем на блоки (хоть чезер маркеры в каментах, хоть еще как). В кажом блоке описываются его характеристики: * export - чем из этого блока можно пользоваться снаружи * import - чем он сам пользуется * config - заивсимость от параметров конфигурации * OS - какие средства ОСи блок использует. Все связи между блоками прописываются на уровне графа и только так! Далее на уровне блока проверятся - блок соотвествует своему дескриптору или нет? Есть блоки более-менее отлаженные. Их фризим, что означает, что они не перегенерируются при генерации программы. Т.е. мы можем для этих блоков только изменяеть использование их export сущностей. Далее берем блок кода и начинаем глазками/ручками/мозгами доводит его до совершенства. Полной автоматической кодогерации делать смысла никакого нет. При герерации заготовки блока генерируются заготовки его export сущностей и import данных, с которыми он работет. Ну и словами - что этот блок сделать должен. Блоки могут быть вложенными. Далее верификауция идет в два этапа. На уровне формальной верификации проверяем, что блок соотвествует дескриптору. На уровне функуциональном прогоняем тест и убеждаемся, что блок делает то, что нам надо, а не ему. На уровне безопасности - смотрим в код глазками и ищем, нет ли там стремных C конструкций. Я с трудом верю, что можно написать верифкатор для этой части, не ограничив искусственно сибкость С. Вот и вся автоматизация. Никакого "искусственного интеллекта" и пр. шняг не предвидится. Все просто и тупо, в моем понимании на год неспешной работы пары толковых программистов. Вопрос в том, почему так никто не сделал???
  11. Написал же. В процесс отладки девайс напишет в лог - типа он тут заснуть пытался. А вот тут у него случилось прерывание, которое его разбудит. Потом анализируем логи и, зная сколько девайс жрет в каждый момент времени (вводим его в такой режим отладочным монитором и тупо меряем тестером), вычисляем, сколько он проживет от CR2032. Кайф ATxmega в том, что я выкину все аппаратные отладочные навороты, поставлю нужный define, чтобы отладочые "засечки" отключить, и все! Больше ничего в программе не изменится! Вероятность, что при столь малых модификация в боевую прогу будут внесены ошибки, пренебрежимо мала. Тут возразить нечего. Такого нет - но, надеюсь, потом добавят.
  12. caxapa:: Рэйлвэй Каген { При всём богатстве выбора, альтернатив, как всегда, две :) А именно - есть алгебраисты и алгоритмисты. Первым ближе сети, графы и автоматы. К перечисленным средствам могу добавить только CPN Tools http://www.daimi.au.dk/~cpntools . Впрочем, это уже было здесь: http://caxapa.ru/110159.html Для генерации в плюсАх можно посмотреть gsmsuite http://www.boutell.com/lsm/lsmbyid.cgi/000341 Вторым - Дракон http://wiki.oberoncore.ru/index.php/%D0%94...%B7%D0%BE%D1%80 Дракон-редактор http://narod.ru/disk/55428000/DRT.rar По сути - очередная реинкарнация блок-схем с полуавтоматической генерацией кода. Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто!(Новые средства для образного представления знаний, развития интелекта и взаимопонимания). М.: Дело, 2001. — 360 с. — Илл.: 154. http://www.transhumanism-russia.ru/documen...tu_uma_Word.rar Недавняя дискуссия здесь http://forum.oberoncore.ru/viewtopic.php?f=62&t=493 , в том числе и по общим подходам к визуализации программ. Думается, что генерация кода из графического представления всё-таки надёжнее, чем визуализация и последующее разгребание произвольного, когда-то кем-то написанного кода. Анализировать вещь вторичную, а именно, конкретную реализацию - занятие куда менее полезное, чем анализ самой задачи на предмет поиска решения либо алгебраического, либо алгоритмического. Правда первое требует на порядок более высокой квалификации разработчика. } Мне добавить нечего :a14: Кое-что добавлю. Лично мне генерация кода из графиеского представления кажется очень привлекательной! Решать обратную задачу мы не будем, не ученые-теоретики, а вот верификатор - проверять кода на соотвествие блок схеме - это очень нужно! Вот только где бы такое взять? Но меня удивляет то, что нет толковых общепринятых тулзов для этого. С/С++ компилеров и их вариантов вон сколько наплодили, а такого генератора/верфикатора нет. Или это жутко конкурентная область, и все заныкали свои наработки под матрасами??? -
  13. http://savannah.nongnu.org/forum/forum.php?forum_id=5247 качать http://download.savannah.gnu.org/releases/.../lwip-1.3.0.zip В секции контрибуторов дистрибутива http://download.savannah.gnu.org/releases/...ntrib-1.3.0.zip много интересного, в частности, порты на Win32 под VC6, VC8 Хотя это прозошло 23 марта :), вдруг кому такая информация будет полезна :)
  14. Почти согласен, кроме одной фишки - tracing. Для отладки сложных систем в реальных условиях мне нужен максимально подробный "лог" работы системы реальном времени. Причем в условиях автонома. Т.е. пусть к контроллеру и будет подключена какая-то железяка, но без пЫсюков, супер-мега JTAG тулзов и пр. В варианте FPGA на шине (подключение которой, к тому же, уменьшит число IO портов, но не "прибьет" периферию, как это часто бывает в других контроллерах) я могу посадить в эту FPGA SDRAM контроллер и сделать так. В нужном месте процессор пишет по адресу какой-нибудь U16. Делается это просто, с учетом дополнительных команд на запрет/разрешение прерывания, в AVR тактов за 10 получится. В FPGA к этим данны приписывается еще значение U64 какого-нибудь внутреннего счетчика, и это попадает в FIFO. От туда в SDRAM. Там оно может храниться, а может быть перекачано при помощи отдельного процессора, подрубленного "с другой стороны" FPGA, в какой-нибудь FLASH. Ну и для пущей точности, я могу подрубить GPS, и понему синхронизировать внутренний таймер, так что засечки разных приборов у меня будут синхронизирваны с точностью 1 мкс без больших напрягов. В результате, развернув, например, в реальных условиях радиосеть из мелких девайсов, я спустя неделю пройдусь по ним, заменю автомобильные аккумуляторы (вместо которых в реальных условиях будут CR2032) и передерну SD карточки. Далее я всасываю логи в большой SQL сервер, и анализирую, все, что у меня творилось в сети. И сразу видно, как разные глюки смотрелись с точки зрения разных девайсов в сети. Разумеется, перед этим я изнасилую свою радиосеть в синтетических симуляторах по полной программе:), но симуляция лишь дополняет натурный эксперимент. Вот для таких точных засечек SPI не пойдет. А параллельная шина самое то. В боевом устройстве я просто разведу плату по другому, возьму малоногий кристалл, и в программе ничего не изменится - только уберу "засечки". Странный подход. При изобилии OLED и LCD девайсов со встронным контроллером нормальная внешняя шина куда важнее, чем встроенный LCD контроллер :)
  15. После того, как я разобрался с Protothreads http://electronix.ru/forum/index.php?showtopic=49133 я понял в очередной раз, что C безграничен, и скать, что он его знает полностью, не может никто :)
  16. caxapa::Vit подсказал еще вот какие интересные проекты: TinyTimber http://www.sm.luth.se/csee/courses/smd/138/TinyTimber.pdf http://www.sm.luth.se/csee/courses/smd/138/TinyTimber.h http://www.sm.luth.se/csee/courses/smd/138/TinyTimber.c TinyTimber, a very small and lightweight run-time kernel for event-driven embedded systems. А тут целая куча интересного: http://www.nilsenelektronikk.no/neprod.html proc Real-Time Kernel nemon Boot and Debug Monitor nesos Finite State Machine Operating System - вот это интересно в контексте рассматриваемых задач. Embedded Web Servers
  17. Странно Вы мыслите. Хотя дело хозяйское. Не все так однозначно в стоимость чипа уперлось. При тиражах до 1к/мес 1 человеко/мес работы инженера добавит в стимость изделия сумму, гораздо больше разницы в цене контроллеров. В ATxmega есть нормальня внешняя шина, которую в STM32 как-то забыли завезти. В Cortex, если не путаю, тоже. А это дает возможность подрубить FPGA (SPI подключение FPGA - это, все же, не совсем то, что и параллельная шина). А это уже совсем другой расклад, знаете ли...
  18. Ладно парни, кончаем воду мутить! Объявлется конкурс на "первого пощупавшего Xmega живьем" :1111493779:
  19. В Хмеге еще просто обалденно сделано мультиплексирвоание IO пинов. На 50 стр. документа можно посмотреть. http://www.atmel.com/dyn/resources/prod_do...nts/doc8067.pdf В частности, подключение внешней памяти не "убивает" встроенную периферию, в отличие от AVR32! Из интересных вещей - поддерживается 4 битный SDRAM. Практическая ценность - может пригодиться для неторопливого логгинга чего-нибудь большого. Еще одна приятная особенность - The EBI is clocked from the Fast Peripheral clock, running up to two times faster than the CPU and supporting speeds of up to 64 MHz. Так что работа с SDRAM не такая уж и медленная будет. Особенно учитывая наличие DMA memory <-> memory.
×
×
  • Создать...