Honored ContributorHi,
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
Honored ContributorI'm not exactly sure but if your bandwidth use is smalling and your using an embedded OS it should be.
Honored ContributorYes it should work, as long as the server doesn't only send data but also checks if data in the other direction is ready to be read.
Honored ContributorUnless '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).Honored ContributorI 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???Honored ContributorIf 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.Honored ContributorThanks...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...
Honored ContributorSo 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.Honored Contributorand as regards...the "...a 1ms idle time..." what do you refer to???
Honored ContributorI meant you had it if you'd used the TK_SLEEP(1) (sleep for 1 system tick, assuming as usual 1 tick=1ms) between send() calls.
Honored ContributorI try with TK_SLEEP but nothing to do....it continues to run...damn!!
