Serial port questions

[SimonLothar]

Am I right in assuming that: 2 means that none of the data from bytes_to_transmit was written to the buffer?

Yep. Serial_BufferedTransmitNBytes() calls Serial_GetFreeTransmitSpace() itself and quits immediately without touching any buffer, if the requested count of bytes does not fit completely.

If yes, don't I need to keep calling Serial_BufferedTransmitNBytes() with the same data until it returns 0? So, this can't be blocking, right? My program is in a main loop looking for user input. Whenever user enters something (say in a text box), I need to transfer it via serial, so I call Serial_BufferedTransmitNBytes(). But I can't build the retry logic here (keep calling the function till 0 is returned) because it would block the user. So I should have a queue in a timer and the main loop should write to the queue? And the function in the timer should take care of error codes, retries etc.?

Keep in mind, that if you transfer at a speed of 115 kBaud, even a completely filled buffer of 256 bytes is transmitted within 25ms! It seems to be impossible, that the buffer will ever suffer times of shortage, if you exchange data based on interactive user input only.

[happy Profile]

Keep in mind, that if you transfer at a speed of 115 kBaud, even a completely filled buffer of 256 bytes is transmitted within 25ms! It seems to be impossible, that the buffer will ever suffer times of shortage, if you exchange data based on interactive user input only.

Thanks Simon. I don't have any real devices to test yet, but I will take your word for it And keep posting here when I do actually test.

Technically, when I get the 3 pin - female serial cable, won't I be able to connect to my laptop's serial port and print whatever I am sending from the calculator on to a terminal emulator program? Similar to what Helder did, but instead of EventGhost, say MacWise for OSX, and print whatever comes on COM1 from the calculator?

That reminds me, the data I want to send will be more than 256 bytes. I will break them into chunks of less than 256 and send, but can I be sure that the order in which they will get to the receving device will be the same as the order in which I send them? Problem is, from the device's (WiSnap Wifi adapter) user manual, it doesn't look like it is capable of responding back to the sender. It can only be configured to post the data it receives on its serial port to an HTTP URL.

[SimonLothar]

Technically, when I get the 3 pin - female serial cable, won't I be able to connect to my laptop's serial port and print whatever I am sending from the calculator on to a terminal emulator program? Similar to what Helder did, but instead of EventGhost, say MacWise for OSX, and print whatever comes on COM1 from the calculator?

If the receiver does not require a special protocol or negotiation, that should work.

That reminds me, the data I want to send will be more than 256 bytes. I will break them into chunks of less than 256 and send, but can I be sure that the order in which they will get to the receving device will be the same as the order in which I send them? Problem is, from the device's (WiSnap Wifi adapter) user manual, it doesn't look like it is capable of responding back to the sender. It can only be configured to post the data it receives on its serial port to an HTTP URL.

It would be a funny stunt, if -in a single channel serial transfer- a receiver reorders received packets by chance. Though, if there is no packet acknowledgement, you will not be able to detect a packet miss. That may be a problem indeed.

[happy Profile]

Code: Select all

   
    void serialSend(char *buffer)
        {
        if (Serial_IsOpen() == 3)
            {
            unsigned char mode[6] = {0, 9, 0, 0, 0, 0};
            Serial_Open(mode);
            Serial_ClearReceiveBuffer();
            Serial_ClearTransmitBuffer();
            }
        if (Serial_IsOpen() == 1)
            {
            while (Serial_BufferedTransmitNBytes((unsigned char*) buffer, strlen(buffer)) != 0);
            }
        }

    void sendData()
        {
        char buffer[255];
        int i;
        int noOfTimes = 150;
        for (i=0;i<noOfTimes;i++)
            {
            memset(buffer, '\0', 255);
            sprintf(buffer + strlen(buffer), "%s", "STA-te-st-STO");
            serialSend(buffer);
            }
        }


sendData() is called from the main loop when user enters some data. In the emulator, it hangs, because it looks like buffer doesn't clear and Serial_BufferedTransmitNBytes() starts returning 2 after some time. It works when 'noOfTimes' is a small number (less than 5).

Atleast in the emulator, shouldn't the transmit buffer be empty almost all the time? Should I sleep for sometime if Serial_BufferedTransmitNBytes() returns 2?

[happy Profile]

It would be a funny stunt, if -in a single channel serial transfer- a receiver reorders received packets by chance. Though, if there is no packet acknowledgement, you will not be able to detect a packet miss. That may be a problem indeed.

Sorry our posts crossed each other. This I guess I will have wait for the adapter to arrive to test.

[SimonLothar]

sendData() is called from the main loop when user enters some data. In the emulator, it hangs, because it looks like buffer doesn't clear and Serial_BufferedTransmitNBytes() starts returning 2 after some time. It works when 'noOfTimes' is a small number (less than 5).

Atleast in the emulator, shouldn't the transmit buffer be empty almost all the time? Should I sleep for sometime if Serial_BufferedTransmitNBytes() returns 2?

Obviously the Emulator does not emulate the serial interrupt system. That could be an explanation for the buffer not be emptied regularly. And if 'noOfTimes' is small enough the serial transmit buffer does not fill up completely and gives Serial_BufferedTransmitNBytes() no reason to return 2.

BTW: Serial_Open resets the buffers automatically
The Serial_Clear...-statements following "Serial_Open" could be omitted.

[happy Profile]

Obviously the Emulator does not emulate the serial interrupt system.

That's what I figured too. Will test the same code in a calculator tomorrow.

BTW: Serial_Open resets the buffers automatically

Thanks

[happy Profile]

Will test the same code in a calculator tomorrow.

It works.

[happy Profile]

[quote="SimonLothar"][/quote]

Hi Simon,

The device I am connecting to requires: "9600 baudrate, 8 bits, No Parity, 1 stop bit, and hardware flow control disabled." I am setting this by:

Code: Select all

unsigned char mode[6] = {0, 5, 0, 0, 0, 0};
Serial_Open(mode);


But how do I disable hardware flow control?

[happy Profile]

PS: The cable is fine. I used it to transfer files from calculator to PC using FA-124.

This is my code:

Code: Select all

void serialSend(char *buffer)
    {
    if (Serial_IsOpen() == 3)
        {
        unsigned char mode[6] = {0, 5, 0, 0, 0, 0};
        Serial_Open(mode);
        }
    if (Serial_IsOpen() == 1)
        {
        int i = 0;
        int begin = 0, end = -1;
        int len = strlen(buffer);

        // 1 byte
        for (i=0;i<len;i++)
            {
            while (Serial_BufferedTransmitOneByte(buffer[i]) != 0);
            }

        // N bytes
        /*
        while (begin < len)
            {
            char buf[256];
            int temp = len - begin;
            memset(buf, '\0', 256);
            end = begin + ((temp > 256) ? 256 : temp);
            for (i=begin;i<end;i++)
                {
                buf[i - begin] = buffer[i];
                }
            while (Serial_BufferedTransmitNBytes((unsigned char*) buf, strlen(buf)) != 0);
            begin += end;
            }
        */
        }
    }



E.g. of a call: serialSend("1w-ab-d7"); The code is executing fine, tried with both TransmitOneByte() and TransmitNBytes(), but there is no data arriving at the receiving device. What could be wrong..?