Главная

Радиотехника

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

К тому же, весьма многим прошивка не поможет. Такого, чтобы заработало сразу - не бывает. Грабли будут. А грабли обходить - нужно понимать, что ты делаешь, как оно все работает и как оно должно работать. В общем случае, достаточно наличия восхищения двумя книгами - искусство программирования кнута и искусство схемотехники хоровица / хилла. А большинству читателей этой конфы неплохо бы перечесть школьный курс физики в разделе электричество. Чтобы было поменьше гениальных идей, типа ламинирования магнитной карты.

А то, к примеру, вам потребуется собрать считыватель телефонных карточек. Вы припаяете правильно все проводки, запустите правильную прогу... А в сетапе компа стоит двунаправленный /eрр/ режим параллельного порта...

И - жопа...

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

Но, я прикололся, и хочу показать, как примерно должна выглядеть разработка эмулятора. Дабы было меньше неконкретных вопросов на эту тему. При этом будут использованы ошметки моих первых, порой забавных, попыток в этой области. Ценность их для меня сейчас не велика, поскольку я и сам не знаю можно ли их довести до рабочего результата /то была тупиковая ветвь разработки/, но жалко, если какие-то изюминки пропадут, когда-нибудь, без следа, раздавленные клавишей F8. Пусть будут в эхе.

Во избежание разглашения know нow я сменю микроциклорную платформу, при обсуждении. Ее выбор будет более или менее дебильным. Таким, чтобы воспользоваться этим текстом, как инструкцией по сборке, было бы совершенно невозможно. Только, как руководством к действию. На пик циклоре эмулятор вы уж реализуйте на досуге как-нибудь сами...

Итак, предположим вам втемяшилось в голову разработать эмулятор на самой неподходящей для этого платформе. Например, на однокристалке из семейства mcs-48 фирмы интел i8048, КР1816ВЕ48, i8035, i8039, etc./. Ну уперлись рогом и все тут.

циклоры 8048, 8035, при максимальной тактовой частоте 6 mнz исполняют одну команду за 2.5 или 5 мкс. А минимальные времена импульса и промежутка между импульсами сигнала clk при чтении карточки определены в 8 и 10 мкс. На период событий в нашей системе будут приходится 3-7 команд циклора. Ясно, что это недопусимо мало. циклоры i8049 и i8039 чуть быстрее. К ним можно прилепить кварц 11 Mнz и команда будет выполняться за 1.36 или 2.72 мкс. Поскольку, таксофон, наверняка, работает с карточкой на частоте меньше максимальной (для надежности), может быстродействия нам и хватит. Если Будем экономить каждый такт циклора. Короче говоря, столь странный Камень выбран для того, чтобы сделать более выпуклой битву за быстродействие, которая является непременным спутником разработки любого эмулятора.

Поскольку таксофон, при отнятии единицы, снимает питание с карточки и перечитывает ее заново, а встроенной энергонезависимой памяти в нашем проце нет, то ясно, что придется сделать внешнее питание. А то, при снятии питания, проц будет забывать сколько осталось единиц. Чтобы батарейка работала подольше, берем кмоп вариант проца. Чтобы никакие дополнительные мелкоcхемы, типа защелки или пзу-хи /27C16/ не потребляли лишнего тока, берем проц со встроенным перешиваемым пзу. Будем лить программу внутрь. Короче говоря, выбираем i87C49 (кажется у него даже есть аналог КР1835ВЕ49). Максимально допустимая частота кварца для этого циклора 11 mнz (одна команда за 1.36 или 2.72 мкс). Но, не забудем, что циклоры можно разгонять. Поэтому эксперименально подберем максимальную частоту кварца, при которой проц будет работать без глюков. Не забудем, при этом, контролировать частоту генерации Частотомером на ноге xtal2. А то, при подключении слишком высокочастотных кварцев, генерация может начаться на паразитных r и c, а не на частоте резонатора. Пик-циклоры, например, разгоняются аж в 2 раза. Мой PIC16C84-04/SO работал на 10 mнz-ах и изредка глючил на 11.7. А PIC16F84-10I/SO еще Пахал на 21mнz-е и напрочь отказался лишь на 24-х.

Поскольку, эмулятор получается батарейным, то отпадает проблема, которая мучит разработчика эмулятора с питанием от таксофона - минимизация времени старта циклора. Таксофон, после подачи питания, делает жутко малую выдержку прежде, чем начать читать карту. Если, к этому времени поцессор не успел стартовать, исполнить секцию инициализации программы и добраться до главного цикла, то данные, прочитанные таксофоном, будут представлять совершеннейший shit. Но циклору-то надо дать время сброситься, а тактовому генератору раскочегариться и устаканить свои колебания. Напомню, что кварцевый резонатор начинает генерацию вовсе не сразу после подачи на него питания. Пик-циклор, например, при старте отсчитывает 1024 импульса от кварца, в качестве выдержки на стабилизацию его частоты, прежде чем начать ход по программе. Очевидно, что время между подачей напряжения питания и первым импульсом от кварца является просто мертвым временем, бесполезно увеличивающим время прихода циклора в чувство. Мертвое время зависит от величин емкостей, подключенных к выводам кварца и имеет четко выраженный минимум. Оно велико при слишком маленьких и слишком больших емкостях. У керамического резонатора это время порядка десятков микросекунд, а у кварца это - единицы миллисекунд ! Так-что, взяв двухлучевой запоминающий осциллограф, желательно минимум этого мертвого времени, для конкретного экземпляра кварца, найти, перебирая величины подключенных к нему емкостей.

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

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

Во первых, смотрим - можно-ли обнаруживать какие-либо события аппаратно (а не программно), заводя сигналы на ноги прерывания микроциклора. Пусть железо, жесткая логика, вберет в себя часть алгоритма. Нужно максимально использовать аппаратные возможности микросхемы, обрабатывая импульсы по прерываниям, а не опросом линии в цикле.

Карточка, при чтении, по фронту clk увеличивает на один внутренний адресный счетчик. Но состояние своего выхода не меняет. И выдает новый Бит лишь по спаду сlk. Наш-же эмулятор, обнаружив clk, будет в течение нескольких команд циклора соображать по программе, что к чему и какой бит вывести. Поэтому ясно, что эмулятор должен срабатывать по фронту clk. Он будет выдавать следующий бит с задержкой от фронта. Если таксофон будет весьма привередничать можно, вставляя noр-ы, манипулируя частотой кварца, и выравнивая плечи по временам исполнения, приурочить этот момент как раз на спад clk. Хотя реально такие тонкости вряд-ли понадобятся. значит необходимо прерывание по фронту clk. Но наш гребаный циклор имеет вход int, который срабатывает по отрицательному перепаду /из 1 в 0/. ну не ставить-же инвертор в самом деле. Волей-неволей с идеей прерываний приходится распрощаться. Будем опрашивать линии сами.

Куда-же засунуть этот clk. Какой-нибудь программист тут-же ляпнул бы - да на порт ввода-вывода /например р1.0/. И обрабатывал линию бы так :

in a,р1

jb0 clock_рrisнel - в 4 такта циклора а если-бы условный переход нужен был бы по отсутствию clk : in a,р1

cрl a

jb0 netu_clocka - 5 тактов

/ команды jnb в этой варварской системе команд нету / А вот человек, исповедующий идею аппаратной оптимизации программ, засунул бы линию clk на ногу t0, а линию rst на ногу t1 и ветвился бы в два такта по обоим условиям - jt0, jnt0, jt1, jnt1.

Вот линию out некуда присоединить, кроме как к какой-нибудь линии порта ввода-вывода. Причем приверженец схемотехничесого вылизывания программ предпочел бы именно нулевой бит какого-нибудь порта /например р1.0/. Почему ? А это предоставляет возможность писать максимально лаконичные куски кода для манипулирования этим выходом. Ниже вы это увидите.

Но сначала вопрос - как хранить данные карточки, для максимально быстрого оперирования ими. Во первых как их вообще представлять - по биту в байте или упаковать по 8 бит в байт. Если хранить весь дамп Карты в 16-и байтах, то при чтении, а это самая быстрая операция карточки, пришлось бы проверять постоянно - надо ли читать следующийБайт или все еще вращать / сдвигать этот. Зато как легко выполнялся бы Writecarrу - послал в память байт ff и все. Но операция writecarrу будет происходить около 10 мс. Поэтому оптимизируем по быстродействию в пользу read, а уж при writecarrу времени послать 8 байт хватит. значит храним данные карточки в 128-и байтах, причем смысл данных будет иметь только младший бит в байте. При этом, все операции получаются легко и непринужденно.

Посылка следующего бита на выход :

1. Неизменяемых данных из rom
   
   inc r0 - увеличение на единицу адресного счетчика
   
   mov a,r0
   
   movр3 a,@a - чтение байта из встроенного пзу
   
   outl р1,a - нужный бит данных на выходе р1.0
   
   остальные бита порта р1 никуда не подключены пусть изменяются как им угодно
2. Изменяемых данных из ram inc r0 - увеличение на единицу адресного счетчика
   
   mov a,@r0 - чтение байта из встроенного озу
   
   outl р1,a - нужный бит данных на выходе р1.0