Косяки VisualDSP Печать
Добавил(а) microsin   

Общее впечатление от VisualDSP++ 5.0: убогая недоработанность (в терминологии Луркмор просто УГ). Стиль среды, поведение и даже внешний вид очень похожи на AVR Studio 4.12. Среда 100% разрабатывалась на том же движке, и наверное теми же программистами. Так же глючит с подсветкой комментариев, так же запускается со свернутыми окнами модулей кода, такой же кривой докинг окошек, и так же норовит упасть при удобном случае. Вклячили только поддержку рабочего пространства, в которое можно добавить несколько проектов (этого в AVR Studio не было) - но лучше бы и не делали. Упрекнуть AVR Studio в косяках нельзя - дареному коню в зубы не смотрят, AVR Studio бесплатна. Но что же нам хотят подсунуть за деньги?..

[Управление конфигурацией проекта]

Полное отсутствие такого понятия, как переменные аргументов (Argument variables), что есть в IAR [1] (и не только в IAR, во всех уважающих себя IDE: Visual Studio, Eclipse и т. п.). В результате в конфигурации приходится в некоторых местах указывать полные пути до файлов, что неудобно при переносе проекта из одной папки в другую.

Если у Вас в рабочем пространстве имеется несколько проектов, то при переключении конфигурации активного проекта (например, с Debug на Release или наоборот) у всех проектов скопом также переключаются конфигурации, хотя Вы этого вовсе не хотели.

Также есть глюк с некачественной работой переключения конфигураций проекта: некоторые настройки проекта не зависят от выбранной конфигурации, и их приходится постоянно переключать вручную. Т. е. надо поменять конфигурацию, а потом еще и поменять настройки проекта. Очевидно, что косяк появился, когда неудачно попытались встроить в среду сложную систему опций и поддержку рабочего пространства.

[Редактор кода]

В редакторе невозможно перейти к определению или декларации переменной (goto definition отсутствует как класс). Вы знаете о том, что вроде должны быть удобные вещи типа Autocomplete, переименования переменных, контекстных подсказок по синтаксису функций, свертки блоков кода в редакторе? Забудьте!

Неудобно организован поиск по файлам и папкам проекта. К тому же диалог поиска строки по файлам (меню Edit -> Find in Files...) не позволяет ввести больше чем 28 символов.

VisualDSP find in files

Причем если выделить искомую строку, и воспользоваться функцией поиска по файлам, то вся выделяемая строка вставится в поле "Find what:", даже если она больше 28 символов, и поиск будет работать нормально по всей этой строке. Но вручную такую строку ввести нельзя.

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

Нельзя закомментировать / раскомментировать выделенный блок кода, приходится комментировать каждую строку вручную.

Глюк с комментариями вида /*  */ перекочевал без изменений из AVR Studio. Когда Вы ставите в коде закрывающие символы комментарии */, и при этом не видны на экране открывающие символы комментария, то закомментированный код не подсвечивается зеленым цветом. Раскраска такого комментария включается только тогда, когда код будет прокручен вверх до открывающих символов комментария /*.

В окне сообщений сборки (Output Window, закладка Build) не корректно обрабатываются сообщения об ошибках, где содержатся длинные имена файлов с пробелами. Например, в случае ошибки повторения декларации типа, когда указан путь до файла с пробелами (типа "C:\Program Files (x86)\Analog Devices\VisualDSP 5.0\Blackfin\include\services_types.h"), двойной щелчок по строке ошибки приведет к сообщению "Access to C:\Program Files was denied", что совершенно не связано с действительностью (по идее путь с папкой Program Files (x86) должен обработаться корректно, и в редакторе кода должен отобразится файл services_types.h в том месте, где задублировано определение типа).

[Отладка]

1. Нельзя настроить отладку через OpenOCD и дешевые JTAG-адаптеры. Не-не, покупайте только фирменные от Analog Devices.

2. Большие претензии к качеству процесса отладки, если сравнивать, к примеру, отладку ARM в среде IAR. В VisualDSP при отладке нет простого способа перезапустить программу без её повторной компиляции и загрузки (F7), что занимает драгоценное время (загрузка происходит довольно долго).

3. Невозможно запустить программу, которая остановилась на точке останова, если не снять эту точку останова. Поэтому, если эта точка останова нужна, то приходится вручную на каждой точке останова снимать её, ставить точку останова ниже, снова восстанавливать точку останова выше, и только после этого снова запускать код.

4. Пошаговая отладка работает очень медленно. Особенно это заметно, когда в окнах Expressions (просмотр выбранных переменных, что в других системах программирования называется окном Watch) или Locals (просмотр локальных переменных) открыто много данных.

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

6. Когда включена оптимизация выбором конфигурации Release, то по умолчанию принципиально невозможна отладка по исходному коду проекта.

7. Окно Expressions глючит, когда в ней открыта локальная переменная, которая имеет разный тип в разных функциях. Тип не меняется на лету, и и структура переменной не обновляется. Чтобы решить проблему, приходится удалять переменную из списка Expressions и добавлять её снова.

8. Еще один неприятный глюк Expressions: при просмотре массивов формат отображения значений может случайно меняться. Например, если выбран тип отображения Hexadecimal, то в списке значений массива могут отображаться значения в формате Unsigned Integer, и наоборот.

[Сборка проекта]

Иногда совершенно неожиданно появляются ошибки линкера [Error li1021] в модулях с расширением *.c, если в проекте также есть модули с расширением *.cpp. Ошибку можно обойти, если поменять расширение у модуля с *.c на *.cpp.

Через контекстное меню каждого модуля проекта можно задать для каждого модуля индивидуальные настройки компиляции (File Options...). У тех модулей, которых применены индивидуальные настройки, отличающиеся от глобальных настроек проекта, на иконке файла стоит восклицательный знак. Тут все хорошо. Но... большое неудобство в том, что для всех файлов в папке проекта нельзя применить или убрать отдельные опции компиляции (в контекстном меню папки проекта нет пункта Options...), как это можно делать, к примеру, в IAR. В результате при поиске ошибки приходится менять свойства каждого файла по одному, что приводит к большим непроизводительным затратам рабочего времени.

То же самое относится и к группе модулей - их можно выделить несколько штук с использованием удержания клавиш Shift или Enter, что хорошо и правильно, но в контекстном меню выделенной группы файлов нет пункта Options...

UPD151019. Генерация двоичного кода может происходить по разному, в зависимости от каких-то совершенно неведомых факторов. Представьте ситуацию: на одной рабочей станции (Windows 7 32 бита) проект VisualDSP++ 5.0 компилируется по-другому, чем на другой рабочей станции (Windows 7 64 бита). Т. е. содержимое выходных LDR-файлов отличается как по размеру, так и по содержимому. Проект тупо копировался с одной рабочей станции на другую целиком (все папка проекта вместе с файлами проекта и всеми модулями исходного кода). Мы дошли даже до того, что побайтно сравнили содержимое каталогов установки VisualDSP на обоих рабочих станциях. Различий между ними никаких нет, но проект компилируется по-разному! В причине так и не разобрались.

UPD190604. Неприятный косяк, связанный с автоматическим определением ревизии процессора. Если проект у Вас имеет настройку Revision -> Automatic, и Вы работаете в VisualDSP с несколькими проектами, то будьте готовы к неожиданным неприятностям. Проблема заключается в том, что когда запускается сессия отладчика JTAG в любом проекте, где выставлена опция Revision -> Automatic, то среда считывает версию кристалла процессора и запоминает её. И... молча применяет эту версию процессора ко всем (всем! Почему так сделали?..) проектам, у которых также стоит опция Revision -> Automatic, которые Вы компилируете при отсутствии подключения через JTAG к процессору.

Поэтому если Вы привыкли при рефакторинге кода использовать двоичное сравнение выходных файлов - старого и нового, то в один прекрасный день неожиданно обнаружите, что файлы не совпадают, хотя в исходном коде никаких изменений не было. Бороться с этим побочным эффектом можно только одним способом - выбрать в опции Revision любой другой вариант, кроме Automatic - none, 0.0, 0.1, .., 0.5, any.

[Ссылки]

1IAR: переменные аргументов (Argument variables).