nedoPC.org

Так вот бывает, делаешь что-то своё, а потом вдруг надо подцепить туда UART, и начинаются поиски...

А в интернете все очень умные стали, только на С и С++ норовят что-то написать!

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

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

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


А схемотехнику включения i8250 или аналогов мы тут на форуме обсуждали здесь:
http://www.nedopc.org/forum/viewtopic.php?p=101034#p101034

И есть у меня ещё русский документ на этот самый UART i8250, и как работать с ним под Вендой
с примерами на ассемблере.

Думаю, может пригодиться для полноты картины работы с UART...


P.S. Ну и в Proteus схема включения UART i8250 всё же не совсем "настоящая": нет там
задающего генератора (он "внутри" модели), нет приёмопередатчиков - терминал работает
по ТТЛ уровням. Реально схема включения UART i8250 примерно вот такая:

Получился у меня один весьма полезный трюк, о котором я знал довольно давно, но ранее меня постигла
с этим трюком неудача под Windows 98, а вот под Windows 7 этот финт у меня вполне получился!

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

Но тут надо вспомнить, что все наши модели компьютеров в Proteus могут собственным кодом работать
с моделями микросхем UART, которых даже в моём старом Proteus 6.7 Pro по меньшей мере две, причем
работа с одной из них расписана в этом топике, а как работать со второй, расписано здесь.

В крайнем случае можно не прибегать к моделями микросхем UART, а написать софтовый протокол RS-232,
к чести Proteus, отлаженный в нём софтовый RS-232, на реальном железе при той же тактовой частоте
работает совершенно идентично! Сам я не так давно проверял.

Теперь - откуда же взять данные для загрузки через RS-232?

В Proteus есть замечательное устройство - COMPIM - которое позволяет модели устройства в Proteus
работать с настоящим COM-портом!

Так было в Windows 98, Windows ME, и даже под Windows XP. Но потом и версии Windows перестали поддерживать
драйвер, да и COM-порты стали редкостью - везде USB.

Но ещё со времен древних существует и развивается очень интересная программа - COM0COM.
Она позволяет в среде Windows организовать два виртуальных COM-порта фактически связанных между
собой нуль-модемным кабелем. (http://com0com.sourceforge.net)

То есть, если драйвер COM0COM установлен, то две терминальные программы, запущенные на одном компьютере
под одной ОС Windows, и подключенные к паре виртуальных COM-портов, взаимодействуют между собой так,
как если бы они работали через "железные" COM-порты и настоящий кабель!

Вот этот трюк с драйвером COM0COM и виртуальным COMPIM Proteus я и пытался проделать весьма давно,
и не вышло это у меня вот по какой причине: виртуальный COMPIM признаёт только порты COM1...COM4,
а COM0COM обычно ставит свои порты как COM6, COM7.
Но переназначить настоящий COM-порт на другой номер, чтобы освободить место для виртуального, вполне
даже можно: Как переименовать COM-порт, но переименовать виртуальный порт так не получается...
На этом закончились мои опыты с виртуальным COM-портами под Windows 98.

Поскольку под Windows 7 COM-портов настоящих у меня на ноутбуке и вовсе нет, я к этой идее вернулся,
скачал весь нужный софт, но тут выяснилось, что COM1...COM4 у меня снова заняты! Теперь уже виртуальными
портами самой Windows 7 для Bluetooth.
Но COM4 удалось переименовать в COM8 обычным способом, а виртуальный COM6, как оказалось, можно переназначить
в свободный теперь COM4 с помощью самой программы COM0COM!

Осталось сделать необходимые настройки COM-портов, и виртуальный компьютер на z80 под Proteus великолепно
заработал с настоящей терминальной программой Terminal 1.9 !!!

Под Windows 7 у меня терминальной программы никакой не было, и я выбрал скачать Terminal 1.9, поскольку
у него настройки наглядно представлены, и как пишут: люди, работающие с микроконтроллерами признали
именно Terminal 1.9 удобным, чтобы передавать bin-файлы.
Что ж... можно попробовать загружать софт через виртуальный нуль-модемный драйвер в наши виртуальные
модели компьютеров под Proteus!!!

Вот как эта идея выглядит на примере MULTITECH MPF-1, который я с интересом взялся поковырять...
Вот его формат обмена с магнитофоном:

Смотрим на формат передачи байта в MPF-1 (обведен красным контуром).
А теперь смотрим на формат передачи байта по протоколу RS-232:

Если откинуть бит четности, то в коде обмена с магнитофоном MULTITECH MPF-1 уже есть блок,
который идентичен формату 8-N-1 интерфейса RS-232!
То есть и дописывать ничего не придётся, а лишь аккуратно заблокировать лишнее - всякие пилот-
тоны, которые хороши для обмена с магнитофоном, а для RS-232 - ни к чему.
ПОТОМУ ЧТО интерфейс RS-232 ПРОПУСКАЕТ ПОСТОЯННУЮ СОСТАВЛЯЮЩУЮ СИГНАЛА!

Вывод по программному RS-232 идеально вписался в Монитор MULTITECH MPF-1 вместо подпрограмм вывода на ленту!

И, кстати, символ "U" (код 55H) идеально подходит для настройки любых устройств с RS-232:
при передаче большого блока кодов 55H передаваемый сигнал вместе со старт-битом и
стоп-битом без бита контроля четности представляет собой практически идеальный меандр,
что очень удобно для наблюдения на осциллографе и измерения временных параметров импульсов.

Программа ввода по интерфейсу RS-232 вместо подпрограмм ввода с ленты затруднений по
существу не вызывает, ищу только подходящее место в теле Монитора, чтобы вписать в него эту
подпрограмму максимально корректно, не затрагивая в коде ничего лишнего...

От виртуального терминала Proteus перешел к настоящему Терминалу 1.9 через компонент COMPIM
и драйвер COM0COM...
Процедуры записи и чтения через виртуальный COM-порт работают великолепно!

А вот сторонний софт мозг выносит не по-децки...
Сегодня пол-дня убил: почему-то этот Terminal-1.9 не может передать без ошибки строку:

Хорошо, что я её один раз уже передавал в MPF-1 через терминал PuTTY, поэтому не стал перетрясать
свой собственный код... Позже выяснилось вдруг в интернете, что символ "$" у Terminalа-1.9 - это
префикс для передачи двоичных чисел: "$2В" он передаст как байт 2ВН...

И очень громоздкий этот Terminal-1.9 для этих целей, что мне нужно...

Часа четыре уже перебираю все терминалки в Интернете... самая простая и шикарная, на мой взгляд -
Termite-3.4 :

Но, к сожалению, не умеет она работать с bin-файлами... и в hex-виде принимать не умеет...

Что ж... Интернет большой - буду посмотреть ещё!

"И они посидели ещё..." (с) И я посмотрел ещё... и пока смотрел, то думал о том, что в принципе
это не так уж и плохо, что ОС Венда у нас практически одна...
Если бы Вендов было столько же, сколько Линуксов, людям некогда было бы работать, они бы только
и делали, что прыгали бы с Венды "минт" на Венду "убунту" и так далее... (щютка)

Но в принципе я вроде как нашел терминальную программу, которая меня устраивает:

Пользователь, по совету которого я и разыскал этот CoolTerm, "перепрыгнул" на него как раз с
Terminalа-1.9 . Функционал примерно как мне надо и размер окна не очень большой...

На этом пока остановлюсь, а то уж мне хотелось "раскопать стюардессу" и скомпилировать
под Венду свой старинный маленький терминал!

И я это попозже сделаю чисто из интересу, потому как этот CoolTerm написан на языке Xojo (впервые слышу! )
и его исполняемый файл CoolTerm.exe весит 6.5 МБайт !

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

С этим терминалом я успешно закончил этот проект по замене магнитофонных программ
на подпрограммы интерфейса RS-232.

Теперь программу в кодах z80, написанную с помощью кросс-средств на РС можно удобно
закинуть в проект эмуляции микро-ЭВМ на z80 посредством виртуального COM-порта и
настоящей терминальной программы. Можно и сохранить какой-то код из проекта эмуляции.

Формат загружаемого файла с заголовком:
4 байта - "имя" программы - любой 4-байтный номер (не критично);
4 байта - стартовый адрес (в MPF-1 ОЗУ пользователя начинается с 1800Н, всего 2 КБайт) ;
4 байта - длина загружаемого блока кодов;
1 байт - контрольная сумма блока - младший байт обычной суммы всех байт;
N байт - загружаемый блок кодов.

Если контрольная сумма блока не совпадёт (не указали её), блок всё равно загрузится верно,
но загрузка закончится сообщением "-Err". Как на картинке постом выше.
В обычном случае при успешной загрузке выводится последний адрес и байт.

Требования к терминальной программе довольно просты, но, к сожалению, не все терминалки
подходят под них: терминальная программа должна уметь принять бинарный файл и сохранить
его, а также уметь передать именно бинарный файл.
Многие терминалки расточены под текстовые файлы и АТ-команды и с бинарниками работать
не умеют.

Также желательно, чтобы у терминалки была опция "поверх всех окон", иначе неудобно работать
с её окном и окном Proteus.

Выкладываю полностью рабочий вариант проекта Proteus "как есть", потому как я сейчас радостно
начну всякие мелочи прихорашивать - а это верный путь что-нибудь испортить...

Первая мелочь на ниве прихорашивания "каши маслом" мне не испортила!
Я начал прихорашивание с этого пункта:
Опция "поверх всех окон" для терминалок редкая поэтому я разыскал очень полезную утилиту
DeskPins, которая способна любому окну назначить свойство "поверх всех окон":

Поэтому я смело приделал "блэкджек со шлюпками", и на этом думаю проект RS-232 в MPF-I закончить.
Что-то подутомил он меня, тем более, что самое интересное я таки сделал...

А про "блэкджек со шлюпками" подробно изложу здесь.