Есть МСВ2360, и есть свежый порт http://www.freertos.org/portlpc2368uIP.html
Надо будет сделать похожее на своем железе, которое уже через месяц будет готово, пока есть желание поиграться с отладочником и софтом.
Скачал поставил CW проект компилится, посмотрел его структуру. Всегда работал с IARом, хочу перенести код туда.
Вопросы:
- ОСь никогда сам не портировал, хотя пользовался DSP/BIOS как ОСРВ работает хорошо представляю. Начал формировать проект в IARе - такое чувство что делаю что-то не через то место. Как правильно работать с такими большими проектами, какие есть программные средства чтобы управлять проектом с осью?
- к CW подцепил сеггеровский драйвер J-Link, а он отказывается работать. Вообще из CW можно прошить кристалл J-Link'ом?

Ну отсюда не видать . Среди FreeRTOS портов есть и IARовские - можете посмотреть в качестве образца. Проект по размерам совсем не большой да и был-бы большой - какие проблемы? На какие волшебные средства 'управления' рассчитываете?

В CW проект разбит на 4 папки демо, ось, стек и системные файлы.
Причем по самим папкам тоже логики нифига никакой в демо кроме самой демки куча файлов из разных папок фриртоса. Даже перетаскивать проект в IAR и то гемор приходится куски по разным папкам собирать логики никакой. Может просто файлы по папкам как-то разложить, отдельно приложение отдельно ось отдельно стек, а потом также и проект разбить. Вообщем хочется чтобы все лежало на своих местах а не кучей.

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

Простите, логика есть.
http://www.freertos.org/ -> Informations->Fundamentals->Source Organisation


Естественно.

ОНИ ТАК УЖЕ ЛЕЖАТ.

Сообщение отредактировал zltigo - May 29 2007, 10:38

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


Компилятор пожалуй нет, IAR пока меня устраивает. Контроллеры возможно и другие но маловероятно что не NXP.

Посмотрел порт под IAR системная часть организована немного по разному.
В IARовских портах в системной папке используется один мизерный стартап cstartup.s79, а вот в порте CW в системной папке файлов полно и функций они выполняют изрядно. Кроме собственно стартапа поддержка таймера, более сложная инициализация стеков, куча функций работы с VIC, ISR IRQ, и самое неудобное что все эти модули подключают кросворковские хидера.
Лишнего там кончено точно полно, исходный порт разбабахивать сразу сильно нехотелось бы, но видимо придется.

Пока вопрос такой - полно вот таких описаний сруктур.

struct uip_eth_hdr {
struct uip_eth_addr dest;
struct uip_eth_addr src;
u16_t type;
}PACK_STRUCT_END;

Компилятор понимает описание
struct
{
поле
поле
...
}
имя структуры

Поэтому PACK_STRUCT_END принимает за имя и ругается на их несоответствие
Error[Pe147]: declaration is incompatible with "struct uip_icmpip_hdr __data PACK_STRUCT_END"
Видимо надо не править а включить у компилятора поддержку какого-то расширения?

Глянул lwIP мельком - это макрос и он должен быть просто определен и проблем не будет.
Но стиль написания, конечно, дурацкий

Там не lwIP а uIP, но не суть. Макрос разрыл в проекте CW он структуру делает packed. Что-то в IARe мне не удалось его заставить понять исходный код. Перенес имена структур вместо этого PACK_STRUCT_END. Помогает, но такие косяки лезут толпами. Наверное это неправильный путь переделывать из CW порта на IAR, запустить порт малой кровью под ИАРом все равно не получается, а если все ломать - то наверное лучше взять порт на ближайший LPC но ИАРовский, портировать его на 2368, а потом уже туда втыкать стек и все остальное.

То, что он делает, это понятно, но то, что кто-то попытался извратиться и вместо более-менее общепринятых вариаций на тему #pragma pack использовать более узкоспециализированное это уже плохо. Все дивные макросы дефинировать в "ничего" и использовать или прямые указания
#pragma pack( push, 1 )
#pragma pack( pop )
либо через #include их-же через внешние файлы.

Я непонял, что Вы сделали, но все очень просто и я описал это выше.

Почему?????

Так и пробовал - ИАР почему то не понял.


Или я не понял или прямые указания надо все равно вбивать перед определением структуры.

Да я чего-то код правлю и правлю, уже хидера от стека переделал, чтобы свои не цеплялись перенес все в новый каталог - получается уже развалил структуру файлов. И при этом я еще и не брался за папку систем а там вообще на первый взгляд сплошные кросворковские подключения.
Просто ломается рабочий код, к тому моменту как он начнет компилиться он перестанет работать. Мне уже кажется что проще пойти с другой стороны взять ЛПСишный ИАРовский порт попроще - и портировать его на 2368, там вроде проще а потом в рабочий код надстраивать стеки.

Он не мог не понять значит ошиблись.

Да. Но с тем-же самым, но в #include получается переносимее, ибо в основном файле уже нет специфики компилятора, а в сам include можно напихать распознавание кучи компиляторов и пользоваться им всегда и везде.

Примерно один черт, единственно, если все впервой и большей частью по наитию, то получается, что идти "от рабочего" кода действительно несколько спокойнее.

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


С инклудом не понял все равно, как можно не меняя хидер uip.h на место PACK_STRUCT_END воткнуть #pragma pack - он же вроде бы как должен быть перед определением структуры.

Так, давайте медленно и печально. Первый вопрос где Вы вообще смогли увидеть PACK_STRUCT_END и прочие паковочные макросы в uIP подчеркиваю в uIP а не lwIP стеке.
В lwIP, где они действительно присутствуют для работы c include просто:

И в два файла (у меня они по жизни называются packon.h и packoff.h а у авторов стека соответственно
bpstruct.h и epstruct.h )
Мои файлы в приложении. Можете их или переименовать, или заинклюдить еще раз в авторские имена.

В хидере uip.h, также uip_arp.h там я правил точно
Может проблема в том что я смотрю в UIP из комплекта порта фриртоса?


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


Я понял - предлагается PACK_STRUCT_**** заменить пустыми дефайнами, а директивы #pragma pack распространить инклудом на весь проект. Так?

Худо бедно стек скомпилил перешел к другим папкам пытаюсь разобраться дефайнами
portENTER_SWITCHING_ISR();
portEXIT_SWITCHING_ISR(...);
чего-то там тоже неблагополучно ИАР теряет скобки Error[Pe125]: expected a "("


Сразу еще такой вопрос, в CW порте используется portmacro и portISR из папки GCC, как в ИАРе быть с атрибутами naked и signal? __irq?

А я тогода куда смотрю

Именно так в оригинале и задумано - варьировать ими в зависимости от возможностей компилятора.

На весь замного будет - только на пакованные структуры правильнее.

А чего с ними разбираться - берете готовые из IAR порта и все.