Отправлено ВН 13 июня 2002 г. 21:47 В ответ на: TMS320 bugs & EPIC (+) отправлено SM 12 июня 2002 г. 21:47

Опыта доказывания чего-либо EPIC'у не имею. Хотя общался с ним. Ответы часто напоминают отписку. И это одна из причин отсутствия такового опыта. А вторая - не применяю TMX,TMP. Только TMS. В них
большинство глюков выловлено. Новых мне не попадалось.
А компиляторы, линкеры, симуляторы -действительно глюкавенькие.
И ошибка, подобная Вашей, встречается и в 54xx.
Пример: add AR7,A. Компилируется за милую душу, по крайней мере в
CCS 1.20. Ни ошибок, ни предупреждений. А в результате получается операция сложения с аккумулятором A ячейки памяти, располагающейся по смещению 0x17 относительно SP или DP. 0x17 - абсолютный адрес AR7.
Если вместо AR7 указать другой регистр - другое смещение будет.
Формально они правы, но, раз уж AR0-7 зарезервированные имена, могли хотя бы предупреждение выдать. Так ведь нет. Я раз накололся. Забыл звездочку напечатать перед каким-то AR в подобной конструкции. И долго искал - почему программа считает погоду на Марсе.
У Вас видимо подобная ситуация. T0 имеет адрес 32.
Но больше всего меня восхитил глюк линкера. Я как-то уже писал о нем. Процессор 5402. Загрузка была из SPI EEPROM. Есть в процессоре область памяти 0x60-0x7f - scratch ram. Используется bootloader'ом для хранения своих переменных при загрузке программы. В том числе и стартового адреса загружаемой программы.
А линкер там норовит разместить константы, если не запретить вообще эту область памяти в командном файле линкера. И ведь хватает памяти, так нет - лезет в эту область. И при загрузке программы константы затирают стартовый адрес программы.
Странная нестыковка отдельных частей математики техасовской. Как будто нельзя было запретить линкеру размещать вообще что-либо в этой области памяти, если того явно не пожелает разработчик.
Или симуляторы. В C62 - ну не хочет он рисовать графики размером больше 2048 точек, может немного больше, но 4096 точно не хочет.
Хоть бы кусок графика нарисовал, а то голый 0. То же с загрузкой-сохранением данных. Даже хуже. При большом размере массива (>2048) данные даже не обнуляются, а перепутываются. Приходится грузить-сохранять кусками. И график кусками просматривать.
А програмулька hex6x - из .out файла делает .hex? Создает по сути дела образ памяти DSP, только в hex формате. Никакой структуры.
Для загрузки через host port нормально, но не всегда же возможен такой режим загрузки. Часто из флэш.
А адреса флэша-пзу в этом .hex файле равны адресам памяти DSP.
Адресное пространство в c62 разрывное.
Если программа не лезет во внутреннюю память и предполагается ее грузить из ПЗУ-ФЛЭШ - жуткого об'ема ПЗУ может потребоваться из-за разрывности адресного пространства DSP. Хотя можно было бы создавать
.hex определенной структуры, как для c54, например. И избежать этой проблемы.
В результате пришлось самому писать конвертер из .out в .hex.
Сплошные шедевры, доставшие уже. Вот и решил поделиться.

• глюки.... — SM   (14.06.2002 12:59, 2117 байт)