Yes, you can use the concept of “Credits” to tell the V24 to enable the hardware flow control and prevent swamping your application by excess of data.
Actually, “Credits” represent a way by which you tell to the module the amount of data blocks which are processed by you application. In simple terminology, you can view “Credits” as data blocks presented to your FCM data handler by the module and “Release of Credits” can be visualized as the release of the buffer used to store the data.
The module can allocate 6 such buffers for storing the received data.
Now, suppose, the external application sends data to your embedded application using V24 serial link. The received data will be allocated a buffer (“Credit”) and will be presented to your application by a call to the data handler.
The release of this buffer depends upon the value that you return from your data handler. Suppose, you return TRUE from the data handler. In this case, the buffer allocated for the received data is released and it acts as an indication that your application has processed the received data.
Now, suppose you retun FALSE from data handler. In this case, the buffer allocated internally to store data will not be released. As a total of 6 buffers can be allocated at a time, hence if your Open-AT application returns FALSE from the data handler for 6 consecutive times, all the buffers which can be internally allocated will be used up.
From now, the hardware flow control come into picture. The module will assert the CTS to logical low and will prevent the external application from sending more data over V24 serial link. When you explicitly release the buffer (using adl_fcmReleaseCredits ()) will the external application be allowed to send more data.
Hence, to solve the problem as in your case, you can configure the credits from within your application in such a way that you buffer the data until all the 6 credits are used up (Now the module will not receive any more data from V24, so you get enough time to send data to TCP socket).
When you are finished sending the data, release one credit. So the external applicaiton will be allowed to send some more data (by asserting CTS). After receiving data, again return FALSE from the data handler (to use up the credit again to enable h/w flow control). Then send the data again. This should solve your problem.
In case, you need more information on credits you can consult the ADL user guide. In case, you feel that ADL user guide is not explicit enough, you should consult the Wavecom Technical Support.
Hope the above explanation help you solve your problems.
Open AT Fan.