Прикручиваю ось к LPC2478, Есть и будут вопросы) Опции

[haker_fox]

Добрый день, коллеги!

Скачал последнюю версию порта для LPC2xxx. К сожалению, на LPC2478 код не запускается, пришлось маленько пофиксить инициализацию периферии, немного ассемблера в одном из файлов ОСи. Вроде дело пошло. Задачи запускаются. Я не уверен в надежности и стабильности, пока тестирую.

Пока первый вопрос.

Как я понял, планировщик может вызываться из прерывания системного таймера и по софтовому прерыванию. Это задается опцией scmRTOS_CONTEXT_SWITCH_SCHEME. Мне кажется, что для LPC2478 софтовое прерывание не нужно. Достаточно таймерного. Я правильно понимаю? Т.е. можно использовать scmRTOS_CONTEXT_SWITCH_SCHEME = 0?

Гм... скажем так, я, прочитав документацию, так и не понял, чем отличаются два метода вызова планировщика, и какой когда использовать?

Спасибо!

[_Артём_]

Не могу определится с окончательным выборомом. Что от стека нужно:
1. ICMP.
2. TCP.
3. UDP.
4. DHCP.

На базе стека планируется использовать web server (возможно понадобится ftp server, telnet server).

Если web, то TCP - точно нужен.
DHCP нужен, если ip-адрес сервера не статический, а выдаётся шлюзом.
ICMP тоже не помешает, хотя бы для того чтобы пропинговать сервер.
UDP может и не нужен, но он настолько мал по сравнению с остальным, что можно его и оставить, может пригодится.

[haker_fox]

Если web, то TCP - точно нужен.
DHCP нужен, если ip-адрес сервера не статический, а выдаётся шлюзом.
ICMP тоже не помешает, хотя бы для того чтобы пропинговать сервер.
UDP может и не нужен, но он настолько мал по сравнению с остальным, что можно его и оставить, может пригодится.

Спасибо за объяснение Но вопрос немножечко не в этом был. Я перечислил, что мне нужно (TCP, DHCP, ICMP, UDP...). У меня вопрос не по составу компонентов, а по выбору стека из двух ранее озвученных. Естественно, как стек брать для конкретной оси - дело десятое. Оба поддерживают многопоточность. Но все же)

В общем решил остановиться на lwIP, т.к. с нуля мне кажется проще прикрутить его к scmRTOS. А вот из стека Юрия Темкина придется вытаскивать кусочки его оси Хотя, объективно, его стек лучше (сделан по мотивам BSD).

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

Мне DHCP нужен, поэтому без UDP никуда)

[shreck]

На базе стека планируется использовать web server (возможно понадобится ftp server, telnet server).

А что за веб сервер будет? Определились уже?

P.S. lwIP 1.4.0 я уже прикрутил к scmRTOS. Нужен?
P.P.S. Под IAR.

[haker_fox]

А что за веб сервер будет? Определились уже?

Пока нет, но может быть по мотивам примеров из FreeRTOS или openTCP. Либо что-то другое. Нужно CGI обязательно. Ну и "базовый" набор html...

P.S. lwIP 1.4.0 я уже прикрутил к scmRTOS. Нужен?
P.P.S. Под IAR.

Ну если Вам не жалко)
Думаю под gcc переклепать смогу)

Спасибо!


Хотя вот еще два интересных конкурента появились: OpenTCP & Microchip TCP/IP.

Кто нибудь может о них что-нить интересное сказать? OpenTCP неплохо документирован) Мне кажется, что даже очень не плохо. lwIP как-то совсем, ИМХО, скудно)

[shreck]

Порт lwIP 1.4.0 c использованием scmRTOS.

1. ipnet_config.h и lwport_config.h - прописать пути для них.
2. Папку port разместить, например, в верхней папке lwip и прописать путь до port/arch
3. Прочитать lwport_config.h и подстроить под себя.
4. Взять ethernetif под свой контроллер (здесь он для stm32).

Прикрепленные файлы

 lwPortscmRTOS.zip ( 17.5 килобайт ) Кол-во скачиваний: 48

 

[shreck]

Обнаружил досадную ошибку в порте, перекочевавшую из порта FreeRTOS.

Код

Файл sys_arch.cpp, функция sys_sem_new(...), строка 227.
Написано:
if (0 == count)
    t->signal();

Должно быть:
if (count)
    t->signal();

[haker_fox]

Новое интересное поведение)
Программа работает великолено. Решил на LCD вывести картинку 480x272x24. На Питоне написал скрипт, который конвертнул картинку в const const

CODE

uint32_t logoImg[] = { ... }

. На каждый пиксель, естественно, 4 байта. Получил размер массива 272 * 480 * 4 = 522 240 байт. Массив находится в хидере, который цепляется к программе. Вот тут-то начинается интересный эффект...

При вызове функции OS::sleep или любой другой, вызывающий переключение контекста, программа виснет на время, много превышающее заданный таймаут. Затем, продолжает нормально работать. Причем на sleep у меня построен небольшой цикл, который выводит каждый 15 мс на экран точку (типа линейка, показывающая процесс). Так вот, одна точка висит вместо 15 мс около минуты, затем дорисовываются все точки с необходимой скоростью. Что интересно, если массив маленько урезать, килобайт этак на 30, то программа работает без нареканий. Картинка, конечно, выводится с артефактами.

Посмотрел, что линкер ложит массив "по середине" прошивки.

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

Правда, как объяснить, что после первой задержки, все остальные отрабатывают нормально?!

Спасибо! Извините, если немного сумбурно...

[shreck]

Новое интересное поведение...

Насколько я помню, в порте scmRTOS под GCC от АНТОХи по умолчанию используется "короткий" прыжок в функции переключения контекста. Может это имеет значение?

[haker_fox]

Насколько я помню, в порте scmRTOS под GCC от АНТОХи по умолчанию используется "короткий" прыжок в функции переключения контекста. Может это имеет значение?

Может быть) Но как это дело заменить на длинный прыжок? И сколько - короткий (в байтах)? Я так, понимаю, надо ассемблер править...

Может тогда проще как-то линкер уговорить, ложить такие массивы где-то "сбоку" от кода?

[_Артём_]

Насколько я помню, в порте scmRTOS под GCC от АНТОХи по умолчанию используется "короткий" прыжок в функции переключения контекста. Может это имеет значение?

У haker_fox не Cortex-M3, а LPC2478.

[haker_fox]

У haker_fox не Cortex-M3, а LPC2478.

Так АНТОХА также делал порт под lpc2xxx

[shreck]

У haker_fox не Cortex-M3, а LPC2478.

Пардон, ошибся. Но возможно и в этом случае стоит просмотреть asm код.

[AHTOXA]

Посмотрел, что линкер ложит массив "по середине" прошивки.

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

[haker_fox]

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

Теперь массив объявле так

CODE

const uint32_t z_logoImg[] = {

Вот, что видим в map-файле

CODE

.rodata._ZL9z_logoImg
                0xa0222160    0x7f800 ./obj/FDesktop.o

Секции в скрипте линкера объявлены так (все во внешней SDRAM)

CODE

MEMORY
{
    RAM (rw)    : ORIGIN = 0xA0600000, LENGTH = 512k
    FLASH (rx)    : ORIGIN = 0xA0200000, LENGTH = 1024k
}

Массив упорно ложится ну не совсем по середине, конечно, но реже прошивку на лапопам

При обращении к массиву используется цикл

CODE

        uint32_t* dst = ( uint32_t* )0xa0000000;

        for( int i = 0; i < 480 * 272; i++ )
            *dst++ = z_logoImg[ i ];

Вроде с индексами все в порядке

В общем такое ощущение, что размер массива сильно мешает. Но из расределения памяти видно, что никаким образмо область FLASH не может затереть область RAM, т.к. между ними 4 метра...

Блин, загадка!

[AHTOXA]

Массив упорно ложится ну не совсем по середине, конечно, но реже прошивку на лапопам

Странно. Если он в rodata, то всяко должен лежать после .text:

Код

        *(.text)                   /* remaining code */
        *(.text.*)                 /* remaining code */
        *(.rodata)                 /* read-only data (constants) */
        *(.rodata*)

Попробуйте убрать из цикла обращение к logoImg:

Код

        uint32_t* dst = ( uint32_t* )0xa0000000;
    for( int i = 0; i < 480 * 272; i++ )
            *dst++ = i;

Узнаем, кто виноват. Может видеобуфер тормозит.