Перейти к содержанию
    

jcxz

Свой
  • Постов

    13 514
  • Зарегистрирован

  • Посещение

  • Победитель дней

    34

jcxz стал победителем дня 29 июня

jcxz имел наиболее популярный контент!

Репутация

218 Очень хороший

4 Подписчика

Информация о jcxz

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

28 539 просмотров профиля
  1. ....и вернуться к той же невозможности определить причину сброса. Вы хотя-бы почитайте - о чём шла речь, в том что вы процитировали. Достаточно какому-то багу привести к порче памяти и, например - снести таблицу прерываний, и прерывание от внутреннего WDT не сработает. Или из-за бага прерывания окажутся запрещёнными. Или ещё какая причина. Если WDT при этом не умеет генерить сброс через некоторое время после выставления сигнала прерывания, то получим зависание.
  2. Если внутренний WDT может только: или генерить прерывание или вызывать сброс (а при выборе режима "прерывание" не вызывает сброса), то это очень плохое решение. Так как при некоторых зависаниях может прерывание не сработать.
  3. Завести сигнал с кнопки кроме входа RESET ещё и на какой-либо аналоговый вход МК (или, если аналоговых входов нет - на компаратор->GPIO). Если схема такой кнопки: RC-цепочка (конденсатор (GND) + резистор (+Ucc)), а кнопка замыкает конденсатор на землю, то после отпускания там будет переключение уровня лог.0->лог.1 - завершение сигнала сброс -> старт CPU -> в начале программы измеряем напряжение на центральной точке RC-цепочки. Оно будет уже хоть и выше порога переключения лог.0->лог.1, но всё равно - ниже +Ucc. Также и при вкл. питания. А после WDT-сброса там будет напряжение, близкое к Ucc. Что позволит отличить сброс по кнопке или power on reset, от сброса по внутреннему WDT.
  4. "Разъём UART" думаю должен находиться между "Host" и "RS232 Transceiver".
  5. За основу можно взять это: 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 не влезет. Так что имхо - эмулировать реально. Если подходить с головой. Конечно - нужно ещё учитывать латентность флеша (если исполнять эмуляцию из него). Или попытаться всё (или самые критические части) всунуть в ОЗУ. Но всё-же, всё же - не думаю должно получиться.
  6. Откуда это известно? если не известно - что подразумевается под блоком "RS232 Transceiver" на схеме ТС? Может там некая схемка на транзисторах? А какой толк от такой подтяжки на входе RX микроконтроллера? Ведь у "RS232 Transceiver" явно должен быть активный низкоомный выход.
  7. Подумайте что будет, когда ничего не будет подключено к разъёму UART, а питание STM32 будет включено. Что будет на ноге RX разъёма?
  8. Странно вы как-то ищете... У меня поиск выдаёт кучу ссылок. Вот хотя бы в этой ветке: сразу несколько ссылок.
  9. Не надо ничего этого. Всё намного проще - как писал выше. Достаточно: Интерпретатор команд написать нетрудно: система команд 8086 известна и детально описана. Симулировать можно даже не все команды, а только используемые в прошивке. Наибольшая трудность (имхо) будет в симуляции периферии. Но если её используется не слишком много и она не особо сложная, то и это будет также вполне по силам даже не слишком опытному бойцу. Т.е. - нужна только прошивка, схема и детальное описание используемой периферии МК. А средства отладки - они будут в платформе, на которой выполняется симуляция. Современные средства отладки.
  10. Я и не волнуюсь. Говнокод уже не только на планете Земля. Недавно его успешно доставили на Луну. В составе миссии "Луна-25". Говнокод окружает нас. Он везде - от 3D-принтера, до космических аппаратов. Куда ни плюнь.
  11. Вот интересно: Программер, сделавший этот баг - может он посещает наш форум? зарегистрирован здесь? Интересно....
  12. Разве сгорел? Вроде читал, что он успешно осуществил сейсмическое воздействие на Луну. Только со временем немного промахнулись - поспешили. Надо было чуть позже, когда индийская станция уже долетела до Луны, развернулась там и была готова регистрировать сейсмическую активность. Ведь для сканирования недр Луны, нужно было произвести сейсмическое воздействие на неё. Вот "Луна-25" это сейсмическое воздействие и осуществила успешно. Точнее даже - не "Луна-25" поспешила, а это индусы опоздали. Как-то слишком медленно летели.
  13. Почти к каждой строчке. Вы разве сами не замечаете, что там понаписали? Начиная от: memset(pArrayRX_dataQSPI, 0xFF, bufQSPI_size); /// - обнуление массива, в который читается информация по QSPI; Зачем вообще какое-то "обнуление"? Почему ложь в комменте? Также на кой задавать такие вопросы и не выкладывать описание ВСЕХ используемых типов данных и функций? И описание начальных значений переменных, с которыми что-то делаете в коде? Вы здесь телепатов ищете, которые должны всё это угадать? Смотрите на свой пост и на каждой строчке пробуйте включать мозг. И что? Вопросы про компоновку в заданные адреса тут обсасывались уже многократно. И в очередной раз - совсем недавно. Попробуйте быть не только "чукчей-писателем".
  14. Ужас конечно. Кровь из глаз... Понимаю теперь почему современные программы имеют такие невменяемые размеры..... ТС, ваш CPU умеет команду REV! Советую наконец-то открыть и почитать мануал на ваш процессор. И на кой интересно rx_data_QSPI прибит гвоздями к абсолютному адресу?? Посещали курсы телепатов? Или вы телепат-любитель?
  15. Подождите немного - сейчас программёры догонят! И используют его на все 100%... для простого калькулятора даже. Давно заметил - чем дальше "прогресс" -> тем тормознее и монструознее становятся программы. Причём - решающую ту же самую задачу, что раньше, не лучше не хуже, но ресурсов сжирают уже кратно больше.
×
×
  • Создать...