Я правильно понимаю, что 876 имеет несколько другую «ногозначимость» и что ноги для 876го в схеме программатора надо будет переназначить сравнив datasheets?
Я правильно понял Вашу схему?

Да, правильно, и так можно шить любой ПИК по методу ICSP. Ноги смотреть по даташиту.
……
ПС2: В том же даташите сказанно, что питание +5В требуется выдерживать только для стирания всего ПИК. Для программирования и проверки допускается весь диапазон Всс, предусмотренный рабочим режимом. Мораль: внутрисхемно, 1 раз, его можно прошить и при +3В питания и при +9В. Может кому это пригодится.

Понятненько! А еще вопрос — а как этот простейший программатор делает верификацию записи? Я вижу что ножка RxD ком порта висит в воздухе. Значит-ли это что проверить прошился чип или нет нельзя?

В схеме ошибка — я ноги не проверил СОМ-порта.
DB9 (3) — 10k — PIC (4)
DB9 (4) — 5k —- PIC (13)
DB9 (8) ————PIC (13)
DB9 (5) ————PIC (5)
DB9 (7) —— 5k —-PIC (12)
+5B —————- PIC (14)
для PIC16F84
прошу поправьте, чтобы не путать людей.
Проверку он выполняет всего (память программ, флэш, регистр управления). На видео это видно.

Ну так вроде так и есть в схеме на видео. А в моей схеме нет указания номера ножек чипа — там их обозначения, я вечерком проверю снова по даташиту, т.к. убегаю срочно. Просто я думаю, зачем тут схема PIC16F84, он используется в IOCARDS?

м-дя)))
интересно как выглядят герберы на компе, а не на плате… и почему у меня все-таки ошибка…

я прекрасно прочитал файлы герберов этой программой http://www.softwarec…nload/SETUP.EXE
Она shareware но дает поработать месяц в пробном режиме — но без ограничений в функционале.

Очевидно слова Evgeny_ оказались пророческими. И я стал читать datasheet на чип, потом на буфер 541N, потом скачал себе такую книжку.

Через денек на компе появился MPLAB IDE, с С компилятором. И вот уже скоро была готова моя первая прошивка, которая должна была просто один в один читать данные с порта RC (к которому подключены ноги энкодеров через RC цепочки) и показывать их на порту RB (который подключен к триггерной сборке 74НС541N, которая замыкает нужные контакты мастер-платы). Т.е. моя прошивка показывала на выходе мастерплаты состояние контактов энкодеров со скоростью опроса около 5 Мгц. Я залил прошивку в чип, вставил его в плату, подключился к мастер-плате и обнаружил что мой софт также виснет как и прошивка с Opencockpits. Чтобы окончательно протестировать работоспособность (или неработоспособность, это с какой стороны смотреть) платы, я решил модифицировать ее, повесив на свободный порт RА0 светодиод, которым я смогу мигать по таймеру из моей программы и увидеть, работает-ли чип или виснет.
Я так и сделал, подключив диод, как везде рекомендуется, для зажигания его низким уровнем на ноге чипа (см аттач) и пришел к удивительному наблюдению. Чип повисает при активной работе энкодером. Спасает только reset. Если же энкодером не крутить, то он счастливо промигал светодиодом всю ночь без проблем И тут моих ламерских знаний по электронике уже не хватило… Что дальше делать — ума не приложу. Может у кого есть идеи почему может зависать чип в таком случае?

P.S. Может неспроста на Opencockpits продается плата с другой разводкой, нежели выложена у них в гербер файлах?

А кварц и его обвязку пробовали заменить ?

Пробовал. Даже пробовал ставить 12 Мегагерц

Повесить пару блокировочных конденсаторов по питанию, если их там нет.
К сожалению платы энкодеров у меня нет, так что сравнить не с чем.

Конденсатор стоит один. Но я сильно на него не грешу потому, что если энкодерами не крутить — схема работает идеально — т.е. питание фильтруется нормально.

В принципе схема опубликована, можно перепроверить соответствие.

Я только начинаю разбираться в схемотехнике, но на мой взгляд читать схемы Маноло Велеса так как они нарисованы это занятие не для слабонервных. Посидел с его схемой в Альтиуме — вот что получилось. Я специально отрезал часть, которой присоединяются энкодеры. В общем и целом сама схема обвязки чипа и буфера ИМХО в порядке (см схему, единственное что я добавил — это LED).
Но вот часть которая «типа» фильтрует дребезг привела меня в замешательство. (см схему включения энкодера на которой обозначены порты в сторону чипа)
Я несколько дней провел в поиске инфы о способах подключения энкодеров (механических), борьбы с дребезгом и т.д. В общем сложилось впечатление, что установка RC фильтра НЧ между ногами энкодера обязательна. Но в схеме от Маноло какие-то странные RC цепочки включены. Я даже попытался вспомнить электротехнику и подчитал про RC фильры простейшие, и почти уверен что конденсатор должен быть включен МЕЖДУ ногами энкодера а не между ногой плюсом.
Тем более в даташите на какой-то механический энкодер от ALPS, умные японцы рекомендуют его включать именно так (см рис.)

Если прошивка
и соединение элементов правильны остаётся вероятность некорректного подключения к мастер плате и указания типа энкодеров

С мастерплатой и типами энкодеров все ок. Она же работает — и хорошо работает, пока не начинаем крутить несколькими энкодерами.

мдя..
по нижней схеме , конденсаторы C4 C5 должны на землю..

Причем как писали на sources.ru еще с резистором последовательно включенным конденсатору, чтобы не обгорали контакты энкодера. Как там сказали что в момент разрядки конденсатора на землю через ламели энкодера проходит ток до 5 ампер, если без резистора. Т.е. там как раз рекомендовали схему в точности как у японцев.

Номиналы резисторов — продбираются по алгоритму фильтрации антидребезга..Хотя ХЗ что там намутили буржуи в прошивках, ну уж точно не 3-х фазный алгоритм распознавания вращения энкодра , если один энкодре забивает другой…

Я пробовал разобрать их код. Но он дизассемблирован, а мне тяжело читать ассемблер. Хотя там кода всего ничего. Что интересно, алгоритм работает нормально. Я думаю из-за дебильной схемы включения «фильтров» для энкодера там летают некислые скачки напряжения, которые через цепь питания и заставляют срабатывать соседей. Но я думаю, что никакого 3-х фазного алгоритма распознавания там нет. Обычный думаю — если один изменился — смотрим соседнюю фазу и по ней определяем куда крутанулись. Но с альпсовскими энкодерами работает хорошо до того времени, пока подключен только один энкодер

P.S. Кстати всем большое спасибо что помогаете. А то по книжкам с нуля тяжеловато самому

У нас так называемый трех фазовый алгоритм обнаружения вращения энкодрера … Примерный принцип такой — полный щелчек энкодера — это целых 4 состояния его контактов… каждое состояние нужно смотреть в интервале времени фильтра антидребезга… — если что не по алгоритму изменения состояний его ног (после определения направления вращения) — то щелчек не считается.
У нас так… причем одним контроллером — 15 энкодеров и можно круить хоть все сразу…

Классая железка, мне бы такую, если бы работала с протоколом SIOCа.
На самом деле понятно, что наиболее надежный способ — это ловить все 4 цикла грея за щелчок, фильтруя дребезг.
Если возвращаться к OPENCOCKPITS, то мастерплата именно потому не поддерживает энкодеры с полным циклом грея, что у нее тупо не хватает быстродействия. Т.е. скорость опроса мастерплаты меньше чем скорость замыкания контактов эенкодера.
Например, при вращении энкодера например из 20 кликов на оборот, пиковая скорость вращения пусть будет ну 5 оборотов в секунду. Нехоитрый расчет дает время между замыканием-размыканием контактов обычного энкодера — около 2.5 милисекунд. Это не учитывая то, что есть еще дребезг энкодера. Причем в даташите на дешевый механический ALPS написано, но время затухания дребезга равно 2 милисекунды на новом, и до 5 милисекунд на раздолбаном энкодере.
Что касается с энкодером с 1/4 цикла на клик, то там все эти временные параметры в 4 раза больше, что позволяет мастерплате работать с ним напрямую успевая делать обработку энкодера программно в SIOC.
У меня на сегодня есть мысль модифицировать плату энкодера, применив более умный алгоритм их опроса и фильтруя дребезг. А на выход мастерплаты выдавать модифицированный сигнал с временной постоянной не более скажем 10 милисекунд. При супербыстром вращении мастерплата будет «догонять» энкодер, но не думаю что это будет заметно на глаз.

А вообще симптомы очень напоминают неправильное соединение пар выходов с платы энкодеров к парам входов мастер карты

Не совсем понимаю отчего такие предположения. Ведь если перепутать контакты энкодера, то переменная будет вращаться только в одну сторону. У меня все замечательно вращается в обе стороны.
Что касается выводов мастерплата — плата энкодеров, там все просто. У энкодеров последовательно попарно идут контаты и последним идет земля для группы контактов мастерплаты.
Контакты мастерплаты в одной группе тоже перепутать сложно:

Подсоединяемся к входам:
Плата энкодер — Мастерплата
1 — 1
2 — 2
3 — 4
4 — 3
5 — 9
6 — 8
7 — 6
8 — 5
9 — 10

Логический вход 0 (контакт 7 мастерплаты) остается свободным в группе.

Я Вас уверяю — подсоединено все верно. Сто процентов у нас разводка платы какая-то левая. Если сегодня будет время отрежу все входы от портов ввода и присоединю энкодеры навесным монтажем через R/C НЧ фильтр. Я УВЕРЕН просто что все заработает.

P.S. Opencockpits — отличный пример как НЕ НАДО делать сайты и КАК НЕ НАДО писать документацию. Но главное преимущество неоспоримо — все фришное! На этом и живут. Ну и сиок влассная штука. Сам подход к event-triggered программированию наиболее выйгрышный в кокпитостроении ИМХО.

Увы.. потребности кокпит строителей перед необходимостью влазить в процесс симулятора для добычи нестандартных переменных требует более сложного и более низкоуровнего программирования роутера…. На это спосорбны только обычные среды программирования работающие с API винды…когда SIOC сможет раболтать с DirctInput и другими API , то тогда — да…
другими словами — не хотелось бы развиваь эту тему..сейчас..

[OFFTOPIC]
Согласен, тема провокационная
Все что я дальше напишу, есть мое сугубо личное мнение.
мой постулат: Сим никогда не может быть ядром кокпита. Сим — это визуализация и окружающий мир и все. Возможно еще и динамика самолета.
Поэтому MSFS стал неинтересен — я выбрал для себя Xplane (вот доделают к нему трафик, у MSFS вообще не останется ни одного преимущества).
Я сейчас работаю над комплексом авионики B737 классики, с помощью одного капитана из Люфтов. Если поподробнее присмотреться, то настоящий самолет связан в миром, т.е. с физической средой путем динамики — раз, и всего НЕСКОЛЬКИХ датчиков (приемники давления, гироскопы, датчики угла атаки, инерционные датчики, и радиоантенны — ВСЕ!). Т.е. комплекс авионики живет своей жизнью взаимодействуя со средой и даже с самим самолетом весьма условно. Гораздо проще, чем это кажется на первый взгляд. т.е. есть комплекс авионики, есть самолет (его динамика) и есть некая двусторонняя связь между ними. Так вот SIOC, это считайте сервер, который передает информацию от одного блока к другому. Каждый модуль (сим, мой модуль авионики, аппаратный комплекс из приборов и органов управления) может что-то брать из SIOCа, если ему нужно, и может класть в SIOC, если ему нужно. Все просто. Небольшая модель того, что уже работает прекрасно себя зарекомендовала! Причем ввиду того, что протокол поверх IP, она автоматом является серверно-распределенной. Поэтому в таком комплексе даже замена сима (а многие впадают в истерику при этой мысли) ничем не грозит, подправим список нужных переменных и вперед.
Еще один момент почему я выбрал именно такой концепт. Не одна модель для сима никогда на 100% не подойдет для кокпита. Т.к. все такие модели орентированы на пользователя с джойстиком, мышкой и монитором. И моделировать какие-то там переменные динамические нагрузки на штурвальной колонке никто не будет. и очень много систем которые никто не реализовывает. Поэтому на мой взгляд «кокпит-аддоны» должны разрабатываться отдельно. И совсем не обязательно встраивать их в сим. Березкам около аэродрома в реальной жизни нет дела до гироскопа в HSI (хороший пример такого концепта — Project Magenta, но она для NG, а я хочу классику).
На практике скорость и простота работы с SIOCом меня очень приятно порадовала. В прокте Sly-я для Ту 154 надо влезть в память? Не проблема — написали IOCP клиента, который лазит переменные достает и синхронизирует с SIOC сервером по его протоколу.
В моем проекте нужно иметь переменные для эмуляции трубок пито и приемников давления? IOCP клиент для Xplane предоставил все нужные переменные со скоростью доступа 10мс.
Вот если бы ваши модули могли при помощи вашего же драйвера просто менять переменные и синхронизироваться с SIOC сервером, то мне бы они пригодились. Все-таки IOCARDS громоздок в плане железа и тоже недешев. А вот софт SIOCа — для меня находка.
[/OFFTOPIC]
Но это был оффтопик, а я пока пошел разбираться с энкодерами