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

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

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


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

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

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

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

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

Спасибо!


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

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

Порт 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).

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

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

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

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

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

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

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

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

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

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

У haker_fox не Cortex-M3, а LPC2478.

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

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

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

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

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

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


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

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


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

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

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

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

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

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