я возможно не совсем понял ситуацию - прошу поправить меня если я не прав:
1. SMK изначально работает некорректно накладывая ОЗУ и ПЗУ. Само по себе наложение уже есть источник конфликта.
те кто первый выставит RPLY, те данные будут приняты процессором, НО это прокатит только в том случае, если опоздание у второго абонента (как я понял это ОЗУ) будет достаточно большим
иначе, будет наложение информации в ответе будет мусор.
2. на обычной машине ПЗУ быстрее, чем ОЗУ, и как следствие разница во времени выставления RPLY достаточная и на чтение успешно отвечает ПЗУ, а ответ ОЗУ маскируется.
3. на быстром ОЗУ ответ идет почти одновременно и возникает конфликт на шине.
Соответственно в AZ конфликт устранить просто:
те я просто не буду отвечать на чтение в ОЗУ если у нас есть ПЗУ. В случае реплики, конфликт изначально не возможен тк ПЗУ у меня эмулируется той же памятью и одновременный ответ в принципе не является возможным.
И у меня вопрос а зачем наложение-то ? те какое практическое применение ?
- - - Добавлено - - -
я сейчас сделал разбивку всего адресного пространства на окна по 4кБ - те всего 16 окон
и каждому окну соответствует регистр с адресом (и дискретность получается в 4кБ)
так, я думаю будет удобно работать
на счет модели с ПЗУ думаю
может сделаю масочный регистр который будет задавать тип ответа на обращение
но сейчас при нагрузочном тесте оперативки из STM32 обнаружили глюки, соответственно ловим. а пока принимаются идеи.





Ответить с цитированием