Re: [lwip-users] lwIP with FreeRTOS memory problem

[FreeRTOS Info]

On 28/11/2016 12:17, Nenad Pekez wrote:

Richard, first of all, thanks for your quick response.

What I forgot to mention is that application doesn't crash at the very
beginning, it actually works for some time how it should work and than
suddenly crashes. I suppose that problem you mention would manifest
itself right from the beginning, when XEmacPs_IntrHandler is called for
the first time? Moreover, I thought that lwIP doesn't use standard C
malloc() and free() functions (if you are talking about those), but have
custom heap-based function mem_malloc(), UNLESS we set option
MEM_LIBC_MALLOC to 1 , which I haven't done.


Mistake on my part - I thought you were using malloc and free.

You said the assert gets hit.  The one on line queue.c:1224 guards 
against the use of a mutex in an interrupt and the one in port.c against 
a non-interrupt safe function being called from an interrupt - so if a 
mutex is being used in an interrupt, the deferred handler bit of my last 
email would still hold true.


Regards,
Richard.

+ http://www.FreeRTOS.org
The de facto standard, downloaded every 4.2 minutes during 2015.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, TCP/IP, FAT FS, Training, and more...


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP with FreeRTOS memory problem

[FreeRTOS Info]

On 28/11/2016 02:17, pekez wrote:

Hello people,

I've been trying to figure out how lwIP uses memory and it's really
important to know exact (or maximum) amount of memory that lwIP uses. I
am using lwIP v1.4.1 with FreeRTOS v8.2.3 on ZYNQ custom board. Right
now, I am working with application examples provided by Xilinx (XAPP1026
).
On ZYNQ board, I am running iperf 
server, and on PC iperf client.

When both MEMP_MEM_MALLOC and MEM_LIBC_MALLOC are 0 then everything
works completely expected. However, when I set MEMP_MEM_MALLOC to 1
(according to RAM usage article from lwIP wiki
), so that every piece of
dynamically allocated memory comes from heap of MEM_SIZE size,
application always crashes, no matter how big or small MEM_SIZE is (I
have a lot of RAM, so I tried to put MEM_SIZE to even more then 20 MB!).
Application crashes because two of FreeRTOS asserts fail, I get these
two prints: "Assert failed in file queue.c, line 1224" and "Assert
failed in file port.c, line 424". According to call trace (which I
provided in attachments), it crashes when XEmacPs_IntrHandler (I am
using Xilinx layer 2 drivers) tries to allocate memory for pbuf.

Is this problem even related to lwIP or maybe to FreeRTOS or Xilinx
drivers, what do you think? I am also providing the entire lwipopts.h,
so that you can see whether some other options need to be changed in
order to make application work with MEMP_MEM_MALLOC set to 1.


It sounds like you are trying to call malloc from an interrupt handler - 
which you can't do [in FreeRTOS] as the malloc is thread safe but not 
interrupt safe. One solution, albeit with a time penalty, is to use a 
deferred interrupt handler, where the IRQ does nothing more then unblock 
a very high priority task and clear the interrupt. Then the interrupt 
will return directly to the unblocked task to perform the actual 
processing necessary (the processing that was deferred from the 
interrupt). You can then optimise it so only interrupts that want to 
allocate memory get deferred to a task.


Example code snippets of how to do this can be found on the following 
page: 
http://www.freertos.org/RTOS_Task_Notification_As_Counting_Semaphore.html


Alternatively provide an additional heap for use just by the ISR so you 
don't get re-entrancy problems, or update the heap_n.c file 
(http://www.freertos.org/a00111.html) so it uses interrupt safe critical 
sections rather than task only critical sections (although this last 
option could make interrupts less responsive).


Regards,
Richard.

+ http://www.FreeRTOS.org
The de facto standard, downloaded every 4.2 minutes during 2015.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, TCP/IP, FAT FS, Training, and more...

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] stm32 ethernet interrup priority

[FreeRTOS Info]

On 22/08/2016 13:00, Erkan Ersoy wrote:

Thank you Noam;

Somethings are confusing but i think i get it


Yes, confusing.



#define configKERNEL_INTERRUPT_PRIORITY (
configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
#define configMAX_SYSCALL_INTERRUPT_PRIORITY (
configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )

those values are
configKERNEL_INTERRUPT_PRIORITY : 240
configMAX_SYSCALL_INTERRUPT_PRIORITY: 80


Those values are used by FreeRTOS itself, which is portable across all 
ARM Cortex devices, which have varying number of implemented priority 
bits (in hardware).





but they never used those defines so they used only values above 5
without defines. Those defines stay there idle.


Some libraries want the full 8 bit values (which is how the hardware 
always sees the values), other libraries want unshifted values.




I use 6 for ethernet interrupt and 7 for USART interrupt now it seems
work fine


So 7 have a logically lower priority, despite being a higher numeric value.

The following link may make things clearer, or alternatively, murkier :o)

http://www.freertos.org/RTOS-Cortex-M3-M4.html

Regards,
Richard.

+ http://www.FreeRTOS.org
The de facto standard, downloaded every 4.2 minutes during 2015.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, TCP/IP, FAT FS, Training, and more...

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] freertos + lwip = no uart ?

[FreeRTOS Info]

I never had problems with UARTS but I did have problems with LwIP when
interrupts priorities were

not defined properly versus the FreeRTOS interrupt.

1.




As far as I recall the XMega port does not support interrupt nesting, so 
the parameters you highlight are not implemented for that code.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for simplicity. More than 113000 downloads in 2014.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fail to get netconn lwip1.4.1+FreeRTOS+TM4C1294

[FreeRTOS Info]

I have just replied to the same on the FreeRTOS forum where the 
suggestion of referring to our reference integration was politely declined.


For others on this list:  There is a memory leak in the poster's code 
because the pointer needed to free the semaphore is overwritten with 0 
without the semaphore having first been freed, and then there is an 
attempt to free the now NULL pointer.  The FreeRTOS FAQ suggests 
defining configASSERT() when having stability issues - two asserts would 
have been triggered in this case.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for simplicity. More than 113000 downloads in 2014.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...



On 26/02/2015 19:35, goldsi...@gmx.de wrote:

Jin Won Seo wrote:

I tried before without sem->queue=0, but all same.


I meant calling 'vQueueDelete()' before setting queue=0.


I reported both TI and FreeRTOS, but TI have not responded yet and
FreeRTOS replied "They have a own network stack", so they are not sure
about lwip.


That's strange. Richard from freertos.org used to be very acive here.
Although I admit he hasn't been lately, so things might have changed
there...

Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ping flood crash

[FreeRTOS Info]

why ? and how to check it?


...because you said the error was "temac error interrupt: rx fifo over 
run".  So presumably the driver is using a FIFO to store received 
packets, but the rate at which packets have been received was too fast 
for the CPU to process, so the FIFO became full and the driver returned 
an error.  Therefore the problem occurred in the driver, before the 
packets were ever sent to lwIP.  This is a perfectly legitimate 
scenario, and not really an error.  If there is no space to store the 
packets then the packets will have to be dropped.  If the dropped 
packets contained TCP data then the TCP protocol will take care of 
ensuring they get re-sent.  If the dropped packets contained UDP data 
then you lucked out - if they need to be re-sent then that has to be 
done from the application level.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 107000 downloads in 2013.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] ping flood crash

[FreeRTOS Info]

On 10/09/2014 07:55, mobin.seven wrote:

Hi
my lwip 1.4 app on microblaze/virtex-5 *crashes * on a simple ping attack.
returns "temac error interrupt: rx fifo over run".
socket API
seems lwip isn't protected againt ping flood...
how to protect it?!


From your very brief description that sounds like a hardware driver 
issue, not an lwIP issue.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 107000 downloads in 2013.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] multiple timers.c in project

[FreeRTOS Info]

On 18/07/2014 17:32, Simon Goldschmidt wrote:

"Sebastian Subik" wrote:


I hoped that there are better solutions available, but your
solution should definitely work. Maybe lwip can consider renaming
their timers.c within a future release to avoid such kind of
problems...


You could ask the same from FreeRTOS. In fact,  why doesn't
every project rename every source file to have the project name as a
prefix? That would be a great idea! 

:-)

Simon


There are a couple of things it would be nice to have the freedom to 
change in FreeRTOS - the file names is top of the list.  List.c in 
particular - would be better as FreeRTOS_List.c.  I really don't think 
it is any hassle to change the name of one file in your project though - 
but do understand it is more problematic when it comes to header file 
name clashes.


When FreeRTOS was created, and probably lwIP too, there was no 
anticipation of its massive uptake, hence it maybe lacked a bit of 
forward thinking about how it would fit into larger projects.  On top of 
that, at the time it was created, the file names all had to fit into 8.3 
format too.


Nearly all such "if only we had done..." wishes have been morphed into 
FreeRTOS over the years, and our newer products (both written already 
and being written) do not have these naming problems.  We can't, 
however, change the name of a file for such a well established product 
as the core FreeRTOS kernel though without causing a major upset - there 
are so many third party tools that use the files, or copy the files 
around, or display the files, etc. and that is not even mentioning the 
thousands and thousands of users who would have to change their project 
files and scripts in order to update their version of FreeRTOS were the 
file names to change (a process that normally just requires a drop in 
replacement followed by a clean build).


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 107000 downloads in 2013.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] The xml schema of the lwip stack

[FreeRTOS Info]

On 30/04/2014 13:16, zakaria jouilil wrote:
> Sure.
> In fact, (as I already described on a previous message) I'm working how
> to model an embedded protocol stack which can be used in an avionic
> context (I work on a little company which operates in this field).
> 
> I met a lot of difficulties to find an adequate model. So, I thought
> that finding a metamodel for such a stack can be very useful and I want
> to know what an xml schema of the lwip looks like since this lwip is
> open-source I think that there is a possibility to find an xml schema
> about it..

...so what would this XML schema look like and what would it contain?
Basically what are you expecting, can your provide an example, and why
do you think such a thing would exist?

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 107000 downloads in 2013.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] FreeRTOS :: LWIP xInsideISR == (portBASE_TYPE)

[FreeRTOS Info]

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...



> configASSERT(xInsideISR == (portBASE_TYPE) 0); (full code below). So im 
> asking why is that happened ?
> 
> I am rookie at these staff so be patient :)
> 
> If anyone can help :)
> 
> Full code:



> if(pdTRUE == xQueueReceive(*pxMailBox, &(*ppvBuffer), ulTimeOut / 
> portTICK_RATE_MS)) {

I'm not sure which code you are basing your project on, or where the
xInsideISR variable is getting set, but if the code really is being
called from inside an interrupt then the assert is quite right to stop
you.  The line above (and several other lines in your post) have two
issues for use in an interrupt:

1) FreeRTOS maintains a separate API for use inside and outside
interrupts.  This is for several reasons, but in summary, it means you
don't need any special code when entering an interrupt, you don't need
to count nesting, and both the code intended for use in an interrupt and
outside of an interrupt can be optimised for their single purpose.  Only
FreeRTOS API functions that end in "FromISR" can be used in an interrupt.

2) It just makes no program flow/sequencing sense to define a block time
when you are inside an interrupt.


In any case, generally it is best to get out of the interrupt as quickly
as you can, and defer processing to a task.  The simple Ethernet driver
on the link below is an example of how that is done.  The interrupt uses
an xSemaphoreGiveFromISR() function to unblock a task, then requests a
yield if the task unblocked by the semaphore has a higher priority than
the task the interrupt interrupted.  That way, the code still runs as
the very next thing, as if it were actually executed in the interrupt,
but it is actually executed in a task.

http://goo.gl/iubh1m -> see the ETH_Handler() interrupt handler and the
prvEMACDeferredInterruptHandlerTask() task definition.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP for safety applications

[FreeRTOS Info]

> Hi,

Hello - I will provide my opinion from my experience working in the aero
space industry, and later in 61508 certification for SafeRTOS...but it
is just opinion.  What you need to do is talk to your certification body
about your plans up front, before you do anything, to get their buy in
to your approach.

You don't say which SIL level you are using, so I will assume 3 as that
is the level worked at for most of my experience.

> 
> I'm building a safety application (IEC 61508) that makes use of
> lwIP. The safety function is not dependent on the data passed by lwIP
> but if lwIP has bugs that corrupts memory that it does not own,
> things might go south. Memory protection by the CPU is an option but
> I would still like to know how "safe" it is.

Strict and provable memory protection can be accepted if you are using a
certifiable scheduler that can ensure that lwIP cannot hog the CPU by
getting stuck in a loop, etc., and that lwIP or its drivers are not
doing something bad with interrupts (running lwIP in an unprivileged low
priority task, for example).  Interrupt service routines are generally
not protectable if you are just using memory protection because they
will run privileged, so extra care is needed there.

> I'm hoping to be able to use lwIP based on the "proven by use"
> clause but in order to do that I need some kind of statistics of its
> use. Is there any such available? Or have any of you tackled this
> problem in other ways?

The practicality of this is very hard.  There are proven in use clauses
but getting a body to accept them is *very* difficult (some countries
are a lot more lenient than others).  Proven in use without strict and
proven memory protection in this case is *very* ambitious unless you
have) an unmodified old version of lwIP that has been under strict
configuration management, unmodified by its users, with a known number
of users, known use cases of your users, and a mandatory bug reporting
and documenting system, at the least.

You may convince somebody, but you have to consider if you are trying to
convince somebody to certify your product, or if you are trying to make
your product safe (which is the point of 61508).  Consider the worst
case scenario - in which you will have to convince a judge with expert
witnesses

Hope that helps.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
Trace, safety certification, FAT FS, TCP/IP, training, and more...


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Low Iperf performance of lwip 1.4.1 on STM32 and FreeRTOS

[FreeRTOS Info]

On 21/06/2013 08:59, Claudius Zingerli wrote:
> Hello all,
> 
> I'm working on a project using lwIP 1.4.1, FreeRTOS 7.4.2 on an
> STM32F407 MCU.
> I have several UDP/TCP/Multicast services running well, but when I tried
> to measure TCP bandwidth with Iperf as well as with dd|nc, I get very
> low results.
> Iperf basically just sends a lot of data and lwIP drops it (using
> netconn_recv();netbuf_delete() or netconn_recv_tcp_pbuf();pbuf_free();)
> 
> An analysis with Wireshark shows the following:
> (TCP_MSS=TCP_WND=1460)
> - SYN,SYNACK,ACK,PSH,PSH (as usual)
> - ZeroWindow (client stuck), WindowUpdate (some ms later)
> - PSH, ZeroWindow, WindowUpdate,...


Ever so slightly off topic -

It sounds like there are lots of people doing good work with FreeRTOS
and lwIP here, and I'm sorry I don't get the time to contribute to these
threads more often.  In the past I have attempted to maintain an
"example integration" running in the FreeRTOS Win32 simulator, but
projects discussed here go far beyond that.

I would be very grateful if people could occasionally post frameworks of
their code in the FreeRTOS Interactive site for others to reference.

http://interactive.freertos.org

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
Trace, safety certification, FAT FS, TCP/IP, training, and more...

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LPC1768/9 LAN8720 FreeRTOS 7.4 LWIP 1.4.1

[FreeRTOS Info]

On 23/05/2013 16:20, Pomeroy, Marty wrote:
> 
> If I'm seeing this right, you are polling for link status, and want to
> figure out which is the better way to poll.
> 
> First, all tcpip thread stuff MUST be done on the tcpip thread, so DO
> NOT call it from the timer interrupt.  Option 2 is eventually going to
> cause errors.
> 
> But better still, most phy chips will generate an interrupt when a cable
> is inserted or pulled.  In that interrupt, send a message to update
> status.  My interrupt is basically:
>tcpip_callback_with_block( s_HandlePhyInterrupt, NULL, 0);
> This passes a static function to be called from the tcpip thread.
> 
> That's my preference - use the interrupt, let the phy chip notify your
> code when there is a change, have the interrupt pass a task-time
> interrupt handler to the tcpip thread.

Normally in a FreeRTOS application you would want this to be event
driven.  There are some example FreeRTOS lwIP integrations you can use
as examples, but the general approach (although for different stack) can
be seen in the example code at the bottom of this page:

http://www.freertos.org/Pend-on-multiple-rtos-objects.html

In this code the cable in/out interrupt would be packaged as a
eNetworkDownEvent event.
Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
Trace, safety certification, FAT FS, TCP/IP, training, and more...















> 
> Marty
>  
> 
> -Original Message-
> From: lwip-users-bounces+martypomeroy=novabio@nongnu.org
> [mailto:lwip-users-bounces+martypomeroy=novabio@nongnu.org] On
> Behalf Of furiantes
> Sent: Wednesday, May 22, 2013 9:56 AM
> To: lwip-users@nongnu.org
> Subject: [lwip-users] LPC1768/9 LAN8720 FreeRTOS 7.4 LWIP 1.4.1
> 
> Hello,
> 
> first sorry for my english.
> 
> I have a bit of problem don't to do this properly, what is a correct way
> (both ways are working). I want to make a lwip cable ON/OFF bulletproof.
> 
> First my HW config is:
> 
> - LPC1768 (i do with LPC1769 too)
> - LAN8720
> 
> SW:
> - FreeRTOS 7.4
> - LWIP 1.4.1
>  - DHCP
>  - TCP
> 
> I execute a TCP connection to some adress like www.example.com/file.txt 
> -> download that file (this is working at is looking)
> 
> My code for init part is like:
> 
>  setupHardware();
>  static struct s_network_config net;
>  net.use_dhcp = 1; // set to 1 to enable DHCP. Or set to 0 and fill
> the struct manually
>  tcpip_init(network_init, &net);
>  InitDelayTimer();
>  xTaskCreate(hc_task, ( signed portCHAR * ) "send hc",1536u, NULL,
> TCPIP_THREAD_PRIO, NULL);
>  vTaskStartScheduler();
> 
> So main lwip thread is in seperate thread, my connection is started in
> hc_task so it's seperated thread.
> 
> I have a 2second timer too. From which i am checking my PHY and i am
> want to do a procedure now to handle cable disconetion/connection.
> 
> I am guessing the right way:
> 
> 1. send a "special" message box to main lwip thread  so add a case and
> call a netif_set_link_down(pxNetIfInUse);,
> netif_set_link_up(pxNetIfInUse); 2. or in timer interrupt call
> netif_set_link_down(pxNetIfInUse);,
> netif_set_link_up(pxNetIfInUse);
> 
> I want to restart DHCP and KILL TCP connection to start it again.
> 
> So what is "more" right:
> 
> - call in interrupt
> - or send a message box to mainlwip thread
> 
> 
> (code is simplified, for cable off i actual call function only once no
> matter this is actually a timer interrupt called in 2 sec intervalls)
> if(cableState == 0)
>  {
>  //link off
>  iface_up = 0;
>  netif_set_link_down(pxNetIfInUse); //method 2
> 
>  /*method 1
>  msg.type= 165;
>  msg.msg.inp.netif = pxNetIfInUse;
>  res = sys_mbox_trypost(toOutput, &msg);*/
> 
>  }
>  else
>  {
>  //link on
>  netif_set_link_up(pxNetIfInUse); //method 2
> 
>  /*Method 1
>  msg.type= 165;
>  msg.msg.inp.netif = pxNetIfInUse;
>  res = sys_mbox_trypost(toOutput, &msg);
>  */
>  }
> 
> 
> 
> Code:
> static void hc_task(void *parameters)
> {
>  struct hc_message mes;
>  mes.client_port_number = 4839;
>  mes.host_addres = "192.168.1.183\0";
>  mes.host_add[0] = 192;
>  mes.host_add[1] = 168;
>  mes.host_add[2] = 1;
>  mes.host_add[3] = 183;
>  mes.host_file = "test/data.php\0";
>  mes.host_port_number = 80;
>  mes.target = "http://192.168.1.183/test/data.php\0";;
>  transferEnd = 0;
>  numberOfPacketsProc = 0;
>  totalRecievedSize = 0;
>  hc_send(&mes, 0);
>  vTaskDelete(NULL);
> }
> 
> 
> The hc_send thread:
> uint_fast8_t hc_send(const struct hc_message *mes, int8_t addParam) {
> 
>  while(!is_netiface_up())
>  {
>  vTaskDelay(500);
>  }
> 
>  if(bufferTmp == NULL)
>  {
>  

Re: [lwip-users] what is the abbreviation for RAW ?

[FreeRTOS Info]

On 10/04/2013 08:06, inurl wrote:
> I didn't find it anywhere, including source code ,document
> 

Sorry - I don't understand your question.

Are you asking what RAW stands for?  As if RAW was an acronym?  If so,
then raw is a word, not an acronym.  The dictionary definition (well,
Google definition) being:

Raw:  (of a material or substance) In its natural state; not yet
processed or purified: "raw silk"; "raw sewage".

So in this case raw means at the lowest level, bits and bytes, without
the higher level protocol abstractions.

Apologies if I have misinterpreted your question...

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 103000 downloads in 2012.

+ http://www.FreeRTOS.org/plus
Trace, safety certification, UDP/IP, TCP/IP, training, and more...


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Stuck in netconn_write()

[FreeRTOS Info]

> There is no vTaskDelay() in my Idle task, but the __wfi instruction. Schould 
> wait for the next tick interrupt

Good - the idle task must *never* block.  Which task would run if the
idle task was blocked?

Later versions of FreeRTOS include a tickless idle mode that stops the
tick interrupt and sleeps in the idle task, but that is very different
to blocking the idle task because when the MCU is sleeping nothing is
executing.

> To protect the TX function I use a critical section so one task can complete 
> the transmit before a new one can do it.

Does the Tx function use FreeRTOS API calls?  If so then you can't use a
a critical section.  Use a mutex instead.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/plus
Trace, safety certification, UDP/IP, TCP/IP, training, and more...


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP 1.4.1 released

[FreeRTOS Info]

On 20/12/2012 07:49, goldsi...@gmx.de wrote:
> l...@piwos.de wrote:
>>
>> i just noticed a problem with the GCC compiler for ARM, in api.h there
>> is the line:
>>
>> #define netconn_write(conn, dataptr, size, apiflags) \
>>   netconn_write_partly(conn, dataptr, size, apiflags, NULL)
>>
>> which will cause an error (netconn_write will not be found here).
>>
> 
> I cannot test on GCC for ARM right now, but according to my knowledge of
> the C preprocessor, this is a perfectly valid line: a line ending on a
> backspace means the preprocessor regards the line as continued with the
> next line's contents. This is used in other places, too (e.g. PP_HTONL
> definition in def.h).


...just ensure there is no white space after the '\' character.  Even if
there isn't in the downloaded files it is possible you have added one in
yourself unknowingly.



Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)

[FreeRTOS Info]

To be clear, my email below related to FreeRTOS-MPU, which is a separate
port to standard FreeRTOS - the latter not using an MPU at all.

[Did other people receive my original email?  I noticed I sent it from
an email address I didn't know I had registered with this list.  In any
case, it is below if not].


On 30/08/2012 09:45, Richard Barry wrote:
> Some replies to FreeRTOS-MPU topics, rather than lwIP topics.  A little
> off topic for this mailing list I think, and not the point of the
> original posters comments, but as it is being discussed I think it is ok
> to give some answers:
> 
>> "Nothing can crash kernel": this would only hold for a kernel
>> that is strictly seperated from tasks stacks and very strictly
>> checks arguments passed from threads to kernel functions,
>> wouldn't it? Is FreeRTOS-MPU designed like that?
> 
> The kernel has extremely strict separation between what is accessible by
> every task.  By default a non-privileged task can only access its own
> stack, and nothing else.  API functions exist to allocate additional
> memory to tasks on a task by task basis - meaning the application writer
> can (for example) share RAM between tasks, or make a section of RAM
> write only to one task and read only to another, etc.
> 
> The kernel is privileged, so can access the task stacks, it has to store
> the task contexts and that is done on the task's stack.  The privileged
> kernel does not use the task stack for its own variables/return
> addresses/etc. though - it uses its own stack as would be expected - so
> having complete junk on the task stack would only cause a crash while
> the system was in an un-privileged mode (assuming the application
> designer has the task running un-privileged) - which would be caught by
> the MPU and not crash the kernel.
> 
> FreeRTOS-MPU does not test input parameters (it is designed to be small)
> in the same way that SafeRTOS does (SafeRTOS, which originated from
> FreeRTOS, is re-engineered to have safety as a primary goal rather than
> size - http://www.SafeRTOS.com).  User code can test before the
> parameter is passed if necessary though.
> 
> [from a different email]
>> So for example, you should have tcpip_thread, communication_thread
>> and app_thread, with safe (queues?) communication comm<->app.
> 
> With regards to queues:  FreeRTOS-MPU switches to privileged mode when
> the queue API function is called to have the (more) trusted kernel code
> copy the data out of the protected memory space into a memory space that
> is only accessible to the kernel.  The same happens in reverse when the
> data is received by another task.
> 
> 
> Regards,
> Richard.
> 
> + http://www.FreeRTOS.org
> Designed for microcontrollers.  More than 7000 downloads per month.
> 
> + http://www.FreeRTOS.org/trace
> 15 interconnected trace views. An indispensable productivity tool.
> 
> 
> 
> On 30/08/2012 09:23, Krzysztof Weso³owski wrote:
>> I would like to add, that in my opinion if LwIP is considered unsafe,
>> all threads using it should be treated this way.
>>
>> So for example, you should have tcpip_thread, communication_thread and
>> app_thread, with safe (queues?) communication comm<->app.
>>
>> Regards,
>> Krzysztof Weso³owski,
>>
>> On Thu, Aug 30, 2012 at 9:51 AM, Simon Goldschmidt  wrote:
>>> jblackarty wrote:
 An: Ivan Delamer , Mailing list for lwIP users 
 
 Betreff: Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)
>>>
> Question: is it important for your application thread and the tcpip
 thread
> to be in different protected memory regions? is it possible for that
> memory to be accessed by both threads?

 As I said already, I did it so. I've placed application thread stack
 in separate memory region and added this region to user
 memory regions of tcpip thread with read/write access. Thanks to this,
 I was able to run my tcpip-enabled application.

 Is it important to avoid this in my application ?
 [..]
>>>
>>> To me, the essence of what you wrote is that the system doesn't run stable. 
>>> That's of course a problem, but it wouldn't run stable with protected 
>>> threads, either. So while I also think that protecting the thread's stacks 
>>> against each other would be a good thing, the lack of this protection 
>>> doesn't seem to be the cause of your problems!
>>>
 Please, note that I didn't even talk about such
 details like that there are chaos is going in whole global
 memory shared between tasks, and network-enabled part of my
 application is not adequate anymore.
>>>
>>> What kind of chaos in global shared memory are you talking about?
>>>
 [..]
 Nothing can crash kernel, provided that tasks are
 run in user-mode and each task has no access to other tasks threads.
 LwIP thread is the only thread which violates this...
>>>
>>> "Nothing can crash kernel": this would only hold for a kernel that is 
>>> strictly seperated from tasks stacks and very strictly ch

[lwip-users] Fwd: Re: Linkedin - Networking (attention off topic)

[FreeRTOS Info]

I would rather keep all lwIP information and discussion in a
single dedicated place, not dispersed across multiple locations.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.



On 08/08/2012 15:20, Funk, Artur wrote:
> I don't know if off topic is allowed or not, sorry If not :>
> 
> Would you mind to build a LwIP developers connection on linkedin?
> Everyone who wants
> to be contacted and connected by further mailing list users, 
> is invited to send his name/surename and location. Others
> are allowed to add the person on linkedin. I would make a start:
> 
> Artur Funk Berlin
> 
> 
> 
> 
> Best Regards 
> 
> Artur
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP with LPC1768 and Eclipse

[FreeRTOS Info]

> On 11/07/2012 13:15, frs709 wrote:
>> Hi guys
>> I am a new guy to the world of micro controller, I am working in a
>> project which needs a TCP/IP stack in lpc1768 without OS by using
>> Eclipse and Yagarto tool chain. lwIP is a good choice for me, but I
>> have no idea where to start. I have done some pre-study and it turns
>> out lpc1768 need a bottom layer (OSI model) driver code as well (In
>> this case I use DP83848c as Ethernet PHY controller). This made me
>> even more confused. Is there anyone who can help me with this? Thanks
>> a lot!
>> Best Regards

See

http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_IO/Demo_Applications/LPCXpresso_LPC1769/NXP_LPC1769_Demo_Description.shtml

It uses an OS, but you should be able to strip the drivers etc. and use
them with the standard super loop lwIP.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LWIP on LPC1769.

[FreeRTOS Info]

On 22/05/2012 02:09, Mauro Antivero wrote:
> First of all, hello everybody.
> 
> And now my first question:
> 
> I have a LPCXpresso board with LPC1769 and I want to run LWIP on it. I
> try the following example:

There is a project running lwIP with both raw and sockets interfaces on
an LPCXpresso LPC1769 here:

http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_IO/Demo_Applications/LPCXpresso_LPC1769/NXP_LPC1769_Demo_Description.shtml

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] mutex API in system layer is necessary ?

[FreeRTOS Info]

On 08/05/2012 06:20, Simon Goldschmidt wrote:
> vincent cui  wrote:
>> I had port latest lwip1.4.0 to my system, it works well . but I found some
>> additional api about mutex are defined in 1.4.0
>>
>> I want to know that are they necessary ?
> 
> No, as it says in sys.h: "Define LWIP_COMPAT_MUTEX if the port has no mutexes 
> and binary semaphores should be used instead". The only disadvantage of using 
> binary semaphores (in this case, the sys_mutex_* functions are defined to 
> their sys_sem_* substitute) is that you can get priority inversion (mutextes 
> are only used for communication between API tasks using netconn or sockets 
> and the tcpip_thread).
> 
> Simon


Trying to keep everything in the same place and out of my own personal
email (FreeRTOS support questions should use the support forum please!),
from a private email:


> For lwIP 1.4.0 with add mutex api in system layer. They are following. I
> write them with freertos mutex api, but it can’t work, once I remove
> those code, lwIP works again .
>
> Who know why ?
>
>
>
> err_t sys_mutex_new(sys_mutex_t *mutex)
>
> {
>
> //  *mutex = xSemaphoreCreateMutex();




There are example FreeRTOS port layers for lwIP in a few places from
which the mutex implementation can just be cut and paste.

A recent(ish) demo is here:
http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_IO/Demo_Applications/LPCXpresso_LPC1769/NXP_LPC1769_Demo_Description.shtml

An older(ish) demo that uses a Windows simulated environment (and now
has an out of date CLI implementation) can be found here:
http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP performance with FreeRTOS

[FreeRTOS Info]

On 24/02/2012 14:43, Chris Ponder wrote:
> Lol, that is no problem, it is good to have the help J
> 
>  
> 
> Yes that is still a long way from what I had hoped for. I had thought
> that the drop from standalone+raw to RTOS+netconn would only be 2 or 3
> Mbps at most, half seems a  little drastic.

How is the network interface signalling that packets have arrived/been
transmitted?

Normally the MAC interrupt will use a semaphore to signal to a task that
new data has arrived and needs processing.  The semaphore will unblock
the task that was waiting for the data, and the task will be prioritised
such that it runs immediately (just as if all the processing was done in
the interrupt itself).

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





> 
>  
> 
> Thanks again
> 
> Chris
> 
>  
> 
> *From:*goldsi...@gmx.de
> *Sent:* 24 February 2012 14:35
> *To:* Mailing list for lwIP users
> *Subject:* Re: [lwip-users] lwIP performance with FreeRTOS
> 
>  
> 
> Chris Ponder wrote:
> 
> Ahh, that helps J
> 
> 
> Hehe, sorry for the confusion. I'm didn't have access to the lwIP
> sources when writing that.
> 
> 
> Yes the correct macro is LWIP_TCPIP_CORE_LOCKING and increased the speed
> to 45.3 Mbps, getting better J
> 
> 
> Hmm, that's still only half of what you get with the raw API, is it? I
> would have expected it to be better...
> 
> Simon
> 
> 
> 
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. If you are not the addressee, any disclosure, reproduction,
> copying, distribution, or other dissemination or use of this
> communication is
> strictly prohibited. If you have received this transmission in
> error please notify the sender immediately and then delete this e-mail.
> E-mail transmission cannot be guaranteed to be secure or error free as
> information could be intercepted, corrupted lost, destroyed, arrive late or
> incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message which arise as a result of e-mail
> transmission. If verification is required please request a hard copy
> version.
> 
> 
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Header Checksum error

[FreeRTOS Info]

> - Header checksum: 0x [incorrect, should be 0x0d6f (maybe caused by "IP 
> checksum offload"?)
> 
> Here is an image from the program:
> http://blog.robertoromo.eu/wp-content/uploads/2012/02/checksum_error.png

I think wireshark is seeing/recording the packet *before* hardware has
added the checksum, hence it is not really an error.  There is an option
somewhere in WireShark to request it to not report that particular
error/warning.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Problem with memory management

[FreeRTOS Info]

On 03/02/2012 10:00, Walter Saegesser wrote:
> I encounter a severe problem with the memory manager (mem.c,
> MEM_USE_POOLS not set, LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT not set).
> 
> My buffer is approx 40kB. An SSL connection to a server on the internet
> does a big amount of allocations/deallocations (mostly small blocks).
> For receiving data from the server I need 1kB blocks.
> 
> It all works fine until all of a sudden the manager is no longer able to
> get a 1kB block and the ‘err’ counter of the mem-stats is counted up
> (every 100ms for about 15s until the system is reset by the watchdog).
> 
>  
> 
> In the debugger I have a real-time monitoring of the used ram
> (lwip_stats.mem.used). The value goes up and down, as expected,
> definitively no accumulation. The high-water-mark is at least 10kB below
> the heap size.
> 
> The system is multitasking. The task trying to get the 1kB block sleeps
> for a while if it fails, thus enabling other tasks to run and possibly
> free memory. However, the error is not recoverable and the system crashes.
> 
> If the systems runs into this situation (one task trying in vain to get
> a 1kB block), you can see the ‘used’ value go down to about 22kB, i.e.
> almost 18kB are free.
> 
>  
> 
> The problem arises always at almost the same amount of data received
> from the server, so I think it’s a systematic problem and not just
> accidental.
> 
> Could this be a bug or what else could be wrong?


If MEM_USE_POOLS is not set could this simply be memory fragmentation?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Hi everybody

[FreeRTOS Info]

On 15/01/2012 15:15, ganezu wrote:
> 
> thanks for your reply  Richard,but i've already done this...I discovered
> google when I had the first contact with the Internet;)).I tried to find
> lwip source code for a dns server and i didn t found it..I really need this
> for my project "implementing a dns server on blackfin bf537 with".It is an
> example with dns client  in analog devices implemented with lwip and I
> believe that i must use lwip;)...Please reply only If you have something
> important to say..
> Thanks!
> Regards,
> Ganezu


Hi Ganezu,

I just provided a very literal answer to the question you actually
asked, which was not "can you point me to a dns implementation", but
"can you help me search the internet".

However, I was making a more subtle point than that.  Your email subject
line is very unhelpful to people who frequent this list with the aim of
helping others, because they will have no idea what your email is about
unless they actually read it.  Likewise, when it gets archived by search
engines, it will be unhelpful to other people searching for the same
thing as you - even though it may eventually contain useful information.

With reference to your intended question - Have you also checked the
lwIP contrib download, in case there is something relevant in there?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Hi everybody

[FreeRTOS Info]

> 
> I'm trying to search on the internet an example with lwip dns server .Can you
> help me?I' ll be very grateful.Thanks anyway

Go to http://www.google.com.  You will be asked for a search string.
Enter "using useful subject text in emails" as your first query, then
"lwip dns server" as your second.  On each search you will be presented
with a list of link options, start with the top, and work you way down,
until you find what you want.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] network driver code for ethernetif.c

[FreeRTOS Info]

On 15/01/2012 13:41, V l wrote:
> I studied through my network interface driver and gained sufficient
> understanding of the network stack.
> I have ported lwip to the ARM device and now in stage of writing the
> ethernetif.c file to interface with my network driver .
> I know now that I have to just replace
> 
> for(q = p; q != NULL; q = q->next) {
> /* Send the data from the pbuf to the interface, one pbuf at a
>time. The size of the data in each pbuf is kept in the ->len
>variable. */
> send data from(q->payload, q->len);
>   }
> 
> 
> send data from(q->payload, q->len); with my driver specific code to send
> the packet . Very nice ! But when I compile this code , its going to ask
> where this driver specific senddata is defined , the header file or
> library .
> How do I resolve this part of the riddle . Its a little newbie kind of
> question . But I have tried , I give up now. Plz help.
> Regards
> Sraddha


You need to write a driver function that sends q->len bytes from
q->payload to the Ethernet hardware.  Where you define that function is
up to you.  You then replace the place-holder text with whatever your
function is called.  Say your function has the following prototype:

long lSendBytesToMAC( xNIC *pvYourInterface, uint8_t *pucBuffer,
uint32_t ulNumBytesToSend );

Then you simply change the code:
"send data from(q->payload, q->len)

to:
lSendBytesToMAC( [whatever], q->payload, q->len );

To compile the file you need to place the prototype for your driver
specific file in a header file (forget the name) that is included from
the same source file.  Naturally, you also have to add your driver
source files (the one where lSendBytesToMAC() is implemented) to the
build too.

I'm not sure if that answers your question.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.






___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] enable socket in lwip

[FreeRTOS Info]

On 07/01/2012 19:00, Gisle Vanem wrote:
> "Carol Lai"  wrote:
> 
>> I ran the windows example and it also stops at "Attempting to open
>> interface number ##" where ## is configNETWORK_INTERFACE_TO_USE value.
>>
>> My dos window shows 7 adapters and I tried all numbers but none of
>> them pass that "attempting" state.  Below is the print out.
>>
>> --
>> Starting lwIP, local interface IP is 172.25.218.200
>> 1. rpcap://\Device\NPF_{2FFF9284-43BC-43DD-BDF1-28185738EFF8} (Network
>> adapter '
>> Microsoft' on local host)
> 
> I doubt that your Winpcap supports remote capture; that's what the
> "rpcap://" scheme
> means. In any case that device isn't writable, so you get no luck with
> that. You need
> to define 'NETWORK_INTERFACE_TO_USE' to a device (GUID) you actually
> have installed.


Using WinXP SP3, my output is as follows:


Starting lwIP, local interface IP is 172.25.218.200
1. rpcap://\Device\NPF_{20B5CDDD-C5BC-4420-A256-903204AE7C2A} (Network
adapter '
Intel(R) 82567LM Gigabit Network Connection (Microsoft's Packet
Scheduler) ' on
local host)
2. rpcap://\Device\NPF_{8018B663-6C6F-4F58-96F0-76F8F3121F9F} (Network
adapter '
Dell Wireless 1510 Wireless-N WLAN Mini-Card (Microsoft's Packet
Scheduler) ' on
 local host)

The interface that will be opened is set by
configNETWORK_INTERFACE_TO_USE which
 should be defined in FreeRTOSConfig.h
Attempting to open interface number 2.
--

configNETWORK_INTERFACE_TO_USE is set to 2, and works fine.


> 
> Btw, I cannot find  'NETWORK_INTERFACE_TO_USE' in any lwIP file. Do you
> mean:
>  #define PACKET_LIB_ADAPTER_GUID   "8D3A23A7-9C6C-408B-A23B-6736F9E56510"

As the message says, configNETWORK_INTERFACE_TO_USE is set in
FreeRTOSConfig.h.  It is not an lwIP file, but tells the FreeRTOS
application which of the available network interfaces it is supposed to
be using for lwIP.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] enable socket in lwip

[FreeRTOS Info]

On 06/01/2012 17:47, Carol Lai wrote:
> Hi, Richard,
> 
> I downloaded the window version but it is asking for wpcap.dll.  Could you 
> recommend a good site to download this dll?
> 

I could be sarcastic and say Google, but will resist and say
http://www.winpcap.org


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] enable socket in lwip

[FreeRTOS Info]

On 04/01/2012 14:47, Carol Lai wrote:
> Does anyone have an example of lwipopts.h that enables socket?  I need
> to use the minimum RAM and ROM for socket support on a TI processor.  We
> don't need DHCP support as we're using a static IP.
>  
> Attached is the lwipopts.h that I currently have.  It is not
> configured to enable the socket yet.
>  
> Thank you.

The FreeRTOS download contains an example command interpreter with a
sockets interface.  The Win32 demo has the same.  I can't guarantee that
either are optimised for RAM usage though, as both systems have ample RAM.

I have a new project that will be published before Embedded World (end
of Feb) on a much smaller micro that also does the same, but the code is
not available yet.

For the MicroBlaze example, start here and follow your nose:
http://www.freertos.org/Free-RTOS-for-Xilinx-MicroBlaze-on-Spartan-6-FPGA.html

For the Win32 example, start here:
http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] makefsdata strange error with .png files

[FreeRTOS Info]

On 03/01/2012 20:40, N.Karakotas wrote:
> Hi,
> 
> No im not using a tmp file I have modified it slightly. Tried to compile
> the visual studio program provided by FreeRtos and got all sorts of
> problems. 

Noting you don't want to spend more time on it, but just for the record,
the FreeRTOS download includes a project to build it, the source code
(obviously) *and* a pre-built .exe.  There is no need to re-build it
therefore, unless you want to change something in it.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] makefsdata strange error with .png files

[FreeRTOS Info]

On 02/01/2012 20:37, N.Karakotas wrote:
> Hi,
>  
> Im using the makefsdata.pl perl script to create the html data. I was
> having a strange problem with .png files not showing up on the browser.
> After tracing the problem I noticed that the array data created by the
> perl script was missing 1 byte of data at the begging of the png header.
> For example below is part of the header bytes of the images:
> Correct:
> 89 50 4E 47 0D 0A 1A 0A 00 00 00
> Wrong:
> 89 50 4E 47 0A 1A 0A 00 00 00
>  
> If you can see byte 5 doesnt contain the 0x0d! When I inserted this to
> the table the image showed up correctly. I cant se why the perl script
> is failing on this line:
>  
> for($j = 0; $j < length($file); $j++) {
> printf(OUTPUT "%#02x, ", unpack("C", substr($file, $j, 1)));
> }
>  
> Im using windows. Any thoughts? Its strange that one has had this
> problem before.

As you are running Windows, I suggest downloading the FreeRTOS zip file
(http://www.freertos.org), unzipping it, then searching the Demo
directory for makefsdata.exe.  It is included in a couple of demo
projects I think, along with a MSVC project to build it.

I don't think I have had a problem with the exe file, although I might
not have used it with a png - although definitely with gifs and jpgs, so
they should be the same with respect to conversion.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] FIXED - Re: inet_chksum.c misbehaving with compiler optimisation?

[FreeRTOS Info]

Hi everybody,

I am pleased to say I can finally move past this point.  Thanks for
everybody's comments, they were indeed very helpful, as it was
indirectly very much execution speed related.

The problem turned out to be in the library code called by my driver.
The DMA code was using an incorrect index, causing the frame being
written to a DMA buffer to overwrite the frame that was being
transmitted by the DMA.  That also explains the corruption I was seeing
on the wire.  Without optimisation the frame had already been transmitted.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 23/11/2011 21:17, FreeRTOS Info wrote:
>> Ok, as would hopefully be expected, checksumming dummy arrays produces
>> the same result with and without the function in question being
>> optimised.  That is good, so I should stop going down that dead end.
>> Thanks for the suggestion, I should have thought to do that myself, doh!
>>
>> I have attached the logs as they look now, and they don't show any
>> strange data at all, but do show the problem with retransmissions.
>> Good.pcap is without optimisation in the checksuming, bad.pcap is with
>> optimisation in the checksumming.  192.168.0.200 is the target.
>>
>> I would be grateful if you could elaborate on the timing theory.  I
>> presume it is because the speed is causing a resource to be exhausted,
>> but where shall I look first.  I checked the stats array some time back,
>> and could not see any error counts incremented.  I also tried to get
>> some debug prints out, but unfortunately the target I have does not make
>> that easy without the CPU being held in debug state for the entire print
>> out (I could write a UART driver and shove the message out there though).
>>
>> The DMA buffers are squeezed into 16K of RAM.  I could try increasing
>> those, but there is very little room.
> 
> 
> Just in case anybody is looking at it, I think as has been suggested by
> various people, speed does seem to be the issue.  To add to the evidence
> of checksumming dummy buffers with/without optimisation, I have now also
> added a forced delay in the check sum function, and everything now runs
> with full optimisation.
> 
> I would still be interested in any elaboration on where to look for the
> part that is falling over at higher execution speed, as I mentioned above.
> 
> I am concentrating on the driver again right now, but none of the error
> bits are being set (out of descriptors, overrun, underrun, etc.).  I
> have also managed to double the number of DMA buffers but cutting out
> other parts of the code.
> 
> If it was queueing packets for transmission due to execution speed
> increases, is there a limit to the queue length, or is it just
> determined by RAM availability?  If there was starvation of a resource,
> pbuf or whatever, would that show up by inspecting the stats array?
> 
> Regards,
> Richard.
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?

[FreeRTOS Info]

> Ok, as would hopefully be expected, checksumming dummy arrays produces
> the same result with and without the function in question being
> optimised.  That is good, so I should stop going down that dead end.
> Thanks for the suggestion, I should have thought to do that myself, doh!
> 
> I have attached the logs as they look now, and they don't show any
> strange data at all, but do show the problem with retransmissions.
> Good.pcap is without optimisation in the checksuming, bad.pcap is with
> optimisation in the checksumming.  192.168.0.200 is the target.
> 
> I would be grateful if you could elaborate on the timing theory.  I
> presume it is because the speed is causing a resource to be exhausted,
> but where shall I look first.  I checked the stats array some time back,
> and could not see any error counts incremented.  I also tried to get
> some debug prints out, but unfortunately the target I have does not make
> that easy without the CPU being held in debug state for the entire print
> out (I could write a UART driver and shove the message out there though).
> 
> The DMA buffers are squeezed into 16K of RAM.  I could try increasing
> those, but there is very little room.


Just in case anybody is looking at it, I think as has been suggested by
various people, speed does seem to be the issue.  To add to the evidence
of checksumming dummy buffers with/without optimisation, I have now also
added a forced delay in the check sum function, and everything now runs
with full optimisation.

I would still be interested in any elaboration on where to look for the
part that is falling over at higher execution speed, as I mentioned above.

I am concentrating on the driver again right now, but none of the error
bits are being set (out of descriptors, overrun, underrun, etc.).  I
have also managed to double the number of DMA buffers but cutting out
other parts of the code.

If it was queueing packets for transmission due to execution speed
increases, is there a limit to the queue length, or is it just
determined by RAM availability?  If there was starvation of a resource,
pbuf or whatever, would that show up by inspecting the stats array?

Regards,
Richard.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] CHAR_BIT=16?

[FreeRTOS Info]

On 23/11/2011 12:27, Simon Goldschmidt wrote:
> Kieran Mansley  wrote:
>> Yes, I think the 16-bit int is likely to be the biggest hurdle.  It is
>> something we should really try and improve with lwIP, but progress is likely
>> to be slow.
> 
> Things like this are hard to change when you don't have corresponding 
> hardware. I'd love to see a patch that fixes this to see if we can integrate 
> it.
> 

I don't think a 16 bit int would cause too much of a problem, with some
inspection/effort.  I believe, however, the OP said it was a 16 bit
char, which leads me to think he is probably using a DSP, which would
definitely cause a problem.  Maybe definitely is too strong a word, but
as the original reply said, making it work would probably require a
large effort.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] sys.c - sys_msleep

[FreeRTOS Info]

On 23/11/2011 06:58, Martin Velek wrote:
> Hi,
> 
> I have defined sys_msleep() to vTaskDelay() - (1 tick == 1 ms) in
> sys_arch.h, because the default implementation is quite tricky.

In which case, 1ms is the maximum, and the resolution, not the absolute.
 You cannot have granularity above the tick period, so if you what "at
least" 1ms, the delay period needs to be 2.  Then you will have between
0. and 1.999.


> However the compiler complains about vTaskDelay() redefinition thus I
> had to modify sys.c, see below. Is this modification correct?

??? How have you redefined it?  All you need to do is #include
"FreeRTOS.h", then #include "task.h", then call vTaskDelay() in your code.

Please send any follow ups to this part of your question to the FreeRTOS
support forum, not this list.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?

[FreeRTOS Info]

On 22/11/2011 20:13, goldsi...@gmx.de wrote:
> FreeRTOS Info wrote:
>> Just in case anybody is watching this thread:
>>
>> As unlikely as this all seems, having previously isolated one file, I
>> have now isolated it to a single function: lwip_standard_chksum().
>>
>> I have the entire applicatino running at maximum optimisation, except
>> this function, and everything is happy.
>>
>> Put the lowest optimisation on just this single function (which is now
>> in its own file), and the network works, but with a lot of corruption on
>> the wire.
> Like Kieran and Stephen, I wouldn't rule out the possibility of a timing
> issue, too. Especially since checksumming was the most time consuming
> task in lwIP when I last benchmarked (aside of memcpy, but I guess you
> haven't changed the amount of optimization of memcpy in your tests as it
> often comes precompiled with the C library).
> 
> Nevertheless, to prove the function fails, why don't you run a test on
> random data comparing the results of the optimized checksum function
> with a non-optimized version? You can even let that test run for a while
> if you put the two functions into the same binary. If it's a compiler
> bug or anything in that area, this test should show it.

Good thinking!  Will do and report back.



> 
> BTW: what do mean with 'a lot of corruption on the wire', invalid
> checksums or more errors?

It was described in a previous email.  Sorry I have to run now but will
be back online later this evening.  I will explain it again when I post
the results of the above mentioned test.

Regards,
Richard.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?

[FreeRTOS Info]

On 22/11/2011 19:57, Stephen Cleary wrote:
> I wouldn't rule out the possibility of a timing issue.
> 
> We are (currently) running lwIP 1.3.2 with FreeRTOS 4.8.0, on
> SAM7_GCC (GCC/ARM7_AT91SAM7S) with EMAC code from
> lwip_Demo_Rowley_ARM7.

Wow.  It is on version 7.0.2 now ;o)


> 
> We don't override LWIP_CHKSUM, so the standard (Version #1)
> lwip_standard_chksum from inet_chksum.c is the checksum code we use.
> We normally compile inet_chksum.c with -O1 (even in debug mode, for
> code size reasons), and we don't see the problems you're seeing.

Yes, I am confused by this as the function is not doing anything
remotely suspicious.  I could understand if a function was passing in a
bum pointer value, but the functions passing pointers in are optimised.

I too have used the exact same code, with full optimisation, with other
compilers, even other GCC compilers (MicroBlaze for example) without any
problems.  Your SAM7 will be using ARM and optionally THUMB
instructions, my target is using THUMB2, so even if we were using the
same GCC compiler version the code gen would be different.

I'm minded to ignore the problem for now (it is suckup up time) in the
hope that I can try it with a different compiler version soon.  I need
to know its cause before I can release the projects though.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?

[FreeRTOS Info]

>>> Does this make any sort of sense?
>>
>> Not really. I can't see how a bug in that code would cause the
>> symptoms you describe. My guess is that the optimisation is
>> causing a change in timing that leads to some race condition being
>> exposed. E.g. if it is running faster there is more chance of
>> packets backing up, resulting in a queue that then becomes
>> corrupted. When it was running slower the packets never backed up
>> and so there was no queue, and no chance for corruption.
>> Unfortunately this means that the file being optimised may not have
>> the bug that you're seeing.
>
>
> I agree it seems unlikely to be something in that file. The file,
> from my inspection, is just a stand along C file will a few
> functions. No static data, no volatile data.
>
> However, I don't think your suggestion that it might be a speed of
> execution issue that is highlighting, rather than causing, an error
> is likely either. My rationale being that, I can have optimisation
> in *all* files set to -O0 (an there are a lot of files in the
> project) except inet_chksum.c, which has -O1, and the problem occurs.
> Therefore the application and stack are going to be running at near
> identical speed to when everything has -O0. It is only optimisation
> on that file that seems to be causing (probably highlighting, rather
> than causing) a problem. The inverse is also true, optimising *all*
> files to the max, and having inet_chksum.c without optimisation does
> not show the problem, and then everything really will be running much
> faster.



Just in case anybody is watching this thread:

As unlikely as this all seems, having previously isolated one file, I
have now isolated it to a single function: lwip_standard_chksum().

I have the entire applicatino running at maximum optimisation, except
this function, and everything is happy.

Put the lowest optimisation on just this single function (which is now
in its own file), and the network works, but with a lot of corruption on
the wire.

Could even be getting into compiler bug territory here.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?

[FreeRTOS Info]

Hi Kieran,

On 21/11/2011 19:40, Kieran Mansley wrote:
>
> On 20 Nov 2011, at 22:06, Richard Barry wrote:
>
>> Does this make any sort of sense?
>
> Not really.  I can't see how a bug in that code would cause the
> symptoms you describe.  My guess is that the optimisation is causing
> a change in timing that leads to some race condition being exposed.
> E.g. if it is running faster there is more chance of packets backing
> up, resulting in a queue that then becomes corrupted. When it was
> running slower the packets never backed up and so there was no queue,
> and no chance for corruption.  Unfortunately this means that the file
> being optimised may not have the bug that you're seeing.


I agree it seems unlikely to be something in that file.  The file, from
my inspection, is just a stand along C file will a few functions.  No
static data, no volatile data.

However, I don't think your suggestion that it might be a speed of
execution issue that is highlighting, rather than causing, an error is
likely either.  My rationale being that, I can have optimisation in
*all* files set to -O0 (an there are a lot of files in the project)
except inet_chksum.c, which has -O1, and the problem occurs.  Therefore
the application and stack are going to be running at near identical
speed to when everything has -O0.  It is only optimisation on that file
that seems to be causing (probably highlighting, rather than causing) a
problem.  The inverse is also true, optimising *all* files to the max,
and having inet_chksum.c without optimisation does not show the problem,
and then everything really will be running much faster.

Does the fact that the problem only seems to occur when the data being
transmitted exceeds a single Ethernet frame give any clues as to where
else there could be a problem?

I can try stepping through inet_chksum to see if I can see if an issue
arises, but stepping optimised code, even when optimisation is low, is a
bit tricky.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] tcp/ip task - stack size

[FreeRTOS Info]

On 13/11/2011 06:41, Martin Velek wrote:
> Hi,
> 
> I am using lwip 1.4.0 on the ARM7(32bit) platform with FreeRTOS and
> NO_SYS = 0. There is a parameter to setup stack size of the core lwip
> task inside lwip header. Has anyone experienced with the smallest
> possible size (in bytes) to save memory? I mean the worst case
> scenario when all relevant options are enabled. I do not include user
> callbacks called from tcp/ip context.

You can do this experimentally by viewing the high water mark of the
consumed stack, then adjusting as necessary.  If you overflow the stack,
that can be trapped.

See:
http://www.freertos.org/uxTaskGetStackHighWaterMark.html
http://www.freertos.org/Stacks-and-stack-overflow-checking.html

If you have a way of viewing the output you can also use:
http://www.freertos.org/a00021.html#vTaskList

If you are using IAR, some Keil versions, or Eclipse, then the kernel
aware plug in will also show you the stack high water mark.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] New to lwip. Where is uIP?

[FreeRTOS Info]

On 07/11/2011 22:56, Patrick Suteja Teh wrote:

> Where is uIP main website? When I google it, it re-directs me to Contiki
> OS. I know Contiki OS is using uIP but does uIP have separate
> development branch or is it now really part of Contiki OS?

As was told to me - the uIP wiki was hacked away, and rather than being
restored, was redirected to Contiki.

> I'm trying to port lwip to PIC24 that has 128K Flash and 8K memory, no
> underlying OS just a single threaded core, C30 compiler, expecting
> running TCP/IP over SLIP. I can remove ARP, Ethernet driver and UDP. Is
> it possible? I can't find any info porting to PIC24 using lwip which
> make me think it may not be possible.

Others here will be able to give a more informed answer than me, but I
would think, if you stuck to the raw API and minimal configuration, you
should be able to get something working, but I'm not sure how useful it
would be because it might not leave room for your application (due to
RAM constrains, rather than ROM constraints).

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Fw: (no subject)

[FreeRTOS Info]

Could you please provide details of what you changed.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 29/09/2011 07:29, Anirudha Sarangi wrote:
> Hi Kieran,
> I was playing with some of the new parameters that are added in lwip140.
> I got good improvement in numbers.
> The numbers improved from around 66 MB to 82 MB.
>  
> With the same hardware and same application files (compiler options are
> also same), lwip130 gives me a number of 92-93 MB for txperf and lwip140
> gives me a number of 82 MB. There is still a difference of 10 MB.
>  
> I want to send you the pcap files for both. Old as well as new lwip. But
> not sure how. The pcap files are quite large.
>  
> Is there anyway I could send them to you? Alternate mail id or something?
>  
> regards
> Anirudha
> 
> *From:* Kieran Mansley 
> *To:* Mailing list for lwIP users 
> *Sent:* Wednesday, 28 September 2011 5:04 PM
> *Subject:* Re: [lwip-users] Fw: (no subject)
> 
> 
> On 28 Sep 2011, at 12:15, Anirudha Sarangi wrote:
> 
>> Hi Kieren,
>> Do you mean capturing the packets in wireshark and sending you the log?
> 
> Exactly.  Please send the pcap file, not just the textual log.
> 
> Kieran
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpserver problem

[FreeRTOS Info]

On 21/09/2011 14:31, vincent cui wrote:
> Richard:
> 
> I reference to "basicsocketcommandserver" , it is almost as mine. So
> I suppose mine code is fine. 

That just uses the sockets interface, and is unlikely to be a problem
unless your lwipconfig.h is wrong.  What you should be looking at is how
packets are passed from the network driver into the stack - that is the
bit that is important to get right in a multi tasking environment.

> But I also found some problem. 1.
> configTICK_RATE_HZ, the DEFINE value is 1000ms , It means switching
> task when tick trigger. So I change it to 5ms.

1000Hz = 1ms period, not 1000ms!  The HZ in the name denotes the units
as Hertz.

If you set the parameter to 5, you will get 200ms (extremely slow) not
5ms.  See the description of the parameter here:
http://www.freertos.org/a00110.html.  That is a very basic thing to get
right before you do anything else, and this mailing list is not the
correct place to be asking FreeRTOS questions.


> 2. my server code for dealing with GET command will send a big of
> data, and those data is defined as global variable So It is possible
> for lwIP hang when new TCP coming but old TCP is not handled done
> yet..
> 
> Does it make sense ?

No.

I think you are describing something to do with mutual exclusion on a
global variable that is in your application?  If so, you will have to
work that out.

Regards,
Richard

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

> 
> 锘?Vincent Cui Sr.Firmware Engineer Mobile: +8613482482211 Tel: +86
> 21 34612525x6104 Fax: +86 21 34619770 E-Mail:
> vincent@enlogic.com Shanghai EnLogic Electric Technology Co.,
> Ltd. Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui
> District, Shanghai, 200233 http://www.enlogic.com -Original
> Message- From: FreeRTOS Info [mailto:nos...@freertos.org] Sent:
> 2011年9月20日 22:48 To: Mailing list for lwIP users Cc: vincent
> cui Subject: Re: [lwip-users] httpserver problem
> 
> FreeRTOSConfig.h will be irrelevant.  sys_arch much more relevant.
> 
> There are some FreeRTOS examples that demonstrate socket usage in a 
> multitasking environment - although thus far only a command
> interpreter, so nothing that will put the stack under the same load
> as an HTTP server has the potential to do.
> 
> From what I have read on this list, the normal answer seems to be,
> there could be a threading issue with the way your interrupts are
> interacting with the stack.
> 
> Regards, Richard.
> 
> + http://www.FreeRTOS.org Designed for Microcontrollers. More than
> 7000 downloads per month.
> 
> 
> 
> 
> 
> On 20/09/2011 15:33, vincent cui wrote:
>> The bug happen in dynamic... If I dump the lwipopt and freertos
>> configuration files.  Do you help to figure it out ?
>> 
>> ï»?Vincent Cui Sr.Firmware Engineer Mobile: +8613482482211 Tel:
>> +86 21 34612525x6104 Fax: +86 21 34619770 E-Mail:
>> vincent@enlogic.com Shanghai EnLogic Electric Technology Co.,
>> Ltd. Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui
>> District, Shanghai, 200233 http://www.enlogic.com
>> 
>> -Original Message- From:
>> lwip-users-bounces+vincent.cui=enlogic@nongnu.org
>> [mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On
>> Behalf Of Kieran Mansley Sent: 2011Äê9ÔÂ20ÈÕ 22:30 To:
>> Mailing list for lwIP users Subject: Re: [lwip-users] httpserver
>> problem
>> 
>> On Tue, 2011-09-20 at 14:10 +, vincent cui wrote:
>>> But I really don't know why lwIP will hang ...
>> 
>> It's either (i) a bug in lwIP; or (ii) a bug in your port; or
>> (iii) badly configured for the load you're putting it under and has
>> run out of resources.
>> 
>> Kieran
>> 
>> 
>> ___ lwip-users mailing
>> list lwip-users@nongnu.org 
>> https://lists.nongnu.org/mailman/listinfo/lwip-users 
>> ___ lwip-users mailing
>> list lwip-users@nongnu.org 
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] httpserver problem

[FreeRTOS Info]

FreeRTOSConfig.h will be irrelevant.  sys_arch much more relevant.

There are some FreeRTOS examples that demonstrate socket usage in a
multitasking environment - although thus far only a command interpreter,
so nothing that will put the stack under the same load as an HTTP server
has the potential to do.

>From what I have read on this list, the normal answer seems to be, there
could be a threading issue with the way your interrupts are interacting
with the stack.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





On 20/09/2011 15:33, vincent cui wrote:
> The bug happen in dynamic...
> If I dump the lwipopt and freertos configuration files.  Do you help to 
> figure it out ?
> 
> ï»?Vincent Cui
> Sr.Firmware Engineer
> Mobile: +8613482482211
> Tel: +86 21 34612525x6104
> Fax: +86 21 34619770
> E-Mail: vincent@enlogic.com
> Shanghai EnLogic Electric Technology Co., Ltd.
> Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui District, 
> Shanghai, 200233
> http://www.enlogic.com
> 
> -Original Message-
> From: lwip-users-bounces+vincent.cui=enlogic@nongnu.org 
> [mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On Behalf Of 
> Kieran Mansley
> Sent: 2011Äê9ÔÂ20ÈÕ 22:30
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] httpserver problem
> 
> On Tue, 2011-09-20 at 14:10 +, vincent cui wrote:
>> But I really don't know why lwIP will hang ... 
> 
> It's either (i) a bug in lwIP; or (ii) a bug in your port; or (iii)
> badly configured for the load you're putting it under and has run out of
> resources.
> 
> Kieran
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Couldn't find any FreeRTOS + lwIP 1.4 port for the NXP Cortex family

[FreeRTOS Info]

I have one, but it is not published yet.  The lwIP stuff is all done,
but I am putting in other non TCP/IP related stuff too.  It uses
LPCXpresso/GCC, is that an good to you?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 16/09/2011 01:33, Felipe de Andrade Neves L. wrote:
> Does anyone know where could I get it ?
> 
> Att.
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] With logs ... Re: Delayed Ack causing problems? Where to call tcp_nagle_disable()?

[FreeRTOS Info]

Excellent.  Thanks.  I will update as necessary.

Output message are not always easy to view in embedded environments.
What I should do is run all lwipopts files through the Windows
environment, where viewing the warnings is easy.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 13/09/2011 20:54, goldsi...@gmx.de wrote:
> FreeRTOS Info wrote:
>> That would be excellent - and exactly the feedback I would look for.
> 
> Alright, so it turns out the lwipopts.h *was* the reason for the poor
> performance. Using the LPC17xx one, I had the same poor performance with
> my win32 port. I got it working by changing the following line:
> 
> #define TCP_SND_BUF(TCP_MSS*2) // was: 2048
> 
> That ensures that TCP isn't limited too before sending 2 mss-sized
> segments (which is the borderline for delayed ACKs on most systems).
> 
> BTW: there *are* sanity checks for these defines in init.c. However,
> they are (yet) runtime checks that output a warning via
> LWIP_PLATFORMDIAG in LWIP_DEBUG mode, so there's a high risk of not
> seeing them. Given the time we spent on this, I'll change them to
> compile-time errors that can be disabled. There are also other sanity
> checks that fail with your configuration. While these can be ignored in
> the very special case of the webserver, I'd strongly recommend to change
> your lwipopts.h to obey all of them.
> 
> I'll update init.c in git these days, and I'll have to adapt the default
> values in opt.h, too, since they fail the sanity checks, too :-(  -->
> bad example!
> 
> Simon
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] With logs ... Re: Delayed Ack causing problems? Where to call tcp_nagle_disable()?

[FreeRTOS Info]

Hi Simon,

That would be excellent - and exactly the feedback I would look for.  As
stated previously, my intention is for these to be "reference"
implementations, which is why I am using both the raw and sockets
interfaces, so there is an example of each.

Various lwipopts files are attached, renamed to indicate which project
they are used with.  From your ping pong explanation, it sounds like the
cause lies within.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 13/09/2011 14:38, Simon Goldschmidt wrote:
> Richard Barry  wrote:
>> I had to change lwipopts.h slightly to reduce the RAM footprint
> 
> In fact, the lwipopts.h settings are the most interesting here. Would you 
> mind sending your file (as attachment)?
> 
> There are some things I don't (yet) understand in the traces (e.g. why does 
> the client announce an MSS of 1260 only? I would have expected 1460 here...)
> 
> The problem could be that you seem to be limited to 2048 byts of snd_buf and 
> with nagle enabled, lwIP-tcp waits to fill a 2nd segment (of 1260 bytes), 
> which it can't and thus doesn't send (maybe we should enhance the nagle-check 
> here?).
> 
> For decent TCP performance, you should ensure that:
> - TCP_WND is at least 4 * TCP_MSS (or the remote mss here)
> - SND_BUF is as big as the window (4 * mss might also be enough)
> - SND_QUEUELEN should not limit the transfer either (i.e. when passing the 
> copy-flag to tcp_write, it should be at least 4 and you should call tcp_write 
> with the biggest possible chunk size)
> 
> Not obeing the rules above will make the connection slow (i.e. you will 
> prevent the sliding window algorithm to work smoothly and instead turn your 
> TCP connections into a ping-pong style of DATA-ACK-DATA-ACK etc.).
> 
> I'll try to reproduce (and maybe fix) this with your lwipopts.h.
> 
> Simon
/*
 * Copyright (c) 2001-2003 Swedish Institute of Computer Science.
 * All rights reserved. 
 * 
 * Redistribution and use in source and binary forms, with or without 
modification, 
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice,
 *  this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 *  this list of conditions and the following disclaimer in the 
documentation
 *  and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 *  derived from this software without specific prior written permission. 
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED 
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT 
 * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
PROCUREMENT 
 * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING 
 * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
POSSIBILITY 
 * OF SUCH DAMAGE.
 *
 * This file is part of the lwIP TCP/IP stack.
 * 
 * Author: Adam Dunkels 
 *
 */
#ifndef __LWIPOPTS_H__
#define __LWIPOPTS_H__

#include 

/* Define platform endianness (might already be defined) */
#define BYTE_ORDER LITTLE_ENDIAN

/* Using the Lite Ethernet IP. */
#define XLWIP_CONFIG_INCLUDE_EMACLITE 1

/* SSI options. */
#define TCPIP_THREAD_NAME   "tcpip"
#define LWIP_HTTPD_MAX_TAG_NAME_LEN 20
#define LWIP_HTTPD_MAX_TAG_INSERT_LEN   1500
#define TCPIP_THREAD_PRIO   configLWIP_TASK_PRIORITY
#define TCPIP_THREAD_STACKSIZE  configMINIMAL_STACK_SIZE * 3

/* MBox sizes cannot be zero, which is their default. */
#define DEFAULT_TCP_RECVMBOX_SIZE   5
#define DEFAULT_ACCEPTMBOX_SIZE 5
#define TCPIP_MBOX_SIZE 10

/* FreeRTOS is used. */
#define NO_SYS  0

/* Sockets are used for the command interpreter. */
#define LWIP_SOCKET 1

/* In this example, only the raw API is used. */
#define LWIP_NETCONN1

/* SNMP and IGMP are not required by this simple demo.  ICMP is always useful
though. */
#define LWIP_SNMP   0
#define LWIP_IGMP   0
#define LWIP_ICMP   1

/* DNS is not going to be used as this is a simple local example. */
#define LWIP_DNS0

Re: [lwip-users] Problem with lwip 1.3.2

[FreeRTOS Info]

Into the land of guessing and speculation here, but here goes:

1) Your network driver is failing under load.  Are you checking the
error bits in the MAC status register, clearing them, and recovering
from errors?  If the network interrupts stop, then there are no packets
being received, and lwIP will do nothing because there is nothing for it
to do.

2) You have your MAC in promiscuous mode.  Otherwise, it would make no
difference if you were behind a hub or a switch.  Turning promiscuous
mode off will mask, although not cure or fix, the issue.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





On 12/09/2011 10:25, Magnus S wrote:
> Hello,
> I have some experienced problems when using lwip 1.3.2.
> 
> We have been using our embedded system successfully for a while, but we
> have now performed load tests/stress tests,
> and we have discovered that in certain circumstances the system
> misbehaves, or hangs completely.
> 
> Our system connects to a server periodically, and exchanges some data.
> In the tests, a 1 minute period has been used, so the system has been
> connecting to the server once a minute.
> 
> We have investigated how well the device handles unrelated ethernet
> traffic, so we have connected the device to an
> old hub instead of a switch, which means that the PHY/MAC receives all
> the data present on the ethernet.
> 
> In the test two Linux machines were used, connected to the same hub as
> our device.
> One of the Linux PC:s acted as a web client, and the other as a web server.
> a 6 MB file was repetedly downloaded to the client, with a 1 second
> delay between each download.
> This means that the ethernet will be completely saturated for a few
> seconds, and then almost idle for one second.
> 
> With this setup, the device will connect once a minute and this normally
> succeeds for a few minutes or so.
> But after a while (normally less than 10 minutes), the system starts to
> misbehave, and hangs completely.
> 
> If a switch is used instead of a hub, the problem is not seem, the
> system works as expected.
> 
> We have investigated the problem cause, and have found that the
> application hangs on the following line in the lwip source code:
> tcpip.c, function tcpip_apimsg():
> sys_arch_sem_wait(apimsg->msg.conn->op_completed, 0);
> 
> This call will never return, and the task will hang forever.
> 
> It seems as something should trigger the semaphore "op_completed", but
> this never happens.
> 
> What could be the cause of this problem?
> 
> We believe that the problem happens when the ethernet is saturated, and
> lwip fails to send an ethernet packet.
> 
> The error handling routines should handle this gracefully, but it seems
> as this case is not handled properly.
> 
> Do you have any suggestions for how this should be solved? Has anyone
> else experienced something similar?
> 
>  
> 
> Regards
> 
> /Magnus
> 
>  
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Delayed Ack causing problems? Where to call tcp_nagle_disable()?

[FreeRTOS Info]

Hi Simon,


On 09/09/2011 09:39, Simon Goldschmidt wrote:
> FreeRTOS Info  wrote:
>> The simulator is exactly that - it is running the FreeRTOS code, which
>> is normally real time, in a non real time windows environment.  It is
>> simulated in the sense that the only way to get the algorithms to run as
>> expected [..] is to have simulated time move much more slowly that
>> actual time.
> 
> That's OK with me, I only wanted to point out that the httpd does *not* need 
> nagle to be disabled, it's fast with it enabled and doesn't gain anything 
> from disabling it.

Yes - the windows simulator does not really tell me anything about the
timing of the TCP/IP applications, so I didn't recognise there was a
problem when using the simulator.  I only recognised there was a problem
when I moved the code onto a proper platform, which happened to be a
Microblaze.

http://www.freertos.org/Free-RTOS-for-Xilinx-MicroBlaze-on-Spartan-6-FPGA.html

Note the microblaze example does not yet include the command console, so
is only using lwIP with its raw interface.

I can get the hardware out again and retry it with/without nagle, just
in case there was something else in the mix that was causing the
perceived problem.  The source code running on the Microblaze (barring
the command console) is the same as that running in the simulator -
other than the MAC driver, naturally.

---

Regarding the default mbox sizes, there was a definite reason why I had
to change them.  It was so definite I cannot remember off hand exactly
why the change was needed, but removing the new definitions would show
it up again right away.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Delayed Ack causing problems? Where to call tcp_nagle_disable()?

[FreeRTOS Info]

On 08/09/2011 22:22, goldsi...@gmx.de wrote:
> FreeRTOS Info wrote:
>> Umm.  I can describe the set up I have, if that helps.  Actually, the
>> code is all available here if you want to look at that...
>>
>> http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server
>>
>>
>> ...but as far as I recall, the only modification I made was that in the
>> post you replied to before this.
> That took me a while...
> 
> Funny, I loaded that ZIP file, added the disable_nagle call and it still
> loads slow, while it loads normally fast on my win32 test port.
> However, even with the same lwipopts.h, the FreeRTOS sim is not as fast...

The simulator is exactly that - it is running the FreeRTOS code, which
is normally real time, in a non real time windows environment.  It is
simulated in the sense that the only way to get the algorithms to run as
expected (for the correct task to run at the correct time, in the
correct sequence) is to have simulated time move much more slowly that
actual time.  If that makes sense.  I believe your port is just running
the lwIP stack as fast as it can, whereas the FreeRTOS simulator is
designed to allow you to develop and debug FreeRTOS code in a
"convenient" (?) environment, before moving it to a "real" environment.
 The lwIP stack being in a FreeRTOS task.  There is a bit more here:

http://sourceforge.net/projects/freertos/forums/forum/382005/topic/4693065


> 
> BTW: sys_mbox_new() should assum standard values if size==0!

Could you elaborate on that point please?  Presumably there is something
in sysarch that needs changing.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





> 
> Simon
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Free LwIP resources

[FreeRTOS Info]

On 08/09/2011 07:34, AMSN wrote:
> 
> Hi all,
> 
> I am using lwIP v1.3.2 with FreeRTOS v6.1.0. My application is a web server
> based on netconn API.
> I have four tasks: tcpip, Ethernet interface, http and dhcp.
> 
> I am looking for a method that allow the following:
> - delete all threads
> - free LwIP resources
> - set down and remove the netif
> Since I need to re-start the application again.
> 
> Please give me some comments.
> Thank you very much !


First - I don't know exactly what you are doing, so this suggestion
might not be appropriate, but if you are truly restarting the entire
application, then the simplest thing to do would reset the
microcontroller (either hard reset using the watchdog, or a soft reset
in software).

Second - I don't want to get into FreeRTOS support here.  This is an
lwIP list and FreeRTOS has its own support forum.  Superficially though,
as far as deleting FreeRTOS tasks go, then when you create a task using
xTaskCreate() you have the option of obtaining a handle to the task,
that can then be used to delete the task.  You must do that with care
though, if the task is blocked on a queue or such like.  You might also
want to delete the queues, etc.  So you don't get into memory
fragmentation problems though, it might be better to design your tasks
such that they can go back to their start rather than deleting them then
recreating them.

Restarting the lwIP tasks will cause the lwIP init and MAC driver
functions to be called again, on the assumption they are not called from
main() before the scheduler is started.  The effect will probably be
different depending on the type of memory management you are using (for
example, you don't want malloc() memory leaks if malloc() is used).  I
will let the lwIP experts answer that fully though.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] FreeRTOS / lwip multiple connections

[FreeRTOS Info]

On 02/09/2011 01:12, vincent cui wrote:
> HI :
> 
> I want to create a semaphore (value is 10) to deal with max connection . but 
> freertos only provide mutex and binary semaphore...
> Is there other way to come it true ?

Yes.  http://www.freertos.org/CreateCounting.html


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





> 
> ï»?Vincent Cui
> Sr.Firmware Engineer
> Mobile: +8613482482211
> Tel: +86 21 34612525x6104
> Fax: +86 21 34619770
> E-Mail: vincent@enlogic.com
> Shanghai EnLogic Electric Technology Co., Ltd.
> Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui District, 
> Shanghai, 200233
> http://www.enlogic.com
> 
> -Original Message-
> From: lwip-users-bounces+vincent.cui=enlogic@nongnu.org 
> [mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On Behalf Of 
> Kieran Mansley
> Sent: 2011Äê9ÔÂ2ÈÕ 3:22
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] FreeRTOS / lwip multiple connections
> 
> 
> On 31 Aug 2011, at 01:18, vincent cui wrote:
> 
>> K:
>> You mean I need make accept socket to be non-blocking , right ?
> 
> No, I'm not sure why you need any of your sockets to be non-blocking.
> 
> Kieran
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip tcp hangup

[FreeRTOS Info]

Maybe the best thing to do is try and work out why it is not currently
working as intended, rather than to work out a workaround to a problem
that should not exist.

What is the problem?  Is it that the select() statement is misbehaving,
and so returning unnecessarily, and therefore using up processing
resources.  Or is it that select is returning invalid data, and hence
using up too many resources.  Or is it something else entirely?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 01/09/2011 10:36, Simon Goldschmidt wrote:
> FreeRTOS Info  wrote:
>> Presumably accept() will keep the task in the Blocked state (i.e. not
>> using any CPU time) until there is something to accept.  This is the
>> intended usage model when using any kernel, be it FreeRTOS or otherwise,
>> isn't it?
> 
> Yep, it is. I don't understand it either, I just assumed that this was to 
> prevent the webserver eating up too many resources...
> 
> Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip tcp hangup

[FreeRTOS Info]

I'm trying to follow this discussion, but it is not clear to me why the
delay is required at all?

Presumably accept() will keep the task in the Blocked state (i.e. not
using any CPU time) until there is something to accept.  This is the
intended usage model when using any kernel, be it FreeRTOS or otherwise,
isn't it?

When there is something to accept, a task is created to handle the
connection (if necessary, but that could become unwieldy if there are a
*lot* of simultaneous connections), then the original task loops back
and Blocks again until there is something else to do.

Am I missing the point here - and if so - what is the point I am missing?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 01/09/2011 10:23, Simon Goldschmidt wrote:
> vincent cui  wrote:
>> while (1) 
>>  {
>> clientfd = lwip_accept(lSocket, (struct sockaddr*)&client_addr,
>> &addrlen);
>>  if (clientfd > 0)
>>  {
>>  xTaskCreate( httphandler, NULL, 128, (void *)&clientfd,
>> HTTP_TASK_PRIORITY, NULL );
>>  vTaskDelay(100);
>>  }
>>  else
>>  {
>>  lwip_close (clientfd);
>>  }
>> }
>>
>>
>> I have added it after accept loop 
> 
> No, after the accept() call, but before the next accept() call in the loop, 
> so between 2 calls to accept(), you will delay.
> 
> Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] FreeRTOS / lwip multiple connections

[FreeRTOS Info]

Is this the project you are referring to?

http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server

If so, look at the command interpreter rather than the web server.  It
uses sockets, and although it is structure to only process one
connection at a time, I think converting it to allow multiple
connections should be simple (?).

>   * checks for incoming data (nonblocking)
>   * checks a Queue for outgoing data (nonblocking)
>   * wait 1 ms (to prevent 100% cpu usage)
>   * repeat :-)

This does not sound like a good solution, unless you are running at the
lowest (idle) task priority.  At any other priority, you are still going
to be using most of the CPU time even when there is no processing to
perform.  A better solution would be to block the TCP/IP processing
until a TCP/IP related event occurs - a semaphore or queue can be used
to signal the event, so the task blocks on the queue.  An event can be
external, like a packet arriving, or internal, like a buffer becoming
free, or an ARP timer event, or data to be sent, etc.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.



On 28/08/2011 17:48, Christoph Kronen wrote:
> Hi all,
> 
> I am using FreeRTOS 7.0.1 on a Sam7X512 and upgraded the contributed
> port lwIP 1.3.0 to 1.3.2.
> 
> The "lwIP Embedded Webserver Demo" is what I took as a starting point. I
> removed the webserver functionality, now I have a task that
> 
>   * checks for incoming data (nonblocking)
>   * checks a Queue for outgoing data (nonblocking)
>   * wait 1 ms (to prevent 100% cpu usage)
>   * repeat :-)
> 
> 
> This works pretty well, I get around 1400 kbyte/s RX and TX.
> Now to my question: Is it possible/difficult/easy to transform this
> functionality to accept multiple connections on the same port ? At the
> moment I am using the netconn API, so I guess I have to switch to the
> Socket API ?
> 
> I read through Richards thread on his "FreeRTOS/lwip Win32 simulator"
> project and it sounds as if it is quite difficult to have multiple
> connections in a multithreaded environment. Unfortunately I could not
> find other helpful topics or contributed examples.
> 
> I am rather new to FreeRTOS and lwIP, so please excuse me if I am
> missing something obvious :-)
> 
> Please give me some comments / suggestions / tips / pushes into the
> right direction.
> 
> Thank you very much !
> 
> Christoph
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] smtp in lwip

[FreeRTOS Info]

Hi,

The Atmel software framework (search for "software framework" on
atmel.com) contains a basic TFTP server.  A long way from an FTP server
I know, but maybe it is good enough for your needs?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 23/08/2011 10:13, ake.forsl...@nibe.se wrote:
> There is an really (and I mean really really) old implementation of an
> ftp-server created for lwip 0.5.3 or something like that but I'm not
> sure it's usable as a reference for a ftp-server for lwip 1.4.0.
> 
> Freescale has a reference design for a FTP-server (also using freeRTOS):
> http://cache.freescale.com/files/32bit/doc/app_note/AN3931.pdfwith
> sources at
> http://cache.freescale.com/files/32bit/doc/app_note/AN3931SW.zip?fsrch=1&sr=1
> 
> 
> 
> It might be a good starting point for your application.
> 
> /Ã…ke
> -
> Ã…ke Forslund
> 0433-273296
> NIBE AB
> Box 14
> S-285 21  Markaryd
> Tel +46-(0)433-273296
> 
> 
> 
> From: vincent cui 
> To:   Mailing list for lwIP users 
> Date: 2011-08-23 10:44
> Subject:  Re: [lwip-users] smtp in lwip
> Sent by:  lwip-users-bounces+ake.forslund=nibe...@nongnu.org
> 
> 
> 
> 
> 
> 
> Ake:
>  
> Thank you .. it maybe a good enter.
> I also wonder to know FTP is not available too ?
>  
>  
>  
> *Vincent Cui**
> Sr.Firmware Engineer**
> Mobile:* +8613482482211*
> Tel:* +86 21 34612525x6104*
> Fax:* +86 21 34619770*
> E-Mail:* _vincent.cui@enlogic.com_ *
> Shanghai EnLogic Electric Technology Co., Ltd.**
> Address:* 1104-1106, Building A, No.391, Guiping Road, Xuhui District,
> Shanghai, 200233_
> __http://www.enlogic.com_ 
>  
> *From:* lwip-users-bounces+vincent.cui=enlogic@nongnu.org
> [mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] *On
> Behalf Of *ake.forsl...@nibe.se*
> Sent:* 2011年8月23日16:42*
> To:* Mailing list for lwIP users*
> Subject:* Re: [lwip-users] smtp in lwip
>  
> smtp is not available in the official contrib-bundle as far as I can
> see. If I google smtp lwip one of the first results I get is
> _http://support.atmel.no/knowledgebase/avr32studiohelp/AT32UC3A_Software_Framework/APPLICATIONS/EVK1100-CONTROL-PANEL/DOC/html/a00113.html_
> 
> Maybe it's worth checking out? (at least as a reference)
> 
> /Ã…ke
> -
> Ã…ke Forslund
> 0433-273296
> NIBE AB
> Box 14
> S-285 21  Markaryd
> Tel +46-(0)433-273296
> 
> From: vincent cui 
> To:   Mailing list for lwIP users 
> Date: 2011-08-23 07:17
> Subject:  [lwip-users] smtp in lwip
> Sent by:  lwip-users-bounces+ake.forslund=nibe...@nongnu.org
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> Hi:
> 
> Is there someone who played smtp in lwIP ? where do I download smtp code ?
> 
> 
> Vincent
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org_
> __https://lists.nongnu.org/mailman/listinfo/lwip-users_
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] smtp in lwip

[FreeRTOS Info]

On 23/08/2011 09:41, ake.forsl...@nibe.se wrote:
> smtp is not available in the official contrib-bundle as far as I can
> see. If I google smtp lwip one of the first results I get is
> http://support.atmel.no/knowledgebase/avr32studiohelp/AT32UC3A_Software_Framework/APPLICATIONS/EVK1100-CONTROL-PANEL/DOC/html/a00113.html
> 
> 
> Maybe it's worth checking out? (at least as a reference)


That's cool - the code you just linked to is using FreeRTOS ;o)


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




> 
> /Åke
> -
> Åke Forslund
> 0433-273296
> NIBE AB
> Box 14
> S-285 21  Markaryd
> Tel +46-(0)433-273296
> 
> 
> 
> From: vincent cui 
> To:   Mailing list for lwIP users 
> Date: 2011-08-23 07:17
> Subject:  [lwip-users] smtp in lwip
> Sent by:  lwip-users-bounces+ake.forslund=nibe...@nongnu.org
> 
> 
> 
> 
> 
> 
> Hi:
> 
> Is there someone who played smtp in lwIP ? where do I download smtp code ?
> 
> 
> Vincent
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Delayed Ack causing problems? Where to call tcp_nagle_disable()?

[FreeRTOS Info]

> Felipe de Andrade Neves L. wrote:
>> May I ask something, how came the Nagle's algorithm has caused the 
>> problem, as it is suppose to group small data until receive the
>> next ack, but the JPG has lots of pending data to be sent and the
>> algorithm shouldn't retain it.
> That's a good, question.
> 
> Richard, can you tell us anything about this? The raw-httpd from
> contrib shouldn't have problems sending a JPG with nagle enabled
> (unless limited by available memory or config options)???

Umm.  I can describe the set up I have, if that helps.  Actually, the
code is all available here if you want to look at that...

http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server

...but as far as I recall, the only modification I made was that in the
post you replied to before this.

I am using Windows XP, with all service packs.  I was testing using
WinPCap developer pack (driver in the files above, that is not the same
as the contrib one) "through" a WiFi adaptor.  I was also using a
FreeRTOS simulator (or should that be emulator?), which is not real real
time.

I have since also tried the code on a Microblaze, which is true real
time, but just used the same code so didn't try it without the nagle
algorithm disabled.  Perhaps I should.

http://www.freertos.org/Free-RTOS-for-Xilinx-MicroBlaze-on-Spartan-6-FPGA.html

[note the link to the Microblaze is not yet complete - the network
driver works well at 100BaseT but is flaky (although working) at
10BaseT.  It will not be released properly until the 10BaseT is fixed,
which will be whenever I get time to look at it again)]


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 22/08/2011 18:40, goldsi...@gmx.de wrote:
> Felipe de Andrade Neves L. wrote:
>> May I ask something, how came the Nagle's algorithm has caused the 
>> problem, as it is suppose to group small data until receive the
>> next ack, but the JPG has lots of pending data to be sent and the
>> algorithm shouldn't retain it.
> That's a good, question.
> 
> Richard, can you tell us anything about this? The raw-httpd from
> contrib shouldn't have problems sending a JPG with nagle enabled
> (unless limited by available memory or config options)???
> 
> Simon
> 
> ___ lwip-users mailing
> list lwip-users@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip socket is stable

[FreeRTOS Info]

}
>   }   
>   } 
>   else if(ret < 0)  
>   { 
>   close(remotefd);
>   remotefd = -1;
>   break;  
>   }  
>   vTaskDelay(100);
>   }  
>   } 
>   vTaskDelay(100); 
>   }
>
> }
> 
> void SocketTask1(void * pvArg)
> { 
>   u8_t buf[32];
>   int count;
>   int listenfd;
>   int remotefd;
>   int len;   
>   struct sockaddr_in local_addr,remote_addr;  
>   fd_set readset;
>   fd_set writeset;
>   struct timeval timeout;
>   timeout.tv_sec = 1;
>   timeout.tv_usec = 0;  
>   // waiting for HDCP to get allocate IP
>   while (IPaddress == netif.ip_addr.addr)
>   {
>   vTaskDelay(100);
>   }
>   
> listenfd = socket(AF_INET,SOCK_STREAM,0); 
> local_addr.sin_family = AF_INET;
>   local_addr.sin_port = htons(port);
>   local_addr.sin_len = sizeof(8081);
>   local_addr.sin_addr.s_addr = INADDR_ANY;  
>   
>   if (bind(listenfd, (struct sockaddr *) &local_addr, sizeof(local_addr)) 
> < 0) 
>   { 
>   printf(" socket bind 8081 fail \r\n");   
>   return ;
>   } 
> 
> if (listen(listenfd, 1) == -1)
>   {
>   return;
>   } 
> len = sizeof(remote_addr);
>   while(1)
>   {
>   remotefd = accept(listenfd, (struct sockaddr *)&remote_addr, 
> &len);  
>   if(remotefd != -1)  
>   {  
>   int ret;
>   send(remotefd,"start to work!\r\n",16,0);
>   for(;;)
>   {  
>   FD_ZERO(&readset);  
>   FD_ZERO(&writeset);   
>   FD_SET(remotefd, &readset);  
>   FD_SET(remotefd, &writeset); 
> ret = lwip_select(remotefd+1, &readset, &writeset, 0, 
> &timeout);   
>   if(ret > 0)  
>   {
>   if (FD_ISSET(remotefd, &readset))   
>  
>   { 
>memset(buf,0,32);  
> 
>if(recv(remotefd,buf,32,0) <= 
> 0)  
>{
>   close(remotefd);
> 
>   remotefd = -1;  
>   
>   break;  
>}  
>else  
>{
>   int i = strlen(buf);
> 
>   send(remotefd,buf,i 
> ,0);  
>   }
>   }   
>   } 
>   else if(ret < 0)  
>   { 
>   close(remotefd);
>   remotefd = -1;
>   break;  
>   }  
>   vTaskDelay(100);
>   }  
>   } 
>   vTaskDelay(100); 
>   }
>
> }
> --
> 
> 锘?Vin

Re: [lwip-users] lwip socket is stable

[FreeRTOS Info]

I think, to get a reasonable answer, you would fist have to post the
relevant snippet of your code - the bit that is accepting and using
connections.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 12/08/2011 08:53, vincent cui wrote:
> Kieran Mansley:
> 
> I create a task that will listen 8080 port and receive data from client. And 
> I use TCP tool to connect it and send data, it works well
> 
> But, I add to create a task that will listen 8081 port. After the first task 
> connect and work,, the second task cann't connect... 
> 
> Why ? 
> 
> 
> Vincent 
> 
> 
> 
> ï»?Vincent Cui
> Sr.Firmware Engineer
> Mobile: +8613482482211
> Tel: +86 21 34612525x6104
> Fax: +86 21 34619770
> E-Mail: vincent@enlogic.com
> Shanghai EnLogic Electric Technology Co., Ltd.
> Address: 1104-1106, Building A, No.391, Guiping Road, Xuhui District, 
> Shanghai, 200233
> http://www.enlogic.com
> -Original Message-
> From: lwip-users-bounces+vincent.cui=enlogic@nongnu.org 
> [mailto:lwip-users-bounces+vincent.cui=enlogic@nongnu.org] On Behalf Of 
> Kieran Mansley
> Sent: 2011Äê8ÔÂ11ÈÕ 22:44
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] lwip socket is stable
> 
> On Thu, 2011-08-11 at 14:27 +, vincent cui wrote:
>> I mean lwIP socket code is without error correction .
> 
> If you use a SOCK_STREAM socket it will be reliable, and in order, as
> for any SOCK_STREAM socket on any other system.  If you use a SOCK_DGRAM
> socket it will (again, as for other systems) be unreliable and
> potentially out of order.  
> 
>> I will port BOA webserver base on lwIP..is it feasible ?
> 
> No idea; I've no experience of that webserver I'm afraid.
> 
> Kieran
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Delayed Ack causing problems? Where to call tcp_nagle_disable()?

[FreeRTOS Info]

I think I have answered my own question.  I put it before these lines,
and everything is fine now.

  /* Tell TCP that this is the structure we wish to be passed for our
 callbacks. */
  tcp_nagle_disable(pcb);//<<<<<<<<<<<<<<<http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 06/08/2011 18:12, FreeRTOS Info wrote:
> Hi,
> 
> lwIP V1.4.0.
> 
> I have moved the demo FreeRTOS example from the Windoze simulator onto
> real hardware in order to check the timing behaviour (which can't really
> be done in the simulator), and found a timing problem.
> 
> Using an umodified raw http server from the contrib distribution, I am
> attempting to retrieve a large jpg file (approx 37K).  The file is
> retrieved in tact, but very slowly.  I am using a point to point connection.
> 
> Taking a Wireshark log I see that data is only being sent by lwIP  after
> an ACK from Windows.  I have attached the log for good measure.
> 192.168.0.200 is the lwIP end.
> 
> I have considered three things to fix this.  First I have set
> TCP_SND_QUEUELEN to (8 * TCP_SND_BUF/TCP_MSS), but that made no
> difference.  Second I considered the calls to tcp_output() after
> tcp_write() to make sure data is actually going out immediately, but
> don't think that is the issue as I'm using an unmodified HTTP server
> from the contrib distribution.
> 
> Finally, I want to try disabling the nagle algorithm, and see this can
> be done by calling tcp_nagle_disable(), but I am unsure where and how to
> do this?  I don't want to modify the core lwIP code, so assume it should
> be in the http server code.  It is using the raw API version, so it is
> not obvious how or where to do to call the macro correctly.
> 
> I would be grateful for advise or an example.  Thanks.
> 
> 
> Regards,
> Richard.
> 
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.
> More than 7000 downloads per month.
> 
> 
> 
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Delayed Ack causing problems? Where to call tcp_nagle_disable()?

[FreeRTOS Info]

Hi,

lwIP V1.4.0.

I have moved the demo FreeRTOS example from the Windoze simulator onto
real hardware in order to check the timing behaviour (which can't really
be done in the simulator), and found a timing problem.

Using an umodified raw http server from the contrib distribution, I am
attempting to retrieve a large jpg file (approx 37K).  The file is
retrieved in tact, but very slowly.  I am using a point to point connection.

Taking a Wireshark log I see that data is only being sent by lwIP  after
an ACK from Windows.  I have attached the log for good measure.
192.168.0.200 is the lwIP end.

I have considered three things to fix this.  First I have set
TCP_SND_QUEUELEN to (8 * TCP_SND_BUF/TCP_MSS), but that made no
difference.  Second I considered the calls to tcp_output() after
tcp_write() to make sure data is actually going out immediately, but
don't think that is the issue as I'm using an unmodified HTTP server
from the contrib distribution.

Finally, I want to try disabling the nagle algorithm, and see this can
be done by calling tcp_nagle_disable(), but I am unsure where and how to
do this?  I don't want to modify the core lwIP code, so assume it should
be in the http server code.  It is using the raw API version, so it is
not obvious how or where to do to call the macro correctly.

I would be grateful for advise or an example.  Thanks.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





get_large_jpg.pcap
Description: Binary data
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] FreeRTOS/lwIP Win32 simulator project now hosted

[FreeRTOS Info]

The FreeRTOS project has now been updated to include a sockets API based
example, in addition to the already existing raw API based example.

The sockets example implements a Telnet "style" interface that can be
connected to using either a telnet client (only tested from Windows) or
dumb terminal type TCP/IP interface (connecting on port 23).

The code and a little set up explanation can be found here:

http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server

As the command interpreter is not re-entrant, the implementation only
allows a single connection at a time.


One quick question, and one longer question:

1) As this is to be used (by me at least) as a reference, I would like
to ensure it is set up optimally.  When implementing a telnet style
server (i.e. sending and receiving very small packets), using a sockets
API, how/should I configure the socket for optimal performance?  Is
there a way to do that?

2) This relates to the SSI functionality.  I want to minimise RAM usage
for when this code is running on real microcontroller targets.  The SSI
functions I have implemented return a very large string, so I have set
LWIP_HTTPD_MAX_TAG_INSERT_LEN 1024.  At the time, I didn't realise this
resulted in 1024 bytes being allocated for each http connection, whether
it was using SSI or not.  Ideally I would like to use a single, global
buffer.  Is that possible (obviously I would need to change the lwIP
code a little in my local copy).

To elaborate a little on this second question.  The command interpreter
just implemented for the sockets example returns the same amount of data
as the SSI functions (in fact, they call the same functions).  In the
command interpreter I have allocated one large buffer that uses a mutex
to ensure only one command uses the buffer at a time.  This is ok, as
the sockets based server runs in its own task, and can block on the
mutex.  Ideally, I would like the SSI functions to use the exact same
buffer - but as the http server uses the raw API I don't think it can
block without blocking the entire stack.  Is there a solution to this?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 26/07/2011 07:20, Paul Archer wrote:
> Hi Richard,
> 
>> Done - although I think it should be SYS_STATS_INC_USED( mbox ) /*
>> without the .used on the mbox. */
> You are corerct, it should have been just SYS_STATS_INC_USED( mbox )
> 
>> I could not see that there was a SYS_STATS_DEC_USED equivalent.
> Also correct, just use the SYS_STATS_DEC as you have.
> 
>> I have attached my current file.  It has also been bent into the
>> FreeRTOS coding style since I posed it up, as it is FreeRTOS specific file.
> This file looks good. And does all that it needs to.
> 
> The only comment I have is due to my requirement for DNS lookups.
> In my sys_arch.c file I needed to add a way to track tasks. This is due
> to performing DNS lookups without needing to lock for each task.
> 
> There is a function
> struct hostent *sys_thread_hostent(struct hostent *hostent)
> 
> My function that I have is
> /**
>  * Get the thread's hostent structure
>  *
>  * \param[in] hostent Copy the data from this into the threads hostent
>  *
>  * \return The threads hostent with the data copied from the argument
>  */
> struct hostent *
> sys_thread_hostent(struct hostent *hostent)
> {
> sys_tcb_t *current;
> 
> syslog(LOG_DEBUG, "Got here: '%s'", inet_ntoa(hostent->h_addr));
> 
> /* Find the current thread */
> if ((current = sys_arch_thread_current()) == NULL)
> {
> return NULL;
> }
> 
> /* Check if we need to allocate the memory */
> if (current->hostent == NULL)
> {
> current->hostent = pvPortMalloc(sizeof(*current->hostent));
> if (current->hostent == NULL)
> {
> return NULL;
> }
> }
> 
> /* Copy the data into the return result */
> memcpy(current->hostent, hostent, sizeof(*hostent));
> 
> return current->hostent;
> }
> 
> What is needed here is a way to get a per tasks hostent structure.
> The way that I did this is sub-par, and is just an linked list of task
> handles, which is searched when needed.
> It works, but its not particularly quick or memory efficient.
> 
> If you can find a better solution and include that in the sys_arch
> example I am sure that many people would like
> thread safe DNS resolving out of the box.
> 
>> To demonstrate sockets use, the current plan is to add in a simple
>> telnet "like" console (just single connection to keep it really simple),
>> and command interpreter (to return the same information that is already
>> being returned by the web server).  Then it will just be a case of
>> adding in a sockets client side demo.
> I think this is a perfect example and is exactly what most people would want.
> 

___
lwip-users mailing list
lwip-users@nongnu.o

Re: [lwip-users] FreeRTOS/lwIP Win32 simulator project now hosted

[FreeRTOS Info]

Hi Paul,

Thanks, that is exactly the sort of feedback I was hoping for.

> A bug that I have spotted with the stats tracking in sys_arch.c
> 
> When stats for 'used' counter is tracked, the macro
> SYS_STATS_INC_USED(x) should be used.
> 
> So for example in
> err_t sys_mbox_new(sys_mbox_t *mbox, int size)
> 
> #if SYS_STATS
> 
>   SYS_STATS_INC(mbox.used);
> 
> #endif /* SYS_STATS */
> 
> Should be replaced with
> SYS_STATS_INC_USED(mbox.used);


Done - although I think it should be SYS_STATS_INC_USED( mbox ) /*
without the .used on the mbox. */

I could not see that there was a SYS_STATS_DEC_USED equivalent.


> There is no need for the #if SYS_STATS as the macro takes care of that for 
> you.

I have also removed all #if SYS_STATS conditional compilations, except
in one place where there is an if() statement inside the #if #endif,
which might cause a compiler warning when the if() has no conditionally
executed code.

> 
> When using a SYS_STATS_INC_USED macro, it also keeps track of the
> maximum allocated at one time.
> 

I have attached my current file.  It has also been bent into the
FreeRTOS coding style since I posed it up, as it is FreeRTOS specific file.

To demonstrate sockets use, the current plan is to add in a simple
telnet "like" console (just single connection to keep it really simple),
and command interpreter (to return the same information that is already
being returned by the web server).  Then it will just be a case of
adding in a sockets client side demo.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

/*
 * Copyright (c) 2001-2003 Swedish Institute of Computer Science.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without 
modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice,
 *this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 *this list of conditions and the following disclaimer in the documentation
 *and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 *derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT
 * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
PROCUREMENT
 * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING
 * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
POSSIBILITY
 * OF SUCH DAMAGE.
 *
 * This file is part of the lwIP TCP/IP stack.
 *
 * Author: Adam Dunkels 
 *
 */

//*
//
// Include OS functionality.
//
//*

/*  System architecture includes 
- */
#include "arch/sys_arch.h"

/*  lwIP includes - */
#include "lwip/opt.h"

#include "lwip/debug.h"
#include "lwip/def.h"
#include "lwip/sys.h"
#include "lwip/mem.h"
#include "lwip/stats.h"

/*---*
 * Routine:  sys_mbox_new
 *---*
 * Description:
 *  Creates a new mailbox
 * Inputs:
 *  int size-- Size of elements in the mailbox
 * Outputs:
 *  sys_mbox_t  -- Handle to new mailbox
 *---*/
err_t sys_mbox_new( sys_mbox_t *pxMailBox, int iSize )
{
err_t xReturn = ERR_MEM;

*pxMailBox = xQueueCreate( iSize, sizeof( void * ) );

if( *pxMailBox != NULL )
{
xReturn = ERR_OK;
SYS_STATS_INC_USED( mbox );
}

return xReturn;
}


/*---*
 * Routine:  sys_mbox_free
 *---*
 * Description:
 *  Deallocates a mailbox. If there are messages still present in the
 *  mailbox when the mailbox is deallocated, it is an indication of a
 *  programming error in lwIP and the developer should be notified.
 * Inputs:
 *  sys_mbox_t mbox -- Handle of mailbox
 * O

Re: [lwip-users] FreeRTOS/lwIP Win32 simulator project now hosted

[FreeRTOS Info]

Hi Simon,

On 21/07/2011 06:48, Simon Goldschmidt wrote:
> 
> FreeRTOS Info  wrote:
>> Eventually, when everything else is done, I would like to also
>> replace the static C structs with a 'standard' file system (reading
>> off an SD card or the like).
> 
> That shouldn't be too hard, since the fs-code used by the httpd is
> already used to do that (or at least that's what TI meant it to, I
> didn't test it, yet).


Sorry - I seem to have missed that code.  Is it in the contrib zip file,
or somewhere else.  I could not see it.

To start with, as it is a Windows simulator, I will probably use a file
system to create a RAM driver, or, at least, access a RAM driver.

Something I didn't say in my original post is that the currently hosted
file (link in previous post) also contains a pre-built makefsdata.exe
binary, and an MSVC 2010 Express project to build it.


>> I would appreciate feedback on the following:
>> 
>> 1) It was my intention to use FreeRTOS software timers to stimulate
>> the tcpip thread to process time outs (ARP timers,etc).  However,
>> it seems that lwIP V1.4.0 does not require any external help with
>> timers, so maybe forcing in FreeRTOS software timers is now
>> overkill.
> 
> Yes, it is overkill. Also, I think it's a better example on how to
> use lwIP if you do use the timer framework lwIP provides.

Ok.  That is what I thought.  With uIP the software timers are a really
good fit, but lwIP 1.4.0 has it covered already.


> 
>> 2) Part of the point of this exercise originally was to have a
>> worked example of using lwIP in a multi threaded environment, in
>> addition to the win32 contrib project which I used as a starting
>> point.  I don't think I am yet meeting that goal fully, as the http
>> server uses the raw API and is "just" a server.  I think adding in
>> a sockets based client application would be beneficial, then, to
>> show a client using the stack, full multithreading, and how to use
>> the sockets interface.  Does anybody have any suggestions on an
>> example sockets based client application that would be suitable for
>> this purpose?  Is the sockets example in the contrib directory
>> suitable?
> 
> I don't really think so. It works, but it does nothing useful. It's
> rather there to show how it works and to test whether
> blocking/unblocking works, etc.
> 
> However, the ping app in contrib has a socket mode, which could be
> quite useful.

I will take a look at its functionality.



> 
>> 3) Likewise, a worked example that includes email, FTP, telnet,
>> etc along side the obligatory httpd would be very interesting and I
>> think useful for the community at large.
> 
> Hmm, did you plan to just include some existing socket apps here, or
> use raw API apps?

That assumes I planned something!  I'm just routing around for ideas on
making the demo as useful as possible, while simultaneously not too
complex, and was really (although not explicitly) asking for opinions on
that myself.  What is already around that can be incorporated, be it raw
or sockets based.  As long as there is at least one sockets example then
that is covered.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

> Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] FreeRTOS/lwIP Win32 simulator project now hosted

[FreeRTOS Info]

Hi list,

Following on from the threads that were posted a month or two back, I
have now created a FreeRTOS project, that runs in the FreeRTOS Win32
simulator (emulator?), using lwIP and WinPCap to implement a web server.

The web server is the http_raw version from the contrib download.  It
includes SSI functionality to show FreeRTOS task stats, and run time
stats (how much CPU time each task is using).

More notes can be found on the hosting page here:

http://interactive.freertos.org/entries/20290712-win32-project-with-lwip-web-server

and even more notes, including where to find configuration parameters
(IP address, etc.) are at the top of main.c.

The project uses the free Microsoft Visual Studio 2010 Express edition.

-

My intention is to develop this project further, then host it with
documentation on the http://www.FreeRTOS.org site.

Naturally the project uses a multi threaded implementation.  I also
intend on adding in a sockets example, because this is the interface
most people are familiar with, even though it is the least efficient in
code and throughput.

Currently I'm mixing metaphors a bit by using multi threading, but also
using the raw httpd implementation.

I am also considering, for this example, changing the mechanism that
sends packets from the driver to the tcpip thread.  Currently, the
driver creates a message that includes the received data, and sends this
to the tcpip thread.  This however means that critical sections are
required in the driver to allocate the messages and the buffers.  For my
example I would prefer that the message sent to wake the tcpip thread is
statically allocated, and when unblocked, the tcpip thread then obtains
the packet from the network interface itself.  That avoids any issues
with running any code in an interrupt context, or having to allocate a
deferred interrupt as a task (with the overhead that that introduces).
It is also inline with how I have written drivers for other stack -
although is mixing metaphors even more as it is closer to how I image a
system that does not use multi tasking would work.

Eventually, when everything else is done, I would like to also replace
the static C structs with a 'standard' file system (reading off an SD
card or the like).

I would appreciate feedback on the following:

1) It was my intention to use FreeRTOS software timers to stimulate the
tcpip thread to process time outs (ARP timers,etc).  However, it seems
that lwIP V1.4.0 does not require any external help with timers, so
maybe forcing in FreeRTOS software timers is now overkill.

2) Part of the point of this exercise originally was to have a worked
example of using lwIP in a multi threaded environment, in addition to
the win32 contrib project which I used as a starting point.  I don't
think I am yet meeting that goal fully, as the http server uses the raw
API and is "just" a server.  I think adding in a sockets based client
application would be beneficial, then, to show a client using the stack,
full multithreading, and how to use the sockets interface.  Does anybody
have any suggestions on an example sockets based client application that
would be suitable for this purpose?  Is the sockets example in the
contrib directory suitable?

3) Likewise, a worked example that includes email, FTP, telnet, etc
along side the obligatory httpd would be very interesting and I think
useful for the community at large.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] problem with SSI module

[FreeRTOS Info]

Hi Rocco,

Co-incidentally, I was looking at this for the first time myself today.
 I managed to get the SSI working without issue, although only in a
limited form (I only have one tag defined, and the text generated by it
can all be sent in one go).

The thing that springs to mind, apologies if it has been suggested
already, is the settings of the following configuration options:

LWIP_HTTPD_MAX_TAG_NAME_LEN
LWIP_HTTPD_MAX_TAG_INSERT_LEN

Is it possible that the code you use to return the SSI text is greater
than LWIP_HTTPD_MAX_TAG_INSERT_LEN long - or that the code is simply
corrupting something?

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 19/07/2011 14:29, rocco brandi wrote:
> hi!
> 
> I managed to set the SSI handler properly, but as you can see from the
> wireshark cap, it sticks at the part of file just after the first tag
> (),although when I debug step-by-step, it seems that
> everything's fine: search for the first tag name, upload the first
> string in hs->tag_insert, send the part of file prior the tag, send the
> insert string, search for the second trag name...
> 
> if  LWIP_HTTPD_SSI=0 the page is sent properly.
> 
> where could be the problem?
> 
> Thanks,
> Rocco
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] having trouble with 'ethernetif_init' & 'ethernetif_input'

[FreeRTOS Info]

This would seem to just be a build error, rather than anything lwIP
specific.

You say you have the header file with the function prototypes in the
same directory as the main.c file, so two things come to mind immediately.

First - which C file actually contains the implementations of those two
functions, and is that C file included in your build?

Presumably, the compiler is finding the header file, as the error is not
telling you it can't find the header file, just that the functions it
contains prototypes for cannot be found.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 03/07/2011 19:33, Alberto wrote:
>  
> 
>  
> 
> I have a Project in Nios IDE 8.0 and lwIP v1.4.0. Compilation ends with
> errors because ethernetif_init' & 'ethernetif_input' are undefined
> references.
> 
>  
> 
> These functions are located in alteraTseEthernetif.h in the same
> directory as main.c and the file calls to "lwip/netif.h".
> 
>  
> 
> I don’t know what would be the cause of this error.
> 
>  
> 
> Any suggestion please?
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwIP reentrancy issues and TCP

[FreeRTOS Info]

Hi Andy, et al.

>>  (although I would pay a small amount for somebody to provide one,
>> as per previous discussion).
> 
> You probably won't have to pay anyone. I've just completed a new "zero-copy" 
> emac/dma driver for the LPC1768. It's "tightly bound" to LWIP (in that it 
> uses 
> pbuf_pool for the descriptor target buffers).

Excellent.

> 
> There are two compile modes configured by macros.
> 
> 1) Classic Lwip: user responsible for calling lwip to process queues and 
> timers 
> in it's "single thread" user context process.
> 
> 2) FreeRTOS: uses just the technique you describe. The queues are handled by 
> queue messages from the ISR to the lwip task. Timers simply by the lwip task.
> 
> Still in beta at the moment but when I am happy I'll be publishing it all as 
> foss.

It is always apprecated by the FreeRTOS community if projects that that,
if they are using FreeRTOS, are posted to the FreeRTOS Interactive site:
http://interactive.freertos.org

Ultimately my aim to to have a reference that uses the sockets API and
runs in the Windows simulator.  Sockets because, although the weightiest
API, it is the most familiar to novices.  In the simulator because, you
can try it without needing any hardware or to purchase any tools.


> But while I have your attention I'd like to ask a question just so I can get 
> this spot on and usable as a good reference design for others.
> 
> First up, a brief description of "Classic Lwip" mode (no rtos) which was 
> where I 
> started out from (I decided to make it FreeRTOS friendly later which means a 
> re-factor, it's this re-factor I want to get right to make it truly useful 
> for 
> others).
> 
> In Classic Lwip mode, lwip pbuf_pool is setup to provide "many small pbufs". 
> In 
> my case at the moment, 38 of them all payload sized at 256 bytes. When the 
> emac 
> driver inits the rx descriptor arrays (there are 18 rx descriptors currently) 
> are each assigned a pbuf_pool pbuf. Once all is setup, the emac and isr is 
> enabled.
> 
> Now, here's where things get interesting. Although the emac driver is tightly 
> bound to lwip (in that is uses lwip memory manager) I wanted my driver to be 
> able to handle Ethernet protocols other than just IP and ARP. So my emac 
> driver 
> after init actually drops all packets. It's not until a "protocol handler" 
> registers itself as "I want these etherType packets" that the driver actually 
> starts doing anything useful (the register is done during init).
> 
> So, for example, during low_level_init() in the Lwip code it calls a function 
> to 
> register 0800 and 0806 etherType packets and provides a C function pointer to 
> callback to. The callback functions simply take a structpbuf * arg which 
> points 
> at the head pbuf in a pbuf chain. The callback then places that into a queue. 
> It's the "user process" that then empties this queue into lwip during it's 
> normal single user thread mode of operation. Likewise, other protocol 
> handlers 
> do the same (in my case I also have an LLDP protocol handler which plays nice 
> with lwip pbufs). If the driver has no etherType callbacks registered it 
> drops 
> the packet.

Sounds reasonable, so far, without the kernel coming into play.



> So this design means there is "some minimal intelligence" built into the 
> emacISR 
> handler.
> 
> So, moving onto FreeRTOS. Instead of registering a C function callback to 
> call 
> in ISR context, the protocol handler (lwip netif, or LLDP, etc) registers an 
> etherType number and a Queue into which it just injects the pbuf chain.
> 


So there is one queue per protocol being handled.

You could alternatively have a single queue, but post to the queue a
structure that has the protocol identifier as one member, and a pointer
to the data as another member.  Then you could have one task that
handles both protocols - the first thing it does is check the protocol
identifier to know which function to pass the data to to get processed
correctly.


> Additionally, when the emacISR forms pbuf chains from the descriptor array, 
> each 
> descriptor is now void of a payload taget. So the ISR makes an attempt to 
> replace this lost pbuf with a new one using pbuf_alloc() (using the usual 
> lwip 
> protection mechanisms in sys_arch). It may not succeed if all pbufs are in 
> use 
> in which case it attempts to "keep up" when other events trigger. 

Be careful of using critical section type protection mechanisms.  If
that can be done in FreeRTOS depends on the port being used.  I find
normally you can do the re-allocation of a buffer to the EMAC driver at
the task level too.


> Anyway, coming onto my question. You've said that in FreeRTOS the ISR should 
> "just send a message" and the task should then do the processing. However, 
> that 
> really doesn't fit my design as it assumes that the task is going to manage 
> the 
> emac descriptor array, forming pbuf_chains, etc etc. So I have two choices:-


As per my comment above - but why

Re: [lwip-users] lwIP reentrancy issues and TCP

[FreeRTOS Info]

[replying to my own post]

I have attached an example "reference" design to illustrate the sort
thing I am trying to describe.  This uses uIP, not lwIP, so is simpler.
 I have wanted for a long time to produce an equivalent reference for
lwIP, but unfortunately time has not allowed yet (although I would pay a
small amount for somebody to provide one, as per previous discussion).

Note in the attached example, things like retry time outs and ARP
timers, etc. use the same messaging system, so the stack only runs when
there is actually something to do.

Also note that none of this code runs in an interrupt!  Although
messages are sent from the MAC interrupt handler.

---

Just to clarify why I made the statement:

> The classic symptom that raises the alarm is when somebody attempts to
> use a critical section from code that runs in an interrupt.

...because the excuse for doing this is always "ah yes, but this code
has to run both in the interrupt and outside of the interrupt".


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 25/06/2011 09:51, FreeRTOS Info wrote:
> Just my 2 cents on this - which is probably not exactly helpful to the
> subject being discussed.  Maybe I'm just griping...
> 
> This is a common "sub-optimal" design found in lots of TCP/IP
> integrations, and not just designs that use lwIP.  In fact, I see it all
> the time in USB drivers too, not even TCP/IP.
> 
> Something like lwIP, (correct me if I'm wrong) was originally designed
> for use in resource constrained systems.  Systems where it might not be
> practical or desirable to use multitasking.  Therefore, polling status
> registers from a non-interrupt loop makes sense.  That does not prevent
> it from being used with an RTOS of course - you just make the loop
> execute in a task, and set the priority of the task as appropriate for
> the application being developed - or do something more clever with
> mutexes, etc.  Likewise, if you don't have an RTOS and the stack (be it
> USB or TCP/IP or whatever else) has high priority, it can run in an
> interrupt if the non-determinism that arises from that is not going to
> break your real time requirements.
> 
> The problem comes when people mix these design patterns up.  Time and
> time again people complain to me that something (i.e. middleware) is
> 'broken' or 'unusable' of 'not designed very well', and when you look at
> it the problem stems from them not understanding how to perform
> integration successfully, and creating a system that has the bad
> characteristics of all design patters, and very few of the good
> characteristics.  The classic case is running half the code in an
> interrupt while simultaneously running some code out of an interrupt.
> The classic symptom that raises the alarm is when somebody attempts to
> use a critical section from code that runs in an interrupt.
> 
> Talking RTOS only, because that is what I do day to day, I would
> normally have the interrupts do nothing other than send a message from
> the MAC to the task running the stack.  The message would be "Rx end" so
> you know something is there to process, or "Tx end" so you know a buffer
> at the driver level can be re-allocated to be an Rx buffer again.  The
> message would unblock the task that runs the stack so the message can be
> processed, and the priority of the task is determined only by the
> requirements of the system being developed.  It can pre-empt less
> important tasks or just wait until higher priority tasks have nothing to do.
> 
> If you want your application to act as a client and initiate
> communications you just extend the messaging system so messages can be
> sent to the task running the stack from the application itself.
> 
> Regards,
> Richard.
> 
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.
> More than 7000 downloads per month.
> 
> 
> 
> On 24/06/2011 23:30, Peter Montgomery wrote:
>> Simon,
>>
>> Sorry about new email vs. renamed email.  I didn't realize the mailer
>> was doing some hidden JuJu in the email headers.  I was just
>> re-subjecting a reply as a fast way to get the email address in the
>> outgoing email.
>>
>> I'm a bit confused by your answer, so I have some more questions.
>>
>> You say that lwIP was designed to be run entirely from foreground (FG
>> for short) code, with the Ethernet hardware interrupt handler merely
>> setting a flag that the FG code polls.  So the entire system was
>> designed to be run in a polled mode?  I guess this presupposes that the
>> FG would never get stuck doing something that took a litt

Re: [lwip-users] lwIP reentrancy issues and TCP

[FreeRTOS Info]

Just my 2 cents on this - which is probably not exactly helpful to the
subject being discussed.  Maybe I'm just griping...

This is a common "sub-optimal" design found in lots of TCP/IP
integrations, and not just designs that use lwIP.  In fact, I see it all
the time in USB drivers too, not even TCP/IP.

Something like lwIP, (correct me if I'm wrong) was originally designed
for use in resource constrained systems.  Systems where it might not be
practical or desirable to use multitasking.  Therefore, polling status
registers from a non-interrupt loop makes sense.  That does not prevent
it from being used with an RTOS of course - you just make the loop
execute in a task, and set the priority of the task as appropriate for
the application being developed - or do something more clever with
mutexes, etc.  Likewise, if you don't have an RTOS and the stack (be it
USB or TCP/IP or whatever else) has high priority, it can run in an
interrupt if the non-determinism that arises from that is not going to
break your real time requirements.

The problem comes when people mix these design patterns up.  Time and
time again people complain to me that something (i.e. middleware) is
'broken' or 'unusable' of 'not designed very well', and when you look at
it the problem stems from them not understanding how to perform
integration successfully, and creating a system that has the bad
characteristics of all design patters, and very few of the good
characteristics.  The classic case is running half the code in an
interrupt while simultaneously running some code out of an interrupt.
The classic symptom that raises the alarm is when somebody attempts to
use a critical section from code that runs in an interrupt.

Talking RTOS only, because that is what I do day to day, I would
normally have the interrupts do nothing other than send a message from
the MAC to the task running the stack.  The message would be "Rx end" so
you know something is there to process, or "Tx end" so you know a buffer
at the driver level can be re-allocated to be an Rx buffer again.  The
message would unblock the task that runs the stack so the message can be
processed, and the priority of the task is determined only by the
requirements of the system being developed.  It can pre-empt less
important tasks or just wait until higher priority tasks have nothing to do.

If you want your application to act as a client and initiate
communications you just extend the messaging system so messages can be
sent to the task running the stack from the application itself.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.



On 24/06/2011 23:30, Peter Montgomery wrote:
> Simon,
> 
> Sorry about new email vs. renamed email.  I didn't realize the mailer
> was doing some hidden JuJu in the email headers.  I was just
> re-subjecting a reply as a fast way to get the email address in the
> outgoing email.
> 
> I'm a bit confused by your answer, so I have some more questions.
> 
> You say that lwIP was designed to be run entirely from foreground (FG
> for short) code, with the Ethernet hardware interrupt handler merely
> setting a flag that the FG code polls.  So the entire system was
> designed to be run in a polled mode?  I guess this presupposes that the
> FG would never get stuck doing something that took a little too long,
> and fail to poll in a timely manner.  That seems awfully hard to guarantee.
> 
> You also say Stellaris is a bad example of an lwIP implementation.  I
> wish that was noted loudly somewhere, as this is the first time I have
> heard this information.  Clearly there are more people using lwIP on
> Stellaris than just me, so there must be solutions.  Unfortunately,
> since you are the first person (and only that I've found so far) to
> state that lwIP for Stellaris is bad, I'm turning to you for help.
> 
> Given that the Stellaris implementation is poor, what can I do to work
> within it?  Since Stellaris has lwIP running completely in interrupts,
> what's the best way for me to get messages from the FG to lwIP's
> interrupt code?
> 
> Thanks,
> PeterM
> 
> 
> On 6/24/2011 1:36 PM, Simon Goldschmidt wrote:
>> First, please make sure you create a mail for a new thread instead of
>> replying to an old mail and simply changing the subject: this confuses
>> my mail app since it sorts by thread Id, not by subject.
>>
>> Peter Montgomery  wrote:
>>> Is lwIP really engineered so that the most logical situation
>>> (incoming TCP handled in the interrupt handler, "tcp_write" called
>>> from the foreground) is not allowed?
>>
>> Yes, it is. (BTW, it might be the most logical situation to you, but
>> that's not really an objective statement.) The reason for this is that
>> the core lwIP code is only supposed to implement the networking code,
>> not the interface to your hardware, OS, or timing requirements.
>> Depending on whether lwIP is the highest priority software in your
>> application or only lo

Re: [lwip-users] upgrading to 1.4.0

[FreeRTOS Info]

On 23/06/2011 12:27, Martin Velek wrote:
> Hi,
> I am doing an upgrade of LWIP from 1.3.2 to 1.4.0(#define NO_SYS 0,
> the OS supports mutexes) . Please, could you help me to confirm the
> following steps?
> 
> 1) Remove all stuff around timers, these are now completely handled inside 
> LWIP.
> 
> 2) Change function prototypes and implementation around semaphores, 
> mboxes,etc.
> 
> 3) Add new functions to support mutexes and typedef __type__ sys_mutex_t
> 
> 4) Add new functions to determine if sem/mbox/mutex is valid or to invalide 
> it.
> Here I would like to ask, what is good *_invalide() for. If this
> functions is called, should I also free the sem/msg/mutex? I could
> understand the *_invalide() is called if and only if during an
> initialization process to set variables into a known state or after
> freeing by *_free().
> 
> E.g. with a FreeRTOS, the semaphore is of a type void * and NULL value
> is (void *)0. However, if the semaphore is created and then
> invalidated, from the function name I would propose that the function
> should set the semaphore to the NULL because there is a function
> sys_sem_free() to free the semaphore. There will be a memory leak if I
> set the semaphore to the NULL in the *_invalide() function. Or what is
> worse, the sys_sem_free() will fail with a NULL semaphore.

Just to comment on the FreeRTOS part...

In FreeRTOS a semaphore is actually of type xSemaphoreHandle.  Inside
the function that implements the semaphore this is defined to be a
pointer to the semaphore structure.  Outside of that function, for
reasons of standard data hiding, it is defined as (as you say) a void *.
 That way, the user cannot access its internals directly.

Semaphores are built onto of the queue primitive (to use the event
management of the queue while keeping the code size very small).  You
can therefore delete a mutex (or any other type of semaphore) by calling
vQueueDelete(  ).  Depending on the compiler, you may
need to case http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.






> 
> 
> Did I miss something?
> 
> Thank you
> Martin
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Anybody interested in converting simulated FreeRTOS/uIP project to lwIP?

[FreeRTOS Info]

Hi Simon,

Thanks for the info.  That will of course lessen the time I would need
to create a FreeRTOS version, and make it more feasible for me to do
that (at last) myself.  Probably starting with the contrib version would
be the best plan.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 30/05/2011 18:47, goldsi...@gmx.de wrote:
> FreeRTOS Info wrote:
>> I'm not sure how most of lwIP development is done currently, but this
>> setup (with or without FreeRTOS) would make an easy and convenient
>> development and test bed (maybe it is done on Windows or Linux already?).
> There's a windows port which I'm using for development. It has a pcap
> driver (which currently only works under windows/with winpcap, but I
> have successfully used it under linux, too), multithreading support
> (directly wrapping the win32 API). This port is available in the contrib
> module in CVS (and in the contrib download ZIP), and I guess it's the
> main port used for development currently. It also has a (raw API) http
> server and some other example applications included (from contrib/apps).
> 
> So it looks like what you want is already there, only it doesn't seem to
> be well known :-(
> 
> Simon
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Anybody interested in converting simulated FreeRTOS/uIP project to lwIP?

[FreeRTOS Info]

Hi list,

There is a lot of communication on this list about using lwIP in a
multitasking environment.  For a long time I have planned on creating an
example as a reference, but time is always a problem.

However, now I have the following convenient development setup using
uIP, that could be converted to replace uIP with lwIP.  Note this all
runs under Windows in a simulated/emulated environment, so no target
hardware is required.  Also, no software investment is required as only
free tools are used:

+ FreeRTOS being simulated in a Win32 environment - where a Windows
thread is created for each FreeRTOS task, and the FreeRTOS scheduler
controls which thread runs when (as if it were real real time, but just
simulated real time).  This builds using both the *free* MSVC 2010
Express Edition, and the *free* Eclipse/MingW/CDT combo, so no software
investment is required.

+ A FreeRTOS demo project that uses the above mentioned Win32 simulator,
that includes a task that runs the uIP TCP/IP stack, with a simple web
server.  Currently the project is using MSVC 2010 Express, but could be
ported over to use Eclipse/MingW simulator setup instead.

+ A WinPCap driver that allows you to create a virtual network node
(virtual IP address and virtual MAC address).  This then allows you to
have the FreeRTOS/uIP/webserver running on the same machine as a web
browser - using one IP/MAC address combo for the FreeRTOS simulation exe
and another IP/MAC address combo for the web browser.  You can then open
a web browser and connect to the web server using the virtual addresses,
all on a single machine (no actual network is required - does that make
sense?).

I'm not sure how most of lwIP development is done currently, but this
setup (with or without FreeRTOS) would make an easy and convenient
development and test bed (maybe it is done on Windows or Linux already?).

If somebody wanted to take this project, convert the uIP web server to
an lwIP web server, and send it back to me, I could then host it along
with FreeRTOS, hopefully maintain it, and document it, and hopefully add
extra example functionality over time.  The result would then (hopefully
again, am I saying that too often) be a good development and test bed,
and an excellent example of how to use lwIP in a multitasking environment.

Ideally the example would use the sockets interface, as this is most
familiar to users of other stacks.  It would also require an experienced
lwIP user to convert the project, as there is no point having a
reference design if it has been configured incorrectly.

Is anybody interested?  If so, I can be contacted on r (dot) barry (at)
freertos.org.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.





___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] uIp vs LWip

[FreeRTOS Info]

I think, from memory, an lwIP build is about 40K bytes - but that is a
rough estimate and the usual caveats apply (compiler, optimisation,
configuration, etc.).

However, if RAM is your limiting factor, then lwIP uses a lot more RAM
than uIP, as uIP has only a single buffer, with no queuing.  lwIP is
going to use less RAM than most full TCP/IP stacks, but still a lot more
than uIP.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 29/03/2011 08:30, Daniel Kilshtein wrote:
> Currently I run uIp on an ARM11. I’m thinking about moving on to the
> latest LWIP but a bit worried about the code size (my RAM is a somewhat
> limited and the whole code should run under FreeRtos)
> 
> Does anyone know (roughly) how much the LWIP code size is bigger than
> Uip code size?
> 
>  
> 
>  
> 
> Thanks & Best Regards,
> 
> Daniel Kilshtein
> 
>  
> 
> Provigent Ltd.
> 
> 4 Shenkar St.
> 
> P.O.Box 2168
> 
> Herzelia 46120
> 
> Israel
> 
>  
> 
> Phone: +972 9 950-5434
> 
> Fax: +972 9 950-5683
> 
> Web:_www.provigent.com_
> 
>  
> 
> Please consider the environment before printing this email  P
> 
>  
> 
> **
> 
> The information in this e-mail message is legally privileged
> 
> and confidential, for the use of the intended recipient
> 
> **
> 
> 
> 
> 
> 
> 
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer viruses.
> 
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip port for LPC17xx micros

[FreeRTOS Info]

I think all you need to do is a memcpy into the buffer then tell the DMA
there is something in the buffer pointed to by the Tx descriptor.  No
copying byte by byte.  Although the DMA driver itself is more complex
than the simply FIFO driver, the actually copying of data is much easier.

The uIP driver tries to be zero copy in that it just points the DMA at
the uip_buf, then sets uip_buf to point to the next Rx buffer (pointed
to by the DMA's RX descriptor).  The lwIP equivalent will be a bit more
tricky because it has more comprehensive memory management than uIP's
very simply single buffer.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



On 03/02/2011 23:41, Bernard Mentink wrote:
> Hi Richard,
> 
> You are write, the uIP implementation is DMA driven, however the lwIP
> stack sample which is written for the Stellaris MCUs writes to a FiFO, I
> don't know if that is a DMA address on that micro , or not.
> i.e in the read function you get the following:
> 
> --- code
> -
> 
> /* Process all but the last buffer in the pbuf chain. */
> q = p;
> do {
> /* Setup a byte pointer into the payload section of the pbuf. */
> unsigned long *ptr = (unsigned long *)q->payload;
> 
> /**
> * Read data from FIFO into the current pbuf
> * (assume pbuf length is modulo 4)
> */
> for (i = 0; i < q->len; i += 4) {
> *ptr++ = ETH->DATA;
> }
> 
> /* Link in the next pbuf in the chain. */
> q = q->next;
> } while (q != NULL);
> 
> --- end code
> 
> 
> I will need to investigate what ETH->DATA is .. and replace it with a
> call to read the DMA channel .. and ditto for the write ..
> 
> Cheers,
> Bernie
> 
> On Fri, Feb 4, 2011 at 10:48 AM, FreeRTOS Info  <mailto:nos...@freertos.org>> wrote:
> 
> Hi again,
> 
> The drivers in FreeRTOS are interrupt (and I think DMA (?)) driven.  The
> driver moves a packet into a buffer pointed to by a chain of DMA
> descriptors, thats it.  I don't see why the driver would not be agnostic
> of the stack it is being used with - the packets coming in off the
> network will be the same - the reception and buffering of the packets by
> the DMA will be the same - only how the packets are read from the
> buffers by the stack will be different and that is not part of the
> driver but part of the stack.
> 
> 
> Regards,
> Richard.
> 
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.  More than 7000 downloads per month.
> 
> + http://www.SafeRTOS.com
> Certified by TÜV as meeting the requirements for safety related systems.
> 
> 
> 
> On 03/02/2011 20:57, Bernard Mentink wrote:
> > Hi There,
> >
> > Yes, I do have uIP working on the LPC1766, so I can use their drivers
> > ... they don't use interrupts, just polling, so will need to do some
> > hacking there
> > (I am also using it with QP OS so every thing needs to be event
> based ..)
> >
> > Reason I am asking, is to try and save myself the work of porting the
> > uIP driver to lwIP, which does need a chunk of work .. so if
> anyone has
> > done it, that would be cool?
> >
> > Cheers,
> > Bernie
> >
> > On Fri, Feb 4, 2011 at 9:34 AM, FreeRTOS Info  <mailto:nos...@freertos.org>
> > <mailto:nos...@freertos.org <mailto:nos...@freertos.org>>> wrote:
> >
> > Hi,
> >
> > If you look at the LPC1768 demos in the FreeRTOS download you
> will find
> > uIP demos, but the drivers are probably just as relevant to lwIP.
> >
> > Regards,
> > Richard.
> >
> > + http://www.FreeRTOS.org
> > Designed for Microcontrollers.  More than 7000 downloads per
> month.
> >
> > + http://www.SafeRTOS.com
> > Certified by TÜV as meeting the requirements for safety
> related systems.
> >
> >
> >
> > On 03/02/2011 19:09, Bernard Mentink wrote:
> > > Hi all,
> > >
> > > Does anyone have 

Re: [lwip-users] lwip port for LPC17xx micros

[FreeRTOS Info]

Hi again,

The drivers in FreeRTOS are interrupt (and I think DMA (?)) driven.  The
driver moves a packet into a buffer pointed to by a chain of DMA
descriptors, thats it.  I don't see why the driver would not be agnostic
of the stack it is being used with - the packets coming in off the
network will be the same - the reception and buffering of the packets by
the DMA will be the same - only how the packets are read from the
buffers by the stack will be different and that is not part of the
driver but part of the stack.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



On 03/02/2011 20:57, Bernard Mentink wrote:
> Hi There,
> 
> Yes, I do have uIP working on the LPC1766, so I can use their drivers
> ... they don't use interrupts, just polling, so will need to do some
> hacking there
> (I am also using it with QP OS so every thing needs to be event based ..)
> 
> Reason I am asking, is to try and save myself the work of porting the
> uIP driver to lwIP, which does need a chunk of work .. so if anyone has
> done it, that would be cool?
> 
> Cheers,
> Bernie
> 
> On Fri, Feb 4, 2011 at 9:34 AM, FreeRTOS Info  <mailto:nos...@freertos.org>> wrote:
> 
> Hi,
> 
> If you look at the LPC1768 demos in the FreeRTOS download you will find
> uIP demos, but the drivers are probably just as relevant to lwIP.
> 
> Regards,
> Richard.
> 
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.  More than 7000 downloads per month.
> 
> + http://www.SafeRTOS.com
> Certified by TÜV as meeting the requirements for safety related systems.
> 
> 
> 
> On 03/02/2011 19:09, Bernard Mentink wrote:
> > Hi all,
> >
> > Does anyone have a port to this family of micros? I guess I am just
> > wanting the eth_driver.c and eth_driver.h files ...
> >
> > Many Thanks,
> > Bernie
> >
> > --
> > You always have believers and scepticts.. A True inventor is always a
> > believer..
> >
> >
> >
> > ___
> > lwip-users mailing list
> > lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> 
> -- 
> You always have believers and scepticts.. A True inventor is always a
> believer..
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip port for LPC17xx micros

[FreeRTOS Info]

Hi,

If you look at the LPC1768 demos in the FreeRTOS download you will find
uIP demos, but the drivers are probably just as relevant to lwIP.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



On 03/02/2011 19:09, Bernard Mentink wrote:
> Hi all,
> 
> Does anyone have a port to this family of micros? I guess I am just
> wanting the eth_driver.c and eth_driver.h files ...
> 
> Many Thanks,
> Bernie
> 
> -- 
> You always have believers and scepticts.. A True inventor is always a
> believer..
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] PORT FOR MCF52259

[FreeRTOS Info]

On 11/10/2010 13:39, Luis Rossi wrote:
> Hi, does any one know any port to MCF52259 (with no OS) or some good
> reference for porting it?

I think, but could be wrong, that Freescale produced an lwIP demo for
the MCF52259 before the device was launched.  Maybe you could find it on
their website?

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Reentrancy in LWIP

[FreeRTOS Info]

On 29/09/2010 20:59, Timmy Brolin wrote:
> 
> 
> Bill Auerbach wrote:
>> 9 or 10 years ago I worked with a non-reentrant stack which was made "RTOS
>> compatible" by using this method.  There simply was a macro at function
>> entry to lock a semaphore and one at exit to release it.  It was one liner
>> of RTOS-specific code which was easily removed by using an empty macro.
>> Every function that could be called from the application had this addition.
>> It was no problem when one function with the addition calls another.  In
>> fact most RTOSes are very efficient when a thread is locking a semaphore
>> that it already owns.

Very effective at making something thread safe at the expense of making
it hellishly slow and inefficient - which users *will* complain about.


> Actually, what you are talking about is probably more appropriately
> called a mutex, not a semaphore.
> The way I understand it, a semaphore cannot be associated to a task, so
> if a task requests a binary semaphore twice, it will block in the second
> request.
> A mutex on the other hand is associated to a task when requested, and
> can be requested/released recursively without problems.
> Not all operating systems have recursive mutexes, so for portability it
> is probably better to use binary semaphores.

Just referring to FreeRTOS because that is what I know:  FreeRTOS has
binary semaphores, mutexes and recursive semaphores (and counting
semaphores, but that is outside the scope of the conversation).

Binary semaphores are simple empty/full semaphores where a task would
block if it attempted to obtain it twice.

Mutexes are binary semaphores with the addition of priority inheritance
(horrible if you have a "real" real time system).

Recursive semaphores are binary semaphores that can be taken multiple
times.  You have to give it back the same number of times it was taken
before it becomes available to any other task.  This feature was
actually added specifically for a TCP/IP stack implementation and is
very useful when integrating any third party code.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] TCP KeepAlive

[FreeRTOS Info]

On 21/09/2010 09:49, Kieran Mansley wrote:
> On Tue, 2010-09-21 at 10:34 +0200, Karsten wrote:
>>
>> @Simon: Can you (or another admin) please add the sugested fix from
>> this 
>> bug to the FreeRTOS port in contrib?! I know, it is no core problem,
>> but 
>> it seems that there are a lot of people outside using this (buggy)
>> port.
> 
> I can't see a FreeRTOS port in contrib.  There are some ports kept there
> that are old and unmaintained and marked as such.  If someone is willing
> to update one (and keep it updated) we could start making such changes,
> but fixing just one of many problems would be wasted effort and give
> them impression that that port was being maintained.
> 
> I think lwIP's FreeRTOS port is maintained and distributed externally,
> so perhaps we should just delete the copy (which I can't find, so maybe
> we already have!) in lwip/contrib/old
> 

I'm not aware of there ever having been a FreeRTOS port in the lwIP
distribution.  There are several ports on the web, and a few (old) ports
in the FreeRTOS download itself, but these are just 'demo' quality.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Examples with FreeRTOS

[FreeRTOS Info]

I was going to add this to the "start point" thread, then thought better
of it.

I wanted to make people aware of the new (ish) FreeRTOS Interactive
section of the FreeRTOS web site.  This is intended to allow people to
post their FreeRTOS related ports, drivers and other code - and I would
like to encourage people to post any FreeRTOS/lwIP examples they may have.

http://interactive.freertos.org/forums - if you look at the bottom of
the list there is a generic forum called "Any other files - Any other
manufacturers - Any other business", but I would be happy to add an lwIP
specific forum if there was interest.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Windows 7 Startup crashes LwIP and Free RTOS

[FreeRTOS Info]

Hi Guys,

Sorry - just dipping in and out of this thread as it has FreeRTOS in the
title and I want to ensure there are no major issues in anything I'm
distributing.

However, just to repeat something I said a while back, the MAC driver
provided in the FreeRTOS download is a 'demo' quality driver.  It is
intended to allow the features of the kernel to be demonstrated, with
some interrupt interaction, etc.  It is not a full and complete driver
with all the possible error conditions handled.  It has been pointed out
before that certain overrun conditions can cause the driver to hang, and
the error handling under these conditions I think is rather primitive.
Its worth looking at the interrupt cause within the ISR to see why an
interrupt was really generated.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



On 17/07/2010 14:01, Simon Goldschmidt wrote:
> Well, as long as it is a home only project for fun, I can understand that 
> it's ok like that. However, if that same setup is used in a real product, I 
> would also suggest to go deeper into it. Especially since turning off 
> promiscuous points to a havey-load condition problem which I would expect to 
> be located in the ethernet diver.
> 
> Simon
> 
> 
> Am 15.07.2010 um 23:56 schrieb "Bill Auerbach" :
> 
>> Marco,
>>
>> Before, it would fail every few days or longer.  Are you at all worried that
>> that now it might still fail every few weeks or months and it will still
>> lock up the device?  You now know how to make the problem occur less often,
>> so you also know how to make it occur more often. Although it's working
>> "quite good" are you accepting the probability that devices will still lock
>> up, and this is OK?
>>
>> Bill
>>
>>> -Original Message-
>>> From: lwip-users-bounces+bauerbach=arrayonline@nongnu.org
>>> [mailto:lwip-users-bounces+bauerbach=arrayonline@nongnu.org] On
>>> Behalf Of Marco Jakobs
>>> Sent: Thursday, July 15, 2010 3:10 PM
>>> To: lwip-users@nongnu.org
>>> Subject: Re: [lwip-users] Windows 7 Startup crashes LwIP and Free RTOS
>>>
>>> Dear all,
>>>
>>> to finalize this with a status: After changing the EMAC initialization
>>> to non-promiscuous mode (MAC filtering enabled at EMAC level, broadcasts
>>> enabled), the problem did not occur on all devices for a week now. Seems
>>> to be solved (or better: avoided) with this setting.
>>>
>>> Actually i can't get behind what was causing it. Maybe the EMAC task,
>>> which had highest priority together with my watchdog task. The RTOS
>>> stats are showing enough free memory while it's running, but maybe
>>> something causes the 512 bytes not reaching anymore. As i want to
>>> continue my home project and it's working now quite good, i actually
>>> won't put more work in investigation of this.
>>>
>>> Thank you all for your great suggestions!
>>>
>>> Marco
>>
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Windows 7 Startup crashes LwIP and Free RTOS

[FreeRTOS Info]

On 29/06/2010 18:31, Marco Jakobs wrote:
> Hi Jim,
> 
> here is an alternative to the dropbox, if you have some minutes to look
> :-):
> 
> http://www.majak.de/downloads/EMAC.zip
> 
> Kind regards
> Marco
> 
> Am 29.06.2010 19:08, schrieb Pettinato, Jim:
>> Unfortunately dropbox.com is blocked by the corporate firewall here so I
>> haven't been able to review your drivers.

I should point out that, if that is unmodified code from the FreeRTOS
download (sorry, I have not actually looked yet), then it is not a
complete driver.  It is somewhat old and was originally intended to
demonstrate the use of the kernel, rather than demonstrate a fully
functional MAC driver.  I believe I have some updates that were sent to
me by various users somewhere on file, although it might take a while to
find.

As I recall not all the error cases are tested for and handled, although
the description of your problem does not sound related to that.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Soliciting opinions for new FreeRTOS/lwIP demo

[FreeRTOS Info]

Hi Micael,

Thanks for the opinion.  I would be grateful for a copy of your
FreeRTOS/sockets code.  I've currently got my head stuck in some uIP
code but will be moving onto this soon and your code could be a good
head start.  You can send it to nospam [at] freertos [dot] org.  Thanks!

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.




Micael wrote:
> Hi, 
> 
> Having gone the route using lwip sockets with your FreeRTOS, I'd say stick 
> with sockets. Having said that, I realise that there are many reasons not to, 
> especially with lower performance cpus.
> 
> I also think, like Simon, that sockets in it self does not need a very 
> advanced demo, better focus on the initializations and startup. 
> However as for me, I had to struggle a bit to get all bits together, with the 
> demos currently available with FreeRTOS; the file structure is a bit 
> complicated if one are also using the fresher lwip from repository or any 
> newer release. If the FreeRTOS/lwip layers could be made more separated, or 
> layered somehow, it would be great. Currently I have bits and pieces from 
> lwip in FreeRTOS demo path, and other stuff from the 'current lwip' path. 
> 
> I still have the very complicated file strucutre in my project, but at some 
> time I'll have to deal with it. I am just not sure what is the best route, as 
> I'd like to follow updates from both lwip and FreeRTOS without a days work.
> 
> 
> Thanks,
>  Micael
> 
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip 1.2.0 + freeRTOS

[FreeRTOS Info]

Sirjee Rooplall wrote:
> I use ATMEL UC3 software framework + ppp on UC3A0512 device with
> external SDRAM as heap.
> 
> Whenever it crashes, i.e no other task seem to be running, I have an LED
> task that flashes the LEDS which stops.
> 
> If I stop the AVR32Studio debugger, I see that it always stops at
> QueueReceive, and tracing back, sys_arch_mbox_fetch last called, and it
> fails in the function: in the line pointed out below
> 
> The other way I can simulate this promlem is that I establish a
> connection, then I remove the antenna, hence no physical connection to
> the server, and I trigger a new connection using external trigger which
> will try and do a netconn_connect.
> netconn_connect then blocks for about 20 seconds or so, and returns with
> ERR_ARBT(-3), I then retry another netconn_connect and same timeout and
> same error, now when I connect the antenna back again and establish my
> physical layer connection and then I try to establish a TCP connection
> using netconn_connect again, it fails in the same way as descibed above.
> 
> static void prvCopyDataFromQueue( xQUEUE * const pxQueue, const void
> *pvBuffer )
> {
> if( pxQueue->uxQueueType != queueQUEUE_IS_MUTEX )
> {
>  pxQueue->pcReadFrom += pxQueue->uxItemSize;
>  if( pxQueue->pcReadFrom >= pxQueue->pcTail )
>  {
>   pxQueue->pcReadFrom = pxQueue->pcHead; // * FAILS HERE 
>  }
>  memcpy( ( void * ) pvBuffer, ( void * ) pxQueue->pcReadFrom, ( unsigned
> ) pxQueue->uxItemSize );
> }
> }

I think I did request this information when you first said it crashed in
that function


I would guess you have a simple data corruption.  Has something written
over the queue data structure?  Is pxQueue valid?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Soliciting opinions for new FreeRTOS/lwIP demo

[FreeRTOS Info]

Hi List,

The FreeRTOS download contains a few lwIP demos that are now rather old
and need updating.  I'm planning a new demo that uses V1.3.2 but am not
sure of the best route to take.

As FreeRTOS provides the required multi tasking, would an example that
uses the socket API be most appropriate.  Or, as FreeRTOS is designed
for small microcontrollers, would a demo that uses the raw API be most
appropriate?  Most code I see on the WEB does not use sockets.

I would also like the kernel integration to be 'done right' as I have
not yet studied the differences in the V1.3.x releases - so if anybody
has example code they could send (even if it was for a different RTOS),
or are willing to review the demo once its done, then that would be
appreciated.  Also, if anybody has a TFTP example that would be great
too - having an HTTP and TFTP server running in the same demo would be a
good example.

Thanks for any opinions you would care to share.  If anybody is willing
to share some example code (I have the code from the contrib download
already) then the email to use is "r [dot] barry [_at_] freertos.org".

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] lwip 1.2.0 + freeRTOS

[FreeRTOS Info]

Sirjee Rooplall wrote:

> If I look in my debugger, sorry I am using freeRTOS + ATMEL's UC3
> device, it crashes at FreeRTOS QueueReceive function which when I dig
> deeper is pending on sys_arch_mbox_fetch.


Can you say where in that function?

Do you have stack checking switched on?  (configCHECK_FOR_STACK_OVERFLOW
set to 2 in FreeRTOSConfig.h).



Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.










> 
> Is there any application not that would teach me more about proper usage
> of the LWIP API's, and hopefully it will deal with fail states as well.
> 
> Thanks in advance.
> 
> Kind Regards, Sirjee Rooplall Figment Design laboratories (Pty) Ltd
> mailto: sir...@figment.co.za Mobile: +27 (0)83 230 8466
> - Original Message - From: "Simon Goldschmidt" 
> To: "Mailing list for lwIP users" 
> Sent: Monday, January 25, 2010 3:53 PM
> Subject: Re: [lwip-users] lwip 1.2.0 + freeRTOS
> 
> 
>>
>> Sirjee Rooplall wrote:
>>> Hi Simon,
>>>
>>> I am new to LWIP, so I copied that code from an example I have seen.
>>
>> Well, then be so kind and tell the author of that example that it is
>> really a very bad one!
>>
>>> I removed the sleep and I have removed the access to the internal
>>> pcb, and
>>> only rely on the API now.
>>>
>>> The problem I am explaining, seems to also exist in LWIP 1.3.0, as I
>>> have
>>> seen in some of the recent lwip archives.
>>
>> Could you tell us where? Also, the current release is 1.3.2!
>>
>>> Another thing:
>>> Because I am connecting through a PPP->GPRS interface the possibility
>>> exists
>>> where someone removes the antenna and the connection longer exists,
>>> however
>>> the user can trigger a server connection externally through a push
>>> button,
>>> which will attempt to perform a neconn_connect which blocks and returns
>>> with
>>> ERR_ABRT(-3), how do I handle this senario without crashing the
>>> stack. At
>>> the moment, I keep trying every 30 seconds, and eventually I cause the
>>> stack
>>> to crash with too many netconn_connect without a physical connection
>>> available.
>>
>> Normally, that shouldn't be a problem. What exactly happens when you
>> say the stack 'crashes'?
>>
>> Oh, and please don't send so much code unless you have a very specific
>> question about it or someone asks you to. People tend to overread
>> mails containing too much code as it's rather difficult to understand...
>>
>> Simon
>> -- 
>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>>
>>
>> ___
>> lwip-users mailing list
>> lwip-users@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
> 
> 
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Why the delay after ARP?

[FreeRTOS Info]

Simon Goldschmidt wrote:

I am using lwIP 1.3.0 and it works great, but I've always wondered where
there's an approx. three second delay after the ARP response before lwIP
sends the SYN.  In other words:

1. I initiate a TCP connection
2. lwIP sends an ARP request almost immediately
3. The host responds (relatively) immediately
4. lwIP waits about three seconds before sending the SYN

When the MAC is in the ARP cache, this doesn't happen, but still, what is
it doing during that time?  Incidentally, I've noticed uIP does the same. 


I guess the three seconds delay is a TCP timeout, i.e. TCP re-sends the SYN 
after three seconds. This is because the initial packet gets dumped because the 
target MAC is unknown.

In contrast to uIP, lwIP has a feature called ARP queueing: if a target MAC is 
unknown, packets are not thrown away but held back until the ARP response 
arrives. This must not beturned off via the corresponding define (ARP_QUEUEING, 
MEMP_NUM_ARP_QUEUE defines how many packets may be queued) in your lwipopts.h!

Simon



I've never been sure why it is done like that.  I normally change it to 
store the MAC address or the ARP request origin as it comes in, then you 
can send the request out immediately.



Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] lwIP StellarisWare source

[FreeRTOS Info]

> Can anyone send me a copy of (or a link to) the lwIP source as packaged
> with StellarisWare.  It seems to be a popular target at the moment, and
> it would help me discuss bugs and problems if I could see the actual
> source that is in use.

I think it used to be included in the main download from Luminary, at least
it was in older versions when it was called DriverLib.  There was a
sub-directory called something like "third party".

http://www.luminarymicro.com/products/software_updates.html

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] Program to generate packets

[FreeRTOS info]

> Does anyone know of a freeware/open source program to 
> generate packets?  I'm having a checksum problem, and would 
> like to generate packets that have a specific data pattern so 
> it's easier to debug.  I suppose I could try something with 
> Visual Basic, but it's been awhile since I used that.


I used to use a terminal utility for this purpose.  I don't have it any
more, but am pretty sure it was this:
http://www.hw-group.com/products/hercules/index_en.html

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] lwIP web server on the FreeRTOS

[FreeRTOS info]

> My project used a Luminary's LM3S6965 microcontroller, 
> Cortex-M3, with freertos v5.0.3.  The freertos demo runs uIP 
> web server as default. 

Did I not send you a 'contributed' lwIP port for the Luminary part?

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/Documentation
Learn how to use FreeRTOS - full source code included.


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] FreeRtos/LWIP function oddly if new task created before vlwipinit();

[FreeRTOS info]

> The webservice task was configured by the default size of the demo
> port of freeRtos, so I assume that it is enough.


Not necessarily.  That depends on the compiler you are using, the libraries
you are using, and how you have modified other code.  Why not just check the
stack usage, or simply make the stacks bigger to see if it makes a
difference.

http://www.freertos.org/Stacks-and-stack-overflow-checking.html

The implementation of sprintf() used when generating the pages makes a huge
difference as most standard implementations are massively stack hungry.  The
FreeRTOS download includes a super skinny version that uses minimal stack.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/Documentation
New FreeRTOS eBook - learn how to use an RTOS.




___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

RE: [lwip-users] best approach to lwip using FreeRTOS

[FreeRTOS info]

> Not a official one, but I found one example from a guy in the luminary
> forum... I´ll probably try that.

I have just sent you some files.  They might be the same as you already
have.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.FreeRTOS.org/Documentation
FreeRTOS eBook.  Learn how to use an RTOS.  Full source code!


___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] a few questions about lwIP

[FreeRTOS Info]

Dear guys;

I am working on an embedded system requiring a tiny implementation
of the TCP/IP stack. Searching in the Internet, I found uIP and lwIP
very useful for my case. As a result, I tried to study lwIP and uIP,
specially lwIP. After studying your documentaions ("Full TCP-IP for
8-bit Architecture", and "Design and Implementation of the lwIP
TCP/IP Stack") we tried to test your simple web server sample, but
facing a lot of errors both in Linking and Compiling phase. I'd be
very happy if you mention another example which uses lwIP APIs and
also has a simple structure. In fact, my main problem is how to use
lwIP APIs to write my codes.

Looking forward to hearing from you and best wishes,
shimimreh



Your best would be to start with a complete project that includes the lwIP 
source, rather than integrating the raw source code into a new project. 
This way you will have something that compiles and links already that you 
can then just modify to suit your application.


Try to find a project/makefile that already exists for your given processor 
or compiler (the FreeRTOS.org download include ARM7/GCC projects that 
include lwIP which may provide a starting point).


Regards,
Richard.

http://www.FreeRTOS.org
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * 






___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] HTTP server - loading files

[FreeRTOS Info]

Server worked without problem, though one difficulty has appered:
I need some program to turn my webpages into c-files or something, to put
them in program memory.


If you want to statically define your WEB pages in your program memory then 
take a look at the uIP code.  It includes a rudimentary file structure that 
does just this, along with a perl script (makefsdata) for converting html 
into C structs.  It should be straight forward to include these files in 
lwIP.


Regards,
Richard.

http://www.FreeRTOS.org
*Now for ARM Cortex-M3!*


- Original Message - 
From: "Jonas L" <[EMAIL PROTECTED]>

To: 
Sent: Friday, June 30, 2006 12:55 PM
Subject: [lwip-users] HTTP server - loading files




I downloaded the HTTP server, found in contrib/ports/msvc6.

Server worked without problem, though one difficulty has appered:
I need some program to turn my webpages into c-files or something, to put
them in program memory.

I'm assuming that is the prefered web server to use. Does someone have
another suggestion? Maybe one that comes with a program to download files?
--
View this message in context: 
http://www.nabble.com/HTTP-server---loading-files-tf1872834.html#a5119157

Sent from the lwip-users forum at Nabble.com.



___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users









___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Porting LWIP to 8051

[FreeRTOS Info]

Which 8051?  How much ROM/RAM do you have.  I suspect you will get stack 
problems even if you have enough memory.  You might like to take a look at 
uIP instead.


Regards,
Richard.

http://www.FreeRTOS.org
*Now for ARM CORTEX M3!*


- Original Message - 
From: "hiran kuttappan" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, May 25, 2006 1:12 PM
Subject: [lwip-users] Porting LWIP to 8051



I want to port LWIP to 8051. Has anyone already ported LWIP to 8051 and if 
so whether the code available open source.


Since I am a beginer to LWIP what are the steps I must follow to port LWIP 
to 8051.


I want to port LWIP to 8051 with out an OS .

Please anyone help Me.

Thanks

HIRAN M.K.







___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users 






___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Need tiny TCP/IP stack

[FreeRTOS Info]

I'm thinking that since this is the lwip group that you are also familiar 
with uIP.  If not then take a look at http://www.FreeRTOS.org which has a 
simple small os with both lwIP and uIP demos.


Regards.

- Original Message - 
From: <[EMAIL PROTECTED]>

To: 
Sent: Friday, March 17, 2006 10:13 AM
Subject: [lwip-users] Need tiny TCP/IP stack



Hi All,

 I need to integrate a TCP/IP stack(only ARP, ICMP, IP and UDP are
needed). Wether anyone knows the smallest stack available in the open
source. better if it is compatible for RTOS.

Also  can anyone help me out in integrate it with the OS.

Thanx in Advance.

Regards,
Raghavendra. S




The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not 
the intended recipient, you should not disseminate, distribute or copy this 
e-mail. Please notify the sender immediately and destroy all copies of this 
message and any attachments.


WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email.


www.wipro.com






___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users 





___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Strange ARP behaviour

[FreeRTOS Info]

> > If you are really going through a router, the ARP should be generated on
> > the local network by the router.  That doesn't seem to be what is
> > happening in your traces.  The ARP is originating at from two different
> > ethernet addresses.  You should probably review all of your setups,
> > i.e., network address, gateway address, and subnet mask, for the ARM7
> > board, the router ports, and the computers that are originating the
> > pings.  It would be easier to understand what is going on if you could
> > present that information with your traces.
>
> I will collect this info when I'm back in the office.  What I do know is
> subnet mask is 255:255:0:0, and the gateway is 172.25.218.3.
>
> It seemed to me that the router contains an ARP cache (as might be
> expected), as even when I deleted the cache on the PC used to issue the
ping
> an ARP was not generated on the far side of the router, so the router must
> have provided the necessary information locally.  I got around this by
> simply changing the MAC and IP address of the ARM7 board but it does show
> that the router is doing something at least.
>


It seems this problem was in fact caused by the MAC address setting.  For
some reason the router did not accept it.  I changed the initial random
setting from 1:2:3:3:1:0 to another more probably random setting of
00:34:57:22:3c:22 and the problem went away.

?

Regards,
Richard.

http://www.FreeRTOS.org




___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users