Re: [lwip-users] Consecutive calls to sendto() and recvfrom() functions
> When it comes to layer-2 driver, it is a driver provided by Xilinx, > so I guess that problem couldn't be there. Ha ha, nice joke! Do you have more like this one ? ;^) Sorry, I can't help further. You should read the wiki and take some training on embedded systems debugging. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Consecutive calls to sendto() and recvfrom() functions
Thanks Sergio for your advice. When it comes to layer-2 driver, it is a driver provided by Xilinx, so I guess that problem couldn't be there. I have no idea how to check driver itself and be sure that problem is not there (do you have any suggestion how I could do that?). As you said FreeRTOS port should be OK, I got it from Xilinx as well, and for hardware itself, that's something I should try to test better. All in all, since I don't have much experience, I would be grateful if you could give me more references about these stuff that is how to eliminate faulty variables in a proper way. On 28.10.2016 19:35, Sergio R. Caprile wrote: > Sergio, can you just explain what you mean by third sentence, how can > I check all those things (port, driver) and what is known-to-work app? lwIP is not and end-user full contained product, it starts at layer-3 (IP) and runs on some hardware, it has been ported to that hardware. Your layer-2 driver might just be discarding/losing frames, for example; or your hardware might be doing that. A known-to-work application is an application that is known to work ;^), that is, it is not something you are writing yourself while you learn how to use lwIP but something that has been proved OK. For example, the examples in the contrib tree. Since your hardware can be faulty, your driver can be faulty, your port can be faulty, and your application can be faulty, you have to eliminate variables (faulty stuff), so if one of the examples do not work for you, either your hardware, your port or your driver (sometimes both...) are the culprit. Most of the times, your driver can be checked alone, and your port can sometimes be checked for doing things the proper way, that is, only calling low-level functions from within a single thread; sockets and netconns can be called each one from its thread. RTOS ports (NO_SYS=0) use some semaphores, you can search the list for a priority problem, I bet the FreeRTOS port is running OK, but depends on where you get it from... You should also read the wiki... http://lwip.wikia.com/wiki/LwIP_Wiki ___ 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] Consecutive calls to sendto() and recvfrom() functions
> Sergio, can you just explain what you mean by third sentence, how can > I check all those things (port, driver) and what is known-to-work app? lwIP is not and end-user full contained product, it starts at layer-3 (IP) and runs on some hardware, it has been ported to that hardware. Your layer-2 driver might just be discarding/losing frames, for example; or your hardware might be doing that. A known-to-work application is an application that is known to work ;^), that is, it is not something you are writing yourself while you learn how to use lwIP but something that has been proved OK. For example, the examples in the contrib tree. Since your hardware can be faulty, your driver can be faulty, your port can be faulty, and your application can be faulty, you have to eliminate variables (faulty stuff), so if one of the examples do not work for you, either your hardware, your port or your driver (sometimes both...) are the culprit. Most of the times, your driver can be checked alone, and your port can sometimes be checked for doing things the proper way, that is, only calling low-level functions from within a single thread; sockets and netconns can be called each one from its thread. RTOS ports (NO_SYS=0) use some semaphores, you can search the list for a priority problem, I bet the FreeRTOS port is running OK, but depends on where you get it from... You should also read the wiki... http://lwip.wikia.com/wiki/LwIP_Wiki ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Consecutive calls to sendto() and recvfrom() functions
Hello, On 10/24/2016 13:44, pekez wrote: For example, server receives only the last message, while the first three are not received/detected. This would be consistent with lwIP's ARP_QUEUEING option being set to zero: while the lwIP stack is waiting for an ARP reply from the (Windows) server, it holds only the last packet being sent. You could confirm if this is the problem by changing your client to start by sending one packet and then sleeping for a second or so (thus allowing the ARP reply to come in), before entering the main loop. Change your server accordingly of course. Regards, David ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Consecutive calls to sendto() and recvfrom() functions
Hi guys!
I've been trying to implement UDP server application on my custom ZYNQ
board. I am using lwip141 1.5 with FreeRTOS.
This is a simple UDP server example I am trying to implement:
while ( TRUE )
{
for ( i = 0; i < 4; i++)
{
printf("waiting for message...\r\n");
bytes_received = recvfrom(socket_value, buffer,
MAX_UDP_PACKET_SIZE, 0, (struct sockaddr*) _addr, _size);
printf("message received: %s\n", buffer);
}
buffer[0] = 'e';
for ( i = 0; i < 4; i++)
{
temp = buffer[0] + i;
sendto(socket_value, , 1, 0, (struct sockaddr*)
_addr, addr_size);
}
}
Note: before this while loop I have only calls to socket and bind, and
of course, part of code that sets sockaddr_in struct for server. So,
it's really simple app.
On the client side, of course, it is vice versa, I have 4 sendto() calls
and than 4 recvfrom() calls. I have tried these applications on PC (with
windows sockets), both server and client were run at the same PC, and
that works in an expected way. However, when I run my server application
on ZYNQ board it behaves quite randomly. For example, server receives
only the last message, while the first three are not received/detected.
Can anyone help me with problem, I would be really grateful? If there is
any other information I need to give, please tell me, I am not sure
whether I forgot to mention something.
Thank you
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Consecutive calls to sendto() and recvfrom() functions
And yeah, the most important thing, PC and ZYNQ board are connected
directly with Ethernet cable, so packets are not going out to network.
On 24.10.2016 13:44, pekez wrote:
Hi guys!
I've been trying to implement UDP server application on my custom ZYNQ
board. I am using lwip141 1.5 with FreeRTOS.
This is a simple UDP server example I am trying to implement:
while ( TRUE )
{
for ( i = 0; i < 4; i++)
{
printf("waiting for message...\r\n");
bytes_received = recvfrom(socket_value, buffer,
MAX_UDP_PACKET_SIZE, 0, (struct sockaddr*) _addr, _size);
printf("message received: %s\n", buffer);
}
buffer[0] = 'e';
for ( i = 0; i < 4; i++)
{
temp = buffer[0] + i;
sendto(socket_value, , 1, 0, (struct sockaddr*)
_addr, addr_size);
}
}
Note: before this while loop I have only calls to socket and bind, and
of course, part of code that sets sockaddr_in struct for server. So,
it's really simple app.
On the client side, of course, it is vice versa, I have 4 sendto()
calls and than 4 recvfrom() calls. I have tried these applications on
PC (with windows sockets), both server and client were run at the same
PC, and that works in an expected way. However, when I run my server
application on ZYNQ board it behaves quite randomly. For example,
server receives only the last message, while the first three are not
received/detected.
Can anyone help me with problem, I would be really grateful? If there
is any other information I need to give, please tell me, I am not sure
whether I forgot to mention something.
Thank you
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
