Пример переделки жидких заводских проводов питания и внешних интерфейсов:

Увеличить

Ремшланг и реммодуль для 170го/бригантины:

Увеличить

hs_19
До АРУ пока не добрался.
Помаленьку, как выдаётся время, разрисовываю алгоритмы функций.
Взаимное сравнение ветвей разных функций даёт некоторое понимание, в какой ячейке ОЗУ какие данные хранятся.
Поэтому каждая новая ветвь алгоритма немного раскрывает смысл других, уже рассмотренных ветвей.
Вот нашёл, что функция установки частоты в блоках Б1-25 и Б2-114 после отправки кода ждёт 45 мс :)

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

Нужно своп выключить. Работать вообще без файла подкачки.

nikifor_r Это поможет?
Раньше я просто загонял цикл передачи: выплёвывал байт, ждал 10 мс, читал из буфера, проверял и опять...

Теперь попробую разделить процессы:
При передаче активируется таймер и каждые 1 мс отправляет байт, пока не кончится последовательность. По передачи последнего байта таймер выключается.
А читать байты будет своя процедура, запускающаяся по приходу инфы в буфер.
И если пришло сразу два байта, то передача останавливается, ждём 300 мс и начинаем передачу заново.

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

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

darkstar
Читать/писать побайтово (как и ставить таймер на 1мс) - имхо неправильно. У винды есть встроенные механизмы работы с serial port, достаточно указать скорость, номер порта и пр, она сама все отправит.
Пример кода можно посмотреть тут: http://www.codeproject.com/Articles/3061/Creating-a-Serial-communication-on-Win

Делал коммуникацию с arduino, никаких проблем, все работало без шаманств с файлом подкачки (и без него скорость реакции винды не гарантируется т.к. это не real time OS). Раньше все массово модемы использовали, и тоже все работало без проблем. В общем, затык тут надо искать где-то в другом месте, а не в настройках винды.
Кстати без файла подкачки часть программ может глючить т.к. могут быть ошибки виртуальной памяти (этот режим не является штатным для винды).

Если конечно Бригантина эта имеет очень примитивный serial-интерфейс без каких-либо буферов, тогда вероятно поможет плата-адаптер на микроконтроллере, которая принимала бы от винды данные, и уже по таймерам пересылала. Но стоит ли возня, хз.

DVE не, Бригантина всё нормально принимает.
Читать/писать побайтово требует интерфейс Бригантины, ибо каждый переданный/принятый байт должен быть подтверждён эхом (соединить Rx-Tx не предлагать!)
Вопрос в другом - винда иногда затупливает дольше, чем на 300 мс (в ардуине такое невозможно при правильно работающей проге).
В результате Бригантина успевает передать два байта, не получить ответ на них и вывалиться в сбой интерфейса.

Я работаю на нетбуке Atom N450 1,6 ГГц. Возможно, более мощный комп решил бы проблему, но требовать передового железа для работы с 30-летним процем Бригантины - смешно :)

А, если протокол такой что требует ответа за 300мс, да еще и железо древнее (Атом 1.6 это не просто тормоз а жуткий тормоз :) ), то тут да, ничего кардинального не сделать. Сомневаюсь что отказ от файла подкачки тут поможет, честно говоря. Ставить таймеры на 1мс - толку-то если проц не успеет.

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

Попробуйте кстати для управляющей программы установить более высокий приоритет ( http://stackoverflow.com/questions/5216347/how-to-set-the-process-priority-in-c ) сомнительно что кардинально поможет но может поменьше сбоев будет.

>но требовать передового железа для работы с 30-летним процем Бригантины - смешно

Проблема в том, что во времена ДОСа не было многозадачности :) Поэтому видимо разработчики считали что 0.3сек на ответ это достаточно даже для 8086.

DVE это не real time OS
Вот в этом-то вся засада!
Ну что ж, перепишу на таймеры, а потом посмотрим.
Ставлю таймеры на 1 мс, т.к. это минимальный интервал. Но при этом происходит разрыв процесса: один байт отослал, и квант закончился, можно передавать управление другим процессам. Иначе мой процесс единолично занимает много времени и операционка прерывает его выполнение самолично.
Думаю, что при таком алгоритме общая скорость передачи данных упадёт, зато стабильность повысится.
Ну а если и это не поможет, то выхода минимум два:
- ставить real time контроллер;
- увеличить интервалы ожидания Бригантины.

Переписал на таймеры - работает :)
Но медленно. Стабильный обмен командами типа "+/- 1 кГц" идёт на скорости 2 команды в секунду. Если передавать 3 команды в секунду - то "отказ линии".
Полный обмен вида "установить частоту" занимает около 3 сек.

Обмен вот такой:

Устанавливаем частоту:
0A <ПС>
46 <F>
30 <0>
32 <2>
31 <1>
37 <7>
38 <8>
35 <5>
35 <5>
0D <ВК>

Потом Бригантина отсылает принятую частоту назад (видимо для контроля):
0A <ПС>
46 <F>
30 <0>
32 <2>
31 <1>
37 <7>
38 <8>
35 <5>
35 <5>
0D <ВК>

И под конец Бригантина сообщает, что проходит сигнал ГОТОВ:
0A <ПС>
52 <R>
31 <1>
0D <ВК>

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

Надо бы дописать распознавание ответов от РПУ.
К примеру, на запрос состояния R0 мы получим следующую информацию (прошивка hs_19):
L11 - включен автоматический режим аттенюатора (АРЧ),
U036 - усиление ЗЧ в режиме АРУ равно 36 дБ,
U169 - усиление ПЧ в режиме РРУ равно 69 дБ,
K0 - включен режим РРУ,
E42 - установлен вид работы H3E,
F0050000 - установлена частота 500 кГц,
R1 - перестройка РПУ завершена, есть сигнал ГОТОВ.

darkstar
Сложно будет реализовать потенциал относительно быстрого синтеза (20мс) с таким небыстрым управлением...

Да я уже сомневаюсь насчёт быстрого синтеза. Где-то встречал инфу о 200 мс синтезе в Бригнатине...
Хотя нет - крутнул ручку на морде: 8-10 шагов за секунду перестроились.
Странно по ИРПС обмен происходит. Никакой оперативности.
Пока пишу распознавание команд РПУ. Потом посмотрим.
Может если передавать команды не виндой, а контролером (в реалтайме), то дело пойдёт быстрее.

darkstar
В т.о. параметры - 20мс.
А контроллером каким? Втычной многопортовкой с отдельными дровами sio?

Пока что дописываю программу хотя бы до бета-версии. Чтобы по-простому и без глюков пользоваться можно было:
- установить режим и полосу, рабочую частоту, аттенюатор, усиление ПЧ (или скорость АРУ), усиление ЗЧ, частоту тонального гетеродина (если требуется).
- записать/считать все эти параметры в каналы РПУ (100 каналов). Эдакие заранее подготовленные волны :)
- автоматически листать каналы со скоростью 2 канала в секунду (или медленнее). Или с той же скоростью шагать вверх/вниз по частоте с шагом 10 Гц/100 Гц/1 кГц.

Контроллер обычный атмеговский, на Ардуине :)
Но думается мне, это тормоза со стороны Бригантины.
Надо ещё переткнуть ПЗУ-шки, попробовать с Конкурсовской прошивкой. Там ответов от РПУ меньше :)

darkstar
Куча разных людей фирмварь на рпу писали наверное...)

Ага. У меня прошивок уже три версии - все разные :)
Твоя самая информативная: на каждую команду выдаёт подтверждение приёма и ещё кучу дополнительной инфы.
Конкурсовская - пока что самая лаконичная, получает команду и молча исполняет :)

Добрался до записи в канал.
Почему-то дистанционно Бригантина не желает писать в каналы с номером выше 00. Пишет только в него...
А с морды всё нормально.
Видимо косяк прошивки. Прошивка, кстати, от hs_19. Жаль.
Надо бы попробовать выполнить эту команду с Конкурсовской прошивкой, может пойдёт.

Разбираю код верчения валкодера.
Блин, как всё сложно.
Повернув ручку валкодера мы вызываем прерывание.
Из порта читается значение - поворот направо или налево. Если прочитались сразу оба - то ошибка, и игнор.
Далее, в каких-то ячейках ОЗУ хранятся признаки, что это за верчение: мы перестраиваемся по частоте, крутим громкость, усиление тракта, или листаем каналы.
Потом с внешних блоков читается значение кода усиления (к примеру). Проверяется, не вышли ли мы за границу допустимых значений.
Потом аккуратно из слова управления блоком вытирается значение усиления и вписывается новое...
Если в процессе этой работы возникло новое прерывание, то все предыдущие действия аннулируются.
Программа постоянно проверяет сама себя.

Да, вот ещё что.
Преобразователь USB-UART-ИРПС питался от USB-порта. И при работе нетбука от батарей ошибок связи было больше :)
Видимо при питании от батарей напруга в порту проваливается, и этого уже не всегда достаточно для чёткого мигания светодиодами ИРПС-а.

darkstar
Разбираю код верчения валкодера.
Блин, как всё сложно.
Повернув ручку валкодера мы вызываем прерывание.
Ага, контроллер жрет как не в себя, когда это прерывание обрабатывает.
Питалово по хилым проводам проваливается и в динамике как результат бульканье
от совокупных помех по питалову... При хорошей антенне на это дело пох, а вот при веревке слышно, и еще как)
Клава, кстати тож по прерыванию. У меня в одном из экземпляров клава была продавлена так, что замкнуто было несколько клавиш к ряду. Контроллер сканируя клаву натыкался на замкнутую кнопку, уже не помню в каком порядке идет сканирование, и закручивался на обработку одого и того же прерывания. Оно безусловное... Вобщем, не достучишься)))

Там прерывание ввода одно на клаву/валкодер, и оно векторное (т.е. проц после возникновения этого прерывания запрашивает адрес перехода). Это прерывание можно запретить установкой седьмого бита (Р=1) в слове состояния процессора (PSW).
Например, выполняя команду MTPS 000 200 мы наглухо блокируем обработку прерываний VIRQ (клава/валкод), IRQ2 ("Готов"), IRQ3 ("ИРПС").

Если мы повернули валкод, то плата 5006 блока Б10-38 определяет направление вращения, и в соответствии с этим выставляет единицу в седьмом или в пятнадцатом бите регистра 060 040. Потом плата подаёт сигнал VIRQкпн.
Если же была нажата клавиша, то плата подаёт сигнал VIRQкл. Код нажатой клавиши хранится в регистре м/с D22 и определяется последующим программным сканированием через регистр 060 040.

Сигналы VIRQкпн и VIRQкл приходят в блок Б10-82, который формирует сигнал VIRQ для платы вычислителя (блок Б10-37). Когда же проц запрашивает вектор прерывания, то блок Б10-82 через микросхему D19 выдаёт адрес 000 340.

Таким образом, при нажатии на клавишу или при повороте валкодера, проц по прерыванию переходит на адрес 000 340.
Но это только в том случае, если прерывания разрешены (бит Р=0 в PSW).


Далее (по прошивке Конкурса) идёт переход на адрес 001 142 и запрещаются все прерывания.
По адресу 001 142 мы читаем данные из регистра 060 040 и определяем, что же вызвало прерывание - клава или валкод?
Если оба бита b7=0 и b15=0, то это клава.
Если оба бита b7=1 и b15=1, то это ошибка. Записываем в регистр 060 040 число 000 377 чтобы клава сработала при следующем нажатии, и выходим из прерывания.
Иначе - это валкод.

Если это был валкод, то смотрим признаки - что именно меняем валкодом: частоту, громкость, усиление, тон или листаем каналы.
В зависимости от этого осуществляется переход на подпрограммы: 014 136, 015 364, 013 300, 013 016, 011 376.

Если же прерывание по клаве, то сканируем клаву.
Сканирование осуществляется последовательной записью и сдвигом одной единицы в регистр 060 040.
Затем читаем данные из регистра 060 040 (запись и чтение производятся в физически разные регистры, хоть программный адрес один).
Если мы получили отклик, то расшифровывается позиция нажатой клавиши.
Если отклика нет, то сдвигаем единицу в следующую строку и повторяем цикл.
Полученный код нажатой клавиши хранится в ячейке 111 144.

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

З.Ы.
Не помню, выкладывал ли я схему сопряжения с UART с ИРПС...

Увеличить

Увеличить

Исходники в Layout 6.0 и Splan 7.0:
http://www.radioscanner.ru/uploader/2014/irps_03.rar

darkstar
З.Ы.
Не помню, выкладывал ли я схему сопряжения с UART с ИРПС...
Да, выкладывал.
Обработка клавы и валкодра сложна и запутана)

Что-то отказывается моя Бригантина запоминать каналы по команде через ИРПС. С передней панели всё ОК.
И на Конкурсовской прошивке пробовал, и на hs_19...
Даёшь команду, а тебе в ответ <ПС>, <ПС>, <ПС>, <ВК> - ошибка обмена.
Команда проходит только после третьей попытки :)
Причём другие команды отрабатывают нормально. Странно.
Дописываю программу управления Бригантиной по ИРПС. Хотелось бы добавить возможность загрузки в Бригантину всего банка памяти - а тут такая попа. Всё остальное работает, как задумано.
Отклик (не эхо) на команду использую для изменения частоты и прочего на морде программы, чтобы отображалась фактическое положение вещей. В этом плане очень удобно.

Опять взялся ковырять ПЗУ.
Оказывается, в обработку идёт только полубайт информации, полученной по ИРПС (0...177[oct]). Старший бит обнуляется перед обработкой.
Так что, к примеру байты 060(oct) и 260(oct) обработаются одинаково.
Собственно, это полностью соответствует кодировке КОИ-7 Н2. Она семибитная.

Что ещё не понравилось - всё жёстко привязано к режиму работы и частоте.
Например, при частоте ниже 500 кГц нельзя включить АРЧ. Аттенюатор должен иметь определённое фиксированное ослабление (0...-30 дБ).
Тональный гетеродин можно включить только в режиме А1А.
Команды на изменение его частоты - недостаточны. Нет прямого ввода частоты ТГ, только +/- 10 Гц. А это неудобно. Как перестроиться с одного края на другой? Подав 600 команд? Опухнуть можно :)

Пока что из 241 подпрограммы алгоритмы построены для 79, т.е. 32 % готово.

darkstar
Что ещё не понравилось - всё жёстко привязано к режиму работы и частоте.
Например, при частоте ниже 500 кГц нельзя включить АРЧ. Аттенюатор должен иметь определённое фиксированное ослабление (0...-30 дБ).
Мне это тоже очень не нравится. Режимозависимое ару - больше всего.

Что-то отказывается моя Бригантина запоминать каналы по команде через ИРПС.
darkstar
А как реализован ИРПС в "Бригантине"? Что-то "рассыпное" или специализированная ИС?
В свое время наш коллектив столкнулся с нестабильной работой КР580ВВ51А - то работает нормально, то вылазят какие-то непонятные "косяки". Дошли до того, что звонили в Киев на завод-изготовитель. Дело оказалось в недокументированной особенности данной м/сх. - длительность сигнала "сброс", который формируется при включении питания, должна быть не менее 4 (или 6, за давностью лет не помню) периодов тактовой частоты. Когда увеличили Tсбр., все стало на свои места.

AVIAAMATOR
Интегральная "хрень логическая" на 2080 элементах :) - приёмопередатчик 1002ХЛ1:
http://www.radioscanner.ru/uploader/2014/1002hl1.rar
Вроде как аналог Harris CDP6402 и WesternDigital TR1602.

Вот схема узла ИРПС Бригантины:


Ошибка не в железе, иначе было бы сообщение "ИРПС НЕ ГОТОВ" (это если ошибка стопа - на чётность проверки нет).
Данные успешно принимаются.
В подтверждение этого выдаётся эхо.
На индикаторах Бригантины даже успевает загореться надпись "ЗАПИСЬ В КАНАЛ".
Но потом, когда приходит время выдавать сообщение о успешном выполнении команды и готовности к дальнейшей работе (должно быть <ПС><R><1><ВК>) получаю <ПС><ПС><R><ВК>.
Так что косяк чисто программный. Или аппаратный, но не связанный с блоком ИРПС, т.к. после третей подряд команды на запись в канал, приходит верное сообщение.

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

Я бы попробовал вставить паузы миллисекунд по 500 или более:
- после символа начала сообщения;
- между информационными байтами;
- перед символом конца сообщения.
Если процессор РПУ начнет "соображать", то дальше уменьшать время задержки до приемлемой величины.
Иногда такой метод срабатывает.

Пробовал вводить команды вручную (паузы поболее 1 сек) - не влияет :(

Вспомнил, что у меня уже лежат электрически репрограммируемые ПЗУ-шки XICOR X28C256.
Прошил, поставил - не работает. Почесал тыковку и решил проверить, куда подключены две "лишние" линии адреса (нога 1 и нога 26). Оказалось, первая нога на плюсе, а 26 никуда не подключена.
Подал землю на 1 и 26 (ещё питание перекинул - оно было совмещено с первой ногой) - заработало в местном режиме.
НО!
По ИРПС мои команды практически не идут. Выполняется одна-две команды, затем: то нет эхо сигнала, то отказ линии... Непонятно.
Думаю, у этой беды и незаписи в канал - один корень зла :)
Попробую ещё раз - сначала с родными ПЗУшками, потом, если всё будет ок, то скопирую их в ксикоры и проверю работу.

В запасе есть вторая (типа референсная) плата вычислителя и плата интерфейсов (с ИРПС).

П.С.
Ничего не трогал, попробовал ещё раз - заработало... даже пара каналов записалась... хм...