[kostya-m 0]

Поскольку впервые приходится делать проект с этим DSP, то есть определенная неуверенность, которую хочется закрыть ответами на вопросы.

1. В даташите и в "Using the TMS320C672x Bootloader spraa69d" рассматриваются BOOT варианты. Среди них нет самой простой - из ROM. Что под этим имеется в виду? Я как-то полагал, что после прошивки в ROM прошивки, которую разработает программист, не надо будет ее грузить каждый раз. Или ROM - это табу, а пользовательскую программу надо грузить каждый раз? Например, поставить Flash.

2. Поддерживается ли загрузка прошивки в ROM через JTAG, если ROM не табу? Есть образец схемы с прошлым поколением процессора http://c6000.spectrumdigital.com/dsk6713/ . Там есть и JTAG и эмуллятор. Как я понял, переключатель JTAG там стоит только для работы с эмулятором. Т.е. для живой платы нужен только разъем и пуллап резисторы?

3. Поскольку внутри платы нужен будет I2C0, то на улицу удастся вывести только SPI1 или I2C1. Возможно ли потом программное обновление прошивки (и или коэффициентов фильтров) через эти интерфейсы штатно или надо предусматривать в программе.

[Eger 0]

Уважаемый, скажите а что значит по- Вашему "прошить ROM"?

ROM - Read Only Memory, память только для чтения, туда записана программа начальной загрузки и некоторые константы, таблицы. В моём понимании прошить это значит уничтожить её, сделав нефункциональным весь микропроцессор.

Edited August 4, 2011 by Eger

[kostya-m 0]

Сначала я так же подумал. Но на сайте ТИ есть возможность взять обновление.... Смысл его брать, если его нельзя перешить. Хотя, может смысл обновления в том, что исправления встраиваются в пользовательский код.

А термин ROM я встречал и по отношению к Flash ROM, ведь не написано Masked ROM. Если Вы знаете точно, что тут имеется не обновляемое ПЗУ с библиотекой и ОС, то так и напишите. Может сразу посоветуете марку недорогого параллельного Flash для пользовательской программы?

[kostya-m 0]

В общем, пришел к варианту I2C EEPROM с boot I2C master. Понравился тем, что удастся легко подменять прошивку по той же шине или же в режиме Mulimaster или просто master во время ресета DSP.

Но я так и не понял Таксаса. Лучше бы поместили в DSP flash ROM, а все что есть поместили бы в библиотеку. Линкер бы взял только используемое, а так будет достаточно мертвого груза, который и подправить то нельзя.

[Eger 0]

есть серия процессоров с flash. Это 2000 серия. Она более медленная, как раз в связи с тем, что flash память имеет ограниченную скорость. Не знаю, пойдёт ли в "массы" FRAM, - поживём - увидим.

А так dsp процессор (особенно в аудио приложениях) желательно использовать только для обработки сигнала, из за возможного джиттера и относительно ограниченных ресурсов dsp. Функции управления и загрузки dsp можно возложить на хост контроллер - например arm, для времён разработки процессора 6720 это было очень актуально. Сейчас ядра ARM и DSP комбинируются в один корпус. У тех же техасов.

[kostya-m 0]

Я изначально хотел использовать OMAP, но вмешались потусторонние моменты, потому управляющий проц будет Маревелловский, а DSP Тексасовский, так скорость разработки комплексного приложения окажется выше. Загрузка DSP напрямую с ARM вполне понятное решение и экономит один корпус, но тестирование DSP будет оттянуто до тех пор, пока не будет написано приложение ARM. Поэтому решил поставить eeprom, которое легко загрузить со стороны. А Вы не знаете уровень джиттера McASP? Клок на него пойдет с кварца. В принципе, могу пропустить через триггер выход, но надо ли?.

[Eger 0]

сложно сказать, зависит от конкретной задачи и программной реализации.

[Связист 0]

3. Поскольку внутри платы нужен будет I2C0, то на улицу удастся вывести только SPI1 или I2C1. Возможно ли потом программное обновление прошивки (и или коэффициентов фильтров) через эти интерфейсы штатно или надо предусматривать в программе.

 

У этих процессоров очень кривой SPI. Использовали TMS320С6727 и получили кучу проблем с аппаратной частью SPI. Причём эти баги не описаны в ерате. В итоге проблему обошли программными изощрениями, но это зарубило нам скорость более чем вдвое.

[kostya-m 0]

Спасибо! Буду ориентироваться на I2C, тем более скорость не критична

Edited August 7, 2011 by Мусатов Константин

[talus 0]

У этих процессоров очень кривой SPI. Использовали TMS320С6727 и получили кучу проблем с аппаратной частью SPI. Причём эти баги не описаны в ерате. В итоге проблему обошли программными изощрениями, но это зарубило нам скорость более чем вдвое.

Использовал SPI под 6727b только как бутлоадер, никаких проблем не испытывал ибо скорость SPI ограничивалась EEPROM. Учтите boot spi не поддерживает flash, только eeprom.

Спасибо! Буду ориентироваться на I2C, тем более скорость не критична

Нормально по сравнению с BottSPI отличается только количеством линий, оба используют EEPROM.

[Связист 0]

Использовал SPI под 6727b только как бутлоадер, никаких проблем не испытывал ибо скорость SPI ограничивалась EEPROM. Учтите boot spi не поддерживает flash, только eeprom.

 

У нас SPI использовался для обмена данными между 6727B и микроконтроллером. И глюк не был связан со скоростью. А заключался он в том, что SPI 6727B выдавал в последнем бите данных неправильные данные, точнее он изменял состояние линии данных на 0 посередине последнего бита в том случае если следующий бит (первый бит следующего слова данных) был равен нулю. А если следующий бит был не равен нулю, то всё нормально. В общем как мы поняли, это глюк реализации блока SPI у техаса.

[C2000 1]

В общем как мы поняли, это глюк реализации блока SPI у техаса.

 

В подавляющем большинстве случаев глюки не у процессоров а у программистов.

 

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

[talus 0]

И глюк не был связан со скоростью. А заключался он в том, что SPI 6727B выдавал в последнем бите данных неправильные данные, точнее он изменял состояние линии данных на 0 посередине последнего бита

Не встречал такого... Точнее при записи еепром такого не видел.

[Связист 0]

В подавляющем большинстве случаев глюки не у процессоров а у программистов.

 

Да, я плохой программист. Не обращайте внимания на то, что я здесь писал выше. :)

Ставьте в свои схемы процессоры 6727B и полностью расчитывайте на работоспособность блока SPI.

 

Кстати, записывались данные при помощи контроллера DMA, так что вряд ли я что-то записывал раньше времени. А если что-то и записывалось раньше времени, тогда почему данные менялись посередине бита, а не в конце или в начале.

[talus 0]

Кстати, записывались данные при помощи контроллера DMA, так что вряд ли я что-то записывал раньше времени. А если что-то и записывалось раньше времени, тогда почему данные менялись посередине бита, а не в конце или в начале.

Ну вот видите, с этого и надо было начинать. Спрашивается с чего вы решили, что ошибка в SPI? Управляя SPI при помощи процессора ошибок нет, попробуйте сами. Значит глядеть то надо в связь между dma и spi.