Obviousely some of my statements were pretty wrong. Sorry! Thanks for
correcting me and for the perfect information David.
-Ursprüngliche Nachricht-
Von: David Empson [mailto:da...@abbey.co.nz]
Gesendet: Dienstag, 2. Februar 2010 23:24
An: m.zen...@mobatime.com; Mailing list for lwI
as i mentioned in the previous email lwip got 2 main type memorys, one is
ram_heap which defined in mem.c and the size of it is MEM_SIZE, another one
is memp_memory which defined in memp.c and size of it is total of size
((num) * (MEMP_SIZE + MEMP_ALIGN_SIZE(size)).
It is easy to understand ram_he
Thanks for the reply.
In theory, the receiver should have a large window, and the LwIP server
can control transmissions, but the problem I had was the large amount
of retransmission requests for a file upload (large data transmission to
server).
Setting TCP_WND = TCP_MSS fixed the problem, since
Mathias Zenger wrote:
Usually you need to obtain your own MAC addresses at IANA (your own OUI costs
about $160).
I can't see any mention of OUIs or MAC addresses at IANA.
The official registry for allocating MAC addresses is run by IEEE, and no other
organisation is allowed to on-sell them.
h
> I need to transmit frames of videostream. And I need more high-speed transmit
> (~55Mbit/s). Is it real?
I mean that is it real with LwIP?
My hardware is :
- Altera DK-NIOS-2S60N based on Stratix II FPGA
- NIOSII/s softprocessor without OS
- onboard LAN91C111 Ethernet controller
My software is
Hi,
Having gone the route using lwip sockets with your FreeRTOS, I'd say stick
with sockets. Having said that, I realise that there are many reasons not to,
especially with lower performance cpus.
I also think, like Simon, that sockets in it self does not need a very
advanced demo, better foc
Nagle is something different, what you are facing is delayed ACK: TCP
tries to reduce the amount of small packets by only ACKing every 2nd
segment. To reduce your delays, you have to make sure that your
webserver doesn't wait to send data until the first segment is ACKed.
This is also called th
> I need to transmit frames of videostream. And I need more high-speed transmit
> (~55Mbit/s). Is it real?
You mean realistic? Of course it is. Just look at the products
available on the market that do just that.
But that's probably not what you were going to ask. Please supply more
information:
Hi,
I have a web server (Luminary Micro contrib module with SSI and CGI). The page
content is sent in few parts. When server sends a part, web browser waits 200ms
before sending ACK.
I think there is nothing I can do with this, but I hope you could help me
somehow. I read a lot about 200 ms del
I need to transmit frames of videostream. And I need more high-speed transmit
(~55Mbit/s). Is it real?
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Daniel,
Thanks for the pointer - I missed your post in the Luminary forum. I'll take
a look at this and see if there's something that needs fixing in there. You
should be able to replace the file system driver without seeing problems but,
now that I think about it, I may not have tried using
Hi Dave. Thanks for your response.
I've been using the latest sources so every file name was 8.3
compliant. I already started a thread in the Luminary forums:
http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,/func,view/catid,5/id,8672/#8672
But since I was able to do what I ne
Daniel,
I've just seen your post regarding SSI/CGI not working from the FAT file system
on an lm3s8962 board. This should work if you remember that the FAT file system
is limited to 8.3 filenames whereas the internal one is not. If you are working
with a release of the StellarisWare software wh
Kieran Mansley schrieb:
Could you send it to the list so that others who are interested can see
the code too?
Sure ... i was not sure if attachments are welcome here.
The RTOS task "AppIP" is responsible for initialization of the LwIP and
PPP handling. There is also a bunch of test code in
Mathias Zenger wrote:
...
if (timeout> 0) {
/* Create a timer and pass it the address of our flag */
sys_timeout(timeout, sswt_handler,&sswt_cb);
}
sys_sem_wait(sem);
...
As far as I see sys_sem_wait() does a call to sys_arch_sem_wait(). The
passed semaphore is the same:
...
timeouts =
Alain Mouette wrote:
when using DHCP I call netifapi_dhcp_start() ant poll netif_is_up()
until the interface is up.
after some long time, if no connection can be made, I want to start DHCP
again (maybe the cable was diconnected and connected to another
network), what should be the correct proced
On Tue, 2010-02-02 at 14:25 +0100, Marco Jakobs wrote:
> Hi Simon,
>
> i've sent my file over to you (LwIP Init, PPP connections). For any
> further questions don't hesitate to ask for it ... ;-)
Could you send it to the list so that others who are interested can see
the code too?
Kieran
___
Hi Simon,
i've sent my file over to you (LwIP Init, PPP connections). For any
further questions don't hesitate to ask for it ... ;-)
Anyway, the bug could still be in other parts of the stack. Can you tell us
about the rest of your setup (i.e. how many threads, how is it initialized, how
i
Marco Jakobs wrote:
> So this means that there *was* a change according the PPP in 1.3.2?
Only some minor ones, but there have been big changes to PPP after 1.3.2 (only
availabl in current CVS HEAD).
> > You *might* want to try PPP from lates CVS HEAD, but that also involves
> some changes to y
Kieran: Thanks for the hints.
I tried to debug the timeout problem but it's quite tricky for me. I agree
that it's probably a problem in the port (ATMEL Software Framework 1.4.0,
lwIP stack 1.3.0). Obviousely a timeout == NULL or a timeout > 0 give the
same behaviour (blocking infinite).
I can se
Thank you !!
Oscar
On Tue, Feb 2, 2010 at 1:37 PM, Mathias Zenger wrote:
> You definitively need to change the MAC address for every board.
> Otherwise your switch can not forward the packets correctly.
>
> Usually you need to obtain your own MAC addresses at IANA (your own OUI
> costs about $1
Hi Simon,
Simon Goldschmidt schrieb:
It's interesting that this happens with PPP. After all, it might be that
1.3.2's PPP has a bug there (in calling into lwIP from the wrong thread, I
mean).
The warning "lwIP task returned" is not a fatal one: PPP from 1.3.2 created a
task for every c
You definitively need to change the MAC address for every board. Otherwise
your switch can not forward the packets correctly.
Usually you need to obtain your own MAC addresses at IANA (your own OUI
costs about $160). For testing purposes in your private network you probably
just can vary
ETHERNET
Hi,
Thanks a lot for PHAM ANH THIEN and Kieran's reply.
To Kieran, do you mean that when my system is running, use the
function stats_display( ) to monitor how much of memory?
Is there a way to calculate MEM_SIZE by the parameters MEMP_NUM_PBUF,
MEMP_NUM_RAW_PCB, MEMP_NUM_NETCONN and so on? I think
Hi Kieran, Hi Simon
There is a second thread, but it is caused by LwIP itself: When the PPP
connection goes up, LwIP creates a new thread for the PPP in line 538
in ppp.c (Function pppOverSerialOpen):
sys_thread_new(PPP_THREAD_NAME, pppMain,
(void*)pd, PPP_THREAD_STACKSIZE, PPP_THREAD_PRIO);
This question seems related to your board and port (Xilinx, I guess?). You
*might* get more answers posting it in a forum related to your hardware, if
there is any. However, you might also be lucky and someone here is using
the same hardware... Not me, unfortunately.
Simon
Oscar F wrote:
> H
Sorry for not including the original mail, gmx webmail somehow does not include
your original mail. Maybe you can send a text-only mail next time (i.e. no
html)?
Marco Jakobs wrote:
> The problem is not always in the tcp.c, after some more testing i've seen >
> that i also get i.e. this assert:
On Tue, 2010-02-02 at 11:22 +0100, Marco Jakobs wrote:
> I found out some mor additional information which may help to solve my
> issue:
This extra information is consistent with the theory that this is caused
by threading problems in the way lwIP is being called.
Kieran
__
Hi Bill,
I've been unable to use CGI's and SSI on my lm3s8962 either. I've
found that the CGI-SSI feature is not working with the FAT file system
so I had to abandon the idea. However, there is a much simpler way of
interacting between html and controller (gpio): just catch up the http
requests at
Hi, i want to connect four EVK1100 using a switch.
In all of them i´m using lwip, and i must to configure the file conf_eth.h.
The code of this file is this:
*Code:*
#ifndef _CONF_ETH_H_
#define _CONF_ETH_H_
/*! Phy Address (set through strap options) */
#define ETHERNET_CONF_PHY_ADDR
Marco Jakobs wrote:
> LWIP_ASSERT("tcp_slowtmr: TIME-WAIT pcb->state == TIME-WAIT", pcb->state ==
> TIME_WAIT);
That means that one of the PCBs on the TIME-WAIT list is not in state
TIME-WAIT, which is not correct. This could either be a bug in lwIP (state
changed without removing the PCB from
I found out some mor additional
information which may help to solve my issue:
The problem is not always in the tcp.c, after some more testing i've
seen that i also get i.e. this assert:
/src/core/tcp_in.c, line 208:
LWIP_ASSERT("tcp_input: TIME-WAIT pcb->state
== TIME-WAIT", pcb->state == TIM
On Tue, 2010-02-02 at 10:54 +0100, Marco Jakobs wrote:
> Unfortunately i've no idea about the meaning of this assert and how
> the system may get to this state. Any ideas are highly appreciated ...
This is a common problem. It means that the the pcb lists have become
corrupted. This is almost al
Hi to all,
i have noticed that i'm sometimes facing complete (watchdog) restarts
of my system. To track this down, i've connected the debug output and
managed to get the error ... but then i have no idea how to solve this
:-(
The systems runs on the assert in line 778 in /src/core/tcp.c:
On Tue, 2010-02-02 at 16:10 +0800, jinwei younger wrote:
> Hi All,
> How to calculate the memory size used by lwIP?
> We set MEM_SIZE in lwipopts.h, but how much memory is enough for lwIP?
It will vary depending on your application, traffic pattern, interface
used, OS, and so on. You could set ev
On Tue, 2010-02-02 at 12:33 +1100, Mykola Kyrylenko wrote:
> Is it possible to have TCP_WND = TCP_MSS for packet reception, but
> have
> the recommended TCP_WND = 4 * TCP_MSS for packet transmission?
It's the other way round: the receiver needs to have a larger window.
The sender could in theory g
the total memory size of lwIP is MEM_SIZE plus memp_memory. memp_memory
include many types memory which define in lwip/memp_std.h, they could be
MEMP_RAW_PCP, MEMP_UDP_PCB, MEMP_TCP_PCB... it depends LWIP_XXX you define
in your lwipopt.h. So how to calculate each type memory, for example with
MEMP_
Hi All,
How to calculate the memory size used by lwIP?
We set MEM_SIZE in lwipopts.h, but how much memory is enough for lwIP?
Thanks for your help!
___
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
38 matches
Mail list logo
