Hi,Is it possible send a character command from a client to a server if server is still sending data continuously to client?....so...I mean....during server->client data sending...? Regards
Unless 'continously' means the server is flooding the socket with data and is using most of cpu time, full duplex communication is possible; as a matter of fact I dare say it's a common situation with TCP sockets.You must also consider your physical layer and link level. Some transmission media is inherently half duplex, although I think you are using a 100Mb or Gb Ethernet interface which both support full duplex transmission. With Nios these lower layers are normally not a problem and the bottleneck is the software side (TCP stack management and application).
I ask this question because...my problem is that when my server (Nios II side) begins to send data continuously (a loop with an 'S' character as end condition) to my client (pc side) I don't succeed in stopping it sending the 'S' character to server....My project is a modified version of simple socket server example...in which I modified the part of SSS_exec_command routine in SSS_Simple_Socket_Server.c file....adding the condition in which if a 'M' character is received ...a loop data sending starts...and if a 'S' character is received this loop data sending SHOULD stop....but I see...this doesn't happen....for all character commands...also led and 7seg display managing commands don't work after the loop starts.How should I do to verify,during my while(1) data sending loop, if a character is received from pc client???
If you have a while loop with a send() and no kind of flux control, the described problem is pretty normal: the transmitting server will continously queue data until it finds free memory, but on the other side the receiver part will not have neither memory, nor cpu time to manage incoming data.If you use uC/OS, a simple solution would be inserting a TK_SLEEP(1) macro in the while loop; this will momentarily release the control to other tasks, in particular the receiver one. However the sleep solution could lead to some performance issues if your application is supposed to transmit lot of data, possibly for streaming; infact you have a 1ms idle time for every send call. So you must devise a flux control method at your application level, for example requiring an answer from client after you have sent a specified amount of data.
Thanks...Cris for information...yes, I have a send() in my while without flux control...but what do you mean with "...a 1ms idle time..." because....from my custom block inside SOPC system I receive 32bit data every about 7us....so if I have to wait 1ms after evey send()...I'd lose many data...
So your send calls are not back to back. I understand in your while loop you actually wait until data is ready from your peripheral and this is correct.What could be wrong is if you are calling send() every 7us for a single 32bit data. Nios is a rather slow processor and can't handle such a fast rate. Consider that if you use uC/OS the task switching itself needs a few us. So, you'd better pack more data in a single send call. With 32bit/7us you need a data throughput about 570kbyte/s: from my experience you can achieve it with Nios running at 50MHz, but you need to optimize the way you handle data. IMHO the SSS sample is good for starting but it has some limitations and must be adapted to the actual application.
How about reading the socket from a separate task that has a higher priority? The task should be suspended as long as no data is here, but when it comes it will suspend the send task, and you can use a share variable to control the other task.IIRC the Nichestack is thread safe so this should work.