Re: [lwip-users] Browser finishes every HTTP GET request with a ACK RST, why ? [SOLVED]

[Info]

Problem solved !

After activate the LWIP_HTTPD_SUPPORT_11_KEEPALIVE macro in the HTTPD 
web server, the problem is gone. And of course the periodic 
communication between the web server and the browser has much less 
overhead, because the connection is not closed after each request.


Thank you very much for all your answers.

Kind regards,
Roland

Am 24.09.21 um 10:35 schrieb Indan Zupancic:

Hello,

On 2021-09-15 15:37, Info wrote:

In the attached Wireshark capture file I can see many frames (from the
web browser) with the set ACK RST flags. For me it not clear why the
web browser sends this frames and if it is the reason for the broken
periodic communication ? Any help and maybe some explanation would be
very welcome.


I ran my own test for 8 hours, first few hours a HTTP request every 
100 ms,

the others every 10 seconds. We're using our own webserver code without
any issues for a few years now.

In those 8 hours I get 8 resets, all in the first few hours during the 
100ms test.

(This is with Windows 10 as host.)

All these resets happened when the port was re-used by the browser 
after 2 seconds
of a previous transaction. Our TIME WAIT is configured for 2 seconds 
(TCP_MSL 1000).


What I see happening is that lwIP sends an ACK with the same sequence 
number
as previously, instead of a SYN, ACK. The other side of course doesn't 
like

that and sends a RST.

This does not fully explain everything in your Wireshark log, but 
maybe it is related.


Looking at the code, this behaviour is intentional and done in 
tcp_timewait_input().

Reading the RFCs this behaviour is by design and lwIP does nothing wrong.

The reason why ports are re-used so quickly is probably because 
they're chosen randomly.
If the host just resends a new SYN and does not return an error to the 
browser this

behaviour is fine.

Greetings,

Indan



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

Re: [lwip-users] Browser finishes every HTTP GET request with a ACK RST, why ?

[Info]

Am 22.09.21 um 12:04 schrieb goldsi...@gmx.de:


Sorry, I don't have an idea what's wrong here.

Regards,
Simon


Thank you Simon (for your honest answer  )...

I made a new Wireshark capture file and logged the corresponding debug 
output from the lwIP (I stripped down the capturing and logging, so it's 
not huge). For the logging output the following debug macros were activated:

  TCP_DEBUG
  TCP_INPUT_DEBUG
  TCP_OUTPUT_DEBUG

Maybe this will bring new insights where the problem might be.

Kind regards,
Roland

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

Re: [lwip-users] Browser finishes every HTTP GET request with a ACK RST, why ?

[Info]

Does nobody have the time to give me some advise where the problem could 
be ?


At least to understand the main problem I need some help.
In the Wireshark capture file at line number 245 is a TCP frame from the 
web browser with the [SYN] flag set. Normally the web server would 
answer with [SYN, ACK]. But for some reason the web server answer only 
with [ACK] (line number 246 in the capture file). And from this point on 
the communication with the web server is disturbed.


Any help would really be very welcome.

Kind regards
Roland


Am 15.09.21 um 15:37 schrieb Info:

Hi

I'm using lwIP (2.1.3-RC1) with the httpd web server from the apps 
directory in my embedded application. After loading a web content from 
the web server a periodic communication starts from the web browser 
that opened the website. This all works, but after a view minutes the 
periodic communication gets broken (the web server/lwIP stack itself 
does not crash). After a reload of the web site the periodic 
communication is established again for a view minutes.


In the attached Wireshark capture file I can see many frames (from the 
web browser) with the set ACK RST flags. For me it not clear why the 
web browser sends this frames and if it is the reason for the broken 
periodic communication ? Any help and maybe some explanation would be 
very welcome.


I also activated the debugging output and the internal lwIP asserts, 
but this did not help me to track down the problem. The web server 
does not support encryption.


The lwIP uses FreeRTOS with the sys_arch files found in the contrib 
package.


IPs used in the Wireshark capture : The web server uses 192.168.3.131 
and the client (web browser) 192.168.10.103 .


Thank you very much for any help
Roland

___
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] Browser finishes every HTTP GET request with a ACK RST, why ?

[Info]

Hi

I'm using lwIP (2.1.3-RC1) with the httpd web server from the apps 
directory in my embedded application. After loading a web content from 
the web server a periodic communication starts from the web browser that 
opened the website. This all works, but after a view minutes the 
periodic communication gets broken (the web server/lwIP stack itself 
does not crash). After a reload of the web site the periodic 
communication is established again for a view minutes.


In the attached Wireshark capture file I can see many frames (from the 
web browser) with the set ACK RST flags. For me it not clear why the web 
browser sends this frames and if it is the reason for the broken 
periodic communication ? Any help and maybe some explanation would be 
very welcome.


I also activated the debugging output and the internal lwIP asserts, but 
this did not help me to track down the problem. The web server does not 
support encryption.


The lwIP uses FreeRTOS with the sys_arch files found in the contrib package.

IPs used in the Wireshark capture : The web server uses 192.168.3.131 
and the client (web browser) 192.168.10.103 .


Thank you very much for any help
Roland


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

[lwip-users] CDC-EEM with lwIP

[Info]

Hi,

I'm trying to implement "Ethernet over USB", means a CDC-EEM 
(Communication Device Class, Ethernet Emulation Model) device. I already 
have a working USB stack and the USB device is listed on the Linux PC as 
a CDC-EEM device. I also did a connection to the lwIP (implementing the 
necessary function to support a new network device). But further 
communication like a ping to the connected CDC-EEM device is not possible.


Has somebody done a CDC-EEM implementation with lwIP as the TCP/IP stack ?

Kind regards,
Roland

___
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 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] Problem accessing "httpd" web server from a Linux PC

[Info]

I don't believe this is a problem. According to the lwIP documentation
it should be no problem to use the RAW API functions as long as you call
all RAW API function from inside the main tcpip_thread... and that is
the case in the "httpd" web server code I use (as far as I could see).

Regards, Roland

Am 03.12.2015 um 17:26 schrieb Bettega Stefano:
> If I well remember the httpd examples uses RAW APIs (it's in httpserver_raw 
> folder) and it's intended to be used when NO_SYS=1, as it accesses directly 
> the internals structures of lwIP. As you are using FreeRTOS, you may have 
> unpredictable results. I had the same problem and had to switch to 
> httpserver, which uses netconn APIs.
>
> Cheers,
> Stefano
>
> -Messaggio originale-
> Da: lwip-users-bounces+stefanobettega=digiteclecco@nongnu.org 
> [mailto:lwip-users-bounces+stefanobettega=digiteclecco@nongnu.org] Per 
> conto di Info
> Inviato: giovedì 3 dicembre 2015 14:34
> A: lwip-users@nongnu.org
> Oggetto: [lwip-users] Problem accessing "httpd" web server from a Linux PC
>
> Hi
>
> I'm using the "httpd" (httpd.c) web server from the lwIP contribution
> package (1.4.1) on top of the lwIP 1.4.1 on an embedded system (using
> the FreeRTOS). If I access the web server from a Windows PC with the
> FireFox browser there is no problem and the pages are all shown like
> expected. If I now use the same configuration and trying to access the
> web server from a Linux PC (also with the FireFox browser) the pages are
> not shown, because there are problems with the communication between the
> PC and the lwIP.
> The PCs are connected directly (point-to-point) to the embedded system
> (means there is no switch, etc. between).
>
> I have activated all the error checking inside the lwIP source code and
> also enabled the statistic counters... but it does not show me any
> problem. There are no error messages (and no stop trough the build-in
> asserts) and the statistic counters look all good, even if a try to
> access the web server with the Linux PC.
>
> I have attached two Wireshark recordings, one done while connected with
> the Windows PC and the other while connected with the Linux PC. If
> somebody with more knowledge could have a look into the recordings and
> maybe give me some hints what the problem could be.
>
> Any help would be very welcome
>
> Regards, Roland
>
>
>
> ___
> 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] 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.


snip

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

[lwip-users] Single connection with httpd web server

[Info]

Hi all

I'm using the httpd (httpd.c) web server from the lwIP contribution
package on top of the lwIP 1.4.1 . The web server is running well
without any problems. I activated the LWIP_HTTPD_SUPPORT_11_KEEPALIVE
macro to keep a connection to web server open. This also works like
excepted. Now I would like to limit the number of connections to one,
that means only one user can connect to the web server (and can make
changes on the configuration of the embedded system). I think it should
be implemented in the http_accept() in such a way, that any new
connection is denied if already a connection is open.
Is this correct or how do I implement such a behaviour ? Any suggestion
would helpful.

Kind regards,
Roland


___
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]

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] 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] 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, sarcasm why doesn't
every project rename every source file to have the project name as a
prefix? That would be a great idea! /sarcasm

:-)

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] Problem after lwIP update (1.3.0 - 1.4.1)

[Info]

Hi Sergio

I found the problem in my (EtherC hardware) driver, which caused the
problem with the re-transmissions (and all other errors).

Thank you very much anyway for your offer to have a look into the
capture file.

Kind regards,
Roland

Am 19.06.2014 23:53, schrieb Sergio R. Caprile:
 I'd like to help on this but currently don't have the time to analyze
 the capture file.
 Check you are calling the netif receive function on frame arrival with
 no polling delays, and if you are still thriving let me know and I'll
 try to check the capture file and see if I see anything wierd


 ___
 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] 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:

snip

 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)
  {
  bufferTmp = (char *) pvPortMalloc((PBUF_POOL_BUFSIZE +
 1)*sizeof(*bufferTmp));
  }
 
  if(bigDataBuffer == NULL)
  {
  bigDataBuffer = 

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] 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 goldsi...@gmx.de wrote:
 jblackarty wrote:
 An: Ivan Delamer dela...@inicotech.com, Mailing list for lwIP users 
 lwip-users@nongnu.org
 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 checks arguments 
 passed from threads to kernel functions, wouldn't it? Is FreeRTOS-MPU 
 designed like that?

 As a summary, lwIP's multithreading design should certainly 

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 vincent@enlogic.com 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();


snip a lot

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] 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] 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] 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] 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] enable socket in lwip

[FreeRTOS Info]

On 07/01/2012 19:00, Gisle Vanem wrote:
 Carol Lai c...@fwmurphy.com 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

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] CHAR_BIT=16?

[FreeRTOS Info]

On 23/11/2011 12:27, Simon Goldschmidt wrote:
 Kieran Mansley kie...@recoil.org 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] 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

[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]

 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.

snip

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]

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]

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]

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 kie...@recoil.org
 *To:* Mailing list for lwIP users lwip-users@nongnu.org
 *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 mailto: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] 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 r.ba...@freertos.org 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 a...@sics.se
 *
 */
#ifndef __LWIPOPTS_H__
#define __LWIPOPTS_H__

#include limits.h

/* 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_DNS  

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] 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]

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] 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 nos...@freertos.org 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] 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]

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 vincent@enlogic.com 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] 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 nos...@freertos.org 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] 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]

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 vincent@enlogic.com
 To:   Mailing list for lwIP users lwip-users@nongnu.org
 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] 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=1sr=1
 http://cache.freescale.com/files/32bit/doc/app_note/AN3931SW.zip?fsrch=1sr=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 vincent@enlogic.com
 To:   Mailing list for lwIP users lwip-users@nongnu.org
 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_ mailto: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_ 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 vincent@enlogic.com
 To:   Mailing list for lwIP users lwip-users@nongnu.org
 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] 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]

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

[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] 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);//Added line
  tcp_arg(pcb, hs);

  /* Set up the various callback functions */
  tcp_recv(pcb, http_recv);
  tcp_err(pcb, http_err);
  tcp_poll(pcb, http_poll, HTTPD_POLL_INTERVAL);
  tcp_sent(pcb, http_sent);


Regards,
Richard.

+ 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

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.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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 a...@sics.se
 *
 */

//*
//
// 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
 * Outputs:
 *  

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 nos...@freertos.org 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
 (!--#loc0001--),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 can that not be done in the task?
When you have data passed to the task, the task knows that the

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 Montgomerypjmo...@csi.com  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 low priority, you need to handle this differently.

 The 

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 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

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( semaphore handle ).  Depending on the compiler, you may
need to case semaphore handle) to a xQueueHandle type - but that should
not be necessary as queue handles also appear as void* outside of the
file that implements the queue API.

Deleting a queue will cause the memory allocated to store the queue
structure and the queue storage area to be freed (the queue storage area
for a semaphore is zero bytes long anyway).  *However* you should not
delete a mutex that is being held by a task, or delete a mutex that has
tasks waiting for it to be released.

Don't know if that helps answer that part.

+ 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

[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] 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

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]

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] 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 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 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]

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 nos...@freertos.org
 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 nos...@freertos.org
 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 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
 mailto:lwip-users@nongnu.org mailto: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

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] 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

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 goldsi...@gmx.de
 To: Mailing list for lwIP users lwip-users@nongnu.org
 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

[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 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] 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] Using MEM_LIBC_MALLOC == 1 in an OS

[FreeRTOS.org Info]

 -Original Message-
 From: lwip-users-bounces+nospam=freertos@nongnu.org 
 [mailto:lwip-users-bounces+nospam=freertos@nongnu.org] On 
 Behalf Of Edward Harris
 Sent: 26 February 2009 10:03
 To: Mailing list for lwIP users
 Subject: [lwip-users] Using MEM_LIBC_MALLOC == 1 in an OS
 
 Hello all.
 
 I have just spotted a possible issue in the LwIP port that I 
 am working with under an OS (FreeRTOS).
 
 The issue is that I have set MEM_LIBC_MALLOC = 1, to use the 
 standard C
 malloc() and free(), however as I'm using an OS, should I redirect the
 mem_xxx() macros to the OS protected versions?
 
 Also, can someone clarify the use of SYS_LIGHTWEIGHT_PROT, 
 should I have it set to 1?
 


This does not answer the question directly, but in FreeRTOS if you include
heap_3.c in your project then the FreeRTOS heap calls just use the standard
malloc too - but protected by a critical region (actually a scheduler lock
so interrupts remain enabled).  It would then seem to make sense for the
lwIP calls to use the same functions.

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] web server connection gateway (ColdFire MCF5282 +FreeRTOS)

[FreeRTOS.org Info]

 Hi all,
 This is my first post, and i'm new to lwIP.  I'm trying to 
 port a FreeRTOS demo that includes lwIP 1.3.0 on the ColdFire 
 architecture.  The goal, at least for now, is to program a 
 simple web server, but later on we'll need to include SNMP.  
 I'm confused about the gateway address.   Here are my 
 questions:  do I even need a gateway when connecting my board 
 directly to the PC using crosswird utp rj-45 network cable?  


The gateway will not be used unless you communicate with an IP address that
is outside of your local network.  So it is not used when using a point to
point connection.

Regards,
Richard.

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




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

RE: [lwip-users] web server connection gateway (ColdFireMCF5282+FreeRTOS)

[FreeRTOS.org Info]

 -Original Message-
 From: lwip-users-bounces+nospam=freertos@nongnu.org 
 [mailto:lwip-users-bounces+nospam=freertos@nongnu.org] On 
 Behalf Of Francois Bouchard
 Sent: 02 February 2009 21:51
 To: Mailing list for lwIP users
 Subject: Re: [lwip-users] web server connection gateway 
 (ColdFireMCF5282+FreeRTOS)
 
 My netmask was incorrect.  now the demo is almost working.  
 By the way, the demo (lwIP_MCF5235_GCC) has 
 portENTER_SWITCHING_ISR(  ); macro that I can't find 
 elsewhere.  From what I see in the documentation and from the eclipse
 5282 demo, it is not needed.  I removed it.
 Francois
 

That is a deprecated port that was never officially supported (the
documentation says as much) - the latest and supported Coldfire V2 port
layer code is in FreeRTOS\Source\portable\GCC\ColdFire_V2.
portEND_SWITCHING_ISR() is defined, but not portENTER_SWITCHING_ISR().  The
new supported port has a full interrupt nesting model and a less complicated
way of defining interrupts, hence the change.

For preconfigured supported projects take a look at:
http://www.freertos.org/ColdFire-RTOS-Port-Using-Eclipse.html
For the supported 5282 project, can't remember if lwIP is included in that
or not.

http://www.freertos.org/MCF52233-RTOS-Demo-With-WEB-Server-Using-GCC-and-Ecl
ipse.html
For a completely pre-configured demo that uses uIP rather than lwIP.

I also have a MCF52259/lwIP project that uses lwIP but this has not made it
into the release yet, although I believe it is included in the dev kits that
Freescale are supplying.

Hope this helps your efforts.

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] LPC2468+lwIP+FreeRTOS+GCC

[FreeRTOS.org Info]

 I could tell you another story about how well lwIP ran on my 
 ARM7, but I'd like to question the significance of the 
 statement never seen lwIP work on an ARM7... If it has a C 
 compiler, it runs! (of course, you need an ethernet MAC also...)


lwIP on an ARM7 - http://www.freertos.org/portsam7xlwIP.html

This is rather old now and does not use the latest lwIP port.  There is code
in the Contributed Ports section of the FreeRTOS.org download that runs on
ARM7 and ARM9 though (I think, from memory).  Plus newer demos on other
architectures.

 
 You have to be careful about using the word GCC, I guess: at 
 first, I compiled lwIP with the C++ compiler of GCC, which 
 lead to many warnings. 
 But using the C compiler, I'm pretty sure there are no 
 warnings generated (unless you use one of the more chatty 
 warning switches).

The above link is using GCC.



Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 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 port for windows + winpcap ?

[FreeRTOS.org Info]

I have an old port to WinPCap that you may be able to resurrect, but it uses
MingW and Eclipse, not MSVC.  There is no documentation on how to get it up
and running, it was just something I was playing with and it is not V1.3.
Is it of interest?

Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 downloads per month.

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



  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Tamas Somogyi
 Sent: 27 August 2008 16:53
 To: Mailing list for lwIP users
 Subject: [lwip-users] lwip port for windows + winpcap ?
 
 Hi guys,
 
 I'm a newbie in this list and wondering where can I find 
 ported LwIP 1.3 for Windows, preferably using winpcap and 
 MSVC compiler?
 
 I browsed a lot of mail archive and webpage, but found 
 old/broken links only...
 
 Thanks,
 Tamas
 
 
 ___
 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 and threads with PPP

[FreeRTOS.org Info]

 My operating system -IAR's PowerPAC, has no support for 
 threads but only tasks. I can implement threads of lwip as 
 tasks (can i?), 

I think in this instance you can consider threads and tasks to be one and
the same thing.

Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 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 and IAR Workbench

[FreeRTOS.org Info]

Everywhere there is a macro that aligns a struct you have to add in:

#pragma data_alignment=4

Everywhere there is a macro that packs a struct you have to add in:

#pragma pack(1)

Because they use a # you cannot simply define the macro PACK_STRUCT_STRUCT
to do this for you.

Regards,
Richard.

+ http://www.FreeRTOS.org
17 official architecture ports, more than 6000 downloads per month.

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



  

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Akshat Bisht
 Sent: 19 August 2008 07:31
 To: Mailing list for lwIP users
 Subject: Re: [lwip-users] LwIP and IAR Workbench
 
 @Richard: Yes there were errors in the PACK_STRUCT part,
 
  i changed: 
 
  #define PACK_STRUCT_STRUCT __attribute__ ((__packed__))
 
  to 
 
 #define PACK_STRUCT_STRUCT 
 
 It compiles without errors now, but i seriously doubt if what 
 was a solution. Can you provide more guidance? 
 
 Regards,
 
 AB
 
 
 
 On Tue, Aug 19, 2008 at 11:49 AM, FreeRTOS.org Info 
 [EMAIL PROTECTED] wrote:
 
 
   
I am new to LwIP and am trying to port it into IAR's
Workbench.
   
   
   Another thing to watch out for with IAR is the pragmas 
 that are required to
   pack and align structures.  These cannot be added in 
 using the pack/align
   macros so must be edited into the code manually - at 
 least this is the only
   way I have found of doing it.
   
   Regards,
   Richard.
   
   + http://www.FreeRTOS.org
   17 official architecture ports, more than 6000 
 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 mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users