Связать LPC2214/01 и TMS320VC5509a, через SSP <-> McBSP Опции

[Altemir]

Всем доброго времени суток.

Стоит задача связать LPC2214/01 и TMS320VC5509a через SSP1 <-> McBSP0. Первая проблема возникла при программировании: использовался последовательный 8-битный режим с фреймовой синхронизацией в первом клоке. Если конфигурить SSP1 LPC в 8-битный режим TI SSI (мастер), то тмс-ка теряла первый и последний байт. С последним разобрался - как понял, внутренний автомат ТМСки защёлкивает данные по дополнительному клоку, т.е. получалось на следующем байте (проц то клоки снимает после передачи байта).

Решилась проблема переводом SSP1 в 9-битный режим. Осталась проблема первого байта, понять которую так и не удалось, пришлось выдавать перед заливкой холостой байт.

С программированием TMS-ки вроде удалось справиться, но проблемы вновь всплыли при работе с залитой программой - проблема первого байта в пакете. После старта проги в TMS-ке, если LPC (мастер) выдаёт холостой байт перед первым пакетом, то TMS и LPC данные принимают корректно, без сдвигов. Во втором же пакете LPC принимает всё корректно, а в начале принятого TMS-кой пакета присутствует нулевой дополнительный байт (LPC его не передавал, смотрел осциллом), за которым идут данные.

Кто сталкивался с таким стыком? Были ли проблемы? Как решали?

Интересует обмен на максимальной скорости. Стабильно поднял на 14,7456МГц (при тактовой LPC - 58,9824МГц и TMS - 192МГц), на 29,4912МГц данные идут враскоряку с обеих сторон, склонен винить длинные дорожки до 9см и отсутствие терминаторов (что подтвердили осциллограммы ). Если переходить в режим SPI1 для решения проблемы первого байта, то придётся ещё снижать клок до 7,3728МГц, т.к. по даташиту на McBSP максимальный клок в этом режиме может быть 12МГц.

Спасибо.

[Altemir]

У 24xx вешается и SDRАМ и цена чипа в общем-то поменьше. Я с LPC229x ушел....

Не по теме, но...
Посмотрел я LPC2468 как потенциальную замену 2214/01. По цене сейчас для нас выигрыша нет, судя по ценам у МТ-Систем: LPC2214FBD144/01 - 184р., LPC2468FET208,551 ver B - 241.41р. Понимаю, что за функционал надо доплачивать, но когда 2214 пока удовлетворяет текущим задачам... И несколько поубавила блеска с проца его еррата , хоть и особо смертельного (кроме CANа) там ничего нет.

По моему вопросу - в пн вернусь к железу, если не удастся решить вопрос на SSI (без коррекции протокола), то придётся на SPI перейти, может там стык не такой капризный получится. Кстати, а CS на SPI1 проц сам будет дёргать, как я понял?

Да, господа, обратите внимание, кто поднимал (или поднимает) SSP1 на 2214, в даташите Rev. 03 — 2 April 2008 (user.manual.lpc2109.lpc2114.lpc2119.lpc2124.lpc2129.lpc2194.lpc2210.lpc2212.lpc
2214.lpc2220.lpc2290.lpc2292.lpc2294.pdf) есть неточность, касаемо включения SSP (по умолчанию включен SPI на SSP1):

Bit 10 (PSPI1) and bit 21 (PSSP) residing in the Section 6–10.3 control the activity of the SPI1 and SSP module respectively. The corresponding peripheral is enabled when its control bit is 1, and it is
disabled when the control bit is 0. After power-on reset, SPI1 is enabled, maintaining the
backward compatibility with other NXP LPC2000 microcontrollers.

А при переходе в Section 6–10.3 (описание PCONP) бит PSSP (PCSSP) уже указан как 23-ий:

23 PCSSP The SSP interface power/clock control bit
Remark: Setting this bit to 1 and bit 10 (PSPI1) to 0, selects the SPI1
interface as SSP interface. At reset, SPI1 is enabled. See
Section 14–3 on page 219.

Правильно работать с 21-ым битом!!!

Сообщение отредактировал Altemir - Sep 6 2008, 10:30

[zltigo]

Посмотрел я LPC2468 как потенциальную замену 2214/01. По цене сейчас для нас выигрыша нет..

Как сказать. Судя по размеру 512К статики она у Вас предположительно на 8/16bit очень скромненьком EMC висит. А тут уже не только LPC2468(а на него SDRAM повесить вагон можно), но и 16bit LPC2458 и 8bit LPC2378.. Причем тот-же LPC2378 на борту имеет 58K (есть и LPC2388 c побольше)своей БЫСТРОЙ а не висящей на половинной частоте ядра RAM, FLASH 512 и попугаев побольше, и функционал, и при цене на рупь дешевле . Добавьте еще LDO для ядра LPC22xx

И несколько поубавила блеска с проца его еррата , хоть и особо смертельного (кроме CANа) там ничего нет.

- При этом это практически единственный пункт Errata для B ревизии - других кроме дежурной багофичи ядра присутствующих у всех (и которую не исправят никогда, ибо совместимость рухнет) и кривизны с батарейным питанием ПРОСТО НЕТ.
- САN у Вас нет, а если захотите использовать, то в LPC2294 он примитивнее и багов там......
Крепко думать надо, прежде, чем в новые разработки закладывать LPC22хх.

Кстати, а CS на SPI1 проц сам будет дёргать, как я понял?

Вычитывать что пишут про LPC2214/01 надо, но на всех свежих чипах SPI (в отличие от SSP) в мастере SS не управляет, только баг с обязабельным подтягиванием убран и все. Можно использовать, как GPIO. C "автоматикой" тоже нюансы - нарезки на фреймы не будет, если между ними FIFO не освобождается.

[Altemir]

Хорошо, спасибо за наводку на проц. Буду пытаться продвинуть в новые разработки, если начальство идею на корню не зарубит. Хотелось бы ещё узнать, какова разница в быстродействии исполняемого кода из внутренней флэш и внешней SDRAMы 32-битной и 16-битной (PC100-PC133)?

По CS SPI из шита так и не понятно, аппаратно он управляется или нет. На временных диаграммах учавствует нога SSEL, при этом на ней корректно появляется импульс между словами при continous-передаче (Fig.52), только кто её дёргает проверить сейчас, к сожалению, не могу Из того же шита:

However, in the case of continuous back-to-back transmissions, the SSEL signal must be
pulsed HIGH between each data word transfer. This is because the slave select pin
freezes the data in its serial peripheral register and does not allow it to be altered if the
CPHA bit is logic zero. Therefore the master device must raise the SSEL pin of the slave
device between each data transfer to enable the serial peripheral data write. On
completion of the continuous transfer, the SSEL pin is returned to its idle state one SCK
period after the last bit has been captured.