Sauris

Сначала установить CCS v5.2 И ТОЛЬКО ПОТОМ драйверы Sauris, версии не ниже 1.2.0.8, желательно последнюю (1.2.1.2) (если под Linux, то последняя 0.1.3) дело в том, что наш инсталлятор инсталлирует поддержку в состав композера, соответственно если поставить драйверы раньше, чем сам композер, то окажется так, что в композере нет драйвера саурис. Либо, если версия инсталлятора драйвера старая, она может композер новый просто не увидеть. Если ставите в Windows, то на последней странице инсталлятора он выведет, сколько композеров он нашел в системе и по каким путям, убедитесь, что в списке был и требуемый. Если ставите в Linux, то инсталлятор спросит, где искать композер, и ему надо указать хотя бы часть пути к нему

Я отсутствовал с четверга и по вчера. Сорри. Теперь в онлайне

Дока на нее лежит в c:\sauris\doc, называется sauflash-ug.pdf Однако под l-138 нет готового порта, так что в том виде, который в 1.2.1.2 так сразу зашить не получится. Надо портировать sauflash под него: 1) написать/поправить все необходимые скрипты инициализации. 2) пересобрать target code под проц. Готов это сделать, если Вы готовы посотрудничать в отладке - у меня нету таргета на L-138, чтобы сделать порт полностью самостоятельно, для этого необходимо наличие ICQ/Mail Agent ну и желание и возможность.

В подавляющем большинстве случаев эта ошибка вызвана некачественными сигналами (а именно TCK/TCK_RET). Исправляется включением или выключением терминаторов, либо изменением частоты TCK, все это в настройках эмулятора в target configuration меняется. В более редких случаях это может быть вызвано некорректным напряжением на пине PD эмулятора (например туда заведено 5 вольт, при том, что требуемые уровни JTAG 3.3 вольта), либо могут быть проблемы с RESET процессора (например его кто-то дергает внешним вачдогом).

Работать под XP. 7-ка никаких преимуществ не дает для работы.

Давно тут не был.... Нет, не заглохло. Но гемор оказался вселенский. Сделано вот что: - в TCLXDS поддержали ARM 7, 9, 11, Cortex-A7/8/9/15, -R4, -M3/4 - теперь TCLXDS умеет их отлаживать, то есть читать-писать память, регистры, ставить точки останова, запускать-тормозить, и т.п. Это был самый жесткий гемор. Сейчас тестируем. - на базе TCLXDS сейчас делается сервер отладки. Чтобы он коннектился к таргету (включая мультипроцессорные конфигурации) и позволял другому софту, в т.ч. IAR, общаться с любым из ядер из жтаг цепочки (включая CCS - чтобы он мог работать с DSP-ядрами параллельно и одновременно с чем-то другим, работающим с ARM-ядрами). - ну и последний штрих - сделать IARу клиента, который бы мог общаться с заданным ядром из тех, к которому приконнекчен сервер. Это самое простое из всего. результат видится каким-то таким - на TCL пишется конфигурация JTAG-цепочки, описывается список ядер, JTAG-маршрутизаторов, и прочей хрени в JTAG=цепочки, а также параметры эмуляции, интерфейса, и т.д. Далее кто-то стартует этот сервер, или сам руками, или IAR. В конфигурации IAR останется выбрать только то, к чему конкретно коннектиться. Но пока все это еще только представляется, как будет. Мультипроцессорность-мультиядерность и параллельная отладка DSP-ядер в CCS очень много всяких нюансов вносит.

Я совершенно не представляю себе, как с ним из-под C# общаться, и что это за C# имею только слабое теоретическое познание, что это что-то типа явы, только микрософтовское. Однако, если из-под C# можно выполнить другую программу с передачей ей параметров, и получить от нее код возврата, то все сделается без каких либо проблем. На языке TCL можно написать скрипт, который прочитает бинарный файл, приконнектится к плате, и загрузит его туда. И далее, если это физически возможно, то из C# надо будет запустить этот скрипт, который и выполнит задачу. Также в библиотеке имеется готовая функция по загрузке в память процессора COFF-файла (.out, то, что композер делает, когда линкует программу) - она сама написана на TCL, так что ее можно посмотреть, как она устроена.

Можно, если имеется такой софт для эмулятора, через который Вы работаете (например как TCLXDS под наши эмуляторы). Если работаете через "набортный" эмулятор, то, насколько мне известно, такого софта нет. Нельзя. Да, готовиться надо. Но проще и полезнее выкинуть глючную виндовс 7, отдав ее бухгалтерам и игроманам, и забыв как страшный сон, и спокойно работать в старом добром CCS3.3 под XP. Либо открутить часы компа назад, CCS будет думать, что еще триальный период.

Для вашей задачи громоздкая FPGA совсем не нужна. Ее решит мелкая простая FPGA. А вот DSP точно нужен громоздкий.

Уточнил вопрос. При оплате по безналу (через банк) физлицам продадут.

сорри, беру таймаут, вопрос оказался неожиданным. я не знал о такой проблеме.

А зачем использовать для 28335 либу Flash28235_API_V210.lib ? Возьмите Flash28335_API_V210.lib и все ошибки уйдут. Либы Flash28235_API_V210.lib , скомпилированной с FPU32, не было, нет, и не будет, потому что ее быть не может - в 28235 нет FPU. За что на специалистов TI наехали то? Сами сначала попробуйте что нибудь с FPU32 на 235-ом запустить, прежде чем ругаться.

Все верно, только еще адаптивный клок включить эмулятору.

Если работаете с симулятором, то он виртуальный. Если с эмулятором и реальной железякой, то он доступен только через JTAG, через подсистему реалтайм-анализа процессора, если нужно считать что-то в программе самому, то юзать надо таймер.

техасцы такого не пишут. Техасцы пишут - http://processors.wiki.ti.com/index.php/XD...supported.C2.A0 это кроме скорости, и, пожалуй, там не весь список. А касаемо SAUFlash - это уже мы не поддерживаем XDS100 в нем, а не техас. нет. Я имею в виду TCL скрипты. SAUFlash это продукт не техаса, а наш: http://sauris.de/index.php?page=articles&a...d=1&lang=ru http://electronix.ru/forum/index.php?act=A...st&id=50556

SAUFlash не надо скачивать, он сам устанавливается вместе с драйверами для эмулятора SAU510. С XDS100v2 действительно проблематично сделать программирование флеш через JTAG, это эмулятор скорее для ознакомления, а не для работы. А вот на базе SAUFlash например (при работе через SAU510) - без проблем, и мы как техподдержка в этом поможем. А алгоритм записи во флеш через JTAG прост как валенок - грузим через JTAG в процессор программу, пишущую во флеш буфер данных, затем ставим точку останова на промежуточном месте этой программы, где она принимает данные и команды. Далее через JTAG передаем в память проца данные для зашивки и комнаду программе "зашить буфер туда то". Далее запускаем программу на выполнение, она шьет и затем опять останавливается по точке останова. Как она остановилась - считываем через JTAG из памяти статус - ОК или ошибка. И все это делается на языке скриптов. В общем - примерно день-два работы, и зашивка любой памяти для любого проца готова.

Можно и совсем не сложно. Ядро записывается любым программатором флеш - оно просто бинарный файл. Файловую систему же придется преобразовать в образ, и тоже шить программатором флеш-памяти.

Flash API и имеем. Например для 281x вот - http://www.ti.com/tool/sprc125 для других разновидностей - другие пакеты

Если используется xds100v2 в виде SAU100-USB - то можем официально поддержать (где-то в течение недели выпустить драйвер), если в этом есть интерес.

Ведь только что писал в соседней теме - за то, что его следующая версия называется DM8168 и по пинам совместима.

Именно об этом и речь. В процессе загрузки биос материнской платы раздает ВСЕМ PCI-устройствам адреса, которые гарантировано доступны. Поэтому, если адрес, который навязывается системе из драйвера (допустим 0x340), физически не доступен, то нужно остаться на том адресе, который выдал BIOS. Это гарантия того, что данный адрес будет доступен. Посмотреть эти адреса можно в выводе биоса при загрузке - он всегда выдает таблицу, каким устройствам PCI выданы какие адреса. А вот дальше - если сам драйвер не имеет возможности работы с адресами, присвоенными устройству из БИОСа, то есть путь - пропатчить драйвер, вписав в него нужные адреса жестко. Хакерство, а что делать? Не материнку же менять. Насчет того, что драйвер перенаправляет куда-то вывод, это сильно сомнительно, это очень тромозной метод. Корректный путь посадить PCI-устройство на заданный адрес в Windows - обработать в драйвере IRP_MN_FILTER_RESOURCE_REQUIREMENTS, задав там желаемые варианты выделения ресурсов шины. При этом, если драйвер шины это разрешает, он выделяет "заказанный" адрес устройству и прописывает это ему в BAR, таким образом переставляя девайс с адреса, присвоенного биосом, на адрес, предложенный драйвером. Однако на части материнок, и тут видимо этот случай, этот механизм не работает, так как нижняя часть адресов физически закрыта от PCI шины. Тогда остается то, что абзацем выше я написал - остаться на адресе, выданном биосом, и драйвер подправить так, чтобы он вместо стандартных 0x340 обращался туда.

Смотря куда. Если про СНГ, а именно Москва, Питер, Минск, Киев - то со склада сразу. Что касается списков совместимости, там бардак вечный. XDS510 совместим со всеми процессорами TI, которые имеют в составе ядра ARM всех разновидностей (7,9,11, Cortex-M3,M4,R4,A7,A8,A9,A15), ядра DSP/DSC всех разновидностей (C2000, C5000, C6000). И не совместим с MSP430.

Это если и можно поправить, то в эмуляторе, а не в биосе. Чтобы он сел не на порт 0x340, а на адрес, выделенный биосом автоматически в процессе "раздачи ресурсов". Если, конечно, эмулятор вообще поддерживает plug-n-play (по спецификации PCI обязан, а уж как оно там...)

XDS510PP безнадежно устарел уже лет 7 назад, когда параллельные порты устаревали. Сейчас актуальны XDS510 или XDS560 с интерфейсом USB, например наш эмулятор SAU510-USB Iso Plus. Если в планах через JTAG гонять большие потоки реалтайм данных в целях отладки - то актуален XDS560.

А вот и кандидаты на релиз. Подчистили еще некие глюки в резете железа эмулятора, и так, по мелочи. http://sauris.de/index.php?page=news&id=24&lang=ru