Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Кто-нибудь что-нибудь скажет плохого/хорошего о Nucleus ?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
DASM
Вроде симпатичная, в 40 кил уложилась.. UCOS не предлагать вместо.. скучная.
zltigo
Собрали таки?
На что портировали?
Ну а насчет хорошего/плохого - слушаем того, кто собрал :-)

Да, кстати а откуда утащено?
KA_ru
Вроде как FTP есть.
Evgeny_CD
Цитата(DASM @ Mar 28 2006, 22:07) *
Вроде симпатичная, в 40 кил уложилась.. UCOS не предлагать вместо.. скучная.
Это вариант, который с местного ftp?
Интересно, а Ваша оценка - чем она "интереснее" uCOS?
zltigo
Цитата(KA_ru @ Mar 28 2006, 20:49) *
Вроде как FTP есть.

Что-то было, посмотрю когда поднимется, но там судя по форуму не в исходниках и возможно и без
лицензии.
Да и меня больше порт под BF533 интересует на данный момент.
DASM
с FTP... сурцы все на месте и дока pdf 320 страниц. Скормил я это дело ADS1_2. Собственно только скомпилировал, ну и в main пару нужных вызовов сделал, дабы линкер не убил неспользуемый код. Счас буду вектора нормально ставить и шедулер настраивать.
Насчет UCOS несколько причин. Первая - я работал с их UCOS GUI - плююсь до сих пор. Не думаю, что фирма делающая подобное Г сделала хорошую ось. 2) на UCOS тут народу много сидит - совершенно неинтересно быть "одним из" 3) Политика приоритетов в UCOS мне не нравится, нельзя поиметь две задачи с одним приоритетом (во всяком случае так было раньше) 4) Кушает она не слишком много и не дает повода клянчить у начальника установку более мощного проца disco.gif disco.gif
Evgeny_CD
Цитата(DASM @ Mar 28 2006, 23:08) *
Первая - я работал с их UCOS GUI - плююсь до сих пор. Не думаю, что фирма делающая подобное Г сделала хорошую ось.
Стратегическая ошибка! uCOS писал основатель микриума, GUI они у кого-то купили. Стиль написания совершенно разный.

Может, у Вас гуй древний был??? Мы с ним осенью 2003 работали - ничего так штука, программеры не плавались особо (но все низкоуровневые процедуры переписали нафиг, что ускорило гуй раз в 20 - платформа AT91RM9200 + SED какой-то на внешней шине)
Цитата(DASM @ Mar 28 2006, 23:08) *
2) на UCOS тут народу много сидит - совершенно неинтересно быть "одним из"
Вот уж натурально disco.gif disco.gif disco.gif жаль, смайлика с малиновым пиджаком нет.
zltigo
Цитата(DASM @ Mar 28 2006, 21:08) *
Не думаю, что фирма делающая подобное Г сделала хорошую ось.

Я много лет назад с uCOS столкнулся - фирмой тогда там и не пахло. Больше всего было похоже
на студенческий курсовик главной "изюминкой" которого автор считал быстрое табличное получение
максимально приоритетной задачи. C тех пор этот заплесневелый изюм там и лежит :-(
А какие исходники там были, особенно комментарии - типа я тут добавил к указателю стека
+4 и заработало незнамо почему :-) А тексты асмовские x86 порта это вообще полный улет.
C теx пор, конечно много чего изменилось, заматерело, обросло прибамбасами, книжками и стало
"делом жизни" Автора, но мое отношение осталость.
DASM
во-во, примерно такое же мнение и у меня сложилось =) А народ то и не знает :-D Вобщем ну её в баню =))
Evgeny_CD
А слабо взрослое тестироваие устроить?

Берем код Dhrystone, и делаем из него задачу. Считаем производительность. Пускам несколько задач с этим кодом, и считаем суммарную производительность всех потоков. Строим таблицу - "юзеровская производительность" от числа потоков. Далее по возрастающей - пускаем loop back на UART на максимульную скорость, и строим тот же график. Потом добавляем SPI, например, передающий байты "в космос". Постепенно активируем все прерыания. Продолжаем строить таблицу.

И так для обоих осей - uCOS и Nucleus.

Также при необломе меряем реакцию на прерывание, и дисперсию латентности.

И сразу все будет видно. А то все о малиновых пиджаках разговор.
DASM
не Евгений, Вы рассуждаете как ребенок, чесс слово. Готов спорить что обе обозначенные операционки по скорости уделает моя самописная каруселька :-D Только вот можно ли её считать осью :-D Или давайте поррасуждаем о выделении пулов памяти, насколько хорошо эти операционки с фрагментацией борятся... или еще куча других факторов.. А Вам только "кто быстрее задачку переключит" :-)))
Evgeny_CD
Цитата(DASM @ Mar 29 2006, 01:02) *
Готов спорить что обе обозначенные операционки по скорости уделает моя самописная каруселька :-D Только вот можно ли её считать осью :-D Или давайте поррасуждаем о выделении пулов памяти, насколько хорошо эти операционки с фрагментацией борятся... или еще куча других факторов.. А Вам только "кто быстрее задачку переключит" :-)))
Я всего лишь идею предложил. Разумеется, не окончательную. Да, есть много других вещей - но, уверяю Вас, даже в таком относительно простом тестировании найдете много интересного. Просто все навороты - это хорошо, их никто не отменял (я же не предлагаю с биг лупом сравнивать), но интересно, как ОСь с первичной задачей справляется.

Если сделаете более полное тестировние - будет супер!
Цитата(DASM @ Mar 29 2006, 01:02) *
не Евгений, Вы рассуждаете как ребенок, чесс слово.
Ну не знаю. По крайней мере у меня нет желания "лишь бы выделиться".
DASM
в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах. Лицензионные вопросы пока не интересуют. От UCOS воротит в частности из-за обилия макросов - код практически нечитаемый. Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот. У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её
Evgeny_CD
Цитата(DASM @ Mar 29 2006, 01:22) *
в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах. Лицензионные вопросы пока не интересуют. От UCOS воротит в частности из-за обилия макросов - код практически нечитаемый. Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот. У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её
Устремления понятные, и лично для меня, сильно интересные. Понятно, что что-то определенное Вы скажете после первого проекта. Никто же не говорит, что Вы к утру отчет напишите smile.gif
KA_ru
добавлю про всякие фишечки в Nucleus
поддержка разных железок там богаче.
Evgeny_CD
Цитата(KA_ru @ Mar 29 2006, 10:11) *
добавлю про всякие фишечки в Nucleus
поддержка разных железок там богаче.
В смысле - бывают дрова под железо?


Цитата(DASM @ Mar 28 2006, 22:07) *
Вроде симпатичная, в 40 кил уложилась..
А сколько RAM скушала? По коду близка к eCos - может, ее [eCos] и имеет смысл ковырять? Но RAM eCos надо немало - 32к самый минимум, 64к - практический минимум. + eCos:
* лицензия правильная
* виртуальные вектора (точки входа) - так что GPL Вас не колышит, Ваш бинарник может быть слинкован отдельно, и Вы не обязаны код раскрывать
* IP, FS - все есть изначально
* вполне нормальная по системны возможностям, ближе к "большим" осям, чем к "таск свитчерам"
* синтетческий порт на Linux - можно отлаживать логику без железа.

В какие камни планируете Nucleus засунуть?
DASM
самой оси надо 1.5 кило рама. Работаю с LPC2148
zltigo
Цитата(DASM @ Mar 28 2006, 23:22) *
в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах.
...
Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот.
...
У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её

Ну лично я от FreeRTOS отплясывать начал. Правда покромсал уже заметно :-(.
Сейчас до 4.00 доросла, добавлены (даже не знаю как назвать, ибо термин Автора "co-routines" явно избит и навевает другие ассоциации) "недозадачи". Kак раз под маленькие с ограниченными ресурсами. В принципе я такое руками обычно пишу, но сама идея стандартизации интересна. Кстати, я посылал Вам когда-то для разборок с MT-Link проектик, так он на практически еще не изменненой FreeRTOS.

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

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


Цитата(DASM @ Mar 28 2006, 23:22) *
в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах.
...
Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот.
...
У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её

Ну лично я от FreeRTOS отплясывать начал. Правда покромсал уже заметно :-(.
Сейчас до 4.00 доросла, добавлены (даже не знаю как назвать, ибо термин Автора "co-routines" явно избит и навевает другие ассоциации) "недозадачи". Kак раз под маленькие с ограниченными ресурсами. В принципе я такое руками обычно пишу, но сама идея стандартизации интересна. Кстати, я посылал Вам когда-то для разборок с MT-Link проектик, так он на практически еще не изменненой FreeRTOS.

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

FTP поднимется - скачаю, посмотрю. Если добьетесь более-менее рабочего порта и будет не жалко,
выложите?
Rst7
Цитата(DASM @ Mar 28 2006, 21:08) *
с FTP... сурцы все на месте и дока pdf 320 страниц.


Так а все-же можно ссылочку?
VAI
Цитата
Так а все-же можно ссылочку?


Доступ только для группы "Свой"
ig_z
Цитата(zltigo @ Mar 28 2006, 22:43) *
главной "изюминкой" которого автор считал быстрое табличное получение
максимально приоритетной задачи. C тех пор этот заплесневелый изюм там и лежит :-(


Имхо на языке "заплесневелой кабернетики" smile.gif это называется двухуровневое восьмиточечное дерево. На каждом уровне которого выполняется линейный поиск. Совершенно очевидно почему восьми и почему линейный. Максимальное время поиска - восемь (семь) сравнений байта на 0 плюс восемь (семь) битовых сдвигов. Имхо вполне разумное и сбалансированное решение.
Во всяком случае в вытесняемых осях соизмеримое время занимает сохранение восстановление контекста.
Скажем, в scmrtos вообще применяется линейный поиск наиболее приоритетной задачи. На сегодня, имхо, наиболее оптимальный вариант. Harry Zhurov большой респект. a14.gif

Что касается нюклеуса, мне довелось работать с портом под вин32. Осталось впечатление излишне тяжелого апи и не совсем оптимального выбора для относительно слабых контроллеров.
Простой пример: пакетный обмен по уарту. Если пакет большой, а фифо маленький , либо вообще отсутствует, что нюклеус, что мюкос - дают огромный оверхед.
Для подобных ситуаций в осекоподобных осах есть два типа прерываний - с вызовом ос апи и без такового. Изящный механизм програмных прерываний использовал и Harry Zhurov в последней версии scmrtos.
Andrew2000
Цитата(Evgeny_CD @ Mar 28 2006, 21:53) *
Интересно, а Ваша оценка - чем она "интереснее" uCOS?

Plus надо сравнивать с eCos - на мой взляд - близнецы-братья.
(вот чего мне не хватает в eCos, так это "partition memory" - выделение памяти блоками фиксированного размера (или плохо искал?), другим видом динамической памяти пользоваться боюсь)


Цитата(DASM @ Mar 28 2006, 22:08) *
... Скормил я это дело ADS1_2. Собственно только скомпилировал, ну и в main пару нужных вызовов сделал, .... Счас буду вектора нормально ставить и шедулер настраивать.

А почему не ASD2.2 ? а чем их среда Nucleus EDGE не устраивает (Eclipse + ADS2.2 + ARMulator, кстати, и демо Plus под Armulator прилагается, без исходников).
И такой вопрос - а зачем main? и что понимается под "шедулер настраивать"? разве там есть настройки времени компиляции?
Andrew2000
Цитата(DASM @ Mar 29 2006, 00:22) *
...У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало)...

smile.gif "каку сделало" и еще какую, и такое впечатление, что специально - в планировщике запрещали прерывание после доступа к глобальной структуре - две строчки поменяли местами.
а что они делают в TCC_Time_Slice (tcc.c) я так и не понял - надо разбираться
(порт под Infineon Tricore)
zltigo
Цитата(ig_z @ Mar 30 2006, 15:29) *
Имхо вполне разумное и сбалансированное решение.

Ага, если кого устраивают все задачи с разными приоритетами, ну и принципиально ограниченное
количество задач. А все остальные должны или "балансировать" уже свои решения, либо переписывать
систему.
dxp
Цитата(zltigo @ Mar 31 2006, 12:58) *
Цитата(ig_z @ Mar 30 2006, 15:29) *

Имхо вполне разумное и сбалансированное решение.

Ага, если кого устраивают все задачи с разными приоритетами

А можно обосновать настоятельную необходимость в задачах с одинаковыми приоритетами? Желательно на примерах.

Цитата(zltigo @ Mar 31 2006, 12:58) *
, ну и принципиально ограниченное
количество задач.

Максимальное количество поддерживаемых задач - не прихоть, а компромисс. Чем больше задач, тем больше накладных расходов для их обработки. И сложность планировщика, как следствие. Здесь и проявляется сбалансированность.

Цитата(zltigo @ Mar 31 2006, 12:58) *
А все остальные должны или "балансировать" уже свои решения, либо переписывать
систему.

Остальные просто должны взять другую ОС, которая их в этой части удовлетворит. И расплатиться за это накладными расходами по памяти и быстродейтсвию. Если целевой процессор это позволяет. Ничего беслатно не быват, вся жизнь - сгусток компромиссов. Сабжевая ОС (и eCOS) просто толще, чем uCOS, и ниши и них немного другие, хотя и пересекающиеся.
zltigo
Цитата(dxp @ Mar 31 2006, 08:37) *
А можно обосновать настоятельную необходимость в задачах с одинаковыми приоритетами? Остальные
...
просто должны взять другую ОС, которая их в этой части удовлетворит. И расплатиться за это
...
Сабжевая ОС (и eCOS) просто толще, чем uCOS, и ниши и них немного другие, хотя и пересекающиеся.

1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять.
2.Что и было сделано.
3.Именно по этой причине я к ней и буду присматриваться, ибо для нижнего уровня выбор сделан
(FreeRTOS) и сейчас выбор, либо по мере необходимости самостоятельно развивать возможности, либо что-то eCOS образное в качестве более можной платформы выбрать. Nucleus пока не вдохновил, но
буду смотреть еще более пристально.
dxp
Цитата(zltigo @ Mar 31 2006, 13:49) *
1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять.

Не помню, что-то. Ссылкой не покажете?
zltigo
Цитата(dxp @ Mar 31 2006, 09:39) *
Не помню, что-то. Ссылкой не покажете?


http://electronix.ru/forum/index.php?showt...698&hl=freertos
Только, действительно, тема оказалась :-( несколько другая - "зачем невытесняющая", но похожая - задачи одного приоритета могут не вытеснять друг друга.
Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить?
dxp
Цитата(zltigo @ Mar 31 2006, 23:38) *
Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить?

Обслуживание железяк занимает все вермя? Или таки не все? Видимо, не все, иначе проц просто не справлялся бы с задачей по параметру быстродействие. Тогда, если производительности хватает, то и распределить работу по событиям и приоритетам. Например, задача обрабатывает пакет данных от оной железяки. Обрабоатала - отдала управление. В следующий раз она получит управление, когда придет очередной пакет. Отдав управление (встав на ожидание семафора), задача ждет, а управление переходит следующей задаче, если для нее есть работа (пришел ее пакет данных, о чем был взведен соотвествующий семафаор). Поскольку обе задачи из класса фоновых, то их приоритетность друг относительно друга практически никакой роли не играет. И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной) ко второй - по окончании обработки пакета, к первой - по приходу ее пакета. И эффектиность распределения тут не хуже, чем схеме карусели. И управление полностью по событиям - т.е. более предсказуемо с точки зрения внешних событий. А планировщик такой (чисто приоиритетный) заметно попроще, чем комбинированный (приоритетно-карусельный), а значит занимающий меньше места (это, в общем, мелочь) и работающий быстрее (а вот это уже не мелочь).
zltigo
Цитата(dxp @ Apr 1 2006, 07:55) *
Например, задача обрабатывает пакет данных от оной железяки.

Может я не написал прямо, что железяки ОДИНАКОВЫЕ, само устройство по количеству таких
железяк масштабируемое, но мне казалось, что это и так понятно. Железки не так, что-бы простые,
но и не чрезмерно сложные.
Цитата
И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной)

Вот именно за такое и боролся - по завершению обслуживания первой железки, если требует
обслуживания вторая... третья... железка-близнец к обслуживанию ее и переходим.
При этом "более приоритетной" здесь явно лишнее. Естественно, что задачи можно делать не комплексные а как Вы предлагаете - ориентированные на железку а ориетнированные на одну из функций железки, а уж с количеством железок путь задача внутри разбирается.... Можно? - МОЖНО! Будет работать - БУДЕТ! Нужет такой подход? - НУЖЕН!, когда комплексная задача начнет превышать
критический предел сложности (для конкретного разработчика?) и разбивка ее на задачи запускаемые под упралением системы принесет пользу.

Стоит, однако провозглашать такой путь практически единственно правильным? Оперируя
постулатами:
Цитата
"И код получается прозрачным и предсказуемым"

"И эффектиность распределения тут не хуже, чем схеме карусели"

"планировщик такой (чисто приоиритетный) заметно попроще"

"а значит занимающий меньше места (это, в общем, мелочь)"

"работающий быстрее (а вот это уже не мелочь)"


Вот тут вынуждет ответить - НЕ ТАК ОДНОЗНАЧНО ВСЕ.
DASM
это все хорошо.. только тот порт на ARM что тут лежит - бредовый.. или у меня бред...кусок очистки BSS сегмента..
INT_BSS_Clear

LDR a2,[pc, #BSS_End_Ptr-.-8] ; Pickup the end of the BSS area
MOV a3,#0 ; Clear value in a3
;
INT_BSS_Clear_Loop

CMP a4,a2 ; Are the start and end equal?
STRCC a3,[a4],#4 ; Clear a word
BCC INT_BSS_Clear_Loop ; If so, continue with BSS сlear
Спрашивается - где тут модификация a4 ? (псевдоимя R3) ?
zltigo
Цитата(DASM @ Apr 1 2006, 12:05) *
это все хорошо.. только тот порт на ARM что тут лежит - бредовый.. или у меня бред...

Дерзайте! Первопроходец Вы наш :-), иначе придется "как все" - без "пиджака".
Сам смогу более-менее заняться сиим делом дней через 10, да и то без особого энтузиазма :-(
Пока код не очень порадовал - достаточно дубовый, видимо вылизаный и естественно портированный на кучу контроллеров... Наверное его стоит покупать и не заморачиваясь пользоватся в готовом виде.
Только рассчитывать на самые легковесные контроллеры (не смотря на упоминание порта на
свежайший микроскопический ARMчик ) я бы уже точно не стал.
А вот стоит-ли практически в одиночку и без особых надежд на то, что в руки попадет 'свежий' исходник с достижениями и правками производителя, его собирать и разбиратся - ВОПРОС!
Суда по количеству дней прошедших с момента первого выступления - успехи скромные?
DASM
ну успехи скромные, так как занимался все время по 20 минут пару раз только. Сегодня поплотнее посижу, думаю в непричесанном виде запущу. Исходники вобшем нормальные - только ассемблерные файлы порта не радуют - явно куча ошибок, причем не логических, а словно "хорошие люди" в некоторых местах нужные строки повыдергивали. Ну да ладно, разберусь. Ну а покупать.... Вначале всеж лучше так поиграть, дорогая эта ось, чтобы вслепую брать.
dxp
Цитата(zltigo @ Apr 1 2006, 14:26) *
Цитата
И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной)

Вот именно за такое и боролся - по завершению обслуживания первой железки, если требует
обслуживания вторая... третья... железка-близнец к обслуживанию ее и переходим.
При этом "более приоритетной" здесь явно лишнее. Естественно, что задачи можно делать не комплексные а как Вы предлагаете - ориентированные на железку а ориетнированные на одну из функций железки, а уж с количеством железок путь задача внутри разбирается.... Можно? - МОЖНО! Будет работать - БУДЕТ! Нужет такой подход? - НУЖЕН!, когда комплексная задача начнет превышать
критический предел сложности (для конкретного разработчика?) и разбивка ее на задачи запускаемые под упралением системы принесет пользу.

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

Цитата(zltigo @ Apr 1 2006, 14:26) *
Вот тут вынуждет ответить - НЕ ТАК ОДНОЗНАЧНО ВСЕ.

Я просто спрашивал, если помните, имеется ли такая уж настоятельная необходимость задачах одинакового приоритета. Пока что вижу, что необходимость в них исходит из личных предпочтений по организации дизайна. smile.gif
zltigo
Цитата(dxp @ Apr 1 2006, 13:26) *
А может тогда вообще незачем на задачи разбивать - пусть одна задача и разбиратся с ними. Накладных расходов на переключение не будет, что есть хорошо. В общем, тут частные подходы к дизайну.

На форуме уже была тема что-то типа "о вреде операционных систем", правда называлась
что-то типа "я написал систему". Но полагаю, что Вы как автор одной из Операционных Систем не об
этом? :-) В программировании, к сожалению, формально возможно почти все - и без системы обойтись и
в прокрустово ложе какой-либо системы уложить... И даже с наружи далеко не всегда внутренние проблемы и компромисы проявляться будут - но я ведь ВНУТРИ сижу и ЗНАЮ.

Цитата
Я просто спрашивал, если помните, имеется ли такая уж настоятельная необходимость задачах одинакового приоритета. Пока что вижу, что необходимость в них исходит из личных предпочтений по организации дизайна. smile.gif

Для меня это является "настоятельной необходимостью", естественно базирующейся на личных предпочтениях в свою очередь базирующихся в том числе и на личном опыте, личных шишках,
личном видении дальнейщего примерения наработанного кода и с учетом личных обстоятельств
связаных в том числе с последующим не личным сопровождением :-).
Короче сплошной субъективизм :-).
DASM
мужики, кончайте спорить, тута Keil глючит нипадецки =( В R13 (SP) ничего писать не хочет в отладке.. млин. Причем только в режиме Supervisor. Как нуль в нем был, так и остается, хоть софт менять его пытается, хоть ручками. В остальным режимах проца - нормально. В IAR тоже нормально. Бред какой-то
zltigo
Цитата(DASM @ Apr 1 2006, 13:58) *
мужики, кончайте спорить, тута Keil глючит нипадецки =( В R13 (SP) ничего писать не хочет в отладке..

Через MT-Link не хочет :-)))))))) Если прекращение спора поможет - готов прекратить.
Ладно - шучу. Я понимаю Кeil из стареньких, либо уже до 3.0.0 допортировались?
DASM
не знаю где у него версии смотреть , после установки вышло KeilARM250a. МТлинк тут явно не причем
zltigo
Цитата(DASM @ Apr 1 2006, 14:10) *
МТлинк тут явно не причем

Я же сказал - ШУЧУ!

То, что у меня в About:

IDE-Version:
µVision3 V3.31
Copyright © Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2006

.....
Tool Version Numbers:
Toolchain Path: d:\MDK\ARM\BIN\
C Compiler: CA.Exe V2.51
Assembler: AA.Exe V2.50
Linker/Locator: LA.Exe V2.51
Librarian: LIBA.Exe V4.26
Hex Converter: OHA.Exe V2.10
CPU DLL: SARM.DLL V1.51
Dialog DLL: DARMP.DLL V1.11e
Target DLL: BIN\AGDIRDI.DLL V1.05a
Dialog DLL: TARMP.DLL V1.10

До этого с Keil-ами дел почти не имел и предисторию изучал только теоретически.
DASM
проапгрейдил на 3.00 - тотже результат. Но я использую компилер от ADS/ Но дело не в нем. Делаю даже так - в IAR простенький тест шью во флеш
main
MRS r2,CPSR ; Pickup current CPSR
BIC r2,r2,#MODE_MASK ; Clear the mode bits
ORR r2,r2,#SUP_MODE ; Set the supervisor mode bits
ORR r2,r2,#LOCKOUT ; Insure IRQ/FIQ interrupts are
; locked out
MSR CPSR_cxsf,r2 ; Setup the new CPSR
mov r2, #-1
MOV sp, R2 // тут в SP должны быть 0xffffffffff
B main
Ну в IAR все работает как и положено. Затем включаю Keil и трассирую,(не компилируя ничего, просто этот уже прошитый асмовый код) - SP (R13) не меняется , остается 0 :-(((
AXD debugger тоже нормально работает. Короче ну эту кейловскую оболочку в болото
Evgeny_CD
Цитата(zltigo @ Apr 1 2006, 14:46) *
Суда по количеству дней прошедших с момента первого выступления - успехи скромные?
А чем должны успехи выражаться? В том что он моргание светиком зхапустил или printf ("Hello, world")? Хочется верить, что DASM заюзает этот nucleus в каком-нибудь реальном (пусть и малотиражном проекте), и доложит всем честному народу, что из этого получилось.
DASM
для начала вообще запустить нада
christy
народ а это вы какую Нуклеус обсуждаете? ядро 1.11.18?
я в свое время посмотрел на нее по-диагонали - вроде хороша, всякие доп модули типа FS,стека протоколов (а сейчас и многие другие вкусные фишечки типa CAN),
но вот беда - заточена под ADS, а я что-то на multi подсел
посему мой выбор threadX - тоже самое, написано тем же самым человеком smile.gif
токо позже и в др конторе
и на arm7 (ат91) завелось с полпинка

ps. а случайно fileX, netX, canX ни у кого не завалялось? smile.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.