Доброго всем времени суток!

До недавнего времени я практически не работал с ARM, были некоторые опыты с AT91SAM7S под IAR, вроде бы все получалось, что хотел. Может быть, потому, что до этого работал под IAR и на AVR, и на MSP430. С Keil имел дело только для 8051, есть, конечно, свои особенности, но особых глюков тоже не замечал. Сейчас необходимо сменить платформу на более мощную. Выбрал после анализа этого форума LPC23xx (конкретно сейчас LPC2368), заказал с starterkit.ru соответствующую плату, в качестве среды разработки остановился-таки на Keil, в качестве отладчика взял SkyLink. В новом проекте нужно поднять сетку, SD, USB, поэтому решил взять таки RTX и плагины к ней от того же Keil. Ранее с операционками экспериментировал только под scmRTOS. В итоге сижу уже несколько дней и ловлю глюки. Непонятно почему, но простое копирование проекта из одного каталога в другой приводит к неработоспособности проекта. Я уже и не знаю, что думать. В оригинальном каталоге пример работает, после переноса - нет. Такое впечатление, что Keil не сохраняет настройки проекта или же вообще их коверкает, в настройках uVision никаких отличий визуально не вижу, но не работает. Все пути прописаны верно. В итоге для того, чтобы работало, лезу в файл uv2 и меняю руками все. Только тогда есть шансы, что заработает. В примере http_demo не работала DHCP, я уж все перепробовал, в итоге заметил, что там флаг таймера не сбрасывается, начал сбрасывать - заработало. Неправильный пример сознательно выложили? Сейчас пытаюсь заставить работать UART, изменил пример для работы под UART0 - не работает, вернул все назад - снова не работает, но я побожиться готов, что ничего кроме 10 строк инициализации ничего не менял, закомментировал-раскомментировал - и все Постоянно замечаю, что после запуска uVision настройки в проекте могут быть вообще от фонаря. Это диверсия? Помимо всего прочего постоянно сталкиваюсь с отпаданием SkyLink, под AVR JTAG так конкретно никогда не подводил.
Что я делаю не так? Может, кто-то сталкивался? Пока что от Keil для ARM одни негативные эмоции, за такое же время год назад я под IAR и USB поднял, и получил продукт функционирующий, сейчас же вообще шаг вперед, два назад.

Помогите, пожалуйста, советом! Есть уже желание бросить его нафиг и делать под IAR. Но тогда отладчик придется покупать другой

Юзал кеил два года, пока он меня окончательно не задолбал своими глюками. Неадекват вполне похожий наблюдался, как один и тот же проект под одной и той же версией кейла на домашней машине компилируется, на ноуте нет. При этом все системные пути одинаковы, все идентично. А как он компилирует - это вообще песня раненого программиста... Почему программа не работает, оказывается компилятор решил, что вот этот кусок совершенно лишний, и просто выкинул его, и это при ноль-уровне оптимизации. При включенной оптимизации многие программы вообще не работают как надо, в т.ч. почти все атмеловские примеры. В общем, совет такой - бросай кейл, ибо дальше будет хуже. Отладчик возьми JetSeven в стартерките, стоит копейки. Под яром все значительно стабильнее и быстрее. Единственное, в чем потеряешь - не будет блатного дебаггера, где в удобном виде можно просматривать состояние периферии (не всей, правда), но привыкнешь.

Удачи, коллега!

И что при этом говорит?


Как программа написана, так и компилируется. А атмеловские примеры сплошь написаны через %опу.
Компилятор RVCT абсолютно адекватен. Единственный минус (и то сомнительный) - неполная совместимость с C99.

Давно это было. Если не изменяет память - ругался на якобы несуществующую функцию или дефайн. Я еще тогда специально сравнил проекты побайтно, и папку с проклятым кейлом тоже... Надо было скриншоты сделать для истории маразмов.
Компилятор RVCT абсолютно неадекватен. Как программа написана, так и компилируется - что ж, верное утверждение, только вот незадача, отлично компилируется и работает под Яр и компилируется но не работает под RVCT, предмет разбора - файловая система FAT32, а также код, содержащий интенсивные вычисления с плавающей точкой.
Возможно все эти приколы могут быть связаны с вылеченной версией кейла, всяко бывает...

Просто IAR прощает некоторые ошибки, только и всего. С плавучкой - могли быть стеки не выровнены, например.

Про глючность среды Keil рассуждать не берусь, но RVCT и его предшественниками пользуюсь еще со времен ADS 1.1 - никаких проблем замечено не было.

У меня в Keil очень часто зависает самодельный MT-Link примерно в одном из 5-8 запусков дебаггера. В IAR еще не разу не зависал, правда пользуюсь я IAR пока гораздо реже.

Нет, это точно не стек, уж не первый день софт разрабатываю. Я все же склоняюсь к мнению, что в кейле есть глюки. Язык один, пусть у каждого компилятора своя специфика, свои расширения, это понятно. Но когда один из них не правильно отрабатывает код, написанный на чистом си, это как минимум удивляет, как максимум - раздражает. Ошибки есть функциональные, есть синтаксические, так вот функциональные выплыли бы у меня и в яре, однако же все работает как часы, стало быть кеил привносит функциональные ошибки на этапе компиляции, что я и наблюдал в некоторых случаях в дизассемблере. Спрашивается - на кой черт тогда компилятор, если его приходится постоянно контролировать, тогда уж лучше писать на асме.

Коллега, а RVCT и RVMDK один компилятор использует? Может мы о разных вещах говорим?

RVCT - это и есть название компилятора, используемого RVMDK.
В стародавние времена Keil включал в себя компилятор CARM. Про него ничего сказать не могу, но опять таки сильно сомневаюсь в "глючности".

Апеллировать к IAR'у не стоит - одна и та же неправильно написанная программа может по разному восприниматься разными компиляторами. Боюсь, без конкретных примеров наша дискуссия не имеет смысла.

Я немного уточню. Подозреваю, что это как-то связано с глючностью RTX. Может ли это быть сделано сознательно? У меня стоит 3.70 со "своего" фтп. Такое впечатление, что после изменения примеров что-то отваливается, потому что вся активность процессов из соответствующей закладки отображается исключительно в RTX_Config.c (100%), в нормально работающем процессе в идле, конечно, проводит большую часть времени, но не 100%. По поводу глюков компилятора ругаться не буду, на 8051 ничего особенного не замечал, тут вопрос скорее в скрытых библиотеках RTX и иже с ней.

Есть стандарт, есть компилятор, который этот стандарт должен соблюдать, и есть программист, который так же должен уметь грамотно писать программы. Одна и та же неправильно написанная программа может по разному восприниматься разными компиляторами - может, но не должна. Компилятор должен выполнять свою работу, он должен скомпилировать программу в соответствии со стандартами, однако на деле мы получаем разный код у яра и кейла, местами абсолютно разный. Возможно у кейла были какие то особые требования к исходному коду, я не знаю. Но зато я хорошо знаю стандарт си, что можно делать и что нельзя, что правильно, что нет, что допускается, что не рекомендуется. И когда я пишу программу в соответствии с этими знаниями, то, как минимум, рассчитываю на то, что компилятор правильно меня поймет, а не будет выбрасывать куски кода. Вот кстати конкретный пример - пустой цикл for, неиспользуемая переменная, которой присваивается значение. В целях отладки иногда нужно и то, и другое, однако кеил это все похерит. Яр исполняет как есть. С точки зрения компилятора, конечно, правильно убрать ненужные фрагменты, но только в том случае, когда его об этом попросят, включив оптимизацию. Это сотая часть зла, есть примеры покруче с полностью неработоспособным фат32. Причем, как показало вскрытие, смерть наступала неожиданно и в разных местах, следует учесть, что периферия MCU при этом используется достаточно интенсивно. Иногда вылет в хард фаулт, иногда вылет програм каунтера черти куда, иногда фриз и ожидание флага готовности ДМА... вечное ожидание. А теперь внимание - тот же код, та же аппаратная библиотека, только под IAR - все работает. Стек и хип тот же. Версия кейла на момент расставания 3.20.

О глюках самой среды я вообще молчу...


А и не должно быть 100%. Диспетчер задач и event pool крутятся всегда.

Я и говорю, что не должно, но там 100%, он просто не запускает задачи вообще.


А что за глюки? Я вот заметил характерное, что он с настройками обращается весьма фривольно, особенно при копировании проекта. Такое впечатление, что он что-то хранит не только в .uv2 и .Opt, но и где-то еще. Постоянно сбрасывает тип контроллера, скорость JTAG, использование RTX.

Хотите сохранить пустой цикл for - используйте его с volatile переменной. Зачем вообще может понадобиться выключать оптимизацию, я не представляю.


Это значит только, что вскрытие ничего не показало - вылетает в разных местах, причины просто не установлены.

Если время позволяет - можно написать свой аналог RTX, сложностей там нет, если имеешь представление как работают ОС. Расширять сможешь как угодно и юзать под любой средой. Практика показывает, что рукописные вещи намного надежнее и в плане гибкости настройки и расширяемости намного лучше чем готовое. Из минусов - время на разработку.



Да, есть такое, еще улинк периодически отваливался. При отладке с точками прерывания невесть что творилось. Старые убранные срабатывают, новые нет...




Да я то знаю, разговор был о том, что творят компиляторы.

Так как отладка во многих случаях может быть затруднена или вовсе невозможна.

Начёрта такая среда разработки, которой надо еще подробное вскрытие проводить? Может мне за него еще машинный код сформировать?

Отладчиком. Ну, понятно все.


Затем, чтобы найти источник проблем. Подход "собрали вот IAR'ом - и все заработало" в корне неверен. Случайно оно заработало.

Я понял, Вы большой поклонник кейла и переубеждать Вас бесполезно. То, что заработало, как Вы говорите, случайно, уже используется в нескольких проектах, где и работает стабильно. А если учесть тот фактор, что и ось и фат работает на разных кристаллах от разных производителей, то мне совсем не верится в такие случайности.

Человек спросил совета, я дал, исходя из опыта, в ответ получаю противостояние и всяческое опровержение третьих лиц. Если Вы такой знаток кейла, почему ни одно из Ваших сообщении не было адресовано автору, ведь вопросы поставлены вполне конкретные? Я не знаю что ему можно сделать в этом случае, поэтому и советую перейти на яр, дабы не мучиться. Может Вы дадите более дельный совет человеку?

Нет, я не большой поклонник Keil'а. Просто я во-первых, очень напрягаюсь, когда слышу словосочетание "глючный компилятор", т.к. в 99% случаев это означает, что человек просто не умеет писать на "C", либо не удосуживается изучить документацию. Во-вторых, крайне настороженно отношусь к любителям внутрисхемной отладки, т.к. неоднократно встречал программы, написанные "из-под отладчика" (выключим оптимизацию - поставим брекпойнты - пройдем в пошаговом режиме - допишем +1).


Где конкретные вопросы? "Ничего не работает, что делать - не знаю". И Ваш опыт, извините, звучит до боли похоже.

Фигня какая-то у Вас.
Системами контроля версий (CVS, SVN и т.п.) пользовались? В таких случаях обычно очень помогает.

На "своём" фтп рядом с компилятором всегда имеются исходные тексты RLARM, так, что о закрытости библиотек разговора быть не может.
Отключайте в свойствах проекта RTX, подключайте исходники....

Где их можно увидеть?


Первый вопрос заключался в опыте работы с RTX, где-то я видел информацию о том, что нелицензионный Keil творит что хочет. Я указал, где его взял, специально для такого случая. Если кто-то работал - то, подозреваю, или сталкивался с этим, или нет. Других вариантов я не вижу. Это раз. Второй вопрос касался проблем с хранением настроек проекта. Ваши советы, извините, вообще никак данной темы не касались. Я сам уже года два работал с Keil, но под 8051, до сих пор с подобным не сталкивался. Не работает конкретно под ARM, потому вопрос именно в этой теме. Тем более, что в форуме информации про RTX практически нет.

А Ваши вопросы, извините, не отличаются точностью формулировок. "Не работает" - это не описание проблемы.

RTX, прямо скажем, не очень популярна, почему Вы решили использовать именно ее при наличии бесплатных и открытых альтернатив?

Ну это уж так выходит не слишком хорошо у меня Состояние сейчас не особо нормальное. Использовать решил потому, что купился на рекламу с сайта кайла, плюс она шла в поставке и имела в составе все, что мне было нужно. Возникла мысль, что интегрировать ее в проект окажется гораздо проще. А что Вы порекомендовали бы?

FreeRTOS, например. Сделать порт для своей платформы можно за вечер.

Сделать порт под Keil можно и из scmRTOS, если уж на то пошло. Но есть ли там модули для сетки, фата, усб?

В качестве сети можно взять LwIP, FAT можно взять от того же Chan'а, работа с USB была где-то среди демок.
Вот только, ИМХО, чем меньше "цельнотянутого" кода, тем лучше. В своих проектах использовал только "голую" FreeRTOS и LwIP, все остальное - FAT, GUI, работа с периферией - самописное.

Для самописного нет времени, буду смотреть в сторону uCOS

Пожалуй, не стану утруждать себя с ответом. Пусть будет по Вашему, мне все равно как Вы думаете.

Polaris, предлагаю сходить на кейловский форум, если все еще есть сомнения какую среду использовать...

Там же, кстати, могут быть ответы на вопросы по поводу RTX.

Был уже там. Очень много неотвеченных вопросов, создается впечатление, что не особо эта операционка хорошо поддерживается. В мануалах с сайта какие-то стародавние функции приводятся, у которых уже формат поменялся, не особо они утруждают себя обновлениями. Пока впечатления из радужных перешли в резко негативные. Единственное, что меня держит у Keil - отладчик. Нужно брать новый, заказывать его, это пара дней будут потеряны.

Вы просто не смотрели, наверное...
...аплоад/МЦс/AРM/Keил/rlarm370.rar
...аплоад/МЦс/AРM/Keил/380/rlarm380.rar

Polaris, какие-то ужасы у Вас. И проект переносил простым копированием, и уарт нормально конфигурится, и настройки проекта не слетают. Кстати, возможно пути к хидерам, например, абсолютные, а не относительные... как вариант. Пользуюсь RV 3.7, но и с предыдущими, и с кейлом под 51, проблем не наблюдалось

VAI, а доступ к аплоуду как осуществить?

Брал как раз оттуда, там же только либы и примеры, исходников самих библиотек нет, они же закрытые


Все бывает, до сих пор 8051 тоже отлично переносился копированием. Но потом возникла необходимость поставить в довесок ARM, так промучался полдня, вместе работать не хотели. Это касается версии 3.24. Скачал и поставил по такой же схеме 3.50 - все заработало. Так что есть там проблемы, вопрос только какие в какой версии. Сейчас у меня стоит 3.70, проблемы с настройками присутствуют.

то есть вместе?

Сейчас изучаю Keil, RTX на MCBSTM32 Evaluation Board проект работал в оригинальной директории примера при переносе проекта в другую директорию задачи TRX не запускались. Причина, как выяснилось. в потере ini файла инициализации дебугера, в котором инициализируется режим отладки STM32.

Есть более удобный вариант:
Option for target > Debug > Initialization File: .... добавить .ini файл, в котором будут пути к исходникам библиотек.
Например:

SET SRC=C:\Keil\ARM\RL\FlashFS\SRC
SET SRC=C:\Keil\ARM\RL\RTX\SRC\CM
SET SRC=C:\Keil\ARM\RL\RTX\SRC\

SET SRC=C:\Keil\ARM\RV31\LIB\ST\STM32F10x

И тогда в отладчике Кеил не "ползает" по ассемблеру, а "бегает" по исходникам. Удобно.

О, вот это дело! Я ж про что и говорил - где-то еще он хранит настройки, не только в opt и uv2! Спасибо большое, буду смотреть!!


два компилятора - 8051+ARM, одна оболочка - uVision. В 3.24 даже при регистрации обоих компиляторов после установки второго первый "слетал", устранить причину не удалось, я уж и последовательности менял установки - не помогало. В 3.50 последовательная установка и регистрация по точно такой же схеме позволили поставить нужную мне систему (есть еще проекты под 8051) с первого раза. Чудеса? Или все-таки глюки?

хм.. сейчас попробовал открыть старый проект под 89с5131... Открылся, скомпилился.
Потом открыл текущий под лпц2103 - открылся, скомпилился, все ОК

Keil RV 3.70

Так: http://electronix.ru/forum/index.php?showforum=89


В посте ssergy указаны пути к исходникам операционки.
Тут проекты:
...\Keil\ARM\RL\RTX\RTX_Lib_ARM.Uv2
...\Keil\ARM\RL\RTX\RTX_Lib_CM.Uv2
А тут исходники:
...\Keil\ARM\RL\RTX\SRC\
Они не закрытые, просто исходники за денюжку продаются, а в скомпиленом виде в МДК АРМ присутствуют.
----
А какие отличия у либ от библиотек?

И у меня тоже А вот 3.24 сильно страдала по этому поводу

интересно... Когда поставил 3.24, доработки в проекте с х51 не производились, прошивал уже скомпиленный hex. Потом поставил 3.40, разрабатывал и арм, и дополнял проект х51
Как раз переставил систему, тортиллу не проставил, копировал проекты в другие места - все ок
Может, действительно, не напоролся на этот глюк в 3.24, а потом его пофиксили?

Все возможно, в том числе и проблемы на моем компьютере, у меня, к примеру, так и не ставится IAR AVR 5.11, хотя уже все что можно проверил, включая все вызываемые dll. Но факт все-таки имел место быть, скачивание и установка 3.50 полностью решили проблему.

Работал с 3.24 некоторое время - не могу с вами согласиться. Прекрасно все компилилось и под ARM и под x51.

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

У меня есть знакомый автоэлектрик. И у него при любой неисправности один ответ --- ШНУРОБИКСЫ... Так он обозначает замыкания и обрывы.
Хочу сказать, что и в Кейле и в ИАРе глюки имеют место всегда. Я думаю, что рассуждения насчет безумной глючности кейла или иара полная ерунда и Вы все таки где-то ошиблись... Насчет примеров. У меня есть отладочная плата от кейла МВС2300. Я ее когда пробовал , загружал разные примеры -- ВСЕ ОНИ РАБОТАЛИ. Сам использовал кейл только для написания загрузчиков. Тоже никаких глюков. Не пользуюсь кейлом только по причине зависания в отладке(лечение плохое). Но вообще-то , если какие-то глюки возникали, то всегда оказывалось, что просто ручки у меня кривые... Так что ИЩИТЕ ошибки.

Если кому-то интересно, то одну из причин странной работы нашел - в разных версиях Keil по-разному оформлены стартапы. К примеру, в моем конкретном случае lpc2300.s для версии 3.70 содержит по умолчанию активированный EMC, с ним приложение виснет на этапе исполнения стартапа. В более ранних версиях такого пункта в визарде не было, соответственно, активным он не был, все работало сразу.
Постепенно, по мере отсутствия более приоритетных задач, осваиваюсь в Keil, особенности свои, конечно есть, но стараюсь решать. Требует, конечно, времени и иного взгляда на вещи.

У меня версия 3.8 с MT-Link еще не разу не зависала при отладке. 3.7 очень часто висла.

У меня 3.70 и SkyLink, при отладке вроде бы не замечал, а вот при загрузке прошивки в контроллер часто происходит обрыв связи, повторная загрузка, как правило, проходит успешно. Попробую 3.80.

Polaris ну да у меня тоже где-то там. Точно не помню толи при программировании толи сразу после, когда уже программа должна стартовать.