jcxz

"Разъём UART" думаю должен находиться между "Host" и "RS232 Transceiver".

За основу можно взять это: https://github.com/iliasam/fake86_to_stm32f429_port В этом проекте есть симуляция выполнения команд 8086 (файл cpu.c). Но правда реализация там - на си, "в лоб", без всякого стремления к оптимизации. Потому работать должно ну оооооочень медленно. По нормальному - там нужно всё переписывать на асме и с глубоким задействованием мозга. Но по-крайней мере видно, что все команды 8086 там реализованы. Можно подсмотреть код реализации каждой команды (если есть какие-то неясности). Т.е. - вполне решаемо. Если переписать по нормальному, на асме, без лишнего хлама, да ещё храня содержимое регистров эмулируемого CPU 8086 в регистрах ARM (а не читая/записывая их каждый раз в ОЗУ, как сделано в том проекте), то думаю - скорости STM32F429 вполне должно хватить для эмуляции 8088, работающего на тактовой даже <=16МГц. Регистров у ARM вполне хватит для этого: 8шт. 16-битных РОН 8086 можно хранить в 4-х 32-битных регистрах ARM. IP - тоже в одном регистре ARM. Сегментные регистры - можно и в ОЗУ, а можно и потратить пару РОН ARM на них. Регистр флагов - ещё один регистр ARM. Итого: максимум нужно = 8 регистров ARM для хранения регистров эмулируемого 8086 (скажем: R5...R12) Самые тяжёлые в плане уложиться по времени при эмуляции будут имхо - арифметическо-логические команды регистр-регистр. Потому как выполняются на 8088 за 3 такта, а при эмуляции требуют много действий. Или же самыми тяжёлыми будут команды типа INC/DEC регистра. Которые выполняются за 2 такта. Вот прикинул код эмуляции команды "ADD AH, DL" i8088 на Cortex-M4: ;R6 - IP ;R7 - FLAGS (bits:27...31: AF:SF:ZF:CF:OF; bits:0...7 - for PF) ;R8 - AX:BX (bits:0...15 - AX; bits:16...31 - BX) ;R9 - CX:DX ;R10 - SI:DI ;R11 - BP:SP ;R12 - CS:DS ;R14 - ES:SS ;ADD AH, DL SBFX R0, R8, #8, #8 ;AH SBFX R1, R9, #16, #8 ;DL ADDS R2, R0, R1 BFI R8, R2, #8, #8 ;AH MRS R7, APSR ;SF, ZF, CF, OF LSLS R0, R0, #28 ADDS R0, R0, R1, LSL #28 RRX R7, R7 ;AF BFI R7, R2, #0, #8 ;for PF later Время выполнения этого кода на Cortex-M4 = 9 тактов. Т.е. = 9/180 = 50мкс; на 8088 на 16МГц = 3/16 = ~188мкс. Вроде как укладываемся с запасом. Да, конечно - после этого нужно ещё выбрать и декодировать код следующей команды и перейти на него. Но вроде как реально успеть по времени. Можно также попробовать сделать эмуляцию не с хранением РОН в регистрах ARM, а хранить в памяти: regAL EQU 0 regAH EQU 1 regBL EQU 2 regBH EQU 3 regCL EQU 4 regCH EQU 5 regDL EQU 6 regDH EQU 7 regSI EQU 8 regDI EQU 10 regBP EQU 12 regSP EQU 14 flagPF EQU 16 SECTION .bss:DATA:NOROOT(2) DATA emulData2: DS32 5 SECTION .text:CODE:NOROOT(2) THUMB LDR R3, =emulData2 ... ;ADD AH, DL LDRSB R0, [R3, #regAH] LDRSB R1, [R3, #regDL] ADDS R2, R0, R1 STRB R2, [R3, #regAH] STRB R2, [R3, #flagPF] MRS R7, APSR LSLS R0, R0, #28 ADDS R0, R0, R1, LSL #28 RRX R7, R7 Время выполнения увеличивается до 10 тактов, но размер кода немного меньше. PS: А ведь есть ещё Cortex-M7 с бОльшей скоростью. Если в M4 не влезет. Так что имхо - эмулировать реально. Если подходить с головой. Конечно - нужно ещё учитывать латентность флеша (если исполнять эмуляцию из него). Или попытаться всё (или самые критические части) всунуть в ОЗУ. Но всё-же, всё же - не думаю должно получиться.

Откуда это известно? если не известно - что подразумевается под блоком "RS232 Transceiver" на схеме ТС? Может там некая схемка на транзисторах? А какой толк от такой подтяжки на входе RX микроконтроллера? Ведь у "RS232 Transceiver" явно должен быть активный низкоомный выход.

Подумайте что будет, когда ничего не будет подключено к разъёму UART, а питание STM32 будет включено. Что будет на ноге RX разъёма?

Странно вы как-то ищете... У меня поиск выдаёт кучу ссылок. Вот хотя бы в этой ветке: сразу несколько ссылок.

Не надо ничего этого. Всё намного проще - как писал выше. Достаточно: Интерпретатор команд написать нетрудно: система команд 8086 известна и детально описана. Симулировать можно даже не все команды, а только используемые в прошивке. Наибольшая трудность (имхо) будет в симуляции периферии. Но если её используется не слишком много и она не особо сложная, то и это будет также вполне по силам даже не слишком опытному бойцу. Т.е. - нужна только прошивка, схема и детальное описание используемой периферии МК. А средства отладки - они будут в платформе, на которой выполняется симуляция. Современные средства отладки.

Я и не волнуюсь. Говнокод уже не только на планете Земля. Недавно его успешно доставили на Луну. В составе миссии "Луна-25". Говнокод окружает нас. Он везде - от 3D-принтера, до космических аппаратов. Куда ни плюнь.

Вот интересно: Программер, сделавший этот баг - может он посещает наш форум? зарегистрирован здесь? Интересно....

Разве сгорел? Вроде читал, что он успешно осуществил сейсмическое воздействие на Луну. Только со временем немного промахнулись - поспешили. Надо было чуть позже, когда индийская станция уже долетела до Луны, развернулась там и была готова регистрировать сейсмическую активность. Ведь для сканирования недр Луны, нужно было произвести сейсмическое воздействие на неё. Вот "Луна-25" это сейсмическое воздействие и осуществила успешно. Точнее даже - не "Луна-25" поспешила, а это индусы опоздали. Как-то слишком медленно летели.

Почти к каждой строчке. Вы разве сами не замечаете, что там понаписали? Начиная от: memset(pArrayRX_dataQSPI, 0xFF, bufQSPI_size); /// - обнуление массива, в который читается информация по QSPI; Зачем вообще какое-то "обнуление"? Почему ложь в комменте? Также на кой задавать такие вопросы и не выкладывать описание ВСЕХ используемых типов данных и функций? И описание начальных значений переменных, с которыми что-то делаете в коде? Вы здесь телепатов ищете, которые должны всё это угадать? Смотрите на свой пост и на каждой строчке пробуйте включать мозг. И что? Вопросы про компоновку в заданные адреса тут обсасывались уже многократно. И в очередной раз - совсем недавно. Попробуйте быть не только "чукчей-писателем".

Ужас конечно. Кровь из глаз... Понимаю теперь почему современные программы имеют такие невменяемые размеры..... ТС, ваш CPU умеет команду REV! Советую наконец-то открыть и почитать мануал на ваш процессор. И на кой интересно rx_data_QSPI прибит гвоздями к абсолютному адресу?? Посещали курсы телепатов? Или вы телепат-любитель?

Подождите немного - сейчас программёры догонят! И используют его на все 100%... для простого калькулятора даже. Давно заметил - чем дальше "прогресс" -> тем тормознее и монструознее становятся программы. Причём - решающую ту же самую задачу, что раньше, не лучше не хуже, но ресурсов сжирают уже кратно больше.

Для управления (сравнения с уставкой) - использовать период; для индикации - rpm (так человеку удобнее). Одно не противоречит другому.

Т.е. - даёте вы кому-то ТЗ: "Измерить частоту, лежащую в диапазоне 100...200Гц". И говорите "а точность мне не важна". Ок. Вам приносят разработанный девайс, который и при входящей частоте 100Гц и при 200Гц, всегда выдаёт одно и то же значение = 150Гц. Разработчик прав? Конечно. Ведь требуемая точность в ТЗ не указана, а значит может быть выбрана разработчиком на его усмотрение - как ему удобнее. Вот он и выбрал точность +-50Гц. И был прав. А вы должны оплатить его работу.

Таймеру - по барабану, но у вас как у разработчика, должно быть ТЗ, в котором должна быть указана требуемая точность измерения. Уменьшая частоту тактирования таймера, вы уменьшаете эту точность. PS: Похоже идёт разработка показометра, а не не измерителя. Который просто должен показывать какие-то циферки. Раз автор даже не озаботился вопросом точности измерения.... Ясно. Вы не имеете понятия в обсуждаемом вопросе. Несёте полный бред.

Ещё раз: Разница в реалтаймовости. Если измеряемые импульсы идут с частотой скажем 10Гц, то измеряя длительность каждого импульса, получаете реалтаймовость = 0.1сек (т.е. - с такой частотой можете обновлять значение на индикаторе). Если будете измерять каждые 10 импульсов, то получите реалтаймовость всего = 1сек. Что крайне мало для наблюдения за динамическим процессом. Это не так. Видимо вы никогда не работали с управлением системами в реальном времени. У нас была ещё более инерционная система - электротранспорт массой в несколько тонн и средней постоянной мощностью эл.двигателя - более 200 кВт. Цикл управления двигателем (в котором крутился цикл векторного управления) при этом составлял ~10кГц. И чем выше частота этого цикла - тем более качественное получалось управление. Если бы позволяло время переключения силовых ключей (и длительность синхронизации нескольких инверторов между собой) - подняли бы частоту цикла FOC ещё выше - выросло бы общее КПД. Любой ПИД-регулятор работает тем лучше, чем чаще делаешь его обновление.

Чисто практическое. Работал сам когда-то на них. А вы сами - имеете практическое представление? Работали когда-нить за ним? Если бы работали, то знали бы, что в процессе обработки, при ручной подаче, резец и касается детали и отходит от неё. Этим управляет токарь. Кроме того: Болванка изначально может не иметь идеально цилиндрической формы. Кроме того: В материале болванки могут присутствовать каверны или неравномерности плотности материала. Измеряем время на старте и на финише. Считаем среднюю скорость прохождения дистанции. Какова будет точность/дискретность измеренной скорости? Чем она будет определяться?

А вес обрабатываемой болванки? При такой мощности привода и неравномерности нагрузки (резец может вгрызаться в металл или лететь по воздуху) - инерция имхо совсем невелика. И неравномерность должна быть существенной. Если конечно обрабатываемая болванка у вас весит не несколько тонн. Вы видимо из тех чукчей, которые "не читатели": Советую перечитывать выделенное до просветления.

ничего не понял..... разница между одним фронтом и другим? Так ведь именно она и измеряется - разница между очередным фронтом и следующим. И что за "неучтённое время"? Я об этом и писал: это добавление этапа фильтрации к этапу самого измерения. И здесь есть существенный минус у такой практики - ухудшение реалтаймовости. То же самое можно делать, производя фильтрацию уже измеренных данных, в CPU. Тогда степень фильтрации будет примерно такая же, но реалтаймовость не уменьшится. Измерять длительность нескольких импульсов оправдано только при их относительно высокой частоте и слабости измерительной системы (если ей не хватает быстродействия). Очевидно здесь не тот случай.

Бред. Точность/дискретность любого измерения времени по таймеру, определяется (и скорее всего равна) точности/дискретности этого таймера. Если речь об МК, в котором таймер тактируется частотой 144MHz, то любые измерения выполняемые по этому таймеру, будут иметь дискретность = 1/144e+6 сек. Если следовать вашей логике, то измеряя по секундомеру время прохождения бегуном дистанции марафона, точность такого измерения будет равна +- несколько часов (время прохождения дистанции). Что является явным бредом. Точность здесь будет определяться ценой деления шкалы секундомера. Попробуйте наконец-то включить голову!

Это и есть - измерение частоты вращения путём измерения периода следования импульсов. А измеряя за несколько периодов, вы просто смешали измерение с фильтрацией. Но лучше/гибче фильтрацию делать математикой в CPU. Подавая на вход усреднителю измерения отдельных периодов.

Это всего то <= 13МГц тактовой? Для такого древнего и тормозного железа, можно даже не реверсировать прошивку. А просто написать симулятор, который будет исполнять код 80188 в режиме интерпретатора. И исполнять это на каком-нить современном ARM-е. (вполне хватит производительности старших Cortex-M). Нужно только разобраться с записями/чтениями портов периферии. Если периферии используется немного и несложная, а общий размер прошивки большой, то думаю - такой путь будет даже проще/быстрее, чем дизассемблировать и разбирать прошивку.

Это по вашему способу необходимо. А если измерять период импульсов - то никаких 10 минут не нужно. А нужна только необходимая дикретность/точность опорного таймера. И стабильность вращения. О чём и речь. Почему ваш способ и не подходит для такой задачи. Не нужно ничего урезать. Измерение периода всё решает. И даже ещё и фильтровать позволяет, без потери реалтаймовости. Ещё раз подумайте.

Какие "12 тыс. отображений"? Какие "10 минут"? Вы о чём??? Нужно отображать обороты. С указанной дискретностью и указанной реалтаймовостью. Хоть 12 тыс., хоть 12 миллионов раз. Попробуйте ещё раз перечитать и попытаться понять написанное. А потом: всё-таки - ответить на поставленный вопрос.

Это всегда было так: Хочешь получить гарантированно работающий код? Решение: Напиши его сам. Во все времена так было, а не только с современными. А ещё есть поговорка: "Дарёному коню в зубы не смотрят".