Странно это. Программа должна выводить все данные пока не встретит команду. Я считал, что пока идут данные с ленты команд нет, а как возникнет команда, то это уже хвост. Последующий после ввода информации обмен завершения передачи. По крайней мере у меня после строк данных программа выводила хвост - такой же как в начале. Его я у Вас не вижу. Попробуйте просто потыкать во вторую ногу СД землёй. На мониторе должна вывалиться голова, потом строчки. Когда строчек наберётся штук 5-6 закоротите на землю вывод 5. Дальнейшее тыкание землёй в ногу 2 приведёт к показу хвостаи останову программы. Это же я ожидал увидеть на натуре.
Когда лента остановится. Но если программа останавливается до окончания ленты , то коротить бесполезно. Что то пошло не так.
Было бы хорошо найти в документации что означают команды.
А какая у Вас самая короткая лента? Нет ли у Вас платы блюпил на stm32f103c8 или какой либо другой? Нужно запомнить всю ленту. В уне только 2к памяти. Этого мало на Ваши ленты.
Тут два варианта. Или найти в документации команды обмена информацией между ЦВМ и магнитофоном или снять весь протокол обмена по всем линиям от начала до конца. Уной снять протокол не получится из за малого объёма памяти. Нужен или логический анализатор - ссылку я давал #189 или плату с большим объёмом памяти, лучше всего блакпилл на stm32f411.
Замерьте напряжения на линиях НГП и НПД перед нажатием кнопки пуск.
Не очень понял какие данные вы пытались получить, но вполне можно использовать вывод через UART притормаживая обмен по шине сигналом НПД.
За миллисекунду между магнитофоном и ЦВМ перед стартом считывания пробежало более 50 байт. Как команд, так и данных. Мы выводим строку почти 2 мс. Тормозить обмен конечно можно попробовать. Но мне хотелось, что бы считав головные команды в режиме накопления данных, программа считала ленту полностью и при первой команде после окончания ленты перешла в режим быстрого набора данных, чтобы посмотреть чем обмениваются магнитофон и ЦВМ после окончания ленты. Согласно второй осциллограмме #19 в конце тоже идёт интенсивный обмен за 1 мс. Кроме того обмен командами идёт при перемотке ленты, про это есть упоминание в #19, но осциллограммы нет и данных тоже нет. А этот режим, как я понимаю то же может понадобиться, что бы ЦВМ знала что магнитофон готов к обмену.
И всё же я не понимаю, почему последняя программа не дочитывает данные ленты до конца. В программе за это отвечает второй кейс и он эквивалентен приему в предыдущих программах. Остановиться он может только после приёма команды - обнуления линии УПР.
Ну и продолжая разговор. Программа пытается задержать обмен через НГП. Мне показалось, что так правильнее. Подключить надо землю, восемь линий данных, СД, УПР и НГП. Неплохо бы было отработать весь цикл - от перемотки до конца ленты.
НПД был подключен? Я просил в #214 землю, восемь линий данных(D6-D13), СД(D2), УПР(D5) и НГП(D3). НПД(D4) подключать не надо. В любом случае начало получилось совсем не как в #205 и #198. Кроме того не видно когда стартанула лента. Было бы не плохо сравнить дырки на ленте, хотя бы вначале ленты, с полученными данными, что бы увидеть есть пропуски полученных данных или нет. Желательно использовать ту же ленту что раньше в #107 и далее, что бы можно было сравнивать. Сейчас есть вопрос - откуда берётся отрицательное время? Программа приложена та же, но с защитой контроля времени.
После подключения платы не должно быть ошибки. Как и после окончания ввода. С этим надо разбираться. С помощью осциллографа. Смотреть, какие сигналы изменились при подключении платы и возникновении ошибки.
В #91 в документации написано, что НГП НДП СД пассивные абоненты не должны выдавать, а считыватель пассивный, это значит, что мы не можем тормозить время этими командами, поэтому возникают ошибки при их использовании. Надо вернуться к программе из #192 но модифицировать её на предмет более короткой записи и запустить без магнитофона с управлением по линиям НГП НДП. Смоделировать полностью магнитофон. Именно для этого нужен логический анализатор. Подключив его к линиям НГП НДП СД УПР КиП и нескольким данных можно понять как происходит общение. Получить времена и соотнести их с тем, что получаем в программе. Подождем понедельника.
Отлично получилось. Всё видно. Увидел главное - УНА не успевает даже в самой быстрой программе отследить весь протокол обмена. Если сравнить голову и запись программы #205 то видно, что есть данные через 11 мкс, которых не видит УНА.
Есть сигнал КнП, который выступает в двух ипостасях - из документации:
1.3.16. Сообщения на линию КпП V ЕД выдам источники или контроллер. Источник выдает на линию сообщение КнП одновременно о выдачей последнего байта данных, свидетельствуя таким образом о заваершени цикла передачи.
Выдача сообщения КнП контроллерам одновременно о сообщением УПР интерпретируется как команда идентификации (ИД) ■ которая вызывает выдачу абонентами ШиД сообщений, 0ТВЕТ НА ПАРАЛЛЕЛЬНЫЙ ОПРОС СОЛО), определяющих являются ли они источником запроса обслуживания.
==============
Т.Е. начинать надо с ожидания сигнала УПР, по его приходу опустить НПД и до сигнала КнП одновременно с УПР надо только моргать НГП и НПД правильно и следить за КнП - тоже в прерывании, потому что он не связан с СД. Встретив КнП одновременно с УПР надо что то ответить ЦВМ какими то из этих байт из#205
50 164 c 45
51 24 d 40
52 24 c FD
53 32 c 43
И начинать передачу данных.
Хвост тоже есть. Там тоже есть КнП, вот кто выдаёт надо разбираться.
Заключение моё такое - на УНЕ сделать замену магнитофону будет сложно. Я бы смотрел в сторону блакпила или самой простой милинки.
Отключите магнитофон совсем и снимите ещё раз. Нужно точно знать какие сигналы гонит ЦВМ до ошибки. Меня напрягает 83 наносекунды между УПР и первым провалом НПД.
Значит буду мониторить где купить, из Китая это не вариант в настоящее время из-за коронавируса. Может надо второй шлейф посмотреть тоже, который идёт от магнитофона к пульту.
Мне из Китая непрерывно идут посылки. Последний рекорд - 4 дня и посылка у нас на таможне. Никаких проблем с короновирусом. Они его победили. А у нас почта работает.
Но это пока без магнитофона не сняли - не актуально. Вдруг не всё так плохо.
Да тот шлейф тоже надо снять сигналы. И почему то я не нашёл сигналы данных. Они были не подключены? Попробуйте ещё снять не Д6 Д7 а Д0 Д1
Картинка понятна. На запрос ЦВМ сразу отвечает магнитофон. Я б даже сказал долбит подтверждением, пока ЦВМ дважды не повторяет запрос. Потом они договариваются и начинается передача данных. Следить надо за сигналами УПР КиП СД и на них реагировать. К сожалению реагировать не одинаково, а в зависимости от ситуации. Что дополнительно добавляет сложностей и с количеством необходимых прерываний и банально ног процессора. УНА не справиться. У блакпила не хватит мощности дергать шину. Надо будет делать адаптер на транзисторах. По одному транзистору типа кт315 или кт3102 на каждую линию. Сейчас есть все данные, чтобы реализовать замену. Если бы было описание протокола обмена, то проблем не было бы вообще. А так надо много телодвижений, что бы протокол восстановить. Делать это удалённо можно, но займёт очень много времени. Идеально было бы найти Вам человека, который мог приехать к Вам и поработать несколько дней.
Рядом я точно никого не найду. С Вами и Imp (правда куда-то пропал, может решил, что я проигнорировал его последний скейтч, да нет, выбило: ошибку и FD 00, прошу прощения не отписался) уже два месяца работаем, бросать тоже жалко.
Тогда ищите блакпилл и программатор к нему ST-Link - в китае обойдётся всё рублей 600, но надо как минимум по паре, а то горят при не правильном втыкании в комп или купите за 2000 руб Nucleo на stm32F411re https://www.chipdip.ru/product/nucleo-f411re-2 . У ней и программатор правильный на борту есть, и в ардуно иде программировать можно.
Никуда я не исчез, просто не совсем понимаю идею которую вы пытаетесь реализовать. На сколько я понял, вы пытались абсолютно точно воспроизвести все временные характеристики протокола. ИМХО, в ситуации когда протокол предназначен для общения с электромеханическим устройством, точное (и даже более-менее примерное) соблюдение таймингов в принципе не возможно. И протокол должен это учитывать. При этом, при реализации для конкретного случая, понимание протокола в принципе не нужно (не, ну конечно хотелось бы, но можно обойтись). В простейшем подходе нужно с имитировать правильные (т.е. взятые из дампа общения реальных устройств) ответы, и передать так, что бы было более-менее похоже на настоящий обмен.
Судя по описанию, обмен состоит из трех частей. Первая - когда ЦВМ указывает настройки чтения, вторая когда идет сплошной поток байт данных из ридера в ЦВМ. И третий когда ЦВМ завершает прием, отменяя настройки. Сложность в том что-бы сымитировать ответы ридера во время настройки и завершения. Сама передача данных тупая и к таймаутам не критичная (электромеханика другого не подразумевает).
По этому мое мнение - для начала нужно получить дамп первых 20 байт обмена, выделить из них ответы и попробовать их подсовывать привязав по номеру в дампе. Так как есть логический анализатор можно действовать "тупо в лоб". Отключаем ридер, подключаем анализатор, запускаем чтение - получаем ошибку. Смотрим какой байт был последним (по позиции), пишем скетч отчитывающий нужное количество переданных байт (по импульсу синхронизации) и подставляем на "пустое" место байт из дампа. Так последовательно получим скетч имитации начала передачи. Дальше тупая передача строки байт (самая короткая лента, забитая в прошивку), и так же подбираем завершение.
В результате получаем данные для написания начала и конца обмена.
Это уже частично сделано. Получены байты которыми обмениваются ЦВМ и магнитофон перед началом обмена данными. Задача не временное соответствие, а логическое. Например на снятие линии УПР магнитофон реагирует установкой НГП и без магнитофона ошибка возникает сразу здесь. С магнитофоном после снятия УПР магнитофон долбит байт 01 до тех пор, пока не появится снова УПР . Причём это может быть 5- 6 раз. Это повторяется ещё 2 раза, но с вариациями на ответ. Тут пробегает сигнал КнП 2 раза без УПР и при третьем повторе обмена КнП приходит очень короткий в момент активного УПР , после чего идёт обмен тремя байтами - кто их посылает надо разобраться, и собственно начинается пересылка байт ленты. Что происходит в конце пока не понятно. Через какое-то время после окончания ленты дергается УПР и КнП и несколько байт обмена.
Таким образом получается что надо следить за СД - по нему идёт обмен данными, следить за УПР и реагировать на его изменения, следить за КнП и менять протокол обмена и режим работы в зависимости от того пришёл КнП с УПР или без. При этом СД никак не связан с УПР и КнП и получать информацию о изменении УПР и КнП надо в отдельных прерываниях. И надо разделить ноги входа-выхода, что бы разделить реакцию на пришедшие байты.
Вот рисунок на котором наложены сигналы линий с магнитофоном и без (более блёклые линии). К сожалению последовательность каналов разная и приходится глазами бегать по разным строкам. 61732 в будущем старайтесь каналы логанализатора использовать в одной и той же последовательности? Видно, что на первое снятие УПР магнитофон реагирует активным НГП (красная стрелка 1) при этом без магнитофона ЦВМ ждет всего 25 мкс (!!!) и снова выставляет УПР (красная стрелка 2), после чего идет ОШИБКА. У нас всего 25 микросекунд, что бы отреагировать на первое снятие УПР. Магнитофон реагирует через 2 мкс и ещё перед этим выставляет СД. Затем начинает долбить байтом 01 - зелёная стрелка.
61732! Можете разобрать байты хвоста? В Вашем файле 24 MHz, 1 B Samples [5].logicdata есть данные - 8 линий данных. Их надо превратить в НЕХ. Если файл открыть в программе Saleae Logic то видно импульсы головы, пробел, тело данных, пробел хвост. Первый байт хвоста 0х34 начинается через 0.37 секунды от тела данных, второй 0х20 через 0.255 мс далее 0х34, 0х20, 0хfd, 0xfb.... и из файла 24 MHz,1 B Samples [1].logicdata восстановить сигналы УПР и КнП к данным хвоста.
Поправил скетч для загрузки байтов предшествующих обмену. Он принимает в буфер 32 байта, выводи их в консоль, и зависает. Нужно проверить, что ранее снятые дампы приняты правильно.
/***********************************************************
Подключение:
ЛД0 - 8
ЛД1 - 9
ЛД2 - 10
ЛД3 - 11
ЛД4 - 12
ЛД5 - 13
ЛД6 - 6
ЛД7 - 7
СД - 2
***********************************************************/
const int PIN_CLOCK = 2; // Пин синхроимпульсов.
const int INT_CLOCK = 0; // Номер прерывания синхроимпульсов.
const int DOP_6 = 6; // Пин шестого разряда данных.
const int DOP_7 = 7; // Пин седьмого разряда данных.
const unsigned char MASK = 0b11000000; // Маска для формирования байта.
const int maxCount = 0x20;
unsigned char bufferTable[maxCount];
int count = 0;
void setup()
{
attachInterrupt(INT_CLOCK, input_char, FALLING);
pinMode(DOP_6, INPUT);
pinMode(DOP_7, INPUT);
DDRB = MASK;
pinMode(2, INPUT_PULLUP);
Serial.begin(57600);
Serial.println("\n\nStart test:");
}
void input_char ()
{
unsigned char ch;
if(maxCount > count) {
ch = ~((PINB & ~MASK) | (PIND & MASK));
bufferTable[count++] = ch;
}
}
void loop()
{
int i,j;
unsigned char n;
if(maxCount == count)
{
for (i = 0; i < maxCount/0x10; i++) {
Serial.println();
for(j = 0; j < 16; j++) {
n = bufferTable[i * 0x10 + j];
if (n < 0x10) {
Serial.write('0');
}
Serial.print(n, HEX);
Serial.write(' ');
}
}
while (true);
}
}
Поправил скетч для загрузки байтов предшествующих обмену. Он принимает в буфер 32 байта, выводи их в консоль, и зависает. Нужно проверить, что ранее снятые дампы приняты правильно.
Посмотрите снятые логером данные #233. Там есть все данные. Все байты и управляющие сигналы до обмена и после . Время ответа магнитофона 1.125 мкс. . Отвечает не только на данные, а на снятие сигнала УПР после байта 0xFB. Причём 3 раза в подряд. Третий раз после КнП. Затем после ещё обмена выдается КнП вместе с УПР, после чего 2 байта 0хFD 0x43 и собственно далее идёт поток данных.
Странно это. Программа должна выводить все данные пока не встретит команду. Я считал, что пока идут данные с ленты команд нет, а как возникнет команда, то это уже хвост. Последующий после ввода информации обмен завершения передачи. По крайней мере у меня после строк данных программа выводила хвост - такой же как в начале. Его я у Вас не вижу. Попробуйте просто потыкать во вторую ногу СД землёй. На мониторе должна вывалиться голова, потом строчки. Когда строчек наберётся штук 5-6 закоротите на землю вывод 5. Дальнейшее тыкание землёй в ногу 2 приведёт к показу хвостаи останову программы. Это же я ожидал увидеть на натуре.
На Сд коротить во время загрузки с ленты или когда загрузка остановиться?
Когда лента остановится. Но если программа останавливается до окончания ленты , то коротить бесполезно. Что то пошло не так.
Было бы хорошо найти в документации что означают команды.
Программа не запускается во время пуска и в дальнейшем во время загрузки ленты с магнитофона. Попробую ещё.
1 раз
2 раз
3 раз
Руками помогли программе закончиться или сама?
Коротил на СД
А какая у Вас самая короткая лента? Нет ли у Вас платы блюпил на stm32f103c8 или какой либо другой? Нужно запомнить всю ленту. В уне только 2к памяти. Этого мало на Ваши ленты.
Это самая короткая лента. Платы никакой нет. Но если без неё никак буду мониторить да покупать.
Тут два варианта. Или найти в документации команды обмена информацией между ЦВМ и магнитофоном или снять весь протокол обмена по всем линиям от начала до конца. Уной снять протокол не получится из за малого объёма памяти. Нужен или логический анализатор - ссылку я давал #189 или плату с большим объёмом памяти, лучше всего блакпилл на stm32f411.
Замерьте напряжения на линиях НГП и НПД перед нажатием кнопки пуск.
Не очень понял какие данные вы пытались получить, но вполне можно использовать вывод через UART притормаживая обмен по шине сигналом НПД.
На НГП 3.3 В, а НПД ничего.
За миллисекунду между магнитофоном и ЦВМ перед стартом считывания пробежало более 50 байт. Как команд, так и данных. Мы выводим строку почти 2 мс. Тормозить обмен конечно можно попробовать. Но мне хотелось, что бы считав головные команды в режиме накопления данных, программа считала ленту полностью и при первой команде после окончания ленты перешла в режим быстрого набора данных, чтобы посмотреть чем обмениваются магнитофон и ЦВМ после окончания ленты. Согласно второй осциллограмме #19 в конце тоже идёт интенсивный обмен за 1 мс. Кроме того обмен командами идёт при перемотке ленты, про это есть упоминание в #19, но осциллограммы нет и данных тоже нет. А этот режим, как я понимаю то же может понадобиться, что бы ЦВМ знала что магнитофон готов к обмену.
И всё же я не понимаю, почему последняя программа не дочитывает данные ленты до конца. В программе за это отвечает второй кейс и он эквивалентен приему в предыдущих программах. Остановиться он может только после приёма команды - обнуления линии УПР.
Ну и продолжая разговор. Программа пытается задержать обмен через НГП. Мне показалось, что так правильнее. Подключить надо землю, восемь линий данных, СД, УПР и НГП. Неплохо бы было отработать весь цикл - от перемотки до конца ленты.
/*********************************************************** Подключение: СД - 2 НПД - 3 НГП - 4 УПР - 5 ЛД0 - 7 ЛД1 - 6 ЛД2 - 13 ЛД3 - 12 ЛД4 - 11 ЛД5 - 10 ЛД6 - 9 ЛД7 - 8 ***********************************************************/ const int PIN_CD = 2; // Пин Данные действительны. const int INT_NUM = 0; // Номер прерывания синхроимпульсов. const int NPD = 4; // Пин НПД. const int NGP = 3; // Пин НГП const int UPR = 5; // Пин для сигнала УПР. const unsigned char MASK = 0b11000000; // Маска для формирования байта. volatile bool flDat = false; volatile unsigned char Ch, cb ; volatile uint32_t tm, tmo, dt; char buf[32]; void setup() { PORTB = 0; PORTD = 0; DDRD = 0x0; DDRB = 0x0; EIFR = bit (INTF0); attachInterrupt(INT_NUM, input_char, FALLING); flDat = false; tmo = 0; Serial.begin(115200); Serial.println("Start test:"); } void input_char () { tm = micros(); flDat = true; bitSet(DDRD, NGP); bitSet(DDRD, NPD); Ch = ~((PINB & ~MASK) | (PIND & MASK)); cb = (PIND & 0x20); bitClear(DDRD, NPD); } void loop() { if (flDat) { dt = tm - tmo; sprintf(buf, "%10ld %c %X", dt, ((cb != 0 ) ? 'd' : 'c' ), Ch); Serial.println(buf); tmo=tm; flDat = false; bitClear(DDRD, NGP); }; }Завтра попробуем. Логический анализатор заказал, но будет не раньше чем через неделю.
При включении начать загрузку программы загорается неисправность, магнитофон не срабатывает.
Все загрузка прошла, но после загрузки загорелась неисправность.
Очень много строк, не хочет сюда копировать.
Только так
https://cloud.mail.ru/public/aZcu/p8hdQcmM1
НПД был подключен? Я просил в #214 землю, восемь линий данных(D6-D13), СД(D2), УПР(D5) и НГП(D3). НПД(D4) подключать не надо. В любом случае начало получилось совсем не как в #205 и #198. Кроме того не видно когда стартанула лента. Было бы не плохо сравнить дырки на ленте, хотя бы вначале ленты, с полученными данными, что бы увидеть есть пропуски полученных данных или нет. Желательно использовать ту же ленту что раньше в #107 и далее, что бы можно было сравнивать. Сейчас есть вопрос - откуда берётся отрицательное время? Программа приложена та же, но с защитой контроля времени.
После подключения платы не должно быть ошибки. Как и после окончания ввода. С этим надо разбираться. С помощью осциллографа. Смотреть, какие сигналы изменились при подключении платы и возникновении ошибки.
/*********************************************************** Подключение: СД - 2 НПД - 3 НГП - 4 УПР - 5 ЛД0 - 7 ЛД1 - 6 ЛД2 - 13 ЛД3 - 12 ЛД4 - 11 ЛД5 - 10 ЛД6 - 9 ЛД7 - 8 ***********************************************************/ #include <util/atomic.h> const int PIN_CD = 2; // Пин Данные действительны. const int INT_NUM = 0; // Номер прерывания синхроимпульсов. const int NPD = 4; // Пин НПД. const int NGP = 3; // Пин НГП const int UPR = 5; // Пин для сигнала УПР. const unsigned char MASK = 0b11000000; // Маска для формирования байта. volatile bool flDat = false; volatile unsigned char Ch, cb ; volatile uint32_t tm, tmo; int32_t dt; char buf[32]; void setup() { PORTB = 0; PORTD = 0; DDRD = 0x0; DDRB = 0x0; EIFR = bit (INTF0); attachInterrupt(INT_NUM, input_char, FALLING); flDat = false; tmo = 0; Serial.begin(115200); Serial.println("Start test:"); } void input_char () { tm = micros(); flDat = true; bitSet(DDRD, NGP); bitSet(DDRD, NPD); Ch = ~((PINB & ~MASK) | (PIND & MASK)); cb = (PIND & 0x20); bitClear(DDRD, NPD); } void loop() { if (flDat) { ATOMIC_BLOCK(ATOMIC_FORCEON) { dt = tm - tmo; tmo = tm; }; sprintf(buf, "%10ld %c %X", dt, ((cb != 0 ) ? 'd' : 'c' ), Ch); Serial.println(buf); flDat = false; bitClear(DDRD, NGP); }; }Прошу прощения, НПД подключал, не внимательно прочитал. Завтра переделаю. Логический анализатор обещали в понедельник доставить.
https://cloud.mail.ru/public/qAkE/XFRsM33e4
Притормозить не получилось. Получилась полная хрень. Особенно время напрягает. Где то что то не так.
С первой попытки магнитофон не срабатывал загоралось неисправность, только с третьего раза. На все влияет НГП.
В #91 в документации написано, что НГП НДП СД пассивные абоненты не должны выдавать, а считыватель пассивный, это значит, что мы не можем тормозить время этими командами, поэтому возникают ошибки при их использовании. Надо вернуться к программе из #192 но модифицировать её на предмет более короткой записи и запустить без магнитофона с управлением по линиям НГП НДП. Смоделировать полностью магнитофон. Именно для этого нужен логический анализатор. Подключив его к линиям НГП НДП СД УПР КиП и нескольким данных можно понять как происходит общение. Получить времена и соотнести их с тем, что получаем в программе. Подождем понедельника.
Спасибо. Ждём понедельника.
Вот что получилось.
https://cloud.mail.ru/public/7QZf/e9Ro1vCs3
Отлично получилось. Всё видно. Увидел главное - УНА не успевает даже в самой быстрой программе отследить весь протокол обмена. Если сравнить голову и запись программы #205 то видно, что есть данные через 11 мкс, которых не видит УНА.
Есть сигнал КнП, который выступает в двух ипостасях - из документации:
1.3.16. Сообщения на линию КпП V ЕД выдам источники или контроллер. Источник выдает на линию сообщение КнП одновременно о выдачей последнего байта данных, свидетельствуя таким образом о заваершени цикла передачи.
Отключите магнитофон совсем и снимите ещё раз. Нужно точно знать какие сигналы гонит ЦВМ до ошибки. Меня напрягает 83 наносекунды между УПР и первым провалом НПД.
Значит буду мониторить где купить, из Китая это не вариант в настоящее время из-за коронавируса. Может надо второй шлейф посмотреть тоже, который идёт от магнитофона к пульту.
Мне из Китая непрерывно идут посылки. Последний рекорд - 4 дня и посылка у нас на таможне. Никаких проблем с короновирусом. Они его победили. А у нас почта работает.
Но это пока без магнитофона не сняли - не актуально. Вдруг не всё так плохо.
Да тот шлейф тоже надо снять сигналы. И почему то я не нашёл сигналы данных. Они были не подключены? Попробуйте ещё снять не Д6 Д7 а Д0 Д1
Не понял: не Д6 Д7 а Д0 Д1 - это что?
Сигналы данных не подключал, потому что логический анализатор 8 пиновый.
Есть 2 свободных пина. 6 и 7. К ним можно подключить линии данных. Например 0 и 1.
ЗО не используется. Можно не подключать. Ещё один канал для данных. Нужны ЛД7 ЛД6 ЛД4
От СЦВМ до магнитофона:
https://cloud.mail.ru/public/tDxk/r6xT2oBiE
https://cloud.mail.ru/public/LpXC/MvisX26aY
Без магнитофона:
https://cloud.mail.ru/public/T4Pr/nmSvbYNi7
От магнитофона до пульта второй шлейф:
https://cloud.mail.ru/public/td7e/CBSRh37fe
https://cloud.mail.ru/public/HxS6/bge5RUSk2
Картинка понятна. На запрос ЦВМ сразу отвечает магнитофон. Я б даже сказал долбит подтверждением, пока ЦВМ дважды не повторяет запрос. Потом они договариваются и начинается передача данных. Следить надо за сигналами УПР КиП СД и на них реагировать. К сожалению реагировать не одинаково, а в зависимости от ситуации. Что дополнительно добавляет сложностей и с количеством необходимых прерываний и банально ног процессора. УНА не справиться. У блакпила не хватит мощности дергать шину. Надо будет делать адаптер на транзисторах. По одному транзистору типа кт315 или кт3102 на каждую линию. Сейчас есть все данные, чтобы реализовать замену. Если бы было описание протокола обмена, то проблем не было бы вообще. А так надо много телодвижений, что бы протокол восстановить. Делать это удалённо можно, но займёт очень много времени. Идеально было бы найти Вам человека, который мог приехать к Вам и поработать несколько дней.
Рядом я точно никого не найду. С Вами и Imp (правда куда-то пропал, может решил, что я проигнорировал его последний скейтч, да нет, выбило: ошибку и FD 00, прошу прощения не отписался) уже два месяца работаем, бросать тоже жалко.
Тогда ищите блакпилл и программатор к нему ST-Link - в китае обойдётся всё рублей 600, но надо как минимум по паре, а то горят при не правильном втыкании в комп или купите за 2000 руб Nucleo на stm32F411re https://www.chipdip.ru/product/nucleo-f411re-2 . У ней и программатор правильный на борту есть, и в ардуно иде программировать можно.
Никуда я не исчез, просто не совсем понимаю идею которую вы пытаетесь реализовать. На сколько я понял, вы пытались абсолютно точно воспроизвести все временные характеристики протокола. ИМХО, в ситуации когда протокол предназначен для общения с электромеханическим устройством, точное (и даже более-менее примерное) соблюдение таймингов в принципе не возможно. И протокол должен это учитывать. При этом, при реализации для конкретного случая, понимание протокола в принципе не нужно (не, ну конечно хотелось бы, но можно обойтись). В простейшем подходе нужно с имитировать правильные (т.е. взятые из дампа общения реальных устройств) ответы, и передать так, что бы было более-менее похоже на настоящий обмен.
Судя по описанию, обмен состоит из трех частей. Первая - когда ЦВМ указывает настройки чтения, вторая когда идет сплошной поток байт данных из ридера в ЦВМ. И третий когда ЦВМ завершает прием, отменяя настройки. Сложность в том что-бы сымитировать ответы ридера во время настройки и завершения. Сама передача данных тупая и к таймаутам не критичная (электромеханика другого не подразумевает).
По этому мое мнение - для начала нужно получить дамп первых 20 байт обмена, выделить из них ответы и попробовать их подсовывать привязав по номеру в дампе. Так как есть логический анализатор можно действовать "тупо в лоб". Отключаем ридер, подключаем анализатор, запускаем чтение - получаем ошибку. Смотрим какой байт был последним (по позиции), пишем скетч отчитывающий нужное количество переданных байт (по импульсу синхронизации) и подставляем на "пустое" место байт из дампа. Так последовательно получим скетч имитации начала передачи. Дальше тупая передача строки байт (самая короткая лента, забитая в прошивку), и так же подбираем завершение.
В результате получаем данные для написания начала и конца обмена.
Это уже частично сделано. Получены байты которыми обмениваются ЦВМ и магнитофон перед началом обмена данными. Задача не временное соответствие, а логическое. Например на снятие линии УПР магнитофон реагирует установкой НГП и без магнитофона ошибка возникает сразу здесь. С магнитофоном после снятия УПР магнитофон долбит байт 01 до тех пор, пока не появится снова УПР . Причём это может быть 5- 6 раз. Это повторяется ещё 2 раза, но с вариациями на ответ. Тут пробегает сигнал КнП 2 раза без УПР и при третьем повторе обмена КнП приходит очень короткий в момент активного УПР , после чего идёт обмен тремя байтами - кто их посылает надо разобраться, и собственно начинается пересылка байт ленты. Что происходит в конце пока не понятно. Через какое-то время после окончания ленты дергается УПР и КнП и несколько байт обмена.
Таким образом получается что надо следить за СД - по нему идёт обмен данными, следить за УПР и реагировать на его изменения, следить за КнП и менять протокол обмена и режим работы в зависимости от того пришёл КнП с УПР или без. При этом СД никак не связан с УПР и КнП и получать информацию о изменении УПР и КнП надо в отдельных прерываниях. И надо разделить ноги входа-выхода, что бы разделить реакцию на пришедшие байты.
Вот рисунок на котором наложены сигналы линий с магнитофоном и без (более блёклые линии). К сожалению последовательность каналов разная и приходится глазами бегать по разным строкам. 61732 в будущем старайтесь каналы логанализатора использовать в одной и той же последовательности? Видно, что на первое снятие УПР магнитофон реагирует активным НГП (красная стрелка 1) при этом без магнитофона ЦВМ ждет всего 25 мкс (!!!) и снова выставляет УПР (красная стрелка 2), после чего идет ОШИБКА. У нас всего 25 микросекунд, что бы отреагировать на первое снятие УПР. Магнитофон реагирует через 2 мкс и ещё перед этим выставляет СД. Затем начинает долбить байтом 01 - зелёная стрелка.
61732! Можете разобрать байты хвоста? В Вашем файле 24 MHz, 1 B Samples [5].logicdata есть данные - 8 линий данных. Их надо превратить в НЕХ. Если файл открыть в программе Saleae Logic то видно импульсы головы, пробел, тело данных, пробел хвост. Первый байт хвоста 0х34 начинается через 0.37 секунды от тела данных, второй 0х20 через 0.255 мс далее 0х34, 0х20, 0хfd, 0xfb.... и из файла 24 MHz,1 B Samples [1].logicdata восстановить сигналы УПР и КнП к данным хвоста.
Пытаюсь разобраться, но не получается.
Как собирать байт.
Наложенные данные и управление. 
Судя по первому СД первый байт 0х00.
Поправил скетч для загрузки байтов предшествующих обмену. Он принимает в буфер 32 байта, выводи их в консоль, и зависает. Нужно проверить, что ранее снятые дампы приняты правильно.
/*********************************************************** Подключение: ЛД0 - 8 ЛД1 - 9 ЛД2 - 10 ЛД3 - 11 ЛД4 - 12 ЛД5 - 13 ЛД6 - 6 ЛД7 - 7 СД - 2 ***********************************************************/ const int PIN_CLOCK = 2; // Пин синхроимпульсов. const int INT_CLOCK = 0; // Номер прерывания синхроимпульсов. const int DOP_6 = 6; // Пин шестого разряда данных. const int DOP_7 = 7; // Пин седьмого разряда данных. const unsigned char MASK = 0b11000000; // Маска для формирования байта. const int maxCount = 0x20; unsigned char bufferTable[maxCount]; int count = 0; void setup() { attachInterrupt(INT_CLOCK, input_char, FALLING); pinMode(DOP_6, INPUT); pinMode(DOP_7, INPUT); DDRB = MASK; pinMode(2, INPUT_PULLUP); Serial.begin(57600); Serial.println("\n\nStart test:"); } void input_char () { unsigned char ch; if(maxCount > count) { ch = ~((PINB & ~MASK) | (PIND & MASK)); bufferTable[count++] = ch; } } void loop() { int i,j; unsigned char n; if(maxCount == count) { for (i = 0; i < maxCount/0x10; i++) { Serial.println(); for(j = 0; j < 16; j++) { n = bufferTable[i * 0x10 + j]; if (n < 0x10) { Serial.write('0'); } Serial.print(n, HEX); Serial.write(' '); } } while (true); } }Появляется только Start test и все.
Поправил скетч для загрузки байтов предшествующих обмену. Он принимает в буфер 32 байта, выводи их в консоль, и зависает. Нужно проверить, что ранее снятые дампы приняты правильно.
Посмотрите снятые логером данные #233. Там есть все данные. Все байты и управляющие сигналы до обмена и после
. Время ответа магнитофона 1.125 мкс. 
. Отвечает не только на данные, а на снятие сигнала УПР после байта 0xFB. Причём 3 раза в подряд. Третий раз после КнП. Затем после ещё обмена выдается КнП вместе с УПР, после чего 2 байта 0хFD 0x43 и собственно далее идёт поток данных.
Пытаюсь разобраться, но не получается.
Снимите логером обмен по шине данных ЛД0 - ЛД7, только замените сигнал ЛД0 на СД. Это необходимо, что бы точно понять, где данные передаются.
Заказывать такой
https://infedox.by/catalog/sredstva_razrabotki_konstruktory_platy_moduli...
Это белорусские рубли. Вас они устраивают? Плата правильная.
https://cloud.mail.ru/public/a28p/njnG8tDzX
В понедельник обещали прислать #247