stremglav

С опозданием в несколько месяцев,.. но удержаться не смог. Задача на самом деле интересная А обсуждение свелось к RS232/485 через USB, но не подключению USB драйвера к MSP USB драйвер без DMA вещь унылая - "плавали знаем". MSP не имеет параллельного порта с DMA, следовательно подключить приличную микросхему не получится. Я пробовал с программной имитацией параллельной шины, повторюсь - "уныло" Задача была решена с применением SPI Однако выбор ИС USB драйверов с SPI не велик, я знаю только одну - устаревшую USBN9603/4 Хотелось бы знать мнение Форума, есть ли у MSP перспектива жить с USB? Новые ИС драйверов с SPI? Может кто знает, есть ли в планах TI встроить интерфейс в MSP?

Каждый раз сообщение "Fuse is blown" оказывалось несколько преувеличенным Пользуюсь TI JTAG под USB & LPT ИАР Помогали обычные виндовые заклинания - закрыть все окна и перегрузить комп

Port u*C*O*S для TMS470 объявлен, как "coming soon". Кто нибудь из участников форума уже портировал ось или ждем Лабросса?

Hi, All! Выигрыш от применения DMA бесспорен, но с оговоркой для чего и как применять. Прошлым летом посадил барышню практикантку, в образовательных целях, протестировать примеры TI с design samle 169-ого. В простейшем случае (перенос области памяти в 256 байт) она получила, дай Бог памяти, 8 кратный выигрыш производительности. Позже я прикрутил связку SPI-DMA для коммуникаций. Выигрыш оказался минимальным из-за коротких посылок по каналу связи. И я сделал свой выбор в пользу прерываний. Однако если понадобится генерить синус собственным DAC-ом и общатся с UART-ом рекомендую DMA. Одного не возьму в толк, как Вы собираетесь прикрутить эмуляцию параллельной шины к DMA каналу MSP? Параллельной, пусть 8 разрядной шины ввода вывода, так не хватает этому процессору. А если еще и c DMA... Или я не все понял из Вашего диалога?

Давно не читал конференцию. Был занят. Как раз делал J*T*A*G на F*T*C*2*2*3*2 в частности для X*i*l*i*n*x и ARM в т.ч. Задача программировать и тестировать средствами BSDL. ЗА основу брал широко известный OpenSource проект N*A*X*JP. Супербезоны должны знать, он только недавно закрылся. Сделал. Работает с CPLD до проверки с АРМ не дошел ход. Пришлось срочно бросаться спасать другую тему. Так что могу сменить NIC на "NEDODEL" Делюсь опытом. ------------------- 1. От DLL F*T*D*I для JTAG пришлось отказаться. Начал ковырять и задавать вопросы - служба поддержки, в лице некого Гордона Лунна, начала слать исправленные версии DLL без замены на сайте. Через некоторое время сдалась и задрала лапки к верху и созналась, что DLL просто пример написанный на Visual Васике. -------------------- 2. Написал используя микрокоманды FTC Работает медленнее, чем с LPT. Ожидать приходимся 2 мС, минимум, данные на чтение - быстрее не может драйвер. А это связано с типом потока BULK выбранным фирмой для микросхемы. Писать вынужден пакетами по 32 бита - формат регистра назначения, а так же SVF и JEDEC форматов файлов данных. FTC не имеет возможности исполнения "холостых" тактов, поэтому задержки 100 мкС и пр., по требованию алгоритма программирования, остаются на совести ПО. При этом остается вероятность гонки пакетов, и как результат, поломка TAP. -------------------- 3. На шине USB1.1 загрузка интерфейса получается неравномерная. Победить этого так и не смог. Загрузка шины USB2 более равномерна, где то 30% Появилась возможность одновремменого запуска нескольких копий программы (для меня это имеет значение) -------------------- 4. Время прошивки XC9572 на шине USB1 ~60 секунд, USB2 16 секунд. CPLD LV шьются раза в 4 быстрее. Для нужд boundary scan , считаю, таких скоростей не достаточно. Позже буду делать JTAG с микроконтроллером. Чтобы TAP и задержки делать на уровне firmware. Кстати, прирост производительности такого решения по сравнению с 115200 СОМ-ом, даже без применнеия DMA со стороны MPU, от 4 до 8 крат. Зависит от длины пакета конечно же. "Проверено электроникой" -------------------- 5. Самый шустрый драйвер, какой я тестировал - J*U*N*G*O. Этот смарт алик умудряется даже по шине 1.1 до 9 запросов в миллисекунду делать на убогом селероне 700-м (моя тестовая лошадка) ------------------------- Резюме. ------------------ F*T*D*I дает добротное решение для виртуального COM-а. Я, лично всю контору обвесил виртуальными комами, счет уже за 200 шт. скоро пойдет. Очень благодарен им за это. Все остальные решения только для тех, кого устраивает какой-то результат. Главное что бы быстро получить этот результат. Желаю всем удачи!

Может быть и не только. Я поиграл с FT245. Тонкость в том что в режиме bit-bang он хорошо работает на запись, но не ча чтение. Если нужно программировать через JTAG или serial slave, то все хорошо. В буффер пишутся последовательные состояния ножек и посылается в USB пакете. А если надо читать TDO, то надо делать отдельный пакет на каждый такт. Так что для верификации не очень эффективно - медленнее чем через LPT. Легко себе представить что в ПЛИСину упихали всю логику JTAG и все биты идут параллелено. Я бы для этого поставил маленький контроллер - PIC или AVR, но можно и как у них, если охота ради десятка нужных ножек ставить чип с сотнями ног. <{POST_SNAPBACK}> Совершенно верно, "те только"... VHDL XC9536 файл приводится http://www.nahitech.com/jtag-en/nusb/nusb.html

У меня вопросы к матерым uC/OS-программистам: "Кто каким способом решает задачу организации потока STDIO?" К примеру, можно отправлять/принимать сообщения из putch()/в в getch() из/в UART. При этом ресурс UART разделяется с помощью мютекса, естественно. А вот для USB обмен по одному байту смотрится не очень привлекательно. Организация же пакетного обмена требует подхода. Например можно использовать sprintf и отправлять сообщение драйверу. Или же реализовать механизм накопления информации в пакеты по признаку заполнения или <CR>, и только потом передавать сообщение драйверу USB. "В uC/GUI есть что поизучать по существу первого вопроса?" Каюсь, документацию на ГУИ не читал, потому что не имею.

И тем не менее - не работает: а) читай выше почему б) проверено экспериментально (как и обещал) KiV, есть варианты. Можно отступить от стандарта и разделить сигналы TDI и TDO, остальные - общие. Проверил, работает. На сем тему предлагаю закрыть

В OMAP-е они сделали DSP и ARM в цепочке, что естественно. Возможно это свойство не распостраняется на MSP. Вероятнее всего его делала другая команда. Этот вопрос можно будет задать в службу технической поддержки TI

Ранее упомянутый CS8900A-IQ имеет индустриальный диапазон рабочих температур (-40С...+85С)

Я проведу такой эксперимент, как и обещал. Но судя по всему результат будет отрицательный, т.к. упомянутых Вами настоек у C-Spy для MSP430FET-UIF не обнаружено (2.44а). TI CCS поддерживает мультипроцессорную отладку. Можно ожидать, что эти возможности заложены в ядро MSP и со временем появятся драйвера для мультипроцессорной отладки. Можно и не дождаться... Мня же вполне устроит, если можно будет запускать отдельные копии C-Spy и он сможет различать отдельные USB устройства.

Извольте. Сами попросили. В моем случае был девайс с тремя MSP, каждый из которых сидел на гальванически развязанной земле. Поэтому объединить JTAG MSP мне не довелось. Думаю, вам проще это проверить, просто соедините JTAG MSP c JTAG Xilinx, если нет проблем с уровнями сигналов. Что все тулзы будут работать вероятность существенно отлична от нуля. Вот только цмыкать LPT каждый раз чревато повреждениями кабеля, порта, отладчика. Не уверен, что C-Spy поддерживает boundary scan или может работать более чем с одним target, или хотябы давать выбрать. Скорее всего ответ будет отрицательный. Хотя мысль интересная, надо будет проверить. В упомянутом случае для отладки на одном ПК был спаян на коленках JTAG-LPT с гальванической развязкой со стороны микроконтроллера. С другой стороны был USB FET. Для каждого микроконтроллера запускалась отдельная копия EW. Третий микроконтроллер висел на нотебуке с LPT-JTAG Если и буду когда ковырять USB FET, в первую очередь сделаю его с гальванической развязкой. В моей практике такие требования имеют место быть. Кстати о Xilinx. Multilinx с USB - яркий пример, как не надо делать такие устройства. Он питается от target и кидает данные по одному байту в кадре USB. Другими словами работает медленно и еще исчезает при каждом отключении питания.

Интересно, как много участников форума остановили свой выбор на этой ОС, и для каких MPU? К примеру я имею опыт приенения OS для MSP430, х186

Позиционные обозначения соответствуют slau138a PS Под термином "содрал" я имел ввиду схемку нарисованную в OrCADе (может кто схватится развести для сообщества) soft.rar

Дешевый вариант это LPT. И спаять можно на коленках. USB более быстрый вариант, возможность отладки системы из нескольких процессоров (давече их было три). Сдераю не для продажи, а для того что бы дать возможность работать коллегам по КБ, обеспечить возможность ремонта в т.ч. и фирменного. Передать N штук в производственное подразделение для технологических операций по завершению ОКР. Завтра выложу