Я может не совсем понял, но такой контролер прерываний будет терять прерывания.
Элементарная ситуация приходит прерывание от UART и через пару тактов процессора приходит кадровое, итог - прозевали прерывание от UART
Я может не совсем понял, но такой контролер прерываний будет терять прерывания.
Элементарная ситуация приходит прерывание от UART и через пару тактов процессора приходит кадровое, итог - прозевали прерывание от UART
Будет. 8 прерываний в строке*312 строк = примерно 2500. Шанс, что одно прерывание перебьет другое - примерно 1 к 2500. Вычисления больше от балды, но скорее всего недалеки от истины. Поэтому возможность кадрового прерывания я блокирую на период от поступления сигнала с UART до окончания INTACK. Извиняйте, забыл упомянуть
Как это реально будет работать - надо пробовать потоковую загрузку. Пока такой возможности нет.
Последний раз редактировалось Ewgeny7; 15.03.2010 в 15:40.
ScorpEvo ZS 1024 turbo+ CF-HDD/FDD/Mouse/SMUC 3.1/ProfROMse/NeoGS/ZC
Speccy-2007 128/AY/TR-DOS
Сайт с документацией к "Scorpion ZS 256"
А вот как это может выглядеть со стороны программной реализации чтобы не пропускать данные uart во время обработчиков Int50 (считаем что аппаратно оба прерывания разделены как описано постом выше):
Расчет на то, что в обработчиках прерывания UART первой командой делается DI, а предпоследней (перед reti) делаем EI.
Обработчик INT50Hz DI/EI не делает. Для защиты от повторного вхождения в самого себя он переставляет вектор своего обработчика на фиктивный обработчик, единственная функция которого запомнить было ли еще одно прерывание INT50Гц во время обработчика (и обработать его при выходе, если было). Так в наcтоящее время сделано в CP/M и я планировал это оставить в таком виде, т.к. пока не вижу подводных камней.
Таким образом, прерывание UART во время обработчика INT50Hz спокойно отработает (т.к. идет не на фиктивный обработчик Int50, вектор которого по адресу +FF, а на реальный обработчик UART по адресу +FD), оно ни на какой алгоритм не повлияет, т.к. лишь спуливает принятый байт в буфер, ничего тяжелого (типа переключения страниц, управления SP) тут не делается, в отличие от обработчика INT50Hz.
А вот прерывание INT50Hz во время обработчика UART работать не будет (из-за DI). Что, КМК, правильно.
Насколько все это хорошо наложится одно на другое покажет только будущее.
Последний раз редактировалось Error404; 15.03.2010 в 15:46.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Скорости во второй линейке более близки к тому, что можно настроить для реального компорта под Виндой (см картинку во вложении).
Кстати, даже если брать 9600, то это хорошая скорость - я именно на 9600 (стандартной дефолтной) использую RS-232 терминалы для современных серверов IBM. Для терминальной консоли хватает за глаза.
А что касается 76800 - то чем черт не шутит, может 10МГц такта Ориона и для 76800 будет достаточно.
Еще вопрос: я задумался где можно сделать буфер для приема символов с UART. Как насчет области 0F504...0F5FF - там в текущей реализации ОЗУ? Было бы удобно...
Или при обращении, к примеру, к 0F583 или 0F58B в действительности идет обращение к 0F503, т.е. к 580вв55 ромдиска?
Последний раз редактировалось Error404; 15.03.2010 в 16:08.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Тож полумера, можно сделать все просто и эффективно, есть к примеру 8 латчей
каждое устанавливается своим источником прерывания, и есть приоритетный шифратор (делается табличкой элементарно и займет в том же циклоне пару LUT).
Последней командой в обработчике надо сбрасывать свой латч командой OUT или к примеру слушать шину и смотреть когда приходит RETI и контролер прерываний скажем через 10 тактов если есть еще не обработанные прерывание, повторно выставит INT процу и все по кругу, в общем примерно так работают широко распространенные PIC, вместо приоритетного можно к примеру кольцевую обработку источников. В общем по ресурсам не много
Последний раз редактировалось ZEK; 15.03.2010 в 16:08.
Будет лучше проверять некую ячейку памяти на предмет равности нулю,
и сразу ее инкрементировать. Если был ноль то мы входим в тело обработчика, обрабатытаем дикреметируем уходим. Если был не ноль то выходим сразу.
Значение этой ячеки будет сообветсвовать количеству пропущенных вызовов, которео всегда можно учесть в теле обработчика.
.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Это уже совсем другая машина получится.
В нашем случае нужно поймать USART (по любому), и по мере возможности обрабатывать INT50. Второе имеет более низкий приоритет, и потеря цикла не будет трагедией.
А наворачивать полнофункцональный PIC - нет ни большого смысла, ни желания. Иначе опять зависнем на полгода...
А за полезную информацию спасибо!
Я пытался примерно как-то так и представить себе "взрослый" контроллер.
---------- Post added at 16:59 ---------- Previous post was at 16:54 ----------
У меня в терминалке выбор побогаче... Ну ладно, второй так второй.
Да, опять забыл добавить. Стоповых битов 2, а не один.
Последний раз редактировалось Ewgeny7; 15.03.2010 в 16:57.
ScorpEvo ZS 1024 turbo+ CF-HDD/FDD/Mouse/SMUC 3.1/ProfROMse/NeoGS/ZC
Speccy-2007 128/AY/TR-DOS
Сайт с документацией к "Scorpion ZS 256"
В моем случае - штатный виндовый HyperTerminal. Я правда не разбирался - этот набор скоростей это свойство терминала или все же драйвера RS-232 Винды.
А отчего это зависит? Просто любопытно, т.к. в наиболее часто распространенных: 8-N-1, т.е. 1 стоповый бит.
Два стоповых бита тоже штатно выбираемо для COM-порта. И даже полтора.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)