Орион-2010. Hard & Soft

[ZEK]

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

[Ewgeny7]

Я может не совсем понял, но такой контролер прерываний будет терять прерывания.

Будет. 8 прерываний в строке*312 строк = примерно 2500. Шанс, что одно прерывание перебьет другое - примерно 1 к 2500. Вычисления больше от балды, но скорее всего недалеки от истины. Поэтому возможность кадрового прерывания я блокирую на период от поступления сигнала с UART до окончания INTACK. Извиняйте, забыл упомянуть
Как это реально будет работать - надо пробовать потоковую загрузку. Пока такой возможности нет.

[Error404]

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

А вот как это может выглядеть со стороны программной реализации чтобы не пропускать данные 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]

Итого - получим скорости 57600, 28800, 14400, 7200, 3600, 1800
Или, как альтернатива - 2400, 4800, 9600, 19200, 38400, 76800.
Выбирай, какой список тебе больше по душе, такой и сделаю

Скорости во второй линейке более близки к тому, что можно настроить для реального компорта под Виндой (см картинку во вложении).
Кстати, даже если брать 9600, то это хорошая скорость - я именно на 9600 (стандартной дефолтной) использую RS-232 терминалы для современных серверов IBM. Для терминальной консоли хватает за глаза.
А что касается 76800 - то чем черт не шутит, может 10МГц такта Ориона и для 76800 будет достаточно.

Еще вопрос: я задумался где можно сделать буфер для приема символов с UART. Как насчет области 0F504...0F5FF - там в текущей реализации ОЗУ? Было бы удобно...
Или при обращении, к примеру, к 0F583 или 0F58B в действительности идет обращение к 0F503, т.е. к 580вв55 ромдиска?

[ZEK]

Будет. 8 прерываний в строке*312 строк = примерно 2500. Шанс, что одно прерывание перебьет другое - примерно 1 к 2500. Вычисления больше от балды, но скорее всего недалеки от истины. Поэтому возможность кадрового прерывания я блокирую на период от поступления сигнала с UART до окончания INTACK. Извиняйте, забыл упомянуть

Тож полумера, можно сделать все просто и эффективно, есть к примеру 8 латчей
каждое устанавливается своим источником прерывания, и есть приоритетный шифратор (делается табличкой элементарно и займет в том же циклоне пару LUT).
Последней командой в обработчике надо сбрасывать свой латч командой OUT или к примеру слушать шину и смотреть когда приходит RETI и контролер прерываний скажем через 10 тактов если есть еще не обработанные прерывание, повторно выставит INT процу и все по кругу, в общем примерно так работают широко распространенные PIC, вместо приоритетного можно к примеру кольцевую обработку источников. В общем по ресурсам не много

[Atari]

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

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

[Advertiser]

[Error404]

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

Можно и так. Эффект примерно одинаковый.
Надо будет посмотреть какая реализация получится короче, такую и принять (там есть ньюансы на этот счет).

[Ewgeny7]

Последней командой в обработчике надо сбрасывать свой латч командой OUT или к примеру слушать шину и смотреть когда приходит RETI и контролер прерываний скажем через 10 тактов если есть еще не обработанные прерывание, повторно выставит INT процу и все по кругу, в общем примерно так работают широко распространенные PIC, вместо приоритетного можно к примеру кольцевую обработку источников. В общем по ресурсам не много

Это уже совсем другая машина получится.
В нашем случае нужно поймать USART (по любому), и по мере возможности обрабатывать INT50. Второе имеет более низкий приоритет, и потеря цикла не будет трагедией.
А наворачивать полнофункцональный PIC - нет ни большого смысла, ни желания. Иначе опять зависнем на полгода...
А за полезную информацию спасибо!
Я пытался примерно как-то так и представить себе "взрослый" контроллер.

---------- Post added at 16:59 ---------- Previous post was at 16:54 ----------

Скорости во второй линейке более близки к тому, что можно настроить для реального компорта под Виндой (см картинку во вложении).

У меня в терминалке выбор побогаче... Ну ладно, второй так второй.
Да, опять забыл добавить. Стоповых битов 2, а не один.

[Atari]

... Эффект примерно одинаковый.
Надо будет посмотреть какая реализация получится короче...

оба варианта не реентерабельны - в этом их главный минус.
в моем подходе кода будет однозначно больше (+ использование стека), но мы всегда знаем к-во пропущенных вызовов.

[Error404]

У меня в терминалке выбор побогаче... Ну ладно, второй так второй.

В моем случае - штатный виндовый HyperTerminal. Я правда не разбирался - этот набор скоростей это свойство терминала или все же драйвера RS-232 Винды.

Да, опять забыл добавить. Стоповых битов 2, а не один.

А отчего это зависит? Просто любопытно, т.к. в наиболее часто распространенных: 8-N-1, т.е. 1 стоповый бит.
Два стоповых бита тоже штатно выбираемо для COM-порта. И даже полтора.