Announcement

Collapse
No announcement yet.

xPico ignores request to leave data mode

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • xPico ignores request to leave data mode

    Hi,
    I'm using the xPico Wi-Fi with firmware 1.4.0.0R28 in mux mode with hardware flow control.

    The way I use it is as follows:

    I accept TCP connections on port 5555t and wait for an incoming connection.

    Code:
    1a5555TCP
    W1r
    Then when I get one, I try to receive the incoming data in 128 byte chunks.

    Code:
    1rb~128
    But I don't want to receive the full 128 bytes in one go - I only want to read it till an abort condition is met, e.g. I want to read until the first '\n' character, as everything up to that point is a command and the rest is handled by a different function:

    Code:
    file:test.bin\n[BINARY DATA AFTER THAT]
    Now this should be no problem as the documentation says

    Data mode terminates when
    1. Number of bytes specified in command has been reached.
    a. Connection is dropped.
    b. Any single character is sent by the host.
    So when I read an '\n' character, I immediately reply with an '\n' character in the hope that data mode now stops and I can resume receiving the data by sending
    Code:
    1rb~128
    again.

    However, xPico just ignores my request to end data mode and keeps sending data until either the data is exhausted or the 128 byte limit is reached.

    As xPico honors that limit I might achieve what I want by always just sending
    Code:
    1rb~1
    and evaluating the response, but that seems very tedious and comes with a large overhead.

    What is the solution for my problem? Am I missing something?

    (I disabled all UART buffering on my side)

  • #2
    The mux doesn't have the capability of reading up to a specific character (e.g. read a line).

    Instead of reading one byte at a time to detect the newline, you could read the 128 bytes into a buffer, then process that buffer on your microcontroller. Execute the command up to the newline, and leave the data after the newline in the buffer for the next command after you read additional data from the xPico Wi-Fi.

    Mariano

    Comment


    • #3
      Thank you - so that means I should just ignore that part in the documentation where it says I could terminate data mode at any time by sending any character to the device. (User Guide, page 80)

      OK, so I'll introduce buffers for each line and won't attempt to leave data mode on my own

      Comment


      • #4
        Ah, I see. No, don't ignore it .

        That part is valid if there's not enough data in the xPico Wi-Fi network buffers to give your Microcontroller.

        For example, if you do 1rb~128, but there's only 100 bytes available, the xPico Wi-Fi will stream 100 bytes to you, then wait indefinitely until the other 28 bytes arrive from the network.

        During this (indefinite amount of) time, you can send a character to say you're tired of waiting and terminate data mode.

        Mariano

        Comment


        • #5
          Ah thank you for clearing that up!

          That makes sense, xPico probably uses DMA for that transfer so it can't check for every character whether there is something to receive from the host.

          Can I take the same liberty as xPico here when sending something to it?

          Right now when I do
          Code:
          1sb~
          I check after every data character I send to the xPico whether it terminates the transfer by sending an error, as the user guide states:

          The device may terminate while the host is still sending bytes by sending E<string><LF>
          I don't want to send garbage to the xPico should it decide to terminate while I'm sending, so I can't use DMA - or can I assume that xPico behaves the same here and will only terminate data mode after I send '<escape>\n', ignoring the data it gets after an error?

          Comment


          • #6
            The data after the error will be ignored. There's very few reasons that an error would show up as long as you're not sending more bytes than what the xPico Wi-Fi responds with after the 1sb~. You could setup the DMA for that amount of bytes.

            Mariano

            Comment


            • #7
              Ok that makes things simpler

              I'm now using a ringbuffer to store surplus data from the xPico for later, but there is still some behavior I don't understand:

              To provoke this condition I set the ringbuffer size to 15 bytes, so I read the TCP answer in 15 byte chunks (higher number in production, this is just for provoking the fragmentation )

              The idea is that first I read all data to the target buffer up until the abort condition, any data after that is stored in the ringbuffer and consumed in subsequent calls before making a new request to the xPico module. The size of the target buffer is irrelevant for this case.

              That means I will always read chunks of size = min(ringbuffer size, space left in target buffer).

              That means I will never read more bytes than would fit into my ringbuffer.
              The moment the abort condition is met and I swap the target buffer for the ringbuffer, I also send "any character" to the xPico to leave data mode as soon as the remaining bytes are received. E.g. if there are 2 bytes left to receive but I said I want to receive 15, I don't want to wait indefinitely here.

              However, it seem to matter what those 'any bytes' are - and still xPico ignores my request to leave the data mode

              When I send '\n' or '\r', nothing happens. When I send any other character, e.g. '\0' xPico will leave data mode as expected, but I get a subsequent
              Error: Timed out waiting for command character.
              It also takes 3s for that timeout to happen, so the connection will be blocked for that period, which is less than ideal.

              I send
              Code:
              echo -n "Hello World\!ABCDEF\r12345" | nc xpico 5555
              And on the xPico I do

              Code:
              > 1rb~15\n
              Hello World!ABC~\n
              
              > W1r\n // if I don't wait for xPico to be ready for the next transfer, it won't answer
              K1r\n
              
              > 1rb~15
              DEF\r
              
              > \0
              
              12345~\nE Timed out waiting for command character
              The delay between receiving the '5' and the '~\n' is 3s.

              When instead I do

              Code:
              > 1rb~15\n
              Hello World!ABC~\n
              
              > W1r\n // if I don't wait for xPico to be ready for the next transfer, it won't answer
              K1r\n
              
              > 1rb~15
              DEF\r
              
              > \n
              
              12345
              I wait indefinitely for xPico to send '~\n' to terminate the data mode.
              Last edited by benpicco; 04-03-2017, 01:31 PM.

              Comment


              • #8
                Turns our when I send
                Code:
                 1rb~15.
                the behavior is as I want it - I don't have to try terminating the data mode as xPico does that on it's own when there are no more bytes to be read from the remote side.

                It seems however impossible to terminate data mode from my side.
                Last edited by benpicco; 04-04-2017, 12:58 PM.

                Comment

                Working...
                X