Уважаемые коллеги! Я начинающий программист в области встраиваемых МК
и ищу людей, с которыми можно будет пообщатся на эту тему. Основные сложности возникают при поиске информации на русском языке, видимо МК С167 еще не очень популярен. Если Вы работали с с167 и можете об этом рассказать(или ссылку скинуть), то эта рубрика для Вас.

Да нет, причина, видимо, в другом: слишком уж бесперспективное это занятие в общем случае - перевод документации (на мой взгляд)

Я делал проект на С167 и еще пару - на похожих (ST10F168 и ST10F269). Так что, если смогу, то отвечу на возникшие вопросы. Только появлюсь я на связи не раньше 2.08.05

Ну лет 10 назад С167 хорошо "смотрелся", а теперь я бы в сторону ARM-ов посмотрел.
Мне кажется, что искать доки на русском - отстать от жизни лет на 15-20.
(Can167.zip - модуль CAN в 167, но мне кажется я и весь где-то видел)


Да-да, а заодно и по Infineon Tricore, а то впечатление, что кроме меня с ними никто не работает

C167 хорошая архитектура. Заточена для очень жесткого и надежного реалтайма. Для этого снабжена многоуровневой с большим количеством векторов системой прерываний, развитым контролем сбойных ситуаций, DSP движком у некоторых и т.д. До последнего времени все мобильники Siemens делались на этом ядре, также поголовно применяется в мерседесах.
Скорость работы во многом определяеться выбором компилятора.
Известным чипам на ядрае ARM7TDMI по скорости работы не уступает, поскольку в отличии от них имеет DMA, быструю внутреннюю шину ну и DSP (у некоторых ;-))
У них есть проблема сегментированности памяти, но если вы не собираетесь часто перескакивать на другие платформы, то к этому можно привыкнуть.
У меня есть большой проект на ядре C167, конкретно на ST10F269.
По ссылке реализация одной из его версий
http://www.teltonika.lt/default.asp?prgID=...13&LanguageID=2
Могу выложить если интересно.

Да, хорошая, одной командой переключить банк регистров, а вот с сегментацией, конечно, не очень удобно.
А если еще взять DAvE - нигде такого сервиса не видел.
Кстати, настоятельно рекомендую им пользоваться - он генерит код, который работает , а из документации от Infineon не всегда ясно, что делать (по опыту с Tricore).

В мерсах, скорее применялся, щас для управления движком Infineon TC1796 сделала.

Хотя, если интересен именно 167 - я бы на серию XC смотрел, 167 скоро думаю трудно купить будет, мы 165 уже с трудом покупаем - дорожают

И, все-таки, вроде видел доку на 167 полностью на русском - в виде книги кто-то издал - спросите у ИНТЕХ-а

Заодно вопрос (san822) - а что за проект на 167, если не секрет?

Мы работаем на XC167, так если что, могу подсказать,
а доки на С167 были здесь http://forum.electronix.ru/index.php?showtopic=6564

если кого интересует, вот еще

и еще

Благодарю всех за участие и помощь. Я думаю, что есть смысл переводить документацию и ещё важнее делать авторские статьи. Это может помочь другим и повысит известность и уважаемость автора.
Например, мне встретился сайт Александра Бельченко. Он решился выставить свои переводы и советы в сети.

а ссылку на сайт Александра Бельченко, где?

http://www.bialix.narod.ru/

Господа! Есть ли проблемы с поставкой 167 процессоров, какие фирмы их продают? Какой ценовой диапазон?

Сейчас официальным поставщиком продуктов Infineon в России считается компания Платан (Они даже сайт посвятили этому - Infineon.ru), хотя и другие компании предлагают продукты этой немецкой корпорации,например, Симметрон.
Цены на сам процессор лежат (ориентировочно) в диапазоне 15-30 у. е. и зависят от конкретной модели МК и ценовой политики фирмы-поставщика.

Господа! у КОГО-НИБУДЬ ЕСТЬ ОПЫТ РАБОТЫ С can-ПРотоколом ?
Документация от фирмы Каскод(RideDoc_1_3) оказалось позезной,
но там эта тема не освещена достаточно широко.
Перевод компании ЭЛКУС очень удобен тем, что он на русском языке.
Кроме того, мне приходится иметь дело с Кейлом
и не вся информация является переносимой для него.
Существуют ли книги(электронные или бумажные) по протоколу CAN ?
В рунете мне встречались лишь базовые знания о протоколе.

ну вот: базовый + личный опыт и есть то что ты хочешь, а у кейла есть примеры,там можно по образу и подобию..., разобраться можно....
а вообще что именно тебя интересует?

Ну, например, не понятно пока как лучше использовать идентификатор (чем его вообще заполняют?)

http://www.can-cia.ru/

Сам писал много программ для с166 правда на нем собраны старые модели телефонов Siemens а сейчас действительно это не актуально лучше ARM, PIC или AVR.

А если уже есть база, ранние разработки , отсутствие необходимости осваивать нечто новое, теряя при этом некоторое время на его освоение, то что делать?
Кроме того экономически пока не имеет смысла бросать то, что уже есть.
Возможно мне придётся принимать решение о выборе МК, но пока это не в моей компетенции.
Какие сайты Вы считаете самыми полезными для людей,
которые выбирают МК?

Уважаемые разработчики!
Исходя из чего выбирают количество используемых буферов сообщений в CAN-контроллере С167 ?
С сайта www.keil.com скачал пример APNT_167,
там почему-то инициализируется только 6 буферов.

Влияет ли количество используемх буферов на быстродействие сети и в каких случаях ?

Каким образом используют особенность 15-го буфера(наверное, не просто так его возможно использовать только на приём и его прерывание имеет наивысший приоритет) ?

Исходя из ситуации.
Как сгруппированы CAN-ID , какие можно применять маски, как нужно реагировать на отдельные посылки и т.п.



Никогда не влияет.

Теперь тут http://www.onembedding.com/

Есть еще вопрос по этой теме.


Чем отличается polling mode от interrupt mode в применении ?


Т. е. когда применяют polling mode, а когда - interrupt mode ?

Вероятно, меняя биты RXIE и TXIE регистра Message Control(MCR)
можно устанавливать polling mode(INTPND не устанавливается
при приёме и передаче) или
interrupt mode(INTPND устанавливается) ?


Или я в чём-то ошибаюсь?

Что стоит за словами remote frame replier и remote request sender ?
Меня интересует не только Ваша интерпретация перевода.

Уважаемые пользователи системы моделирования Proteus!
Кто-нибудь из Вас моделировал С167 в этой среде моделирования?
Можно где-то найти модель микропроцессора С167 для Proteus ?

Возможно так
remote frame replier - объект, возвращающий "удалённый" кадр (чтобы обратиться к удаленному узлу)
remote request sender - объект, посылающий "удалённый" запрос (опять же к удаленному узлу)

Хорошо бы контекст. Но на сколько я понял, это термины из идеологии CAN. "Удаленный" кадр посылается в удаленный узел обычно для того, чтобы получить от него соответствующий кадр с данными. Так я прочитал в мануале.

Подключаю к портам C167 напрямую L298 для реверсивного управления парой ДПТ на 9V. Чуваки перестраховываются и хотять ставить развязку на оптопарах. Я их отговариваю! Источник питания один, а если будет косяк с двигателями, то сгорит только силовая часть. А может я не прав?
Решили подавать сигнал ШИМ на входы "enable" для каждого моста (L298), а по входам ("input1,2,3,4") задавать направление вращения. Нормально?

Да, контекст, тут действительно необходим.
Во-первых, присоединяю архив с сайта www.keil.com - чтобы
было понытно о чём идёт речь.
Во-вторых, сразу спрошу конкретно:

1) Читаю нижеприведённый текст с описанием функций и
не могу понять - как осуществляется ответ на такой запрос ?
Заодно хотелось бы знать - приходилось ли Вам применять
когда-нубудь такие запросы или писали что-то своё?


int CAN1ReqRemote (unsigned int ch) {
unsigned char typ;
if (ch >= sizeof (id_typ)) return (-1); // channel not defined
typ = id_typ[ch];
if ((typ & DIR_MASK) != CanRX) return (-1); // channel is not a receiving channel

C1MOBJ[ch].msg_ctl = TXRQ_SET & NEWDAT_CLR; // Очищаем данные и требуем
// передачу "пустого" сообщения,
// которое на самом деле состоит
// из поля идентификатора и
// поля контрольной суммы
return 0;
}


/*
* CanSetRemote:
* Input Parameter: ch := message object channel (1 .. 15)
* p := pointer to data buffer
*
* - check if CAN message object is defined for transmission
* - Fill data buffer with data
*/
int CAN1SetRemote(unsigned int ch, void *p) {

unsigned char typ;

if (ch >= sizeof (id_typ)) return (-1); // channel not defined
typ = id_typ[ch];
if (!(typ & DIR_MASK)) return (-1); // channel is not a transmission channel

C1MOBJ[ch].msg_ctl = NEWDAT_CLR & MSGVAL_CLR; // очищаем часть буфера с данными
// и делаем буфер недействительным
memcpy (C1MOBJ[ch].msg, p, (typ >> 4)); // записываем в буфер сообщения "ответ"
// на запрос данных
C1MOBJ[ch].msg_ctl = NEWDAT_SET & MSGVAL_SET; // показываем, что были записаны
// новые данные и делаем буфер
// действующим, но не требуем
// передачи сообщения!
// TXRQ не устанавливаем!
return 0;
}




2) Чем отличаются очень похожие функции(описываются в файле CAN1.C, который находится в
присоединённом к этому сообщению архиве) CAN1Send, CAN1Read
и CAN1SendIsr, CAN1ReadIsr ?
Уточню вопрос - когда следует применять CAN1Send, CAN1Read,
а когда CAN1SendIsr, CAN1ReadIsr?

Странно , что на второй простой вопрос нет ответов.
Никто даже не упрекнул меня - "Неужели ты не разобрался в этих сравнительно несложных функциях (CAN1SendIsr,CAN1ReadIsr), которые пересылают данные в "промежуточное хранилище" и затем, когда возникает возможность, пересылают их(а CAN1ReadIsr соответственно потом принимает то, что передано с помощью CAN1SendIsr)?"


Пользуясь случаем, поздравляю всех с наступающим Новым годом!

Привет всем. Потихоньку ковыряю контроллеры М168-3, М269-3 от Каскода.
Че то получется, че то нет. Вопрос?: кто-нибудь занимался удаленной прошивкой по RS-485 или CAN для этих контроллеров? Есть вопросы по конфигурации в uKeil2.

А где вопрос?

В CAN-контроллере C167 в регистре контроля-состояния CSR
есть бит TXOK, который устанавливается если последняя передача сообщения была успешна завершена. При его изменении изменится значение INTID
в регистре PCIR – оно будет равно «01» (т.к. CSR обновил состояние).
В тоже время, в регистре передающего буфера MCR установится бит INTPND (если это разрешено установкой бита TXIE). Например, если передающий буфер имеет номер 3, то возникает прерывание и бит INTID регистра PCIR будет
иметь значение (2 + 3) = «05».
Понятно, что прерывание с INTID = «01» имеет больший приоритет и обработается первым, но что будет с прерыванием от передающего буфера ?
Будет ли оно «поставлено в очередь» или будет потеряно ?

Если у вас возник встречный вопрос - о чём здесь идёт речь,
то почитайте сперва файл CAN167.zip, который присоединен к третьему сообщению данной темы.

Чтобы не забыть, может пригодится...
Keil Crack работает с Keil c166v602 -> www.megaupload.com/?d=GJI2CQGG

что-то ссылочка не работает
Может у кто-нибудь скинет crack для Keil (желательно под c166v606), хотя кидайте любую!

Тема, конечно, древняя, но я только сейчас столкнулся с проблемой.

1) Зачем такая хитрая система в регистре MCRn - установка и сброс двумя битами? И как обойтись без того цикла чтение-модификация-запись, про который упоминается в руководстве? Это XRAM, поэтому побитно туда не обратишься, следовательно и команды BFLDL/BFLDH не работают.

2) Как я понимаю - маски работают по принципу сверять идентификатор пришедшего сообщения с полем арбитража в объекте сообщения или нет. Т.е. если маски все в 1, значит жесткое отсеивание - примутся только те сообщения, чьи идентификаторы явно прописаны в приемнике (в поле арбитражей), если маски все нулевые - любое пришедшее собщение запишется в объект первого сообщения. Так это или нет?

3) Если в CSR запретить прерывания, будут ли выставляться флаги этих прерываний?

4) Обязательно ли пользоваться регистром CSR для отслеживания завершения приема-передачи, или можно ограничиться регистром MCR каждого сообщения, там есть аналогичные биты.

5) Если не трудно, опишите последовательность действий при правке сообщения, при постановлении на отправку, при посылке кадра запроса. Желательно в формате "для чайника" по типу:
Записываешь в бит ХХ регистра ХХ значение ХХ - для того-то, того-то
Записываешь........ и т.д.

Скачайте DAVE - он именно это и сделает.
http://www.infineon.com/cms/en/product/mic...1134ee4d3b30265

Кому надо - ответы на часть моих же вопросов.

Если запретить все прерывания, их флаги будут выставляться в глобальном регистре, в управляющем регистре каждого сообщения флаги прерываний появляться не будут (все остальные работают как должны).

Глобальным регистром и прерываниями пользоваться не обязательно, в регистре управления каждым сообщением достаточно информации чтобы понять что произошло:
для принимаемых сообщений - флаг NEWDAT и флаг потерянного пакета MSGLST;
Для отправляемых сообщений - тот же NEWDAT (сбрасывается при успешной передаче) и флаг RMTPND + TXRQ.
Сам я в начеле основного цикла заполняю буфера, передаю данные и посылаю запросы, в конце основного цикла по флагам проверяю что пришло и распаковываю.

В регистре MCRn данная организация чтобы можно было одним MOVом сделать три (а не две - как ORом или ANDом) операции над каждым флагом - установить, сбросить, не менять. Зарезарвированные комбинации при чтении ни разу не возникали, при записи игнорируются.

Вопрос по маскам остался. Как работают понять не могу. Если в масках все единички - то сообщение записывается в объект, арбитраж которого полностью совпадет с арбитражем сообщения. При наличии в маске 0 начинается полная абракадарбра. В DAVE про это ничего не сказано - заполнение масок и арбитражей он оставил на моё усмотрение. Если кто в курсе - подскажите пожалуйста.

подскажите, в какой момент происходит считывание данных из внешней памяти (демультиплексная шина), из даташита понял, что по фронту сигнала RD, это верно? интересует вот в каком ключе: если этот сигнал подцепить на CS внешней флехи, будет ли это корректно? не успеет ли она перейти в 3-е состояние до завершения считывания данных?

Есть несколько вопросов по C167CR.
В блоке управления ДВС (блок на диагностику не выходит) установлен данный процессор, и ЗАДАЧА состоит в проверке работоспособности его.
На сколько я правильно понял, то при помощи программы R16x Flash Programmer я могу соединится с процессором.
Народ, подскажите где возможно скачать программу или пакет ИСР RIDE???

Помню, когда давным-давно занимался C167, прямо на сайте у Infineon была программка Memtool. Сам я ей не пользовался, так как работал с Keil C166, и он делал всё, что мне было нужно.

Чем можно посмотреть и запрограммировать фьюзы в С167?

работаю с с167. А что такое фьюзы?

Да уж сморозил, я имею ввиду регистры. Пробовал MiniMon читать есть только соединение с проц. Подскажите чем можно посмотреть и записать состояние регистров. Соединение по UART. Пробовал FLASHit - читается и пишется нормально,а посмотреть и записать состояние регистров - не доходит.

Регистры в этом контроллере - всего навсего кусок оперативки. Посмотрите, куда в программе указывет CP и 30 байт вниз от этого адреса - и есть регистры. Если, конечно, в указанных программах есть возможность читать ОЗУ. Мы на работе используем небольшие самописные модули, например перекладка PECCом в S0TBUF.
Т.к. это кусок ОЗУ - запрограммировать его невозможно. Начальные значения копировать в регистры при инициализации в самом коде.
Хотя я на практике сталкивался, что минут пять без питания в ОЗУ остается висеть мусор - так что желательно в инициализации еще и обнулять всю ОЗУ.

Да,есть функция считывания содержания отдельных адресов с указанием с какого и по какой адрес нужно. Спасибо,wedmeed, за подсказку.

Небольшое уточнение - вниз от CP - т.е. в сторону увеличения адресов (по привычке в голове карта памяти как в дизассемблере). Содержимое CP = адрес R0, прибавляем 2 - R1.

Регистры SYSCON, BUSCON и ADDRSEL также висят в RAM и их конфигурация устанавливается програмнно и/или аппаратно?

Да в RAM. Адреса в даташите на мк. Устанавливаются программно. Изначальная конфигурация в асм-файлах, которые есть у Keil'а.

С регистрами я понял, но такая проблема - проц в режиме BOOTSTRAP работает, а флеш не видит. Видит только что это внешняя флеш. По всем адресам на флешке - 0v. После разбора выяснилось что выход RSTOUT активный. Т.е. на выходе RSTOUT всегда 0v. Флеш рабочая(обменял с рабочим блоком). Даташит говорит что нет команды EINIT. Или может быть аппаратная ошибка?

Про RSTOUT - не помню, как на работу попаду - гляну.
Не совсем понял вот это:

Как он видит что это внешняя флеш? И вообще её ли он видит?
Через регистры BUSCON и ADDRSEL настраиваются адресные окна. Если у Вас внешняя флеш - возможно неправильно собрана карта памяти (например проц в это время обращается ко внутренней). Ну и DPP можно лишний раз перезаписать после настройки системных регистров - где-то встречал глюк с ними (причем обрамить командами типа JMPS на следующую строку).

С RSTOUT разобрался, а насчет внешней флеш - глюк программы. Блок до недавнего времени работал нормально и внезапно умер. Конфигурация проца записана в ROM процессора? Работа блока записана во флешке. Конфигурация проца записана отдельно? Извините за такие вопросы - жизнь заставила менять профиль.