Цифра в пробирке

AVR в Linux - Тропой Кулика.

2010-01-22T10:46:00.011+05:00

Леонид Алексеевич Кулик, советский специалист по минералогии и исследованию метеоритов. Особый интерес проявил в исследовании Тунгуского метеорита. Несколько раз организовал экспедиции в район Подкаменной Тунгуски но найти метеорит не удалось.

Я начал эту статью так, потому что Linux невероятно интересная и прогрессивная платформа, но работать в ней человеку пришедшему из мира $MS титанически тяжко... Как в распространенной шутке, собственно, "первые три года тяжело, а потом привыкаешь" :) Вот и я подобно Кулику постоянно предпринимаю попытки найти философский камень в Linux, но всегда оказываюсь перед проблемой недостатка опыта и знаний что бы его найти. :) Отчаявшись приспособиться к линкусовой психологии шарахаешься опять в мир $MS где все привычно - где работают все "программаторы", где нет проблем с Quartus-ом, с VMLab-ом, но при всем при этом нет той понятности и стройности, а главное открытости операционной системы.

Начитавшись до дури статей я приступил: выкачал старого знакомого Ubuntu сменившего за мое отсутствие номер версии, установил и... и начала морочиться. Видимо нормальные люди разрабатывают в IDE, но я же настолько прирос к FAR-у (приятно осознавать что используешь продукт земляка воспитанного тем же ВУЗом, что и ты, с которым можно сказать через одно рукопожатие знаком :)). Ну и поскольку я уже привык к файловому менеджеру то MC меня начал раздражать практически сразу, я его выкинул из головы и перешел на терминал где возни конечно побольше, но хотя бы раздражения не вызывает. Тут надо сказать, что я забыл о великолепном ресурсе, который подготовил Vitasam, специально для тех кто отважился спрыгнуть с Win. Потерял бы меньше времени.

Начать необходимо с avr-binutils, avr-gcc, avr-lib, avrdude как основного и самого необходимого инструментария разработчика.
Затем задуматься над вопросом в чем писать. Vitasam предложил не плохой вариант без нагромождений - Geany. В принципе вариант достойный, единственное что не позволяет создать makefile как это делал например автоматически, VMLab. Страшного в этом ничего нет, те кто работал с WinAVR помнят что в поставке всегда был инструмент MFile. Мне приходилось пользоваться им крайне редко - обычно все решалось копированием имеющегося makefile и изменением содержимого: списка файлов проекта, типа микроконтроллера, опций компиляции. Однако автоматический генератор makefile существует он интерактивный так же как и в Win и он скрипт поэтому требуется небольшая доработка. Сам MFile находится по адресу. Доработка скрипта попила много крови, сперва я не понял почему не стартует скрипт, оказалось что в заголовке файла (который является для Linux исполнимым) прописан не Ubunt-овский интерпретатор Tcl/Tk. Прописывание интерпретатора Tclsh, оказавшимся в Ubuntu не самим файлом, а лишь ссылкой на него (/etc/alternatives/tclsh) ничего не решило. Tclsh - интерпретатор не поддерживающий работу mfile в GUI. Но на широких просторах интернета благодаря google отыщется все, а именно то что для запуска mfile нужно использовать wish прописав внутри самого mfiel строчку запуска #!/usr/bin/wish.
После компиляции и сборки обычно необходима симуляция. В Win это либо VMLab, либо AvrStudio, либо Proteus. С тех пор как VMLab стал свободен привык использоваться им, хоть он и вызывает у меня нарекания по навигации в исходнике. Под Wine VMLab устанавливается исключительно, даже под старый WINE 1.0.1, который по умолчанию находится в Ubunt-овском репозитари (sudo apt-get wine). Само собой изменения вносимые на ходу в проект VMLab компилировать toolchain-ом, который находится в Linux не будет. Конечно можно поставить под Wine и WinAVR но получится что-то вроде "масло-масляное". На сайте VMlab есть информация что включением опции Any 3rd party high level lenguage generating COFF при создании проекта производится выбор компиляции и сборки сторонними средствами генерирующими исполняемый файл в формате COFF для отладки его в VMLab. Эта ключевая фраза задала мне жару часа на 4 поиском ошибки makefile при создании COFF.

Рис.1. Использование VMLab для отладки проектов в Linux под WINE.

Благодаря ошибке с COFF возвращаемся к этапу номер один. В комплекте avr-binutils поставляется маленькая, но так необходимая утилитка avr-objcopy собирающая из elf файла coff файл. Попросту конвертор исполняемых форматов который нужен потому, что elf файлы VMlab не приемлет. Запущенный из makefile avr-objcopy при сборке выдает ошибку

avr-objcopy: "имя преобразуемого файла".cof: Invalid bfd target

Благодаря своему не важному знанию языка и не желанию вчитаться в "англицкий" текст хотя бы в течении пяти минут, я минимум три часа провел в бесполезном серфинге. Вот пост рассказывающий как победить ошибку. Все достаточно тривиально для того что бы ошибка была исправлена нужно либо "одеть" на новый avr-objcopy заплатку, либо взять старый файл, в котором этой проблемы еще не существовало. Репозитарий Debian или Ubuntu содержит свежие avr-binutils и ошибка там себя проявляет, а вот распространенный некогда cdk4avr остановился на версии GNU objcopy 2.16.1 + coff-avr-patch (20050630) (CDK4AVR 3.0 2.16.1-20060708) и в нем этой ошибки нет. Однако не спешите ставить это пакет, потому что остальные утилиты из avr-binutils нас устраивают , да и не стоит мешать сапоги с конфетами. Необходим только avr-objcopy нужно его извлечь из пакета cdk-avr-binutils_2.16.1-20060708_i386.deb находящегося на сайте архиватором и поместить, внимание !!! в два места /usr/bin и /usr/bin/lib/avr. Во вторую папку на всякий случай, хоть путь $PATH и указывает на /usr/bin, а вдруг где то жестко в makefile будет прописано /usr/bin/lib/avr для вызова binutils. Кстати копирование под Ubunu в системные места разрешено только "судоерам", так что про sudo перед командой копирования cp забывать не нужно.

#sudo cp avr-objcopy /usr/bin

И так проблем симуляции железа уже решена, но можно чуть расширить ее посмотрев в сторону Code::Block IDE который дает все возможности и по созданию проекта (вплоть до сборки) и по его симуляции с применением avr-dbg и simulavr, все это очень хорошо описано на этой страничке и нет смысла пересказывать. Однако у меня почему то не заладилось с отладкой все переменные были пустые хоть отладчик ходил по веткам кода.

Следующий вопрос является наиболее важным - ЧЕМ ШИТЬ?

Все время до этого пользовался удачным вариантом USB программатора AVR910 USB (разработки prottoss).

Программатор хороший но по рассказам на форуме линуксоидов для его использования необходимо пересобирать ядро включив туда изменения для нештатной работы с USB, либо перешивать сам программатор в avr-doper. Перешивать я не стал боясь оказаться без удобного рабочего инструмента (в загашнике на всякий случай есть деревянный PonyProg), а стал искать какой программатор легкий в сборке поддерживается и работает без нареканий в Linux. Таким программатором оказался USBasp. Конструкция похожа на AVR910 USB, но для того что бы на сигнальные линии диф-пары USB не попало напряжение питания микроконтроллера (в схеме USBasp VCC равно 5 вольт) использовано два стабилитрона на 3.6В. Такой "выверт" необходим из за того что не во всех материнских платах чипсеты толерантные к уровню TTL и требуют конвертирования уровней. Конструкция AVR910 USB обеспечивает питание микроконтроллера программатора 3.6V, чем координально решает вопрос с попаданием 4..5V уровней на сигнальные линии USB. Падение напряжения после двух диодов приводит к тому что напряжение питание VCC снижается с 5V до приемлемых 3.5-3.6V. Переделка отражена на рис.4., дополнительные детали (два диода и конденсатор) выделены красным цветом, а номинал резистора R3 изменен на 1.5КОм (на USBasp R3 = 2.2КОм).

Рис.2. Часть схемы USBasp обеспечивающая толерантность линий USB к уровню сигналов TTL с AVR.

Рис.3. Решение Prottoss на "корню" ликвидирующее не толерантность линий USB сигналам с AVR.

Рис.4. Изменения вошедшие в USBasp из схемы AVR910 USB.

После сборки и зашивки USBasp его наличие в Linux можно проверить утилитой lsusb вот как это выглядит:
# lsusb
Bus 002 Device 003: ID 16c0:05dc VOTI USBasp AVR Programmer
Bus 002 Device 002: ID 16c0:05e1 VOTI
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Устройство 16c0:05dc это USBasp, а 16c0:05e1 это AVR910 USB. На форуме рекомендуют записать правило (помните про sudo) для определения USBasp утилитой avrdude и другими программами:

# UDEV-style hotplug map for usbasp programmer
# Put this file in /etc/udev/rules.d

SUBSYSTEM=="usb", ATTR{product}=="USBasp", ATTR{idProduct}=="05dc", ATTR{idVendor}=="16c0", MODE="666"

При помощи утилитки avrdude шьется огромная часть AVR и в принципе ее более чем достаточно для работы. Документация на русском Часть 1, Часть 2 также доступна благодаря блогу.
Но под USBasp оказывается есть софт не только для Windows, но и для Linux.

Однако надо сказать софт этот принес мне массу головоломок. После установки (простой распаковки) xAVR необходимо было установить wxGTK, как это рекомендует автор (usblib уже стоял). wxGTK взял с репозитария версии 2.8. Софт для работы с USBasp запускается из под sudo, о чем предупреждает автор. После запуска ./avrprog заявляет, что с библиотеками 2.8 работать не хочет, желает 2.6. Деинсталируем gtklib 2.8 ставим 2.6 - софт выдает уже одну ошибку вместо двух, где требует so-шку из библиотеки 2.8. Предупреждаю сразу ставить 2.8 бессмысленно получим тоже сообщение "с 2.8 несовместимо". Поступил так: выкачал RPM (для RedHart нашел в какой пакет засунуты нужные *.so) и скопировал их по адресу, который от меня требовали /usr/lib. Однако avrprog этого оказалось мало и он сгонял меня за следующим *.so из очередного пакета wxGTK. Под конец потребовав tiff-овскую библиотеку (tiff*.so), ублаженный запустился.

Рис.5. Ублаженный xAVR

Рис.6. Программатор USBasp с небольшими доработками, в работе.

Рис.7. USBasp макетная плата, работы не так уж много.

Рис.8. USBasp макетная плата, оборотная сторона.

Поскольку большинство программ мечтают о запуске через sudo, но не являются при этом терминальными то могу предложить использовать простой алгоритм по их запуску со стола кликом по значку - в созданном текстовом файле на столе располагается скрипт запуска

#!/bin/bash
gksudo /usr/bin/dolphin

Файл сохраняется с нужным именем, и назначается исполняемым выбором крыжика в закладке ПРАВА - позволять исполнения файла как программы. Кликом на это скрипт программа запустится с правами root, запросив при этом пароль.

ATMega8515 - Гори гори, моя звезда...

2009-12-21T23:09:00.000+05:00

Новый 2010 Год наступает нам на пятки!

Всяк по своему пытается создать атмосферу праздника - украшая, наряжая, размалевывая во все тяжкие. Однако мы же хорошо знаем, что по В.И.Ленину - "Из всех искусств для нас важнейшим является кино». Или по Павлову - первая сигнальная ублажает мозг млекопитающего своей глубинностью и дремучестью. Так всегда было народ со времен Вавилона требовал "Хлеба и зрелищ!".

Предыстория вопроса контроллера гирлянд уходит своими корнями в далекое прошлое когда микроконтроллеры были жутко дорогие и очень слабенькие по функциональным возможностям. В те давние времена получив заказ от высокого руководства, требовавшего "хлеба и зрелищ" в завуалированном виде "что бы во дворике предприятия все мигало, да причем разными цветами" мы с моим хорошим другом стали "отращивать мозг" :) как же бы это реализовать. До этого во дворе по периметру вешали раскрашенные в разные цвета лампочки ватт так на сто пятьдесят. Лампочки сильно грелись цвета выгорали, так что мало того что к следующему "нью еар" нужно было их красить, так еще и от начальства, вернувшегося с новогодних праздников по шапке за поблеклость внешнего вида отхватывали. Предложений было много некоторые хотели на двигатель прилепить группу размыкаемых контактов и таким образом отделаться от назойливой верхушки предприятия. Однако разобрав несколько катодных станций на предмет мощных тиристоров T-160 нами было решено сделать по науке - генератор, счетчик и дешифратор. А что бы с управления мощным тиристором вдруг бы не пришло на логику вольт эдак сотню в качестве дешифратора была выбрана популярная для газоразрядных цифровых индикаторов (от 0 до 9) микросхема высоковольтного десятичного дешифратора К155ИД1. Вся конструкция была упрятана в ящик из фанеры и просуществовали лет эдак пару. Но кто то из электриков это дело благополучно "запалил" по извечной русской "авось". Теперь уже в наших ручках суждено было блеснуть микроконтроллерам, к которым мы подобрались практически вплотную. Задача управления нагрузкой большой мощности встала в полный рост. Лепить на мощных тиристорах стало очень накладно ибо такими мощностями в гирляндах мы не управляли и близко. Тиристоры по проще нужных мощностей (до 400 - 500 ватт) не обеспечивали. Совершенно случайно в одном из журналов по комплектующим были подсмотрены "твердотельные реле" довольно дорогие по тем временам но для нас как возможность реализоваться бесценные. S202T02 - оптосимисторы позволяют управлять нагрузкой в 400-500 ватт и при этом изолировать управляющий интерфейс микроконтроллера от воздействия переменного тока 220 вольт :)

Мы были счастливы как дети и на радостях воплотили идею практически мгновенно. Но как водится, то что делается наспех, почти всегда не долговечно и не реализует всех возможностей. Так и вышло. В этом году дела давно минувших лет аукнулись. На этот раз решено было не допускать соплей при проектировании и сделать на совесть, с возможностью реализовать на 16 линиях управления любую схему коммутации как то "бегущий огонь", "инверсию", "пульсирующую линию" и прочее.

И так хотелось бы:

1. Управлять мощной нагрузкой переменного тока 220В
2. Иметь возможность менять схемы управления "огнем" в любом порядке
3. Сделать систему настраиваемой вплоть до внесения изменений в составленную программу светопреставления "на ходу", без использования средств высокого уровня
4. Обеспечить наглядность прохождения программы и тем самым упростить диагностику в цепях управления и коммутации нагрузки

Одна из "авосечности" и "торопыжничества" предыдущего проекта было отсутствие даже приблизительного расчета по возможному току портов МК и как следствие напрямую, даже без токо-ограничительных резисторов запайка управления непосредственно на линию порта. Если внимательно приглядеться к ДШ по твердотельным реле можно узреть что номинальный ток на открытие 50мА, а это на 10мА больше возможного номинального тока порта. Со временем (3-5 лет) как указано в ДШ на "твердотелки" оптопары реле деградируют имеющегося тока на открытие не хватает - разжечь ветку гирлянды становится не возможно и она начинает мерцать вместо того, что бы гореть. В этот раз из имеющихся под рукой КТ3107 были собраны ключи с током до 100мА (200мА в импульсе) и в качестве индикатора работоспособности каждый ключ нагружен светодиодом визуализатором. Схема ниже.

Для расчета ключей (дабы транзисторы не вошли в насыщение и при этом хватило тока на открытие) моим хорошим другом профессионалом в "радио" была предложена следующая методика расчета.

Справедливости ради нужно сказать что более разумным было бы использование комплементарного КТ3107 транзистора КТ3102, по схеме с разрывом эмиттером общего провода, однако схемотехника уже изготовленного шлейфа для гирлянд подразумевала управление "+" а не "-".

Программа управления построена на чтении инструкции из памяти EEPROM, и предусматривает задержку поступления следующей команды на исполнение. В дальнейшем нужно предусмотреть переход программы управления на любой шаг (пока только в нулевой шаг) и редактирование программы управления средствами контроллера гирлянд. В качестве источника ввода данных неплохо будет смотреться переменный резистор, а так как ATMega 8515 не имеет встроенного АЦП, то для задачи референсного напряжения для сравнения на компараторе можно использовать либо сеть R2R резисторов (ЦАП) либо ШИМ с RC цепочкой. В AppNote AVR400 фактически рассмотрен пример построения ADC на базе встроенного компаратора и ШИМ, с условием правда что измеряемые напряжения до 2/5 VCC.

Application Note AVR400. Применение МК без АЦП для измерения аналогового сигнала.

Application Note AVR400. Таблица значений R,C и тактовой частоты.

Application Note AVR113. Схема включения RC цепи

К моему великому сожалению контроллер отобрали как только я завершил испытания на стенде и обещали вернуть только по прошествии праздников. Так что изыскания будут продолжены :)

Исходные тексты проекта находятся по адресу адресу в Google Code

ATTiny12 - Позвони мне, позвони...

2009-11-25T19:50:00.000+05:00

Дверной звонок - что может быть проще? Как правило об изготовлении дверного звонка никто не задумывается - возьми готовый в магазине. Но приобретение в магазине не окупается моральным удовлетворением от проделанной работы. Не важно как, но старый звонок времен СССР решено было отправить на заслуженный отдых, взамен водрузив что то издающее приятный или уж по крайней мере не режущий ухо звук. Задача в общем не ахти какая сложная, но интересная.
Глаз попремерявщись к имеющимся в заначке микроконтроллерам выбрал восьми ногую ATTiny12. Эх была бы ATTiny11.... или выпущенная недавно ATTiny10... глаз непременно упал бы на нее. Но в наличии только ATTiny12.
И так ознакомимся что же мы имеем в составе ATTiny12. Интервальный таймер, 1024 слова программной памяти, встроенный RC генератор до 1МГЦ, пять линий IO из которых одна линия может работать как внешнее прерывание INT0. Не плохо! Подойдем к задаче творчески. Что бы нам хотелось? А хотелось бы нам, что бы звонок мог проигрывать мелодию! Это означает нужно издавать определенную ноту с определенной длительностью по списку партитуры. Насчет ноты все более менее ясно, имея интервальный таймер ничего не мешает проигрывать ноты, задавая их частотой меандра. Формировать его можно в прерывании по переполнению таймера, в этом случае имеющийся интервальный таймер задает период колебания. А вот с длительностью уже так легко не выйдет, если мы задаем ее через кол-во периодов сигнала - нам становится очень неудобно жить. Периоды будут обязательно не кратные целым числам ms, придется использовать целые числа бОльших разрядностей. Сплошная головная боль да и только. Вот если бы нам еще один таймерок бы в помощь, тогда задавать длительность было бы так просто и однозначно... По счастью AVR снабжен еще одним таймером могущим отрабатывать несколько вариантов задержек - это Watch Dog timer, "сторожевая собака" не дающая AVR впасть в маразм - например бесконечный цикл по вине программиста или помехи из вне. Как правило работа с этим устройством происходит по принципу - взвел таймер на случай ошибки и "виса", а если таковой не случился и процедура отработала нормально - "собаку" вернем в будку на цепь (инструкцией WDR) и пусть опять ждет в будке пока не завершится сторожевой интервал. Если все таки "собаке" вовремя не дали "укорот" - она "кусает" кнопку RESET. В принципе этот сброс ничем не отличается от внешнего, но идентифицировать что именно привело к сбросу возможно. Регистр MCUSR содержит информацию о событии предшествующем сбросу.

рис.1. Схема формирования сигнала RESET для MK AVR фирмы Atmel.

И так возьмем эту собаку в оборот и не станем "дергать ее за цепь" возвращая на место преждевременно - пусть срабатывает как и положено через интервал Twdg который к слову достаточно гибок и может настроиться отдельным делителем на разные интервалы (см. рис.2).

рис.2. Пределитель для "сторожевого пса" MK AVR фирмы Atmel.

Таким образом WATHCDOG будет таймером задатчиком интервала работы основного таймера издающего тональный сигнал. Надо заметить что у данного метода будет один не очень существенный но заметный на слух недостаток - так как WATHCDOG именно сбрасывает МК, то состояние всех портов, в том числе и порта используемого для формирования тонального сигнала будет сбрасываться в логический ноль. Практически это означает, что с определенным периодом задаваемым таймером WATCHDOG будет происходить срыв внутри периода генерации на время восстановления. Время восстановления конечно не значительное, но ухо все равно будет слышать срывы из за их периодичности. На качество инструмента аля "дверной свисток" влияет не сильно :) Можно окончательно избавиться и от этого изъяна отключив WATCHDOG в процедуре обработки прерывания Timer0 (тонального сигнала), тогда интервал работы тона будет слегка варьироваться на половину периода, но никогда не будет обрываться внутри периода тональной посылки. Мне показалось что борьба за чистый и незамутненный звук инструмента достойного Амати, не так уж и важна.
Само собой мелодию надо хранить в виде записи последовательности ДЛИТЕЛЬНОСТЬ, ТОН в памяти программ. Кроме того необходимо отлавливать прерывание от внешнего источника (дверной кнопки) и осуществлять старт проигрыша сигнала. После проигрывания сигнала вполне допустимо уложить контроллер в летаргический сон - дабы минимизировать потребление (а вдруг проще будет менять батарейки чем возиться с источником питания?).

Рис.3. Схема электронного музыкального многотонального программируемого дверного звонка.

Конечно писать программу для такого устройства на Си можно, но невероятно глупо - ибо чего там писать то?

Исходный текст программы на ассемблере AVR.

P.S. Расширение этого устройства может быть весьма забавным - например добавление к имеющимся возможностям атаки звука или вариации звука по громкости в зависимости от установки пользователем. Но это уже совсем другая история.

Рис.4. Автопортрет дверного звонка.

Используемая литература:

1. ATTiny11-ATTiny12 Atmel datasheet.

N6100-T2 - "А вы ноктюрн сыграть могли бы, на флейте водосточных труб?"

2009-10-04T22:25:00.000+06:00

Комплекс N6100-T2. Уже не еж провода и деталей на "макетке" :).

Комплекс N6100-T2 общий вид.

Фирма Nokia безусловно флагман мобилостроения в Европе, однако не все то что позволено Юпитеру, позволено быку :)
Проведя на просторах интернета поиск по ключевой строке "LCD Nokia 6100 AVR" я еще до начала макетирования выяснил что Nokia использует в своих изделиях LCD различных производителей отличающихся между собой контроллерами. Все "разнообразие видов" этих цветастых животных по мнению "съевших на них собаку" радиолюбителей размножалось в рамках четырех платформ-прародителей
a) Philips Semiconductors PCD8833
б) LEADIS LDS176
в) Seiko Epson Corparation S1D15G00
г) Seiko Epson Corparation S1D15G10, (S1D15G14, S1D15G17 см.1)

список литературы по описанию различий контроллеров применяемых Nokia для моделей телефонов 6100,6610,2600,7200,7250,3100 :

1. http://www.silabs.ru/pubs/Stat_119.pdf
2. http://www.electricstuff.co.uk/noklcd.html

Изучение, ДШ легкодоступных в интернет, дает много пищи для размышлений. В принципе основное различие LCD в том, что изначально ставившийся в Nokia на ряд совместимых по нему моделей (6100,6610,2600,7200,7250,3100....) LCD имел возможность работать в режиме 16 битного цвета. В целом же были доступны 8-битный, 12-битный упакованный, 12-битный не упакованный и 16 битный режимы. А вот последующие (S1D15G00 как я предполагаю) поддерживали только 8 и 12 битный режимы. По системе команд для управление дисплеем зверинец делится на два класса PHILIPS и EPSON. Пункты списка а) и б) соответственно PHILIPS. Как показала практика вышеуказанные корпорации все время совершенствовали свои устройства (при этом меняя технологические нормы) и изменяли процедуры инициализации - пуска LCD. Фактически LCD запитывается одним напряжением (на самом деле их два VCC, VDD) 3.3В, но для работы ячейки ЖКИ нужно как минимум напряжения разной полярности, кроме того еще и в зависимости от температуры окружающей среды оно должно варьироваться. Таким образом внутри изделия стоит зарядовый насос (Booster) и его запуск процедура и так крайне запутанная судя по всем четырем ДШ еще и прирастала изменениями связанными с модернизацией, о чем можно судить по многочисленным вариантам кода инициализации гуляющего по вебу.

http://forum.lcdinfo.com/viewtopic.php?t=586&postdays=0&postorder=asc&start=0

Вход, а особенно выход из режима сна тоже связаны с запуском "насоса" и осциллятора и они тоже очень разные для разных модификаций. При инициализации кроме запуска бустера, нужно еще и сконфигурировать сам LCD, а именно развертки данных из ОЗУ (горизонтальная и вертикальная), режим хранения цветовых данных в ОЗУ LCD, палитра, контрастность, настройка входного питания (резистивного делителя я полагаю). На форумах посвященных LCD Nokia N6100 вычислять и определять тип попавшего в руки LCD предлагалось по размерам кристалла контролера, его в некоторых дисплеях может закрывать легко устраняемая полоска изоляционного материала, в части он открыт для обозрения со стороны ЖКИ и залит компаундом. По данным этих исследований получалось так что самый маленький по размерам кристалл это PHILIPS совместимый. Оно и понятно так как по всей видимости он явился родоначальником этого вида LCD для Nokia. Однако мне в частности попался экземпляр EPSON с контроллером по размерам даже ниже чем у последних PHILIPS. Так что селекция по данному типу не всегда работает. Так же не работает и предложенная селекция по цвету шлейфа зеленый - EPSON, желтый/коричневый - PHILIPS. Кроме того PHILIPS во время инициализации в определенный период времени (во время старта) умеет посылать идентификационные данные.
Что характерно мне попался PHILIPS-совместимый дисплей, который совершенно не стандартным (не по ДШ) методом отрабатывал зеркальность вокруг осей и добиться результата стало возможным используя неописанный в ДШ режим работы по цвету, спать и просыпаться данный LCD так же пришлось учить в слепую. Этот дисплей весьма неприятно вел себя при выходе из режима "сна" и запуске бустера, на экране появлялось переконтрасированное изображение с четко пересвеченными по габаритам вертикальными полосами. Как мне показалось данный тип дисплеев очень зависит от напряжения питания, и пр его больших значениях (выше 3.4В) начинает комкать гамму и "жечь" переконтрастом экран. Подгонка контраста на нем занятие очень не приятное градиент в 2-3 единицы не заметен на глаз, но значительно влияет на цветность.

Новый PHILIPS-совместимый дисплей, заставляет попотеть при запуске. Внешне очень похож на EPSON.

Кроме того один из дисплеев (мой знакомый в другом городе) не принял ни одно ухищрение - картинка осталась инверсной по цвету и отраженной зеркально, не смотря на то что дисплей принимал команды PHILIPS-ской кодировки.

Нечто PHILIPS-подобное неподдающееся дрессировке.

При этом имеющийся в моей коллекции ортодоксальный PHILIPS вел себя очень покладисто, правильно реагируя на все то что описано в ДШ. Как мне кажется хорошим признаком что LCD является оригинальным PHILIPS является наличие, спрятанного под скотчем в задней части дисплея шлейфа с контактными дорожками, к которым очень удобно подпаяться. Однако настолько же легко этот шлейф и ломается по сгибу (в моем случае переломался за 2-3 цикла сгибания-разгибания) припаянным шлейфом, поэтому закреплять его надо жестко на макетной плате или печатной, раз и навсегда.

Оригинальный PHILIPS "убитый" в последствии за два перегиба шлейфа.

Оригинальный PHILIPS вид с задней панели, разгибать и сгибать шлейф противопоказано!

Подпаяться к EPSON на много сложнее - придется сдернуть разъем "кроватку" (это легко сделать обычным паяльником) и распаяться на открывшиеся монтажные площадки этой "кроватки". МГТФ хороший вариант но нужно выбирать сечение поменьше, что бы получившийся шлейфик а в нем 8-9 проводников не был жестким. Самое сложное это припаяться к шлейфу - это практически "вырви глаз", а если еще и рука не набита... :) Третий по счету дисплей я оппаял за минуты, набив руку и глаз, хотя перед этим уходило до часу. Исходя из этого конечно лучший вариант будет приклеенный к монтажке и распаянный ответный разъем "кроватка". Только не нужно пытаться снять ее с телефона феном, она покоробится (что и получилось у меня) и станет не пригодной для сочленений.

EPSON совместимый дисплей "распят" на макетной плате.

Подпайка не к оригинальному PHILIPS составляет определенную трудность. Вид EPSON-совместимого дисплея с обратной стороны защитная лента отклеена.

Вдоволь намучившись с дисплеем на монтажке я перенес устройство в уже окончательной конфигурации на печатный монтаж. PCB проектировалась в KiCAD ровно как и схема устройства.

Схема комплекса N6100-T2. KiCAD

Я бы остался в целом доволен KiCAD если бы вдруг не оказалось, что он "позабыл" о нескольких соединениях указанных на схеме в печатной плате. Печально конечно, это означает что KiCAD нужно проверять после разводки гораздо тщательней.
В дополнении к "косякам" KiCAD, некоторые я допустил еще и сам, они хоть и были не приятной новостью, в принципе легко устранились без применения скальпеля. Сама печатная плата как мне сейчас кажется зря была сделана с применением фотоспособа (позитивным фоторезистом), вполне подошла бы и "утюговая технология". Ультрафиолет полученный естественным путем (с выносом на открытое пространство), без применения ультрафиолетовой лампы, чуть-чуть "не добил" дорожки и потом при проявке и травлении хлорное железо их изрядно подъело. Одна подъеденная дорога таки попила у меня крови, проявившись в готовом устройстве непостоянством инициализации дисплея. Я даже начал подумывать - а не перетерло ли у меня шлейфик LCD? Пробитая дорожка нашлась и оказалась выбором LCD, линией #CS. В тот момент когда я прислонялся к ней пальцем или пинцетом и сбрасывал комплекс - устройство не заводилось.

Фотоспособ при нанесении рисунка дорожек на фольгированый текстолит.

Так видит печатный монтаж N6100-T2 KiCAD (3D-просмотр монтажа)

Флюс, канифоль - печатный монтаж комплекса N6100-T2 без доводки C2H5OH :)

Изначально в конструкции планировалось использовать две батареи AAA или одну дисковую CR. Однако до конца совладать с умножителем не получилось и я запустил компромиссный вариант от трех Ni-Cd аккумуляторов. Таким образом напряжение питания устройства 1.2*3 = 3.6-3.8В. Скорей всего у порта МК попросту не хватает возможностей по току раскачать умножитель (утроитель см. схему) в итоге от имеюшихся Uпит=3В на выходе умножителе получается 5.19В, что не достаточно для качественной подсветки дисплея (как правило это два светодиода).

Схема умножителя (х3). *1

Возможно мне удастся довести умножитель в следующих вариантах, но установка в конструкцию IC "зарядового насоса" по эффективности на порядок лучше умножителя. Да и в качестве МК для термометра стоит выбирать не ATMega8 а что нибудь по совершенней, например ATMega88P.
Применение в любительской конструкции однопроводных цифровых термометров DALAS DS18S20(DS18B20) не очень то и оправдано. Лучшим решением по моему мнению было бы применение внутри ШИМ датчика температуры серии TMPxx от AD, а внешнего либо DS18xx, либо AD7814, либо цифрового последовательно Microchip-а.

статья в стадии завершения....будет дописана и дополнена в части фотоматериала в ближайщее время :)

ссылки на литературу:

1. Ирвинг М. Готлиб "ИСТОЧНИКИ ПИТАНИЯ. Инверторы. Конверторы. Линейные и импульсные стабилизаторы".

N6100 - "Задание дадено, будет сделато!"

2009-08-19T11:08:00.000+06:00

Вот такой прибор комнатный/уличный термометр пришлось в условиях сжатых сроков делать на NokiaN6100, подвинув в сторону то что "ближе к телу" - mk61avr. Цветовая схема и экспозиция заказчика, к сожалению я не разделяю его эстетических наслаждений от этюда в темных тонах. Прибор отображает температуру дом/улица и старается как может экономить батарейное питание :) засыпая и гася подсветку через минуту. Как видно подсветка дисплея на 3.6В было 3.3В преобладает артефактами - чередующимися светлыми-темными полосами. Напряжение питание пришлось поднять до 3.6В, так как 3.3В это все равно что "кина не будет, электричество кончилось" :). Заказчик хочет долгой и безбедной работы от дисковой батареи желательно 3.3В. Замеры с амперметром увы приводят к не очень утешительным результатам, ток потребления в спящем режиме 0.16-0.20 мА. В рабочем состоянии с включенной подсветкой 10-11 мА. С выключенной подсветкой 6-7 мА. При особых стечениях обстоятельств (расчеты приведу потом) получается на 280мАЧ батарейки протянуть с полгодика можно, но не год! Правда еще пока не отключаю в "спячке" питание самого LCD, как вариант конечно можно рассмотреть - но время старта тогда около 2-3 секунд, не очень то приятно. В "горячем" режиме время старта 0.8-1.2с из за задержки между конвертированием температуры и ее чтением из датчиков.

Из интересного - так как клиент захотел дюже красиво и что бы шрифты антиалиасились, конечно пришлось попотеть загоняя битмапы цифр и изображений в расчетные 5-6Кб, на данный момент реализована разновидность алгоритма RLE позволившая вкатить прилично картинок в flash контролера (Данные без сжатия в районе 20-25Кб). Однако реализую сейчас смешанный RLE-словарь алгоритма сжатия который даст выигрыш в еще пару Кб, что не лишне для продвинутого сервиса термометра.

to Vitasam: Виталий в связи с уже наработанным алгоритмом сжатия ФС для mk61avr мы с тобой поменяем в пользу сжатия RLE что бы не морочаться с указанием размера кода в странице MK61. Я думаю что ты меня все таки поддержишь с ФС и поможешь в реализации тем более там осталось на один чих.

P.S. Для себя решил если заказчик "потеряется" (а похоже что к тому идет) исходники надо будет отдать в массы, не плохой термометр получается в хозяйстве каждому сгодится.

P.P.S.Не устаю восхищаться n6100 потребляет мало, функциональность интерфейса выше всяческих похвал, возможно Виталий стоит подумать о применении в mk61avr как штатного средства отображения. Потребление подсветки ~2mA. Сколько потребляет "тельце" LCD пока не измерял но скоро доберусь и до этого :)

Дисплей Nokia N6100 - "от нашего стола - вашему".

2009-08-10T09:22:00.000+06:00

Выпала случайная возможность познакомиться с еще одним весьма дешевым (от 150 до 250 рублей) цветным графическим дисплеем. Мало того приличное разрешение 132х132, так еще и 12 и 16 битные режимы цветности. По сравнению с ZX-spectrum это больше половины разрешения экрана спектрума 256×192, а по цветам так и в десятки раз превосходит последний. Это я к тому что как далеко шагнула микроэлектроника, на первый "замыленный" взгляд кажется что успехи незначительны, но если оценивать пристально - то результаты на лицо. Контроллер дисплея принимает данные последовательно, так же как например и Nokia3310, а значит для управления всего и нужно 4 сигнала CS, SDA, CLK, RESET. Кроме того очень много полезных функций возложено на сам контроллер LCD, в отличии от Nokia3310 который прямо сказать сервисом не перегружен :). Работать с LCD удобно, удобней даже чем с N3310, результаты тестов на фотографиях.

"монтажка" в сборе и LCD N6100 с подсветкой от 3.6V

Шрифты и изображения на LCD N6100

MK61avr - Подальше положишь, поближе возьмешь.

2009-07-21T21:09:00.000+06:00

Фотография mk61avr комплекса vitasam на "бредовой доске"

Решение хранить во внутреннем EEPROM AVR программы МК61, конечно самое простое, но хочется что бы порядок был во всем. Приятно когда память внешняя и ее может быть не один или два, а много. А еще хорошо когда что то кроме памяти можно зацепить.. А еще хорошо управлять чем то зацепленным к mk61avr... А еще.., а еще.. Вот так собственно мы и пришли к мнению, что лучшим из лучших, удобнейшим из удобнейших будет решение оснастить mk61avr внешней шиной стандарта I2C - мало того что это возможность подключить 127 устройств, семь из которых могут быть памятью EEPROM для хранения программ или памятью для хранения процедур mk61avr, но так же и возможность зацепить различные датчики I2C и любые устройства обладающие I2C интерфейсом. Так же было решено что I2C шина расширяет во вне адресное пространство виртуальной машины VM61 и дает возможность передавать исполнение на куски кода находящиеся не в стандартной странице mk61avr (в отличии от MK61, mk61avr поддерживает размер страницы 256 байт) и работать с EEPROM как с частью адресного пространства для mk61avr распространяющимся от 0..0xFFFFFFFF (базовая разрядность). Так же пришли к выводу что оснастить внешним EEPROM хотя бы в количестве одна штука для хранения программ было бы для базовой конфигурации вполне сносным решением, не сильно тяготящим карман, но и дающим возможность хранить более 2-4 стандартных программ.
Вот так чаяниями Vitasam и моим "кодингом" и "паянингом" платформа mk61avr обзавелась внешней шиной I2C и EEPROM 24LC32 хорошо известной фирмы Microchip.

Схема I2C встроенного "хранилища" программ.

Надо сказать что фирма Филипс очень хорошо позаботилась о логичности и понятности двух проводного синхронного интерфейса I2C. Разборки с ним, для меня еще не подходившему к данному протоколу, не составили большого труда.

P.S. Ну а внутренний EEPROM с подачи Vitasam теперь принято считать резервным хранилищем контекста (регистров,стеков и страницы кода из ОЗУ) mk61avr при выключении.

P.P.S. На комплексе Vitasam была проверена работа с внешним EEPROM 24LC128. В принципе до значения адреса FFFF внутреннего счетчика все EEPROM будут работать увеличивая кол-во страниц под программы - пропорционально размерной сетке.

24LC32 - 4Кб
24LC64 - 8Кб
24LC128 - 16Кб
24LC256 - 32Кб
24LC512 - 64Кб

единственный пока не вписывающийся EEPROM
24LC1025 - 128Кб

MK61avr - делу время, потехе час

2009-07-06T00:38:00.000+06:00

Устав от монотонного прохождения тестов все ж таки не утерпел и "устроил шалость", результаты на видео.

http://code.google.com/p/mk61avr/source/browse/trunk/%20mk61avr%20--username%20vitasam70/avi/mk61avr_native_write_lcd.AVI

Текст программы в мнемонике МК61

ИП0 КП7 ИП3 КП8 FL3 02 БП 06

Если перевести в ЯВУ то это примерно следующее:

X = R0;

*R7 = X;

do {X = R3; *R8 = X;} while(--R3>0);

while(1);

С пояснениями:
в R0 константа для позиционирования в LCD и одновременного вывода данных. Так как MK61avr - имеет базовую разрядность 4 байта то при выводе в ячейку памяти с адресом 16, 2 байт - это координата X, 1 - байт координата Y, 0 -байт информация, которую нужно вывести в LCD по координате X,Y. Если писать в адрес выше 16, то позиционирование на байт происходить не будет, а будет просто записываться байт 0 в LCD. Так как LCD nokia3310 автоматически переходит к следующему байту после операции записи, то последовательная запись в адрес например 17 будет заполнять LCD данными. На видео видно как 50000 вводится в R3 и затем программа записывает данные в LCD в цикле 50000 раз.

mk61avr [06. 51]>d

60 B7 63 B8 5A 02 51<06>

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

mk61avr [06. 51]>@

R00=255.0000000

R01=255.0000000

R02=0.000000000

R03=1.000000000

R04=0.000000000

R05=0.000000000

R06=0.000000000

R07=16.00000000

R08=17.00000000

R09=0.000000000

R0A=0.000000000

R0B=0.000000000

R0C=0.000000000

R0D=0.000000000

R0E=0.000000000

mk61avr [06. 51]>

Анализ архитектуры МК61 - кто сильнее Кит или Слон?

2009-06-26T23:47:00.000+06:00

И так воспользовавшись синтезатором Quartus и описанием моделей 4 битных сумматоров для BCD и BIN определим кто "сильнее" и насколько :) Оговорим правила схемного решения блока суммирования (сумматора) пусть в модуль входят исходные значения для суммирования A и B, и вход переноса Cin с предыдущего сумматора для возможности каскадирования блоков. Выходом является результат суммирования RESULT и выход переноса Cout. При каскадировании перенос Cout соединяется с входом в очередной сумматор. Оговорим так же что по фронту тактового сигнала clk значения A,B,Cin,RESULT,Cout - записываются в свои регистры, это нужно для окончательного придания дизайну синхронности. Кроме того по расчету допустимой тактовой частоты на "клоке" синтезатором мы и будем судить о скорости решения.

Опишем в Verilog обычный четырех битный сумматор.

module sumbin(RESULT, Cout, a, b, Cin, clk);

output reg [3:0]RESULT;

output reg Cout;

input [3:0]a,b;

input Cin;

input clk;

reg [3:0]rA,rB;

reg rCin;

wire [4:0]sum_bin = rA + rB + rCin;

wire BIN_carry = sum_bin[4];

always@(posedge clk) begin

rA <= a;

rB <= b;

rCin <= Cin;

RESULT <= sum_bin[3:0];

Cout <= BIN_carry;

end

endmodule

Синтезируем и смотрим результат:

Синтезатор показывает нам что тактовая частота способна достигнуть 380МГц, задержка на самом длинном участке 2.631 ns.

Так же синтезатор показывает нам свои затраты на реализацию схемы - это 6 LUT и 14 однобитных регистров (D-триггеров), так как в ядре общая обвязка РОН - сумматор - РОН симулируется нашими регистрами то расход именно D-триггеров можно не рассматривать. Таким образом затрачено 6 LUT из которых 5 находятся в арифметическом режиме (т.е. фактически сумматоры-полусумматоры и есть). Кое какое представление как синтезатор видит описанную в HDL схему мы можем получить из просмотра RTL схемы, это конечно не ахти что - но пользоваться этим приходится.

Как видно из RTL представления схемы синтезатор вполне разборчиво отрисовывает регистры на входах (это то что он делает очень хорошо), а вот с изображением сумматора почти всегда не задается - единичный бит Cin суммируется при помощи еще одного сумматора, как 4 битная константа 0001B. Это не совсем так и для того что бы четко выяснить что же там понастроил синтезатор можно взглянуть на пост-роутинг блоков LE's.

Вот тут уже становится понятно что каждый LUT это однобитный полусумматор с входом переноса с предыдущего разряда. А вот два LUT в начале и в конце цепочки сумматоров синтезатор влепил как обыкновенные проводники, не берусь точно сказать почему он так решил сделать, но рискну предположить что цепи входа на D-триггер оказались более удаленными от выходов LUT полусумматоров. Думаю ситуация поменялась бы заставь я синтезатор оптимизировать по размеру, а не по скорости. В принципе эти два LUT можно не считать и тогда расход LUT составит - 4.

Приступим к BCD четырехбитному сумматору. BCD сумматор можно представить себе как двоичный сумматор с коррекцией результата, коррекция необходима тогда когда полученный результат является недопуcтимым значением (1010B,1011B,1100B,1101B,1110B,1111B) или в результате сложения возник перенос в следующий разряд (сумма превысила 1111B).

Коррекция - это вычитания из полученного результата 10, например для 7+7 сумматор даст 0111B + 0111B = 1110B (Eh), а должен дать 0100 (4h) с переносом в следующую тетраду 1. Воспользуемся тем что вычитание - это сложение с отрицательным числом, а отрицательное число это дополненое до 1 значение.

A - B = A + ~B + 1

A - 1010B (10) = A + 0101B (5) + 0001B = A + 0110B (6)

Таким образом коррекция результата BIN для возращения его в BCD форму это сложение полученного при двоичном суммировании значения с 0110B.

Опишем в Verilog, BCD сумматор.

module sumbcd(RESULT, Cout, a, b, Cin, clk);

output reg [3:0]RESULT;

output reg Cout;

input [3:0]a,b;

input Cin;

input clk;

reg [3:0]rA,rB;

reg rCin;

wire [4:0]sum_bin = rA + rB + rCin;

wire [3:0]sum_bcd = sum_bin[3:0] + 4'b0110;

wire BCD_carry = (sum_bin > 4'b1001);

wire BIN_carry = sum_bin[4];

always@(posedge clk) begin

rA <= a;

rB <= b;

rCin <= Cin;

RESULT <= (BCD_carry|BIN_carry)? sum_bcd : sum_bin[3:0];

Cout <= BCD_carry;

end

endmodule

Просинтезируем схему с помощью Quartus и рассмотрим полученные результаты.

Таблица использования ресурсов говорит о том что количество LUT увеличилось до 10 и похоже два LUT опять обычные проводники - так как используется только два входа, точнее можно ответить рассмотрев пост-роутинг.

Рассматриваем "скорострельность" схемы, само собой понимаем раз LUT стало больше то и задержка увеличилась (чудес не бывает). Так оно и есть максимальная частота снизилась до 353МГц упав на 27МГц по сравнению с BIN сумматором. Однако можно совершенно четко сказать что применения суммирования в бинарном виде и коррекции результата раздельно, в следующем такте (через этот же сумматор) снизило бы частоту решения вдвое. Так что выигрыш все таки есть, насколько он значителен сказать трудно - нужно строить полную модель ядра что бы понять это. Ну и посмотрим на схемы.

Мда... Бред сивой кобылы и то выглядел бы более подобающим :) Мы видим опять каскад сумматоров, элемент сравнения и кучу мультиплексоров. Конечно схемотехнически выразить то что описано Verilog очень сложно и ориентировать на RTL не стоит. Очевидно что оператор ? означающий селекцию по логическому значению в скобках оператора синтезатор отрисовывает как мультиплексор переключаемый этим значением. Взглянем лучше на пост-роутинг он даст неимоверно больше информации о реализации схемы.

Ну вот совершенно другое дело, видно даже то что синтезатор понял что суммирование в первом разряде не требует коррекции и завел это разряд сразу на регистр готового результата. Оно и верно с каким бы числом мы не суммировали 0110B (константа коррекции) в первом разряде ничего уже не поменяется. Лишний раз убеждаемся что синтезатор прогоняет всю таблицу истинности через оптимизатор (ну например через карту Карно). Кроме того видим опять шунты из двух LUT, таким образом считаем расход LUT как 8. В дальнейшем эти LUT могут быть использованы синтезатором в своих целях.

Осталось верифицировать BCD сумматор проверить получаемый им результат. Для этого необходимо написать testbench на том же Verilog.

module testbench;

reg clk;

wire [3:0]Co;

wire Carry;

reg [3:0]Ai,Bi;

reg Ci;

reg [15:0]QADDR;

sumbcd sum(

.clk(clk),

.a(Ai),

.b(Bi),

.Cin(Ci),

.RESULT(Co),

.Cout(Carry)

);

initial begin

Bi = 4'h0;

forever #40 Bi <= (Ai > 8)? Bi + 1'b1 : Bi;

end;

initial begin

Ai = 4'h0;

Ci = 1'b0;

forever #40 Ai <= (Ai > 8)? 0 : Ai + 1'b1;

end

initial begin

clk = 0;

forever #20 clk = !clk;

end

endmodule

Запустив проект в симуляторе ModelSim можно отсмотреть осциллограмму, хотя в принципе можно было бы просто сравнивать результат с тем что должно быть автоматически.

Результат появляется на регистрах только в следующем такте, так как по первому фронту значения слагаемых записываются в регистры rA, rB и только в следующем фронте результат сложения rA и rB записывается в выходной регистр результата.

И так сделаем выводы:

BCD сумматор - 8 LUT

BIN сумматор - 4 LUT

Расход LUT для BCD арифметики вдвое выше.

BCD сумматор - 353 МГц

BIN сумматор - 380 МГц

Частотность - здесь не все так очевидно, возможно будет и выигрыш по скорости, если количество операций для суммирования итоговых вещественных чисел будет меньше в случае BCD. Для этого необходимо задаться примером и совершить сложение на полноразрядных BIN и BCD сумматорах таким образом что бы получить вещественные значения в сопоставимом по точности формате BIN и BCD.

По следам "публикаций" - термины и пояснения

2009-06-19T16:03:00.000+06:00

Как совершенно верно заметил kosmoflyko любая статья должна быть самодостаточной, читающий не обязан знать всех терминов, их расшифровка должна быть под рукой в "подвале", а по возможности тут же в скобках понятно и наглядно. Виноват ― исправляюсь. :)

BCD - Binary Coded Decimal, представление чисел в двоично-десятичном виде. Основание счисления точно такое же как и в десятичной системе - 10. Несмотря на то что в двоичной тетраде можно закодировать большее число чем 9, кодирование идет до девятки:

DEC BCD(bin) BCD(hex)

0 - 0000 0000 - 00

1 - 0000 0001 - 01

2 - 0000 0010 - 02

3 - 0000 0011 - 03

4 - 0000 0100 - 04

5 - 0000 0101 - 05

6 - 0000 0110 - 06

7 - 0000 0111 - 07

8 - 0000 1000 - 08

9 - 0000 1001 - 09

Согласно правила для любой позиционной системы счисления после использования всего набора знаков (цифро-буквенных элементов системы счисления) происходит переход к следующей цифре в обоих разрядах числа (из всего набора цифр возможных в данной системе счисления). То есть девятка в нулевом разряде переходит в ноль, а ноль в первом разряде переходит в один 09 => 10. По большому счету число девять имеет один значащий разряд и бесконечное количество разрядов незначащих, столько сколько мы пожелаем 000000000..0009, практически это ничего не меняет поэтому незначащие нули опускают. Но опуская нули мы опускаем и суть систем счисления, превращение ноля в единичку происходит для нас рефлекторно ― буквально из небытие, из пустого места, как по волшебству вырастает единичка. На самом деле все логично ничего для нас не значащий ноль логично сменяется на следующую в наборе цифру 1.

Возвращаясь к BCD имеем следующее

DEC BCD(bin) BCD(hex)

10 - 0001 0000 - 10

11 - 0001 0001 - 11

12 - 0001 0010 - 12

13 - 0001 0011 - 13

14 - 0001 0100 - 14

15 - 0001 0101 - 15

16 - 0001 0110 - 16

17 - 0001 0111 - 17

18 - 0001 1000 - 18

19 - 0001 1001 - 19

Строго говоря указанные выше в таблице код 0001 0000 - это упакованное BCD число, неупакованное BCD число в качестве разряда использует не тетраду (4 бита), а байт и в итоге табличка будет выглядеть следующим образом:

DEC BCD(bin) BCD(hex)

10 - 0000 0001 0000 0000 - 01 00

11 - 0000 0001 0000 0001 - 01 01

12 - 0000 0001 0000 0010 - 01 02

13 - 0000 0001 0000 0011 - 01 03

14 - 0000 0001 0000 0100 - 01 04

15 - 0000 0001 0000 0101 - 01 05

16 - 0000 0001 0000 0110 - 01 06

17 - 0000 0001 0000 0111 - 01 07

18 - 0000 0001 0000 1000 - 01 08

19 - 0000 0001 0000 1001 - 01 09

Очередная особенность BCD числа ― это то что в двоичном мире за двоичным числом 1001 должно следовать число 1010 ― которая ни что иное как десять ― 10 в десятичной системе счисления. Но не для BCD чисел, для BCD дальше двоичного кода 1001 чисел не существует.

Таким образом мы теряем для

байта ― FF - 99 = 156 значений двоичного числа (62%);

слова ― FFFF - 9999 = 55536 значений двоичного числа (85%);

двойного слова ― FFFFFFFF - 99999999 = 4194967296 значений двоичного числа (98%);

Примеры без знаковых (unsigned) упакованных BCD чисел:

DEC BCD(bin) BCD(hex)

61279045 – 0110 0001 0010 0111 1001 0000 0100 0101 – 61 27 90 45

459 ― 0000 0000 0000 0000 0000 0100 0101 1001 ― 00 00 04 59

Примеры со знаком (signed) упакованных чисел BCD :

DEC BCD(bin) BCD(hex)

+1238901 ― 1100 0001 0010 0011 1000 1001 0000 0001 ― C1 23 89 01

-3524492 ― 1101 0011 0101 0010 0100 0100 1001 0010 ― D3 52 44 92

Как видно из примеров знак числа кодируется запрещенной комбинацией, для «плюса» принято использовать 1100B – 0CH, для «минуса» 1101B – 0DH.

ЯВУ - язык высокого уровня (Си, Паскаль, Бейсик, Ада, Фортран, Алгол …) считается что ЯВУ приближает программиста к низкоуровневым абстракциям и делает программы платформо независимыми. ЯВУ упрощает разработку программ, упрощают поиск ошибок в них, делают возможным повторное использование кода, увеличивают наглядность и самодокументируемость кода.

FPGA - Field Programmable Gate Array матрица программируемых логических элементов (Logic Element) связанных между собой магистралями с зарнее известным врменем распространения сигнала, подсоединение к магистралям и выделеным линиям (тактовые линии, линии сброса и установки) осуществляется настраиваемыми мультиплексорами. Логические элементы на основе LUT и D-триггера(ов) способны при комбинировании осуществлять множество логических функций (сумматоры, дешифраторы, шифраторы, счетчики, регистры). Как правило FPGA подразумевают синхрнный дизайн устройств, осуществляя таким образом безошибочное и быстрое функционирование синтезированной схемы. Частоты на которых могут работать FPGA для отдельных элементов до 450-500МГц. Такая частота есстесвенно достигается за счет блоков PLL существующих не в каждом семействе FPGA.Все данные подключений и LUT в FPGA хранятся в ОЗУ, таким образом при снятии питания FPGA "забывает" схему.

ASIC - Application specific integrated circuit, попросту интегральная схема выполненая по нормам позволяющим полученной схеме работать на заявленной частоте, с заявленным потреблением. В отличие от FPGA цикл разработки для ASIC значительно трудоемче и дороже. Как правило до корпусировки изготовленного кристалла необходимо пройти такое колиичество проверок и тестов что не хватит денег на изготовление масок для фотолитографии, именно по этому цифровые ИС предварительно обкатывают в FPGA.

LUT – Look Up Table, базовый элемент FPGA (сейчас уже и CPLD) позволяющий проектировать логические функции не комбинированием основных логических элементов (И,ИЛИ,НЕ,ИСКЛ.ИЛИ), а описанием таблицы истинности для входов блока LUT. Совершенно ничего нового в мире цифровой схемотехники не произошло, существовавшие много раньше шифраторы и дешифраторы по сути использовали ЗУ (например К155РЕ3) точно так же как и LUT. LUT это ОЗУ содержащие N входов и один выход, в него загружается таблица истинности представленная в бинарном виде для каждой комбинации входов, фактически же фирмы производители ПЛИС «изгаляются» с различными режимами работ LUT внося дополнительные входы и выходы переноса для каскадирования арифметических функций.

"Строительный блок" Altera MAX-II использует 4-х входовой LUT

"Строительный блок" Altera Arria-II использует 6-и входовой LUT

"Строительный блок" Xilinx Spartan-3 использует 4-х входовой LUT

Анализ архитектуры МК61 - рекогносцировка местности

2009-06-16T09:47:00.000+06:00

Виртуальная машина MK61 хоть и существует как программное решение поверх унифицированной аппаратной базы К745ИК13xx (MK161/152 - MCS51; mk61avr, calc152 - AVR), является самостоятельной сущностью - вычислительным ядром МК61 использующим стековую модель вычислений, это дает возможность сравнивать его функциональные возможности с распространенными вычислительными ядрами AVR, ARM, Z80, MSC51. В таблице приведенной ниже возможности МК61 сопоставляются с перечисленными вычислительными ядрами - как возможности платформы, без учета их реализации (ASIC/выч.комплект).

Характеристика	MK61	MK161 /152	Z80	AVR	MSC51	ARM7
Базовая разрядность данных	48	64	8	8	8	32
Кол-во РОН	5/15	5/15	18/3	32	9	31
Регистровые фреймы	Нет	Нет	Да	Нет	Нет	Да
Битовые операции	Нет	Нет	Да	Да	Да	Да
Логические операции	Да	Да	Да	Да	Да	Да
Арифметика с целыми числами	Нет	Нет	Да	Да	Да	Да
Арифметика с вещественными числами	Да	Да	Нет	Нет	Нет	Нет
Адресное пространство данных	Нет	Да	Да	Да	Да	Да
Прямая адресация	Да	Да	Да	Да	Да	Да
Абсолютная адресация	Нет	Да	Да	Да	Да	Да
Косвенная адресация	Да	Да	Да	Да	Да	Да
Кол-во условий ветвления	4	4	8	20	8	15
PIC (перемещаемость кода)	Нет	Нет*	Да	Да	Да	Да
Самомодификация кода	Нет	Нет	Да	Да**	Нет	Да
Косвенный переход	Да	Да	Да	Да	Да	Да
Цикловые конструкции	Да	Да	Да	Нет	Нет	Да***
Авто инкременты (++)/ декременты (--) регистров РОН (SP и PC не входит)	++ --	++ --	++ --	++ --	Нет	++ --
Стековые структуры	2 AS = 5 RS = 5	3 AS = 5 RS = 64 TS = 2	1 64K	1 64K	1 64K	1 4Г
Обслуживание прерываний	Нет	Да	Да	Да	Да	Да
Формат инструкции 0, 2, 3 - адресный	0/1	0/1	2/1	2/1	2/1	3/1
Гибкий формат машинной инструкции	Да****	Да	Да	Нет	Нет	Нет

* - Перемещение кода между страницами возможно

** - Самомодификация кода для AVR осуществима только в старшем семействе AVR и связанна с необходимостью записи данных в EEPROM программ, а значит ограничено предельным кол-вом циклов записи и длительностью записи в EEPROM.

*** - Циклической конструкцией для ARM подразумевается блочная загрузка/выгрузка регистров в память, поскольку она является параметризированной командой то с некоторым приближением ее можно назвать итеративным процессом с задаваемым количеством итераций.

**** - В том виде в котором МК61 существует с прошлого века формат инструкции задан двумя типами с однобайтным операндом (адресом перехода) и без оного. Но это не помеха и формат может быть легко изменен например увеличением разрядности второго операнда, отчасти благодаря наличию "расшиваемого" декодера команд (микропрограммное управление). В отличии от MISC (чем МК61 скорее всего и является) и CISC - практика построения RISC зачастую подразумевает дешифрацию определенных полей команды на лету (в такте выборки инструкции) и смена формата инструкции даже в части операнда - прямое изменение аппаратуры дешифрации.

Так как видимо ядро МК61 не предполагалось использовать вне ветки калькуляторов разработчики пошли на многочисленные упрощения платформы MISC. Например стараясь сделать систему команд понятной для ввода программ не специалистом, заменили непосредственный набор константы на ввод ее по разрядно или осуществили ввод и хранение адресов перехода в двоично-десятичном, а не полностью двоичном виде (МК61 может "переваривать" в качестве адресов и полные бинарные данные строя адрес по тому же BCD принципу). Использование медленной элементной базы (и принципа передачи и хранения данных в ЗУ комплекса - последовательное кольцо с 4 фазным методом передачи) скорее всего и привело к отказу от ввода событийного управления вычислительным ядром, лишив таким образом ядро МК61 подсистемы обработки прерываний. Ориентация на скромный объем программ, диктуемых калькуляторными задачами, внес в схемотехнику МК61 отказ от вместительных ЗУ и исключение инструкций доступа к адресному пространству через абсолютную адресацию (да и не в писывалось это в модель передачи индиректных констант). Однако наличие в системе команд косвенных операций решают проблему доступа к ЗУ, как к памяти данных (К(И)ПМ) так и к памяти программ (КБПМ, КППМ). Плата за такой переход - необходимость постоянно держать свободным регистр указатель на адрес в ЗУ или сохранять значение регистра используемого для доступа на арифметическом стеке. Увеличение кол-во уровней стека возвратов так же возможны без особых изменений платформы.

Одна из особенностей МК61 заслуживает особого внимания, поскольку благодаря этому платформа находится на ранг ближе к ЯВУ чем любая из рассмотренных. Эта особенность - возможность реализации циклических структур командой FLМ XX, где М это четыре возможных итератора в регистрах РОН R0...R3, а XX адрес перехода в случае неравенства результата итерации нолю. Структуры FLM дают возможность организовать автоматичеcкий декремент итератора (надо заметить - только декремент) с последующим сравнением на достижения ноля и переходом по результатам сравнения. При этом не происходит изменения в арифметическом стеке ядра - что не маловажно. Инструкция FLM в МК61 выражает сходную конструкцию do-while-for на языке Си:

do{

} while (i-- > 0);

while(i-- > 0){

};

for(i=N;i<0;i--){

};

с одной не очень приятной особенностью итератор i никогда не достигнет ноля, так как его изменение в МК61 происходит в момент исполнения адреса перехода. И выход из цикла FLM всегда знаменуется равенством итератора 1, при этом количество циклов соответствует значению итератора на входе в цикл.

Хотелось бы заметить так же, что МК61 обладает такой интересной особенностью не свойственной стековым машинам как регистр предыдущего результата Х1 (попросту "откат" регистра Х), в некотором смысле это пятый по счету уровень стека. Для стековых машин, по мнению Каупмана, наличие уровневости арифметического стека менее определенного числа (точно не помню скорее всего это 16) приводит к снижению эффективности производимых на базе стека вычислений. В принципе стек как безадресное ЗУ действительно быстрее любого адресного ЗУ, если он реализуется на основе регистров, так как при этом как минимум отсутствуют дешифраторы столбца/колонки. Мало того что стек как физический объект быстрее чем ЗУ с произвольным доступом, но он еще и приближает ядро к ЯВУ в виду того, что при разборе арифметических высокоуровневых скобочных выражений они легко (см. Дикстра - "лекции по компиляторам") сводятся к стековому порядку вычисления. Кроме того стек как капсула с параметрами отправляемыми в процедуру, мало того что очень выгоден (ибо быстр) и может являться удобным возвращаемым из процедуры контейнером результатов (для стековых машин), еще и исполняет роль фрейма локальных переменных. Почти всегда скорость работы стека организуемого в ОЗУ разработчиков компиляторов ЯВУ не устраивает, заставляя плодить сущности вида fast call для передачи параметров в регистрах :). Но и регистры в МК61 точно так же присутствуют как и в сравниваемых платформах.

В остальном, как показывает таблица сравнения ядер, МК61 вполне самостоятельное, специализированное на вещественной арифметики вычислительное ядро. Тот факт что скорость вычисления для вещественных чисел ниже чем для целочисленных может быть восполнено наличием аппаратного блока вычислений с вещественными числами. Правда есть тут и своя "ложка дегтя" - в МК61 вещественная арифметика осуществляется в BCD формате, а адресация по BCD весьма и весьма расточительна :) так как использует не всю информационную емкость двоичных чисел. Емкость тетрады (4 бит) 2^4 = 16, из которых BCD использует 10 позиций (от 0000B до 1001B), оставляя за бортом 6, которые составляет 37.5% - треть общей емкости. А значит и приведенное к целому BCD, вещественное BCD число так же будет адресовать меньше ЗУ, чем бинарное целое. Эта "неприятность" может быть разрешена внесением в платформу бинарного формата целого числа или возможным переходом с BCD представления вещественных чисел (IEEE-854) в бинарное представление FP чисел (IEEE-754). Это было бы целесообразно еще и потому что BCD представление ощутимо увеличивает размеры аппаратных сумматоров из за необходимости контроля десятичного, а не бинарного переноса (суммирование младших разрядов для BCD чисел зависит от получаемого результата). Существует мнение что работа с BCD числами быстрее отчасти из за того что не требует перевода в десятичное представление при выводе :), от части из за того что работать с вещественным представлением в BCD намного проще, нежели в бинарном. Кроме того из за того что BCD представление напрямую отображает ряд чисел точность вычислений по сравнению с IEE-754 напрямую зависит от количества представленных разрядов. В принципе осуществить качественное и количественое сравнение сумматоров соответствующих друг-другу разрядностей на базе LUT не составит особого труда.

P.S. Как частенько бывает ошибки и неточности вкрадываются уже после публикации, но не ошибается лишь тот кто не работает. Правки вносятся. В комментариях к посту можно понять какие изменения и почему произошли.

MK61avr - Доверяй, но проверяй!

2009-06-10T22:38:00.000+06:00

Развернутое тестирование платформы mk61avr по тестам приведенным у Дьяконова приносит урожай разномастных "глюков" и "багов", никаких революций и потрясений - просто нудное монотонное прохождение или провал тестов. Что делать, хоть в голове и рояться идеи побыстрей запустить на mk61avr работу с графикой - нужно обязательно получить результаты на тестах.

Скорость исполнения кода VM61 показывает завидную по сравнению с платформой МК61 воплощенной в "Калькулятор 3000", но надо заметить что это сравнение с железом прошлого века, кроме того single precision и должен быть быстрей.

Подробное описание пройденых тестов как всегда на сайте проекта, там же выложены их бинарные образы для зашивки в EEPROM.

Вскрылась интересная подробность на следующем тесте

у Дьяконова ответ 1090.3019, на mk61avr 1090.3018 - предположил что из за точности используемого формата чисел. Однако.... проверка на "Калькулятор 3000" дала тот же результат 1090.3018. Проверка кода Vitasam-ом на МК52 образца "шестьсот лохматого года" дала теже результаты 1090.3018. Либо "ошибка" в прошивке образца МК61/52/Б3-34 используемого Дьяконовым для составления программ и проведения расчетов, либо банальная опечатка :)

MK61avr - а не пора бы нам - пора?

2009-05-31T21:52:00.000+06:00

За исключением одной малой, но значительной детали (переключатель Р-ГРД-Г), комплекс MK61avr можно считать аппаратно состоявшимся, т.е. комплекс имеет функционирующие клавиатурный и дисплейный модуль. MK61avr на данном этапе работоспособен в обоих режимах МК61, автономном и программном.

Результат выполнения команды терминала "=12.405". В регистр X внесено делимое 12.405.

Результат ввода делителя 3.2 с клавиатуры комплекса.

Результат выполнения команды "делить" с клавиатуры (/).

Ошибка в последней цифре - точность арифметики с числами single precision.

Отладочный интерфейс реализованный через RS232 - "черный ход" в MK61avr :)

Включен режим ПРГ, на экране фрагмент программы (12.3,Вх,С/П) MK61avr.

Конечно на MK61avr в рамках платформы можно не только делить 12.405 на 3.2 :) ниже привожу список что возможно и что нет:

а) single precision арифметика, а значит, точность вычислений не соответствует МК61;

б) формат переходов несовместим с МК61 (в некотором роде это сделано намеренно)

в) VM61 на данном этапе не поддерживает

1. тригонометрию sin,cos,tg,arcsin,arccos,argtg и операции с угловыми величинами

2. логические операции not,or,and,xor

3. lg, ln, e^x, ВП

4. |x|,{X},[X],max,ЗН,СЧ

г) MK61avr оснащен последовательным интерфейсом для отладки и тестирования, в дальнейшем может быть исключен из кода (код терминала MK61avr объемист).

д) клавиатура МК61 завершена и транслирует все опкоды МК61

е) экран МК61 (газоразрядный 7-сегмент индикатор) воспроизводится на ЖКИ (кроме порядка числа при приведении и вводе порядка - команда ВП)

ж) MK61avr работает в обоих режимах - АВТ и ПРГ.

Вот и подумалось мне а не пора ли начать тестирование и "скармливание" тест-пакетов MK61avr, а мой соратник Vitasam и главный зачинщик :) проекта MK61avr меня в этом поддержал, предложив хороший набор таковых.

как всегда все подробности и исходные тексты проекта на googlecode.

MK61avr - русские с финами братья на век!

2009-05-25T00:37:00.000+06:00

Пришло время отложить клавиатуру в виду ее завершенности и приступить к дисплею.

Терминал с логом работы клавиатуры, набрано (123 Bx 65 /)

В качестве такого верного соратника я почти всегда использую очень дешевый у нас в стране (у нас до 150 рублей. На родине Торвальдса очень даже не дешево от 7 евро.), но одновременно очень удобный в подключении графический ЖКИ дисплей NOKIA 3310. Данное изделие просто подарок нам от финов :) такого распространения как у нас телефон NOKIA 3310 больше не смог бы получить ни в одной стране мира :). Дисплей исключительно удобен, управляется по последовательному интерфейсу и может быть подключен к порту SPI AVR. Дисплей сверх документирован, набрав в поиске lcd nokia3310 AVR можно получить огромное количество ссылок на его использование вот часть из них:

http://fandigunawan.wordpress.com/2008/06/18/lcd-nokia-3310-pcd8544-driver-in-winavravr-gcc/

http://www.microsyl.com/

Года два назад один мой знакомый написал под дисплей компонент для VMLab, я там кое что поправлял и ревизировал, но основную работу сделал он. К сожалению я этот модулек куда то задевал. В Proteus разработчики тоже быстренько подсуетились заметив эту тенденцию "народного ЖКИ" и сделали компонент для LCD Nokia3310.

Есть конечно и ложка дегтя - дисплейчик с контактами на стекле и поэтому нужно очень хорошо прижимать "гребенку" с контактами к самому дисплею и очень аккуратно распаивать проводочки (желательно потоньше). Кроме того питание контроллера дисплея 3.3В и к ТТЛ по всей видимости не толерантен - либо нужно конвертировать уровни, например через делитель на сопротивлениях 1К/1.2К и стабилизировать питание (LM117), либо переходить на питание AVR от 3.3В.

В комплекс MK61avr добавился ЖКИ дисплей (на экране тестовая заставка).

Монтаж делителя и стабилизатора для подключения LCD Nokia3310.

Схема подсоединения LCD Nokia3310 к комплексу MK61avr (KiCAD).

MK61avr - истории из гаражной жизни

2009-05-16T22:41:00.001+06:00

Програмно-аппаратный комплекс MK61avr.

Проект Mk61avr дошел до стадии подключения клавиатуры, и извлеченная из гаражных залежей того что выкинуть жалко, а хранить негде - МК61 отправилась ко мне на "прозекторский стол" на подключение в качестве модуля клавиатуры к своему последователю MK61avr.

Довольно стандартная для 80х-90х пленочная клавиатура.

Сразу оговорюсь что МК61 уже как 10 лет неспособна к вычислениям - тряпичная корпусировка (если кто видел телефонный провод с основанием из ниток поверх обмотанных медной тонкой стружкой то легко представит что из себя представляет корпусировка микропроцессора МК61) не выдержала нажатия на кристалл со стороны частей корпуса и клавиатуры и отошла от торца кристалла.

Корпусировка центрального процессора МК61.

В составе "программно-аппаратного комплекса MK61avr" клавиатура выглядит совсем даже не поблекшей и уже дает скан-коды.

Схема клавиатурного модуля MK61avr (KiCAD)

Справедливости ради стоит заметить, что по глупости и извечному "торопыжничеству" при подключении "вылетел" порт, а надо то было всего то включить токо-ограничительные резисторы и мое головотяпство прошло бы безболезненно.

Лунолет-1 на MK61avr взлетел и сел по тестовому шаблону один раз.

Взлет....

Посадка!

А вот почему не смог сеть при первом испытании Vitasam

Затем пришлось очень серъезно переработать терминал, и подтвердить результаты полетов мешали возникающие как грибы после дождя ошибки.

Проект продолжает развиваться. Vitasam всерьез взялся за SVN организовав все необходимое для работы коллектива вплоть до форума, подписки и Wiki.

http://code.google.com/p/mk61avr/wiki/Software

MK61avr - Лунолет-1, на рубеже

2009-05-10T09:32:00.000+06:00

MK61avr делает первые шаги по программам своих старших товарищей МК61 и МК52, после того как нам удалось реализовать необходимый инструментарий в терминальной отладке, кстати проект опять ушел на платформу ATMega16 уже бесповоротно, так как терминальный режим для МК61avr потребовал реализации объемного сервиса. А так как еще потребуется подключить клавиатуру и ЖКИ дислпей - в платформу ATMega8 уже не влезть.

И вот сегодня утром пришло сообщение от Vitasam - MK61avr смогла пройти по тестовым данным для программы Лунолет-1 почти до самого конца, отказав уже на посадке (зависнув в бесконечном цикле). Разбор полетов продолжается :) Листинг черного ящика Лунолета опубликует Vitasam http://mk61avr.googlecode.com/files/Lunolet1_on_mk61avr_terminal_1.pdf.

Исходные тексты программы MK61avr доступны в репозитарии (благодаря Vitasam, настроившему его)

http://mk61avr.googlecode.com/svn/trunk/ mk61avr-read-only

С Победой!

2009-05-09T12:22:00.001+06:00

С днем Радио!

2009-05-07T08:29:00.000+06:00

73!73!73!

Всех, всех, всех причастных к радио и не причастных поздравляю с Днем Радио, с тем что в нашей стране в первые в мире в этот день 7 мая (по старому стилю 25 апреля) 1895 года была продемонстрирована работа радиопередатчика-радиопремника инженером Александром Степановичем Поповым. Попов А.С. удивительно скромный человек, совершивший прорыв в области беспроводной связи и так и не удостоившийся заслуженной награды - признания по всему миру, образец для современных инженеров. В Российской и Советской науке таких людей было не очень много, но именно такие люди в и делали Российскую, а затем и Советскую науку.

Для тех кто желает ознакомится подробно: http://www.connect.ru/article.asp?id=5481

MK61avr - теперь в "железе" :)

2009-05-03T22:26:00.000+06:00

Устал от медлительной симуляции "терминалки" достал из "закромов родины", совсем так же как это делает kosmoflyko :), собранную ранее для экспериментов монтажку с ATMega8 и MAX232 закачал туда MK61avr... Ну и заработало! Тут же по ходу действия выявился глюк в дампировании с d, поправил. Посмотрев программу Лунолет-1, на сайте СЕМИКО http://mk.semico.ru/text/kon-tiki.djvu. Выяснил что отсутсвует набор /-/ с клавиатуры (т.е. с отладчика из терминала) пришлось приладить и опкод /-/ и терминальную команду '=~' для смены знака числа. Пора полетать на Лунолет - 1, хотя бы в терминале (LED дисплей к монтажке не подцепил еще).

Хотел было фотку монтажки подцепить, но телефоны плохо снимают - мажут, в принципе ничего интересного конечно.

P.S. Осталось 164 слова, убить их что ли на загрузку программы из файла через терминалку?

mk61avr - звезды становятся ближе или в погоне за Лунолет-1

2009-05-02T15:42:00.000+06:00

1 Мая - это всемирный день солидарности трудящихся, и самый что ни на есть повод ударно поработать на благо МК61 :) Виртуальная машина VM61, умеет почти все за исключением следующих операций:

10^X, E^X, Lg, Ln, Arcsin, Arccos, Arctg, Sin, Cos, Tg, Число Пи, /-/ и ВП

Поскольку клавиатуры еще нет, точнее пока ей мы еще не занимались, а набора опкодов как утверждает Freshman хватает для Лунолет-1,... и в общем так хочется, что то запустить пусть и неправильно (а как еще выявлять ошибки) и вот тут нам на помощь приходит отладочный интерфейс через терминал (UART - RS232 PC) , так удачно написанный в эти праздники, дающий нам возможность делать следующее:

d - общий дамп памяти программ МК61 в шестнадцатеричном виде.

x - вывод содержимого регистра X и дисплейного буфера (содержащего X в виде char)

s - вывод содержимого арифметического стека в виде

r - ывод содержимого 6 уровневого стека возвратов

g - запуск программы МК61 (аналог С/П в автономном режиме)

= - 16 символов команд для интерактивного ввода (0,...9,.,+,-,*,/) (по сути ввод чисел и операций в автономном режиме)

Терминал подключается на скорости 2400 бод, 2 стоп бита, 8 - бит данных, без четности

Не рекомендуется давить на "щелкатели" до окончания вывода отладочной информации на экран, хотя вроде бы эту проблему решить удалось (но в самом начале запуска МК61 и вывода приглашения все таки осталась возможность испортить UDR).

Так как оказалось что я перемудрил с библиотекой printf/scanf, и удалось еще уменьшить размер программ для AVR до 3887 слов, то мы вернулись на ATMega8, а использование TX/RX ног микроконтроллера потребовало переразместить интерфейс с разрядами LED, изменились подключаемые к LED ноги - PORTD[4...7],PORTC[0...3].LED нужно подключать через ключи открывающиеся по "1" на выводе порта, сегменты так же разведены на активную "1". В желез не проверялось, так что может быть и расхождения с симулятором.

Проект состоит уже из трех файлов, не считая компонента dll 7-сегментного дисплея. По идее нужно разделять его еще сильнее - надоедает прыгать сверху внизу по листингу.

место нахождение исходников http://mk61avr.googlecode.com/

MK61avr - промежуточные итоги

2009-04-29T00:49:00.000+06:00

Итоги таковы, что пришлось перебраться на платформу ATMega161, так как ATMega8 оказалась маловатой. Конечно это только исполнение программы, без автономного режима, клавиатура отсутсвует, в качестве устройства отображения результатов вычисления 8 разрядный LED - дисплей. Это все симуляция на VMLab фактически на железках ничего не проверялось, ввиду бессмысленности и достаточности симулятора VMLab.

Исходники проекта:

http://code.google.com/p/mk61avr/

реализованные опкоды

для набора числа 0...9, .

операции +, -, *, /, SQRT(X), X^2, 1/X, X^Y,

управлением стеком Bx, FBx, XY, Fo

работа с регистрами памяти П0...ПЕ, ИП0...ИПЕ, КП0...КПЕ, КИП0...КИПЕ

управление исполнением программы БП, X==0, X!=0,X<0,x>=0, L0, L1, L2, L3

MK61avr - Шах и рокировка

2009-04-26T21:39:00.000+06:00

"Определяющие трудности", а именно точность арифметики при реализации МК61 на распространенной платформе Atmel AVR не заставили себя ждать. Как правильно заметил гн. Степанищев, проектант МК161, single precision это не та база на которой плавающая точка будет сохранять необходимую точность. Что бы это понять нужно осознать что в бинарном мире выразить дробное десятичное число невероятно сложно из за интервала в котором находятся максимум и минимум таких чисел. Это настолько же сложно насколько сложно в реальном мире привести любую дробь к абсолютно точному значению...

В первые я понял это когда в черте каком лохматом году сдавал лабораторную по сопромату (надеюсь все знаю когда надлежит жениться прилежному студенту? :)), принимал у нас лабы зав. кафедрой, мужичок на редкость въедливый и жутко противный. Ну понятно что целых чисел при нагружении балки от индикаторов часового типа не добиться, особенно дело усугублялось трех этажными формулами переводящими перемещение в напряжение, ну а когда ко всему этому прибавляется кручение балки вокруг возможных осей и в дело вступают углы, а значит синусы - то хорошо обученный студент задавшись точностью округляет до третьей цифры после запятой и высчитав огроменный формульный ряд в калькуляторе ничтоже сумнявшись идет сдавать. Ха-ха в этот день все получили отлуп... Поокруглив исходные значения для конечных формул мы естественно получили неправильные результаты - такие прогибы и кручения балки какие были у нас должны были разрушить конструкцию еще на первом этапе нагружения. Лабы мы сдавали ровно неделю, под конец уставший от нашей тупости зав.кафедрой потребовал немедленно выбросить все наши калькуляторы и считать в дробях пока есть такая возможность, каково же было наше удивление когда без всякого округления до тысячных или десятитысячных (некоторые кадры округляли до -6) у нас получились значения прогибов и кручений с точностью до сотых и десятых долей. Мораль собственно такова что обыкновенная дробь до тех пор имеет точность - пока отсутствуют эволюции по переводу ее в десятичный вид. Поскольку в двоичном виде мы завязаны на базу - степень двойки, то как бы мы не крутились точно может быть представлена только дробь.

32 битный формат хранения так сильно растягивает отрезки на числовой прямой пытаясь охватить необходимый диапазон min..max что результаты будут заметны уже в 7 порядке после запятой (если привести число к виду 1.MxE = ) - что и демонстрирует симуляция исполнения сложения двух чисел на виртуальной машине МК61avr:

123.235

961.32

МК61avr = 1084.5551

МК61 = 1084.555

Это для разминки мозгов тех, кто одной левой на просторах инета хотел показать собственную удаль. Для double precision 64 бита существует только одна возможность работать нативно в пределах платформы компилятора - это купить IAR C. WinAVR к сожалению только называет double - double-ам, а на самом то деле это обычный single precision то, что в ANSI Си часто кличут float32.

Что бы шах не стал матом нужно найти библиотеку 64 битного floating point и прикрутить ее к WinAVR. А пока рокировка - терпим ту точность, которая есть в наличии :)

P.S. Вот как эту же операцию проделывает код от BCB6 для float32 становится понятно откуда у 1 после 555 ввыросли ноги :)

МК61avr - виртуальная машина, ход Е2..Е4

2009-04-23T10:28:00.000+06:00

Виртуальная машина, это почти что машина желаний :) ты ей номер желания, а она распоряжается собственными ресурсами используя процедуру реализации желания. Сразу вспомнился анекдот про то как в "дурке" контингет травит анекдоты, и так давно он уже этим делом занят, что за анекдотами закрепили номера и вместо длинной борадатой байки называют номер анекдота - ну а дальше по ситуации "ржут" или обижают расказчика. Тут в палату заходит медсестра и один из разказчиков хитровато выпаливает - "127!". Народ начинает мычать "уууу....как тебе Вась не стыдно в присутсвии женщин такой пошлый анекдот рассказывать!". Вот точно таким же образом используя маш.код МК61 занимающий ровно байт нужно "будить память" виртуальной машины и выполнять список действий над ресурсами.

Ресурсами ВМ являются:

регистры памяти П0...П14 - по аналогии с MCU регистры общего назначения (РОН)
регистры арифметического стека X1,X,Y,Z,Т - для стековой машины маловато
регистры стека возвратов - по аналогии с MCU аппаратный стек возвратов

(ничего не забыл?)

Обощенно мне видится следующая блок схема виртуальной машины МК61.

МК61ppc - лучше меньше, да лучше

2009-04-22T23:05:00.001+06:00

Не буду нараспев хвалить Бейсик как язык, он в этом не нуждается, но вот среда Basic4ppc - выше всяких похвал, пишется комфортно, удобно - думаешь только о проекте, не отвлекаясь на мелочи " как это сделать", "а как тут вывернуться". Все очень органично, уже который вечер просто получаюу довольствие от самого процесса. Дело с эмулятором стронулось настолько лихо, что под впечатлением скорости разработки я начал забредать не туда, подставляя костыли под покосившиеся конструкции, потом понял это - осознал сделал несколько шагов назад и перелопатил код так как мне бы хотелось что бы он выглядел не мешая наращивать мясо. Благодаря этому отливу обнажились острые камни, которые потом бы резали ноги. Успел к "приливу" :) вырастить новый скелет - теперь "нарастать мясу" одно удовольствие.

В который раз удивился Бейсику (но первым языком в памяти все равно остается Фортран!) умудряющемуся простотой не мешать творческому процессу.

Теперь эмулятор умеет многое (арифметика, читать/писать память, кое-что со стеком). Конечно это далеко не все, но что особенно важно не стыдно показать :) и легко его будет нарастить новыми оп-кодами. Как писал Владимир Ильич - "лучше меньше, да лучше!". В режиме программирования загнал простецкое вычисление гипотенузы :) получилось без ошибок - чем собственно и доволен.

Как художник, художнику оформление не задалось - дорисовать фальш панель можно и позже.

Хоотел прицепить файлик с исходным кодом, кто бы научил как это делать? :) Ну не постить же простыню исходника на весь блог.

МК61 - симуляторы, определяющие трудности

2009-04-21T20:19:00.000+06:00

Тема аппаратного симулятора МК61, на примере его реального прототипа МК152 в свое время дало огромную пищу для роста все возможных спекуляций и заблуждений, а именно в "инете" процветали высказывания:

"Что тут продавать, ерунда какая, никакого прорыва, никакого хай тека!"

"Вот так разработчики что за халтуру они нам продают, чем хвалятся? Да я за неделю (день, месяц, полгода) сделаю лучше и удобней!"

На самом деле МК152 это образец хорошо выполненной работы. Далеко не халтура, а прибор, в который инженер проектировщик вложил душу и знания. И вот почему я так считаю - по заявлению многих уже опробовавших калькулятор, он очень близко совместим с аналогом, при наличии заложенного в него огромного потенциала расширения. Совместимость это огромный плюс, учитывая накопленную базу алгоритмов в маш-коде МК61-МК52. Достаточно быстрая арифметика и, что самое главное, при заявленной скорости работы допустимая погрешность вычислений (на уровне аналога или выше) - вот это тот самый параметр, который на мой взгляд и показывает глубину вложенных в МК152 знаний.

Первое с чем столкнется человек решивший повторить разработку СЕМИКО в железе это точность вычисления. Точность вычислений задается форматом арфиметики с плавающей точкой используемой в проекте. Золотой серединой будет floating point single precision формат требующий для хранения 32 бита. При использовании 8 битного микроконтроллера (а в МК152 стоит х51 клон) добиться от арифметики сходных по сокорости с зарубежными микрокалькуляторами результатов (с 32 битным сердцем и аппаратным умножением, а под час и блоком MAC) задача очень сложная. Требующая проработки процедур на уровне ассемблера.

Вот что из себя представляет формат хранениния 32 битного fp single числа:

Для того что бы хотя бы начать с ним работать его нужно как минимум распаковать :)

в PocketPC теперь можно програмировать легко и удобно

2009-04-17T10:51:00.000+06:00

Накануне решил поискать, а какие средства разработки есть под мой старый добрый коммуникатор PocketPC Rover W5. И очень удивлся когда кроме монстроидального VisualStudio2008 (3.5Гб !!!), сущетвует маленький пакетик Pelles C с SDK и визардом под создание проектов на платформе Windows Mobile 5 (6, 2003) http://www.smorgasbordet.com/pellesc/. Принцип создания программ в этом пакете восходит к старым древним традициям - опуская нас на уровень обработки очереди сообщений от GUI устройства (все возможные WM_ сообщения) бесконечной вереницей case-ов. Ну в принципе тоже хорошо, хоть и отвык я от этого в Borland C++ builder.

Порывшись еще в мировой паутине, я наткнулся на велкиолепную штуку позволяющую писать программы для коммуникаторов (и для Смартфонов тоже) не только на хосте (IBM PC), но и на самом коммуникаторе, причем делать это в очень удобной форме визуальной разработки и на всем доступном и понятном языке Basic. Продукт это называется Basic4ppc http://www.basic4ppc.com/Downloads.html , триальная версия ограничена тем что не может компилировать в исполняемый модуль, а работает только с интерпритатором устанавливаемом на PocketPC и являющимся таким же законченным модулем для разработки исключительно средствами самого PocketPC. Существует Российский сайт поддержки данного продукта http://basic4ppc.narod.ru/index.htm

Меня это водушивило (ну а что еще делать сидя в очереди у кабинета врача?! Или например в очереди на предстоящем техосмотре?!). И я решил а не попробовать в появившиеся у меня внезапно свободное время написть симулятор программируемого калькулятора МК-61 на этом языке. Найти таковой на просторах интернета для PocketPC не удалось, а покупать аппартную платформу МК-152 точнее его мобильный вариант МК-161 пока нет средств. Кстати думаю что стоит приобрести себе МК-161 как память об МК-61 и моих лучших дестких впечталениях от начал программирования - когда программировать очень хочется, а не на чем :) и тут появляется подарок родителей - поошривших меня за мое зверское стремление к программированию. СЕМИКО в Новосибе конечно молодцы, работу проделали огромную http://mk.semico.ru/oinfo.htm.

Так выглядит настольный варинат МК-152

Так выглядит мобильный варинат МК-161

Вот так выглядит средство разарботки Basic4ppc с моим проектом МК61 в нем, в принципе очень удобно как на хосте так и на самом КПК работать в этом пакете.

Шина PCI - оптимизация

2009-04-14T09:49:00.001+06:00

Несмотря на сваливший меня с ног грипп я все так заставил себя добить симуляцию схемы, и заменил дешифратор на ИМС (уж слишком много ступеней логики) на дешифратор на диодной матрице :) симуляция в Протеусе показала работоспособность на уровне логических связей :) Пришлось правда вместо регистра SN74F377 (оказалось в предыдущей схеме я накосячил с регситром взяв латч с разрешением выхода SN74F374) поставить 6-триггерный регистр хранения, так как в Протеусе SN74377 не симуляционная модель. На уровне времянки я думаю проще проверить практикой. Кстати Протеус делает авторазводку. Но вот разъема PCI у него в шаблонах нет. А вот в KiCAD-е, который так любезно подсказал мне Kosmoflyko есть все, и пакет очень не плох, попробую в нем изготовить PCB.

P.S.(от 15.04.2009) Изменил схему, (убрал лишний диод и лишний элемент, таким образом даже уменьшил готовое устройство - на один ИМС корпус). Слегка поправил симуляцию, была помарка.

Шина PCI - хулиганство чистой воды

2009-04-08T23:43:00.001+06:00

Вот так я себе представляю это устройство в серии SN74Fxx, честно скажу я его еще не проверял в симуляторе. Проверю и скажу работоспособно ли. Три ступени логики с задержкой порядка 8 нс, дают Fmax схемы до 41МГц. Не уверен что у дешифратора задержка не больше 8нс, скорее всего больше. Надо бы как то проверить в симуляторе. Ну вообщем хулиганство это чистой воды :)

Шина PCI - интересная эта работа из болота тащить бегемота

2009-04-08T01:08:00.000+06:00

Вообщем чувствую я это далеко не последний подход к схеме :). О главном - два триггера, один Dsel отмечает начало и конец транзакции данных (не транзакции PCI шины!!!), второй Dst служит формирователем импульса захвата (импульс одиночный в первом такте транзакции данных). Сигнал DEVSEL# и TRDY# формируются по остаточному принципу, при появлении готовности IRDY# от инициатора обмена по шине (в данном случае от CPU). Как мне кажется элемент AND на запись данных в Dsel все таки излишен, надо думать как от него избавится не нарушив логику работы.

Соответсвенно болячки остались:

а) при обмене с портом ВВ в пакетном режиме с стартовым адресом отличным от 8оН, весь пакет будет пропущен.

б) при изменении готовности инициатора в момент передачи данных не повлияет на устройство, оно все равно защелкнет "какой-то" код.

В отличии от схемы приведенной ранее, эта хоть работоспособна на разных пакетах данных, первая схема - совсем "шлак". Как я заметил позже там и сигнал TRDY# не правиильно формируется, так же и триггера не возращаются в исходное состояние по завершении транзакции.

Ну и как всегда результаты проверок ModelSim-ом:

Данная диаграмма отражает запись в порт 80Н данных 22Н. Это самый простой вариант.

Данная диаграмма отражает запись в порт 80Н данных 80Н. Это вариант посложнее - так как линия декодера POT80# активна в течении всей транзакции шины PCI, а диаграмма показывает что устройство зависит от этого сигнала лишь однажды в начале транзакции по шине PCI.

Исходники устройства на Verilog:

`timescale 1ns / 100ps

module post(POSTo, TRDY, AD, CBE, FRAME ,IRDY, RESET, CLK);

output [7:0]POSTo; // вывод кода POST-ошибки

//input MXpost; // мультеплексирование тетрад POST-кода

//input PortSel; // конфигурация устройства на адрес порта POST 80H/84H

//-------- ШИНА PCI --------------------------------

output TRDY; // Target Ready - готовность к обмену целевого устройства

input [15:0]AD; // Address/Data - мультиплексированная шина (32 бита) адреса/данных. В начале транзакции передается адрес, в последующих тактах -данные

input [3:0]CBE; // Command/Byte Enable - команда/разрешение обращения к байтам.

input FRAME; // Кадр. Введением сигнала отмечается начало транзакции (фаза адреса), снятие сигнала указывает на то, что последующий цикл передачи данных является последним в транзакции

input IRDY; // Initiator Ready - готовность ведущего устройства к обмену данными

input RESET; // Сброс

input CLK; // Тактовый сигнал

//--------

reg [7:0]R80H;

reg Dst,Dsel; // Триггера START и выбор устройства

wire CAPTURE = ~Dst;

assign TRDY = Dsel|IRDY;

assign POSTo = R80H[7:0];

wire PORT80 = ~((AD == 16'H0080)&(CBE == 4'B0011)&(~FRAME));

wire Dsti = PORT80|~Dsel;

wire Dseli = PORT80&FRAME;

always@(posedge CLK or negedge RESET) begin

if(~RESET) begin

R80H <= 0;

Dst <= 1;

Dsel <= 1;

end

else begin

Dsel <= Dseli;

Dst <= Dsti;

if(CAPTURE) R80H <= AD[7:0];

end

endmodule

Исходник тест-прогона для устройства не изменился.

Шина PCI - "семь раз отмерь - один раз отрежь"

2009-04-06T00:16:00.000+06:00

Или доверяй, но проверяй :) Результаты симуляции показали вот такую картину.

Смотрим на TRDY# и видим неприятную площадку вызванную запаздыванием сигнала IRDY# - готовности ведущего относительно фронта сигнала по которому переключается триггер обеспечивающий активизацию устройства сигналом DATA. Это означает что главным является сигнал IDRY#, а операция AND (элемент И на схеме) к сожалению коммунитативна. Значит.... продолжение следует на месте этого элемента должен быть мультиплексор, схему нужно изменить.

Исходники HDL проекта прилагаю.

Само устройство:

// команды по CBE шине
`define ConfigRead 4'b1010
`define ConfigWrite 4'b1011
`define PortWrite 4'b0011
`define MemRead 4'b0110

`timescale 1ns / 100ps

module post(POSTo, TRDY, AD, CBE, FRAME ,IRDY, RESET, CLK);
output [7:0]POSTo; // вывод кода POST-ошибки
//-------- ШИНА PCI --------------------------------
output TRDY; // Target Ready — готовность к обмену целевого устройства
input [15:0]AD; // Address/Data — мультиплексированная шина (32 бита) адреса/данных. В начале транзакции передается адрес, в последующих тактах —данные
input [3:0]CBE; // Command/Byte Enable — команда/разрешение обращения к байтам.
input FRAME; // Кадр. Введением сигнала отмечается начало транзакции (фаза адреса), снятие сигнала указывает на то, что последующий цикл передачи данных является последним в транзакции
input IRDY; // Initiator Ready — готовность ведущего устройства к обмену данными
input RESET; // Сброс
input CLK; // Тактовый сигнал
//--------
reg [7:0]R80H;
reg Dst,Dframe; // Триггера START и FRAME

wire DATA = ~Dframe;
wire CAPTURE = ~Dst;

assign TRDY = DATA&IRDY;
assign POSTo = R80H[7:0]; //(MXpost)? POST[7:4] : POST[3:0];

wire Dsti = DATA|FRAME;
wire PORT80 = (AD == 16'H0080)&(CBE == 4'B0011);

always@(posedge CLK or negedge RESET) begin
if(~RESET) begin
  R80H <= 0;
  Dst <= 1;
  Dframe <= 1;
end
else begin
  Dframe <= FRAME;
  if(PORT80) Dst <= Dsti;
  if(CAPTURE) R80H <= AD[7:0];
end
end

endmodule

Тест-прогон для него:

`timescale 1ns / 100ps
module testbench;
reg clk, reset;
wire [7:0]POSTo;
wire TRDY;
reg [15:0]AD;
reg [3:0]CBE;
reg FRAME, IRDY;

post card(
   .CLK(clk),
   .RESET(reset),
   .POSTo(POSTo),
   .TRDY(TRDY),
   .AD(AD),
   .CBE(CBE),
   .FRAME(FRAME),
   .IRDY(IRDY)
);
initial begin
   reset = 0;
   IRDY = 1'b1;
   FRAME = 1'b1;
   AD = 16'H0200;
   CBE = 0;
   #15 reset <= 1'b1;
   #20 AD = 16'H0080;
   #1 CBE = 4'b0011;
   #30 FRAME = 1'b0;
   #39 AD = 16'h0022;
   #1 IRDY = 1'b0;
   #81 FRAME = 1'b1;
   #2 IRDY = 1'b1;
end
initial begin
   clk = 0;
   forever #20 clk = !clk;
end
endmodule

Шина PCI - первый подход

2009-04-03T11:08:00.000+06:00

Пользуясь казусами шины и формализую задачу:

Необходимо выполнить захват операции записи в порт 80H (POST-CODE) на PCI-шине.

По пунктам:

1. Падение FRAME# сигнализирует о начале операции на шине PCI (о любой операции!!!)

2. Поднятие FRAME# сигнализирует о завершении операции на шине PCI, синхронно сбрасывая по приходу фронта CLK аппаратуру устройства в исходное состояние.

3. Переданные по первому фронту CLK, после упавшего FRAME#, 4 бита шины C/BE и 16 бит мультиплексируемой шины AD необходимо дешифровать в одну линию - сигнал PORT80H, уведомляющий о наличии на шине PCI операции по записи в порт ВВ с адресом 0080H.

4. Сигнал PORT80H является стартовым для устройства. По получению этого сигнала необходимо будет ответить на готовность ведущего IRDY# собственной готовностью TRDY# и указать сигналом DEVSEL# на то, что устройство (то бишь мы) выбирает себя в качестве целевого на шине PCI.

5. Сигнал CAPTURE# является определяющим для регистра R80H назначения кода-ошибки. Важно то что это сигнал необходимо фиксировать только на один такт шины (второй по счету), для избежания записи данных остального пакета - если будет запущен пакетный режим обмена с устройством.

5. Переданные во втором такте CLK, при наличии разрешающего сигнала CAPTURE#, данные с 8 младших бит шины AD защелкиваются в регистре R80H по фронту CLK.

Вот пожалуй и все. Басенку конечно я сократил до минимума. :). Если порт 80H попадется внутри пакетной операции и будет не первым в ней при записи в порты ВВ - мы пролетаем. Если операция записи в порт 80H будет прерываться ведущим устройством при помощи сигнала IRDY# сразу же во втором такте с момента падения FRAME# , то мы защелкнем "какие то" данные. Блок схему и диаграмку сигналов прилагаю.

P.S. Ндао будет отладиться в Model-Sime на ошибки. Может быть и намудрил где.

P.P.S. Читая спецификацию заметил что я не правильно нотирую сигналы, # - означает что действующий активный уровень сигнала низкий. Т.е. по сути эквивалентно обычному подчерку инверсии сигнала в привычных гостовских обозначениях. Исправился :)

Шина PCI казусы кторые помогают

2009-04-01T23:37:00.000+06:00

После изнурительного серфинга по вебу, скопилось много информации, которую необходимо систематизировать. И так вот интересные ссылки, которые раскрывают подробности по использованию PCI что называется "на коленке". По всей видимости "коленка" эта произрастает по моему скромному мнению из следующих причин:

а) для многих чипсетов на мат.плате находятся куча устройств PCI которые вися за мостом захватывают на себя порты ВВ как ресурс, соответственно на шине за мостом всегда будет выделен ресурс ВВ.

б) для многих древних PCI устройств спецификация шины не предусматривала крайне неудобного протокола автоконфигурации, правда такие устройства хоть и область ресурсов устанавливать не обязаны, маску доступа к портам ВВ указывать должны, так же как и код вендора.

Честно говоря ни пункт а) ни пукт б) меня совершенно не удовлетворяют в качестве ответов - почему оно работает, не думаю что спецификация по PCI даст какие то "всходы" после изучения. Конечно братья из комитета по стандартизации PCI хотели не малых американских денег за "тугоментацию", но ничего - свою работу они уже закончили стандартом 3.0 и денежных знаков у них наверное и без меня с избытком (нашел я спецификацию в свободном доступе :)).

и так ссылки:

1. http://www.platan.ru/shem/pdf/pci.pdf

===============================

Если кратенько: автор не рекомендует идти таким путем - ибо некрасиво это, да и инженерной мысли не достойно. Но как говориться "если сильно хочется, но нельзя! То - можно" :) Автор для ухода от реализации дешифратора области ВВ использует PAL(GAL) , в общем ПЛМ в своем самом зачаточном еще состоянии. Это понятно, потому что на 16 линий адреса и 4 линии команды нужно дешифроваться горой логики.

2. http://elm-chan.org/works/pci/report_e.html

=====================================

Хорошо известный в интернете китайский ресур также особо не напрягается, следуя принципам - "а что бы работало!", предлагает схожий подход - в центре PAL как стейт-машина и дешифратор адреса на 8 компараторах SN74F521. Причем адрес выставляется набором "щелкателей", что очень удобно. Все прекрасно обходится без шинников, за счет регистров с три-стейтом. Соответственно тоже ни каких "автоконфигураций" и областей ресурсов.

3. http://www.rlocman.ru/shem/schematics.html?di=41202

===========================================

А вот тут уже подход продуман и что радует автор так же "убился" затолкав все-про-все в 21 макроячейку и применив, как я и задумал, EPM7032. В данном изделии осознано отдается в конфигурационное пространство порт и шина с переключателей. Вот это уже явный прогресс DeviceID на шине позволит потом найти устройство в списках подключенных в ОС. Снимаю шляпу перед автором http://pvuinc.narod.ru устройства.

Посмотрев на народное творчество захотелось похулиганить самому, собрав все на голимой логике и посмотреть а зарботает ли. Вот уже почти и схема готова. Конечно без конфигурирований - только захват команды write IO (B/CE#=4'b0011) и адреса 84H или 80H. Схемка конечно не очень большая, но и маленькой ее не назвать. Так хотелось собрать дешифратор адреса на диодиках :) - но решил без фанатизма.

Шина PCI - доступно ли простому смертному?

2009-04-01T11:35:00.000+06:00

Сожалею что не пришлось столкнуться раньше, очень занимательный протокол и архитектура. Думаю что обязательно эксперементну с ней, на прмере POST-CODE считывателя. Посмотрел имеющиеся в свободном доступе реализации на VHDL и AHDL. В принципе понятно, после прочтения вступительного материала по шине PCI, понял что зря ее боялся. Но залезть даже на 33МГц будет не так просто. Все имеющиеся реализации начинают с 64 ячеечной EPM7064, у меня либо больше (EPM240) либо меньше (EPM7032). Поскольку простых путей мы не ищем :), попытки реализоваться начнем с 7032.

Как нельзя вовремя попался блог http://kosmoflyko.blogspot.com/2009_04_01_archive.html, хотелось бы отгородится от 8 старших бит адреса - нужно было знать задержки на логике (мои благодарности автору, за то что не поленился систематизировать материал). Хотелось бы без рассыпухи и с честными DeviceID, ClassID и BAR. Будем посмотреть.