Кто-нибудь что-нибудь скажет плохого/хорошего о Nucleus ? Опции

[DASM]

Вроде симпатичная, в 40 кил уложилась.. UCOS не предлагать вместо.. скучная.

[zltigo]

Собрали таки?
На что портировали?
Ну а насчет хорошего/плохого - слушаем того, кто собрал :-)

Да, кстати а откуда утащено?

Сообщение отредактировал zltigo - Mar 28 2006, 18:32

[KA_ru]

Вроде как FTP есть.

[Evgeny_CD]

Вроде симпатичная, в 40 кил уложилась.. UCOS не предлагать вместо.. скучная.

Это вариант, который с местного ftp?
Интересно, а Ваша оценка - чем она "интереснее" uCOS?

[zltigo]

Вроде как FTP есть.

Что-то было, посмотрю когда поднимется, но там судя по форуму не в исходниках и возможно и без
лицензии.
Да и меня больше порт под BF533 интересует на данный момент.

[DASM]

с FTP... сурцы все на месте и дока pdf 320 страниц. Скормил я это дело ADS1_2. Собственно только скомпилировал, ну и в main пару нужных вызовов сделал, дабы линкер не убил неспользуемый код. Счас буду вектора нормально ставить и шедулер настраивать.
Насчет UCOS несколько причин. Первая - я работал с их UCOS GUI - плююсь до сих пор. Не думаю, что фирма делающая подобное Г сделала хорошую ось. 2) на UCOS тут народу много сидит - совершенно неинтересно быть "одним из" 3) Политика приоритетов в UCOS мне не нравится, нельзя поиметь две задачи с одним приоритетом (во всяком случае так было раньше) 4) Кушает она не слишком много и не дает повода клянчить у начальника установку более мощного проца

[Evgeny_CD]

Первая - я работал с их UCOS GUI - плююсь до сих пор. Не думаю, что фирма делающая подобное Г сделала хорошую ось.

Стратегическая ошибка! uCOS писал основатель микриума, GUI они у кого-то купили. Стиль написания совершенно разный.

Может, у Вас гуй древний был??? Мы с ним осенью 2003 работали - ничего так штука, программеры не плавались особо (но все низкоуровневые процедуры переписали нафиг, что ускорило гуй раз в 20 - платформа AT91RM9200 + SED какой-то на внешней шине)

2) на UCOS тут народу много сидит - совершенно неинтересно быть "одним из"

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

[zltigo]

Не думаю, что фирма делающая подобное Г сделала хорошую ось.

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

[DASM]

во-во, примерно такое же мнение и у меня сложилось =) А народ то и не знает :-D Вобщем ну её в баню =))

[Evgeny_CD]

А слабо взрослое тестироваие устроить?

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

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

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

И сразу все будет видно. А то все о малиновых пиджаках разговор.

[DASM]

не Евгений, Вы рассуждаете как ребенок, чесс слово. Готов спорить что обе обозначенные операционки по скорости уделает моя самописная каруселька :-D Только вот можно ли её считать осью :-D Или давайте поррасуждаем о выделении пулов памяти, насколько хорошо эти операционки с фрагментацией борятся... или еще куча других факторов.. А Вам только "кто быстрее задачку переключит" :-)))

[Evgeny_CD]

Готов спорить что обе обозначенные операционки по скорости уделает моя самописная каруселька :-D Только вот можно ли её считать осью :-D Или давайте поррасуждаем о выделении пулов памяти, насколько хорошо эти операционки с фрагментацией борятся... или еще куча других факторов.. А Вам только "кто быстрее задачку переключит" :-)))

Я всего лишь идею предложил. Разумеется, не окончательную. Да, есть много других вещей - но, уверяю Вас, даже в таком относительно простом тестировании найдете много интересного. Просто все навороты - это хорошо, их никто не отменял (я же не предлагаю с биг лупом сравнивать), но интересно, как ОСь с первичной задачей справляется.

Если сделаете более полное тестировние - будет супер!

не Евгений, Вы рассуждаете как ребенок, чесс слово.

Ну не знаю. По крайней мере у меня нет желания "лишь бы выделиться".

[DASM]

в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах. Лицензионные вопросы пока не интересуют. От UCOS воротит в частности из-за обилия макросов - код практически нечитаемый. Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот. У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её

[Evgeny_CD]

в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах. Лицензионные вопросы пока не интересуют. От UCOS воротит в частности из-за обилия макросов - код практически нечитаемый. Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот. У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её

Устремления понятные, и лично для меня, сильно интересные. Понятно, что что-то определенное Вы скажете после первого проекта. Никто же не говорит, что Вы к утру отчет напишите

[KA_ru]

добавлю про всякие фишечки в Nucleus
поддержка разных железок там богаче.

[Evgeny_CD]

добавлю про всякие фишечки в Nucleus
поддержка разных железок там богаче.

В смысле - бывают дрова под железо?

Вроде симпатичная, в 40 кил уложилась..

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

В какие камни планируете Nucleus засунуть?

[DASM]

самой оси надо 1.5 кило рама. Работаю с LPC2148

[zltigo]

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

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

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

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

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

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

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

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

[Rst7]

с FTP... сурцы все на месте и дока pdf 320 страниц.

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

[VAI]

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

Доступ только для группы "Свой"

[ig_z]

главной "изюминкой" которого автор считал быстрое табличное получение
максимально приоритетной задачи. C тех пор этот заплесневелый изюм там и лежит :-(

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

Что касается нюклеуса, мне довелось работать с портом под вин32. Осталось впечатление излишне тяжелого апи и не совсем оптимального выбора для относительно слабых контроллеров.
Простой пример: пакетный обмен по уарту. Если пакет большой, а фифо маленький , либо вообще отсутствует, что нюклеус, что мюкос - дают огромный оверхед.
Для подобных ситуаций в осекоподобных осах есть два типа прерываний - с вызовом ос апи и без такового. Изящный механизм програмных прерываний использовал и Harry Zhurov в последней версии scmrtos.

[Andrew2000]

Интересно, а Ваша оценка - чем она "интереснее" uCOS?

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

... Скормил я это дело ADS1_2. Собственно только скомпилировал, ну и в main пару нужных вызовов сделал, .... Счас буду вектора нормально ставить и шедулер настраивать.

А почему не ASD2.2 ? а чем их среда Nucleus EDGE не устраивает (Eclipse + ADS2.2 + ARMulator, кстати, и демо Plus под Armulator прилагается, без исходников).
И такой вопрос - а зачем main? и что понимается под "шедулер настраивать"? разве там есть настройки времени компиляции?

[Andrew2000]

...У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало)...

"каку сделало" и еще какую, и такое впечатление, что специально - в планировщике запрещали прерывание после доступа к глобальной структуре - две строчки поменяли местами.
а что они делают в TCC_Time_Slice (tcc.c) я так и не понял - надо разбираться
(порт под Infineon Tricore)

[zltigo]

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

Ага, если кого устраивают все задачи с разными приоритетами, ну и принципиально ограниченное
количество задач. А все остальные должны или "балансировать" уже свои решения, либо переписывать
систему.

[dxp]

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

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

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

, ну и принципиально ограниченное
количество задач.

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

А все остальные должны или "балансировать" уже свои решения, либо переписывать
систему.

Остальные просто должны взять другую ОС, которая их в этой части удовлетворит. И расплатиться за это накладными расходами по памяти и быстродейтсвию. Если целевой процессор это позволяет. Ничего беслатно не быват, вся жизнь - сгусток компромиссов. Сабжевая ОС (и eCOS) просто толще, чем uCOS, и ниши и них немного другие, хотя и пересекающиеся.

[zltigo]

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

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

[dxp]

1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять.

Не помню, что-то. Ссылкой не покажете?

[zltigo]

Не помню, что-то. Ссылкой не покажете?

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

[dxp]

Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить?

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

[zltigo]

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

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

И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной)

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

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

"И код получается прозрачным и предсказуемым"

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

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

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

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

Вот тут вынуждет ответить - НЕ ТАК ОДНОЗНАЧНО ВСЕ.

[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]

это все хорошо.. только тот порт на ARM что тут лежит - бредовый.. или у меня бред...

Дерзайте! Первопроходец Вы наш :-), иначе придется "как все" - без "пиджака".
Сам смогу более-менее заняться сиим делом дней через 10, да и то без особого энтузиазма :-(
Пока код не очень порадовал - достаточно дубовый, видимо вылизаный и естественно портированный на кучу контроллеров... Наверное его стоит покупать и не заморачиваясь пользоватся в готовом виде.
Только рассчитывать на самые легковесные контроллеры (не смотря на упоминание порта на
свежайший микроскопический ARMчик ) я бы уже точно не стал.
А вот стоит-ли практически в одиночку и без особых надежд на то, что в руки попадет 'свежий' исходник с достижениями и правками производителя, его собирать и разбиратся - ВОПРОС!
Суда по количеству дней прошедших с момента первого выступления - успехи скромные?

[DASM]

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

[dxp]

И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной)

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

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

Вот тут вынуждет ответить - НЕ ТАК ОДНОЗНАЧНО ВСЕ.

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

[zltigo]

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

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

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

Для меня это является "настоятельной необходимостью", естественно базирующейся на личных предпочтениях в свою очередь базирующихся в том числе и на личном опыте, личных шишках,
личном видении дальнейщего примерения наработанного кода и с учетом личных обстоятельств
связаных в том числе с последующим не личным сопровождением :-).
Короче сплошной субъективизм :-).

[DASM]

мужики, кончайте спорить, тута Keil глючит нипадецки =( В R13 (SP) ничего писать не хочет в отладке.. млин. Причем только в режиме Supervisor. Как нуль в нем был, так и остается, хоть софт менять его пытается, хоть ручками. В остальным режимах проца - нормально. В IAR тоже нормально. Бред какой-то

[zltigo]

мужики, кончайте спорить, тута Keil глючит нипадецки =( В R13 (SP) ничего писать не хочет в отладке..

Через MT-Link не хочет :-)))))))) Если прекращение спора поможет - готов прекратить.
Ладно - шучу. Я понимаю Кeil из стареньких, либо уже до 3.0.0 допортировались?

[DASM]

не знаю где у него версии смотреть , после установки вышло KeilARM250a. МТлинк тут явно не причем

[zltigo]

МТлинк тут явно не причем

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

То, что у меня в 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]

Суда по количеству дней прошедших с момента первого выступления - успехи скромные?

А чем должны успехи выражаться? В том что он моргание светиком зхапустил или printf ("Hello, world")? Хочется верить, что DASM заюзает этот nucleus в каком-нибудь реальном (пусть и малотиражном проекте), и доложит всем честному народу, что из этого получилось.

[DASM]

для начала вообще запустить нада

[christy]

народ а это вы какую Нуклеус обсуждаете? ядро 1.11.18?
я в свое время посмотрел на нее по-диагонали - вроде хороша, всякие доп модули типа FS,стека протоколов (а сейчас и многие другие вкусные фишечки типa CAN),
но вот беда - заточена под ADS, а я что-то на multi подсел
посему мой выбор threadX - тоже самое, написано тем же самым человеком
токо позже и в др конторе
и на arm7 (ат91) завелось с полпинка

ps. а случайно fileX, netX, canX ни у кого не завалялось?