Denis писал(а):_sva_ писал(а):Alexander писал(а):С CAPCOM6 разобрался - для каждого модуля, подключенного к XBUS - свой ADDRSEL XBCON регистры, но с адресов 0хЕ800-0хЕ80Е CAN, E890-E8D8 CAPCOM6, E900-EFFE CAN, т.е. настроить шину так, чтобы окна для обоих блоков не пересекались не представляется возможным. Т.Е. одновременное использование на МК CAN и CAPCOM6 - невозможно?
Извините за задержку с ответом. Действительно, в данной редакции схемы есть проблемы с одновременным использованием этих блоков. Рекомендуем пользоваться возможностями CAPCOM1 и 2, в случае необходимости использования порта CAN.
Честно говоря для меня это шок, мы уже платы развели, программу пишем, комплектующие закупаем...
По существу:
1. Я правильно понял, что для CAN должны использоваться XBCON1/XADDRS1, а для CAPCOM6 XBCON4/XADDRS4 и никак иначе?
2. Может можно обойти? Если адресное окно XADDRS4 отобразить, например, с адреса 0x60000 (размер 64к), то по адресам 0x6E890-0x6E8D8 можно будет достучаться до CAPCOM6? Будет ли при этом все корректно работать?
Плач Ярославны:
Уже не первый раз пытаемся применить отечественный контроллер и все время мимо тазика. Основные проблемы: десятки ошибок и недодумок, которые могут поставить всю программу раком и мозгоразрывающая документация. Взять к примеру описание того же CAN из вашего ТО: вместо диаграммы передачи (рис 23.45) нарисована диаграмма приема, вместо диаграммы приема нарисована диаграмма передачи. Но диаграммы не просто перепутаны, надписи на них "творчески" переведены, например в оригинале было "Start
receiving CAN frame", а стало "начало
отправки сообщения". Да, да я понимаю, не царю батюшке пишем, сам догадается, что надо документацию на инфинионовский MultiCan читать. Как думаете доживем до момента когда в России будут делать вещи на продажу, прибыли ради, а не для того чтобы ОКР сдать/деньги освоить/отчет написать? Вы не обижайтесь только, я все понимаю, этот текст следствие шока.
По существу:
1. Да.
2. Обойти можно. Если CAN имеет только одну возможность обращения по адресам (0E800 - 0EFFF) и все разряды адресов используются для декодирования, то обращаться к CAPCOM можно и по адресам, например, 1E890-1E8D8 или 6E890-6E8D8 и все должно корректно работать.
По поводу "плача Ярославны":
Лично я не обижаюсь на то, что Вы написали. Я понимаю, чем это вызвано. И во многом я с Вами согласен. Проблемы и ошибки встречаются не только у отечественных микросхем, у буржуев их ничуть не меньше, сами знаем. На пути постоянного совершенствования наших микросхем стоят несколько проблем:
1. Большая номенклатура поддерживаемых в разработке микроконтроллеров при не большом объеме их поставок и большом сроке жизни МК. Долгое время промышленность была нацелена на выпуск аналогов зарубежных процессоров, тех, которые применяются в военных разработках. Так как наши разработчики применяли все, что им захочется, то и получается, что приходится поддерживать несколько линеек 16-разрядных МК, 8-разрядных МК и т.д. Не большой объем производства и отсутствие достаточного количества профильных специалистов не позволяют нам под каждое направление набрать и содержать специализированные группы, которые бы идеально "вылизали" каждое изделие. Снять какое-то изделие и больше им не заниматься мы тоже не можем, даже с серийными изделиями приходится возиться от партии к партии.
2. Не возможность изменения изделий в короткий срок и в небольшие деньги. Каждая итерация микроконтроллера, типа 1887ВЕ3Т занимает не меньше 3-х,4-х месяцев по разработке, и еще столько же по производству. Мы не можем запускать новую партию после каждого найденного бага. После присвоения "5" приемки, запуск каждой новой итерации вообще большая проблема, если только не закрыть глаза на проведение всяческих испытаний и т.д., что делать мы не имеем права.
3. Отсутствие внятной и оперативной обратной связи с потребителем и не всегда по нашей вине. Вычистить все ошибки кристалла без помощи тестирования изделий потребителем практически не реально, но оперативность данного тестирования хромает. Одно предприятие начнет заниматься схемами только через полгода, год, второе - подойдет к этому делу формально, третье - найдет ошибку и не сообщит, четвертому вообще не нужно использовать одновременно CAPCOM и CAN
Другая сторона обратной связи: некоторые потребители засыпают элементарными вопросами, присылают программы с банальными ошибками и говорят о том, что нашли баг. Приходится брать их код, прогонять на наших моделях, что тоже требует времени, корректировать их программы, отсылать обратно.
4. Про документацию: мы стараемся оперативно править ошибки, конечно, когда о них узнаем. Но не многие об этом сообщают, говорят об ошибках, как правило, только после мучительного изучения документации, и все сообщения проходят в русле "все плохо, документация кривая". По такому сообщению очень тяжело что-то поправить.
И это проблемы, которые только на поверхности. Часть этих проблем - следствие военной направленности разработки микросхем в России, часть проблем - в отсутствии таких же бюджетов, как у зарубежных компаний, часть, чего уж скрывать, в российском способе организации работ. Но мы работаем как над вопросом улучшения качества уже разработанных изделий, так и над вопросом создания новых изделий с улучшенным, относительно существующих, качеством. Как то так.