1887ВЕ3Т

Модераторы: ea, Alis, pip, gurzzza, _sva_

mcsimoff
Сообщения: 1
Зарегистрирован: 09 апр 2013, 21:59

Re: 1887ВЕ3Т

Сообщение mcsimoff »

DVS писал(а):Ниже представлена часть ассемблерного кода, где инициализируются выводы порта, задается частота baudrate генератора и устанавливается режим порта с помощью регистра s0con:
mov dp3,#0403h
mov r15,#0403h
mov altsel0p3,r15

mov r10,#8000h
nop
mov s0bg,#0002h
mov r15,#0000h
mov s0fdv,r15
mov s0con,#8010h

Этот код рабочий, используется при тестировании блока ASC0, а также во всевозможных программах передачи данных через интерфейс RS232.
Здравствуйте.

Буду благодарен, если Вы выложите здесь на форуме весь код. На ассемблере, но хотелось бы на С видеть примеры.
А не появилась ли реализация примера CAN на языке С?
Заранее спасибо.
wedmeed
Сообщения: 4
Зарегистрирован: 26 окт 2012, 09:49

Re: 1887ВЕ3Т

Сообщение wedmeed »

Здравствуйте. Обнаружены странности в работе системного стека. Стек работает прекрасно во всем диапазоне (0x0F200-0x0FDFF). В ТО рекомендуется располагать стек не ниже 0xF600 (почему? или это опечатка?). Одна при попытках прочитать (например MOV-ом) из памяти значения, сохраненные стеком, читается "мусор". Записанные в память значения (MOV) так же не читаются стеком (POP). Проблема решается только при расположении стека от 0xFA00 и выше.
В приложении проект с тестами, описание в комментариях.
Вложения
test.rar
Тестирование стека
(12.21 КБ) 251 скачивание
wedmeed
Сообщения: 4
Зарегистрирован: 26 окт 2012, 09:49

Re: 1887ВЕ3Т

Сообщение wedmeed »

...с адреса 0xFC00 тоже проблемы.

Забыл добавить, тест написан под макетную плату, можно сразу загружать.
wedmeed
Сообщения: 4
Зарегистрирован: 26 окт 2012, 09:49

Re: 1887ВЕ3Т

Сообщение wedmeed »

Все, проблема решена - срабатывал механизм виртуального стека. До einit с SP лучше не работать.
Alexander
Сообщения: 7
Зарегистрирован: 24 янв 2013, 02:08

Re: 1887ВЕ3Т

Сообщение Alexander »

Здравствуйте, возникли проблемы с CAPCOM6.
При попытке записи в XSFR (CAPCOM6)- ничего не пишется, настройки XBUS взяты с вашего примера для CAN, если в этом проблема.
Прошу вас дать пример по генерации ШИМ, (параметры ШИМ не важны), для CAPCOM6, заранее спасибо.
Alexander
Сообщения: 7
Зарегистрирован: 24 янв 2013, 02:08

Re: 1887ВЕ3Т

Сообщение Alexander »

С CAPCOM6 разобрался - для каждого модуля, подключенного к XBUS - свой ADDRSEL XBCON регистры, но с адресов 0хЕ800-0хЕ80Е CAN, E890-E8D8 CAPCOM6, E900-EFFE CAN, т.е. настроить шину так, чтобы окна для обоих блоков не пересекались не представляется возможным. Т.Е. одновременное использование на МК CAN и CAPCOM6 - невозможно?
_sva_
Специалист
Сообщения: 215
Зарегистрирован: 12 ноя 2009, 17:42
Откуда: Воронеж
Контактная информация:

Re: 1887ВЕ3Т

Сообщение _sva_ »

Alexander писал(а):С CAPCOM6 разобрался - для каждого модуля, подключенного к XBUS - свой ADDRSEL XBCON регистры, но с адресов 0хЕ800-0хЕ80Е CAN, E890-E8D8 CAPCOM6, E900-EFFE CAN, т.е. настроить шину так, чтобы окна для обоих блоков не пересекались не представляется возможным. Т.Е. одновременное использование на МК CAN и CAPCOM6 - невозможно?
Извините за задержку с ответом. Действительно, в данной редакции схемы есть проблемы с одновременным использованием этих блоков. Рекомендуем пользоваться возможностями CAPCOM1 и 2, в случае необходимости использования порта CAN.
Denis
Сообщения: 32
Зарегистрирован: 16 май 2013, 22:01

Re: 1887ВЕ3Т

Сообщение 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 читать. Как думаете доживем до момента когда в России будут делать вещи на продажу, прибыли ради, а не для того чтобы ОКР сдать/деньги освоить/отчет написать? Вы не обижайтесь только, я все понимаю, этот текст следствие шока.
_sva_
Специалист
Сообщения: 215
Зарегистрирован: 12 ноя 2009, 17:42
Откуда: Воронеж
Контактная информация:

Re: 1887ВЕ3Т

Сообщение _sva_ »

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. Про документацию: мы стараемся оперативно править ошибки, конечно, когда о них узнаем. Но не многие об этом сообщают, говорят об ошибках, как правило, только после мучительного изучения документации, и все сообщения проходят в русле "все плохо, документация кривая". По такому сообщению очень тяжело что-то поправить.
И это проблемы, которые только на поверхности. Часть этих проблем - следствие военной направленности разработки микросхем в России, часть проблем - в отсутствии таких же бюджетов, как у зарубежных компаний, часть, чего уж скрывать, в российском способе организации работ. Но мы работаем как над вопросом улучшения качества уже разработанных изделий, так и над вопросом создания новых изделий с улучшенным, относительно существующих, качеством. Как то так.
Denis
Сообщения: 32
Зарегистрирован: 16 май 2013, 22:01

Re: 1887ВЕ3Т

Сообщение Denis »

Alexander писал(а): 2. Обойти можно. Если CAN имеет только одну возможность обращения по адресам (0E800 - 0EFFF) и все разряды адресов используются для декодирования, то обращаться к CAPCOM можно и по адресам, например, 1E890-1E8D8 или 6E890-6E8D8 и все должно корректно работать.
По поводу "плача Ярославны":
Лично я не обижаюсь на то, что Вы написали. Я понимаю, чем это вызвано. И во многом я с Вами согласен. Проблемы и ошибки встречаются не только у отечественных микросхем, у буржуев их ничуть не меньше, сами знаем.
Спасибо за ответ, камень с души сняли. А PECC будет работать с CAPCOM6? Нам PECC очень нужен, мы с его помощью синус на ШИМе делаем. Естественно, в PECSN запишем все как надо.

По поводу количества ошибок у буржуев не могу с Вами согласиться - их меньше, значительно меньше. И еще не в обиду, раз уж речь зашла, так поговорить... Бывает такое чувство, что периферийные блоки у наших МК проектируются как будто не для живых программ, а для запуска тестов, что ли....

Наша типовая конфигурация: проц, снаружи ОЗУшка. Как мы знаем ближняя память адресуется в С16x через регистры DPP, коих ровно 4.
- DPP3 по многим причинам должен иметь значение 3 (сподручнее к SFR обращаться, да и 3 Кб ОЗУ). Сам KEIL так делал и нам завещал с 1997 года (см. apnt 123).
- Один DPP мы отводим под константы, т.е. он указывает во флэш.
- Два оставшихся указывают в ОЗУ, адресуя таким образом 32К памяти.

И вот вопрос: как эффективно задействовать 8 Кб внутренней памяти по адресу 0x50000? Буржуи, почему то, не сговариваясь располагают ОЗУ в диапазоне 0xC000-0xFFFF, что бы к нему можно было адресоваться через DPP3.

Я вопрос Шеховцову Дмитрию на мыло задавал: у меня память 256К внешняя на первом чип-селекте. Можно ли настроить контроллер внешней шины таким образом, что бы при обращении в диапазоне 0x50000-0x51FFF шло обращение внутрь процессора, а в диапазоне с 0x52000-0x8FFFF во внешнее ОЗУ? Иными словами: если диапазон в ADDRSEL1 пересекается с внутренними адресами куда пойдет обращение?

Посмотрите, пожалуйста, на досуге. 8кб пропадают, жалко :(
Ответить

Вернуться в «16-разрядные RISC микроконтроллеры»