[yuri_t 0]

TN NET TCP/IP написан для процессоров с размером RAM >= 32 KBytes и с размером FLASH >= 128 KBytes ( NXP © LPC23xx/LPC17XX, Atmel © AT91SAM7X, Luminary Micro © LM3S6xx/LM3S8xx/LM3S9xx, Freescale © MCF5223X и других аналогичных MCU).

 

TN NET TCP/IP stack базируется на industry-standard BSD TCP/IP stack. В качестве API используются BSD sockets. TN NET TCP/IP stack использует TNKernel ОСРВ для обеспечения действительно мультизадачной и реентерантной работы.

 

B предварительную версию (0.8) не включены TCP и DHCP протоколы.

 

www.tnkernel.com

[zltigo 0]

TN NET TCP/IP stack базируется на industry-standard BSD TCP/IP stack.

О! Т.е. Действительно максимально портировали BSD исходники? Или просто, типа, в приглядку писали?

[Rst7 5]

Вышла предварительная версия TN NET TCP/IP stack

 

B предварительную версию (0.8) не включены TCP и DHCP протоколы.

 

[yuri_t 0]

- по поводу портирования BSD

 

Идея была использовать BSD stack по максимуму, добавляя/изменяя только те части, которые не помещаются в 32kbyte RAM/128 kbyte ROM.

 

В частности, весь TCP/UDP/IP/ARP взят с минимальными изменениями из BSD Lite 4.4/OpenBSD/NetBSD. Изменения коснулись тех мест, которые не требуются и/или не помещаются в MCU типа LPCxx (например, не требуется перехода из kernel space в user space и обратно)

 

BTW, TCP stack будет выложен в ближайшее время.

 

IMHO, написать stack c нуля (начитавшись разнообразных RFC) конечно можно, но такой продукт, во-первых, будет

ничем не лучше BSD, во-вторых, потребует многолетнего тестирования для выявления всяких obscure bugs. Кстати,

такими проблемами страдают многие коммерческие реализации TCP/IP именно из-за ограниченной для маленьких

компаний возможности тестирования.

 

С другой стороны, если не устраивать революций в BSD Lite 4.4 TCP/IP, a изменить только незначительные/

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

например, компания InterNiche в своем продукте NicheLite (и Microsoft (!) в WinSock2)

[zltigo 0]

IMHO, написать stack c нуля (начитавшись разнообразных RFC) конечно можно, но....

Ну я к этому и не призывал :).

С другой стороны, если не устраивать революций в BSD Lite 4.4 TCP/IP, a....

Вот именно этот путь мне очень привлекателен.

[yuri_t 0]

TN NET обновилась до версии 0.8.3.

 

TN NET TCP IP/ stack версии 0.8.3 включает TCP/UDP/IP/ICMP/ARP протоколы.

 

www.tnkernel.com

[zltigo 0]

TN NET TCP IP/ stack версии 0.8.3 включает TCP/UDP/IP/ICMP/ARP протоколы.

Отлично! Правда я так и не нашел времени вдумчиво посмотреть :(

[yuri_t 0]

TN NET TCP/IP stack обновился до версии 0.8.5.

 

Добавлен пример "Embedded Web server".

 

TN NET TCP/IP stack версии 0.8.5 представляется достаточно зрелым для использования/тестирования

в реальных проектах.

[yuri_t 0]

Вышла версии 0.9 TN NET TCP/IP stack.

 

Добавлен DHCP client.

 

Просьба ко всем, кто использует (пробует) TN NET TCP/IP stack - присылайте,

пожалуйста, ваши замечания и предложения на [email protected].

[sim732 0]

Вышла версии 0.9 TN NET TCP/IP stack.

 

Добавлен DHCP client.

 

Просьба ко всем, кто использует (пробует) TN NET TCP/IP stack - присылайте,

пожалуйста, ваши замечания и предложения на [email protected].

 

Здравствуйте Юрий. Пытаюсь использовать Ваш TCP/IP stack с TN kernel в одном проекте

и столкнулся с такой проблемой. Есть задача, которая с одной стороны работает с клиентом

на host PC по tcp/ip, а сдругой стороны с двумя очередями. Если задача читает сокет, то она

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

сообщение из очереди. Есть ли в Вашей реализации стека что-либо такое (типа select), что

может сообщать о событии появления сообщения через сокет до вызова функции s_recv ?

Изменено 28 марта, 2010 пользователем sim732

[sim732 0]

Почитал tn-net-sockets.pdf. Оказывается в Вашей реализации сокет можно перевести

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

процессорное время), но все же лучше, чем ничего. Использую предоставленную функцию s_ioctl().

Сокет переводиться в неблокирующий режим не хочет. Смотрю исходные тексты и вижу, что

в функции tcp_s_recv() проверка состояния so->so_state на SS_NBIO вообще отсутствует. Т.е. в этой

версии tcp/ip стека(0.9) перевести открытый сокет в неблокирующее состояние нельзя.

[yuri_t 0]

Ф-ция 'select' создавалась для классических аппликаций - где нет multithreading и все происходит

внутри одной ф-ции main(). Для малоформатных RTOS типа TNKernel 'select' "тяжеловат", да и в

общем-то и не нужен (IMHO).

 

В случае TNKernel/TN NET и использовании TCP sockets, task, в которой производится s_recv(), должна

только принимать по s_recv() и не в коем случае не ждать какие-то другие события, очереди etc.

Другие события, очереди etc. дожны ждать ДРУГИЕ task(s).

Результат приема должен посылаться в ДРУГУЮ task (c помощью tn_queue например).

При этом блокирующий прием работает естественным образом, а неблокирующий прием

не нужен вообще (поэтому он и не реализован).

void task_rx_socket_A_func(void * par)
{

   for(;;)
   {
      rc = s_recv(g_s, (unsigned char*)g_rx_buf, RX_BUF_SIZE, 0);
      if(rc < 0) //-- SOCKET_ERROR
      {
      }
      else if(rc == 0) // closed by peer
      {
      }
      else //-- got some data
      {
          //--processing data, obtained by the s_recv(), or send it to another task 
      }
    //-----
   }
}

[sim732 0]

В случае TNKernel/TN NET и использовании TCP sockets, task, в которой производится s_recv(), должна

только принимать по s_recv() и не в коем случае не ждать какие-то другие события, очереди etc.

Другие события, очереди etc. дожны ждать ДРУГИЕ task(s).

Результат приема должен посылаться в ДРУГУЮ task (c помощью tn_queue например).

При этом блокирующий прием работает естественным образом, а неблокирующий прием

не нужен вообще (поэтому он и не реализован).

 

Спасибо Юрий за комментарий. Я так и поступил. Хотя и добавил пару строк в

tn_tcp_send.c для того, чтобы было соответствие с документацией.

      if(m)
         break;
      else
      {
        if(so->so_state & SS_NBIO)
        {
           splx(tnet, sm);
           return -EWOULDBLOCK;
        }
        else
        {
           splx(tnet, sm);
           tn_net_wait(&so->so_rcv.sb_sem);
        }
      }

Спасибо еще раз за Вашу работу. Отличная RTOS и стиль написания очень

ясный.

[LightElf 0]

Изучаю сорцы. Возникли несколько вопросов:

1) Можно ли вызывать s_send и s_recv одновременно из разных потоков для одного и того же сокета? То есть один поток ждет прихода данных из сокета, а второй - в сокет пишет.

2) Может в силу лености ума не очень понимаю взаимодействие стека с ethernet контроллером. Нет ли какого-нибудь porting guide или это с моей стороны совсем уж наглость :)?

3) Правильно ли я понимаю, что в порте TNKernel под Coldfire прерывания обрабатываются на стеке текущего процесса?

[yuri_t 0]

Изучаю сорцы. Возникли несколько вопросов:

1) Можно ли вызывать s_send и s_recv одновременно из разных потоков для одного и того же сокета? То есть один поток ждет прихода данных из сокета, а второй - в сокет пишет.

 

Можно

 

2) Может в силу лености ума не очень понимаю взаимодействие стека с ethernet контроллером. Нет ли какого-нибудь porting guide или это с моей стороны совсем уж наглость :)?

 

На какой процессор собрались портировать ?