No announcement yet.

uSD card read

  • Filter
  • Time
  • Show
Clear All
new posts

  • uSD card read

    Using the serial environment on a uVGAIII and a teensy 3.0 with Arduino development.

    I have successfully created a graphical plot on the vga screen by reading a text file placed on the SD, using the getstr cmd 0x00,0x07,0x01,0x0F converting the data and plotting the graphics with a line cmd 0xFF, 0xCA ,xpos_msb, xpos_lsb ypos_msb, ypos_lsb I have run this code fro days without a problem using 200000 baud rate on the teensy 3 serial port speed.

    The problem; as soon as I combine the graphics plot with a string display on the uVGAIII from the same text file line using putst cmd 0x00,0x18, ------ 0x00, after a few lines of successful information, the data becomes corrupt somehow during tx & rx but the file remains ok on the uSD. I am using different communication buffers for the send and receive channels, one for each (1) file data retrieve, (2) string display and (3) graphics plotting .

    Is there any reason why I can't read my own file on the uSD?
    I must admit to being a bit sceptical as I could not see a 'file create' command either.

    Regards LP

  • #2
    I'm having a bit of trouble understanding just what you are saying.

    File_Open(filename, 'w') is 'file create', ensure the file is closed using file_Close(handle) or the file will not be correct on uSD

    The data corruption you are reporting with strings is most usually caused by not waiting for the ACK to the write command (or not waiting for an ACK to an earlier command that results in a 'buildup' of not waited for ACKs)

    Another possibility is sending a 'too long' string.


    • #3
      Hi Mark,
      Thanks for your reply and the File_Open(filename,'w') to create a new file. I saw that point in the manual when you said.
      If you had problems understanding my first comment wait till you see the next Think you managed to see what I was getting at.

      So I have focused on the serial code and have come up with the following prognosis:

      The ACK 0x06 is the first byte sent back to establish the command was successful (true?), Think this is where I got it wrong, I assumed that this would remain at 0x00 until the complete tx has finished. So I put a wait loop to test for a 0x06 in the first byte returned then started reading the comms buffer. It seems that according to my monitoring, the first byte 0x06 ACK is only set to confirm the command was executed and then the byte stream is sent. So the only way I can confirm all data is in the buffer is to put a delay in the receive code.

      This is a trace on the communications:
      file_read >0>7>0>3C>F>7D<[3]6<[10]0<[21]1F<[30]47<[29]32<[28]58<[27]2D<[26]31<[25]37<[24]35<[23]2E<[22]35<[21]31<[20]35<[19]59<[18]34<[17]39<[16]2E<[15]35<[14]36<[13]31<[12]49<[11]38<[10]2E<[9]39<[8]37<[7]35<[6]4A<[5]2D<[4]30<[3]2E<[2]30<[1]30<[0]30 Waited m/sec=18

      file_read is the command the '>' is the tx byte then I wait for a byte to arrive in the comms buffer
      The '<' indicated the byte received in the braces [] the number represents the decimal number bytes received at that time.[3] then next says [10] then next [21] the next [30] up to this point the buffer starts to reduce as the bytes are called off by the read. the hex Is the byte itself. Even with the overhead of the monitor running this shows the 0x06 is present before the full set of returned bytes are complete.

      In real terms, should the ACK acknowledge a completed session? So in terms of the serial buffer being ready to read the first byte should be a zero until the last byte is in the buffer abd then the final action is to make the first byte a 0x06.

      Could you please let me know if this is correct?

      In the meantime. I have put a 500 microsecond delay on the receive code which reduced the buffer fill count to 4 reads over 30 bytes as seen in the example trace. before I did this that was around 12 reads of the buffer before all the bytes were added.

      I will now check o see if the file data is corrupted when displaying a string back to the vga.
      I am progressing the earlier versions of code to check each step along the way.

      Regards LP


      • #4
        Serial comms occurs serially, one byte at a time, there is no ability to 'go back' and replace a byte.

        Also the data does not come in 'instantly' it is slowed by the baud rate, it is also 'slowed' by any intermediate buffering / re-transmission / latencies, etc.

        Your comms routines should have some sort of 'amount of data bufferred' function call and/or a read call that waits until a byte is available

        So for this particular example you can 'wait' until 1 byte is available and then check it to ensure it is an ACK.

        Then wait until two bytes are available to get the length

        Then read length bytes with 'wait until byte is available'. (or wait until length bytes in buffer and read it all at once)


        • #5
          Seems a bit harsh, ok got all that and I have all he checks you talk about: No longer see this as a client comms problem, but possible a host issue. Otherwise nothing else would work. It is not caused by the file read nor the graphics display but as soon as I put a string on the vga while reading the file as soon as a combination of file tell and file seek is used to reposition the file an error happens on a single line the error is repeated again on another line further down the file. This is not random as is repeatable at exactly the same location each time, whether I change my code structure or not. This is seen on line 25 of a 60 line text file, there is no problem with the file itself. The point you make about getting the length of the string is where the problem resides, the length of that string is 30 characters where the get_str command says its 42 and has garbage included.

          The process is as follows:
          1 Read the file at the last address using file_Seek & get_str
          2 Display a line in a window using putstr and txt_MoveCursor
          3 Read the file position at line increment using file_Tell and store the address
          4 Display the next 25 lines in a window using get_str putstr and txt_MoveCursor
          5 Process the first line in the file
          6 Increment the next line
          7 Loop to 1

          The string in the file is "G2X184.491Y40.586I0.000J-8.975" (30 (1E) bytes + CR & LF). It should read these data as a string and set the incremental pointer at the CR. The read from the file has the information correct info when I plot the graphics.

          The returned data when not combined with a putstr. This works fine
          file read >0>7>0>3C>11>DD<[3]6<[18]0<[30]1E<[29]47<[28]32<[27]58<[26]31<[25]38<[24]34<[23]2E<[22]34<[21]39<[20]31<[19]59<[18]34<[17]30<[16]2E<[15]35<[14]38<[13]36<[12]49<[11]30<[10]2E<[9]30<[8]30<[7]30<[6]4A<[5]2D<[4]38<[3]2E<[2]39<[1]37<[0]35 Waited m/sec=27

          However when combined with displaying the data on the VGA the file read does this at the same point in the file each time! It has 43 (2Bhex) as the length of the string. This time the read has ignored the CR at the end of the string and must have seen an EOF or another CR and sent a larger number of bytes.

          file_read >0>7>0>3C>11>DD<[3]6<[18]0<[33]2B<[42]47<[41]32<[40]58<[39]31<[38]38<[37]34<[36]2E<[35]34<[34]39<[33]31<[32]59<[31]34<[30]30<[29]2E<[28]35<[27]38<[26]36<[25]49<[24]30<[23]2E<[22]30<[21]30<[20]30<[19]4A<[18]D4<[17]35<[16]8<[15]0<[14]7C<[13]C6<[12]CE<[11]DE<[10]F6<[9]E6<[8]7C<[7]0<[6]31<[5]31<[4]35<[3]2E<[2]38<[1]30<[0]38 Waited m/sec=40

          My code has no control over the file_read (get_str) return string except displaying these data,

          In any conditions, surly the file_read (get_str) command should not produce an error such as this? Especially as it works initially when used without displaying the information and produces this "garbage" when used in combination with a putstr and a file_Tell.
          Typically this sort of problem is one of data stream use where the information is stamped on by another process while working. As you quite rightly say this is all sequential so it processes each in sequence, so there should not be any corruption of data come from the file read get_str.

          I may change the structure to work with two handles on the same file, one to process the 25 line window page and one to handle the execution line sequentially. This will eliminate the need to set the address for each page.

          Regards LP



          • #6
            I'm sorry, I cannot begin to understand the issue you are seeing in the way it is presented. I'm sure it makes sense to you, it just doesn't 'transfer' well to someone who has only this information to read an no knowledge of what you are trying to do or why.

            Can you create a Serial Commander log that shows the issue. and attach the file so that I can try and do exactly the same thing here?


            • #7
              I will try to keep this simple:
              The commands sent to the uVGAIII basically read data from a text file on the uSD, process the geometry and send further commands to the uVGA to display the geometry and the text from the source file.

              Assuming you can read and stream the bytes to a uVGAII the enclosed text files
              Would you be able to stream these data into a uVGAII at your end and compare the output from the card?
              You would have to sort out the file handle but most everything else should be ok.

              If you have my input and output to compare the same input with your output and have the same source file on the uSD, you should be able to emulate this issue and check the raw data to see what is happening to the uVGA card each step of the way.

              There are the following files enclosed:
              - gcde.txt is the main file with the geometry data this is opened and a handle established
              - dec input or the hex input is the command set for the uVGAIII

              To compare output from the uVGAIII, I have included hex input output and the hex_n_char the latter shows the char from the file with the hex command and response data.

              the stream should:
              - Initialise the screen in 800 x 480 mode
              - Grey the whole screen
              - put two boxes one on the left dark grey this is the text window
              - one on the right in black this is the graphics window
              - then read the file to set the graphics size for scaling the graphics window
              - then read the file again to plot the graphics in a red colour
              - then read the file again to display the first 24 lines of the text file
              - then sequence through the file again and run the graphics in yellow and trace over the red
              - when the line is at the center of the window scroll the window down by refreshing the window and moving the file pointer to the next line each time

              I have used the serial commander to emulate this, that how I established the feasibility for the requirement. I could not reproduce the same issue in the serial commander.
              I have put "// ???" in the files enclosed to identify where this issue happens.

              Hope this helps, I will continue to investigate the problem by changing the approach to the requirement.

              Attached Files


              • #8
                the file extension for the gcde file should be .tap not .txt.


                • #9
                  I'm sorry, I've spent a couple of hours on this and what you are presenting is just too complicated for me to ascertain just what is going wrong.

                  I really need a 'simple' gtx log that shows the issue, but I understand that is difficult to make in this instance.

                  All I can suggest is more debugging code in your Teensy.

                  Could the teensy be running out of RAM?

                  Can you attach your teensy program? (Not sure what I can do with it really, but something might be possible)

                  What version PmmC are you running in the uVGA?


                  • #10
                    Hi Mark,
                    Thanks for trying to see what is going on.
                    Yes I have included more debugging, re-structured the command control on the Teensy and found the way I use file handle controls file open, close, seek and tell to be somewhat unreliable, so I have changed the order to see if this has an impact. Still trying to pinpoint why the error occurs by attempting a different approach. This has made a difference, but have a program code catch 22 where combining the two text and graphics now shows the text still with the corruption but successfully plots the graphics so that function is reading the data correctly. It is clear to me that trying to deal with all functions by jumping from one to another with open and close is causing too much activity and possibly losing something along the way.

                    It seems separating out the function to read the data for the text display and then read the data for the plotting has made some progress, an additional file tell while displaying the text and passing this pointer to the plot function with a file_seek works ok. The plot function opens its own handle, which I expected to see a different handle, but this was the same handle even though the text open was not closed!! So not quite there yet but hope to solve this today as quite clearly multiple handles can be used simultaneously on the same file (see the serial command log). So rather than trying to combine all functions in one sequence with one open handle, I can run the text display as the driver and simply lookup the address of the line for the plot on its own handle. Mapping line addresses will be handled by a window of 30 lines in the file unsigned int window_line[30];. adding the last on each index when moving up the file and adding the first when moving down the file.

                    file_Open[000A "gcde.txt" 'r'] 0.019 (ACK 4592 0x11F0)
                    file_Open[000A "gcde.txt" 'r'] 0.027 (ACK 4307 0x10D3)
                    file_Open[000A "gcde.txt" 'r'] 0.025 (ACK 4022 0x0FB6)
                    file_Open[000A "gcde.txt" 'r'] 0.026 (ACK 3737 0x0E99)
                    file_Open[000A "gcde.txt" 'r'] 0.017 (ACK 3452 0x0D7C)
                    file_Seek[FF16 10D3 0000 0049] 0.016 (ACK 1 0x0001)
                    file_GetS[0007 0028 10D3] 0.005 (ACK 3 0x0003, "G17") Line at address 0x00000049
                    file_Seek[FF16 0FB6 0000 0000] 0.005 (ACK 1 0x0001)
                    file_GetS[0007 0028 0FB6] 0.018 (ACK 17 0x0011, "(COMPONENT:Facia)") Line at address 0x00000000

                    Is this approach considered appropriate, is there any reason why I shouldn't open multiple handles on one file?

                    In answer to your questions:
                    - The uVGA PmmC is rev 4.2
                    - Afraid I cant send you the code as this is not an open source project. The Teensy K20 platform is only the prototype and feasibility coding. The whole lot is re-coded into assembler if it passes the feasibility stage.

                    Your point on the Teensy memory is important where we continue to check the array boundary management on the program, a stray memory index pointer could affect the Teensy serial receive buffer array, etc. or stamp over the code segment.

                    Overall, we are very pleased with this device and can see much potential in the future. A VGA display is a professional addition to our monitoring devices.
                    When we find what is causing this issue, although I have a feeling the handle address pointers will work ok, I will drop you a note, it may simply be the way and order we use the command set.

                    Thanks for your help
                    Kind regards,


                    • #11
                      You should be able to open the same file for read and have multiple handles for it without issues, although I can't say I've ever done it. You should certainly get a different handle each time if the file hasn't been closed at any point.

                      The PmmC version has no known issues in that area.