Всех почитателей процессора КР580ВМ80А и не только, с наступающим Новым годом!
Всех благ, счастья и успехов в творчестве!
И как бы процессоры в надежде на продолжение исследований в следующем году.
Всех почитателей процессора КР580ВМ80А и не только, с наступающим Новым годом!
Всех благ, счастья и успехов в творчестве!
И как бы процессоры в надежде на продолжение исследований в следующем году.
Попробовал пока без анализатора, что на Родоне 9005 (на 3МГц не работает), что на Кванторе 9008 (на 3МГц работает) красного бордера не возникало ни разу.Сообщение от ivagor
Все таки я думаю, что как то завязано с выполнением кода из ОЗУ. Я конечно могу для подстраховки снять анализатором эпюры, но похоже проблема не в этом.
А я думаю, что дело все же в записи, но есть какой-то нюанс. test1pic и testlog немного отличаются по организации проверки:
1. test1pic сначала переписывает картинку из пзу в озу, потом, когда все переписал, сверяет
2. testlog пишет и тут же проверяет, чтобы поймать неудачную запись. И не ловит, т.к. что-то принципиальное поменялось
Логи testlog записывать нет смысла, раз на всех процах он работает правильно. А вот лог test1pic с пойманной ошибкой на "быстром" проце может прояснить ситуацию, главное найти эту ошибку в логе
- - - Добавлено - - -
Прошло много времени, поэтому напомню на всякий случай, что в test1pic (и testlog) нет выполнения кода из озу, только из пзу. И нет никаких обращений к озу кроме записи и чтения тестовых данных (т.е. никаких вызовов подпрограмм или хранения рабочих переменных в озу)
Попробовал test1pic3 c анализатором, к сожалению на IORW цепляться тяжело потому как ты при окончании записи долбишь в порт FE - записываешь черный бордер.
Можешь чуть изменить тест, в момент записи красноты в бордер перед этим читать порт FE - лучше по IORD триггер тогда ставить
Запись 0 в FE я могу вынести из основного цикла, будет один раз при старте и в конце ожидания после нахождения ошибки (после красного бордюра). Ты хочешь в момент нахождения ошибки прекращать запись по триггеру IORD, я правильно понял? На мой взгляд это особо ничего не даст, можно и вручную выключить при появлении красного бордюра, все равно ошибочную запись придется искать "вручную", просмотром, т.к. она произошла намного раньше обнаружения ошибки (здесь, в отличие от testlog, запись и чтение/проверка разнесены). У меня пока нет идей, как облегчить нахождение ошибки.
Нет, я хочу начинать поиски с этого момента.
Это понятно, что надо как минимум искать по количеству циклов записи.
Можно сделать по другому, записывать сначала допустим по 8 значений, потом сверять, затем следующие 8 и так далее. По крайней мере будет проще считать если вылезет ошибка
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Так я и не понял эту идею
Это можно попробовать, но уже завтра
Дык и проверять завтра только смогу
Примерно придумал, как можно сделать, но надо уточнить насчет триггеров.
1. Нужны триггеры старта записи лога и окончания записи или только один из них (какой)?
2. Если нужны триггеры старта и окончания записи, то они должны быть в разных каналах? Для примера запись лога можно начать по первой записи в память, следующие записи в память (надеюсь) ничего не перетриггерят, а стоп записи лога можно сделать по чтению порта. Но можно и не так, начинать запись вручную, а стоп по триггеру.
Скорее наверное так, ибо я не совсем разобрался еще с анализатором.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
