SD Card Speed

14567810»

Comments

  • That doesn't make any sense - double check that the file being written to has the same name as the one being read from. If they were different that would explain it.
  • You can always examine the SD card on a PC to see the files and their sizes.
  • Jason...In the write to SD memory portion of the program the file name is plasma.txt but in the read portion of the program it is plasma.bin.

    Recycling electrical power to the Propeller Activity Board does not clear the problem. Two minutes and forty-five seconds worth of data are output.

    Discovery
  • Jason...Additional information. I changed the write file name to match the read file name so both are plasma.bin and the program output only 012E then stopped.

    I changed the write file name back to plasma.txt and got the output 012E. I recycled power and the program output 012E. I reloaded the saved program and the output remained the same 012E.

    It appears that something has changed in the SD memory due to changing the file name to plasma.bin.

    Discovery
  • Discovery, have you look at the files on a PC? How large are they?
  • Dave...No since there is no port on any of my computers that can handle the SanDisk micro memory. There is one port that handles the large SanDisk 32 gigabyte memory.

    Discovery
  • So get a cheap carrier that mounts in a standard socket and holds a micro card!
    Jim
  • I will see about that.

    Discovery
  • Jason...Through an adapter I can see three files on the SD memory:

    PLASMA.BIN 1k
    PLASMA 1k
    TEST 16k
    X.AXI 4,194,304 kB

    Discovery
  • Could it be that the X.AXI file is the data?
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • Jason...I will see about reformatting the SD memory and run more tests.

    Discovery
  • New Test Data...The SD memory was erased. The fopen() instruction in Jason's read code was changed to .txt and 1,000,000 nibbles were written to the SD memory.

    The program ran fine.
    Reading the memory files showed:
    PLASMA Test file 977 kB
    X.AXI 0 kB

    The SD memory was erased and 2,000,000 nibbles were written to SD memory.
    The program ran fine.
    Reading the memory files showed:
    PLASMA Test file 1,953 kB
    X.AXI 0 kB

    The SD memory was not erased and 500,000 nibbles were written to the SD memory.
    The program ran fine.
    Reading the memory files showed:
    PLASMA Test file 488 kB
    X.AXI 0 kB

    The fopen instruction does indeed over write the file name with no problem.

    The program is back to normal and I can now address getting my step and direction nibbles into the Buffer[0] block write to SD memory.

    Discovery
  • Oops...Not so fast. The current code can write Buffer[0] to the memory very fast but changing Jason's fopen() instruction to .txt caused the motors to turn extremely slowly. There appears to be some sensitivity to writing to memory with .txt or .bin and reading the memory with .txt or .bin.

    Discovery
  • JasonDorieJasonDorie Posts: 1,909
    edited April 18 Vote Up0Vote Down
    If I have code that looks like this:
      FILE * fb = fopen( "filename.ext", "wb" );
      // magic file writing stuff happens here
      fclose( fb );
    
      fb = fopen( "filename.bla", "rb" );
      // .. . . . 
    

    The first fopen() call is opening a file called "filename.ext" for writing.
    The second fopen() call is opening a file "filename.bla" for reading.
    They aren't the same file if they don't have the same name, including the extension.

    If you're altering the 2nd call to open "filename.txt", but not SIMULTANEOUSLY altering the first call to CREATE "filename.txt", you're not working with the same file in both places.

    Are you only changing one of the fopen calls, or both? It wasn't clear from your message. They have to use the same filename AND extension.
  • Jason...Current status to date.

    Test (1) .txt write to memory, .txt read of memory to motors
    Fast write to memory, very slow turn of motors
    fopen("plasma,txt", "wr"); write to memory
    Buffer[0]...
    fwrite(Buffer[0]...
    if
    if

    fopen("plasma.txt", "rb"); read memory and turn motors

    Test(2) .bin write to memory, .bin read of memory to motors
    Fast write to memory, very slow turn of motors
    fopen("plasma.bin", "wb");
    Buffer[0]...

    fopen("plasma.bin", "rb"); read memory and turn motors

    Test(3) .bin write to memory, .bin read memory and turn motors
    Slow writing to memory (2 minutes 15 seconds for 200,000 nibbles, fast turn of motors
    char byteToOutput = (1<<0) |(1<<1)|(1<<2)||(1<<3);
    fwrite(&byteToOutput,1,1,fp);
    byteToOutput = (0<<0)|(0<<1)|(0<<2)|(0<<3);
    fwrite((&byteToOutput,1,1,fp
  • Jason...Current status to date.

    Test (1) .txt write to memory, .txt read of memory to motors
    Fast write to memory, very slow turn of motors
    fopen("plasma,txt", "wr"); write to memory
    Buffer[0]...
    fwrite(Buffer[0]...
    if
    if
    fclose(fp);

    fopen("plasma.txt", "rb"); read memory and turn motors

    fclose(fp);

    Test(2) .bin write to memory, .bin read of memory to motors
    Fast write to memory, very slow turn of motors
    fopen("plasma.bin", "wb");
    Buffer[0]...
    fclose(fp);

    fopen("plasma.bin", "rb"); read memory and turn motors
    fclose(fp);

    Test(3) .bin write to memory, .bin read memory and turn motors
    Slow writing to memory (2 minutes 15 seconds for 200,000 nibbles, fast turn of motors
    fopen("plasma.bin", "wb");
    char byteToOutput = (1<<0) |(1<<1)|(1<<2)||(1<<3);
    fwrite(&byteToOutput,1,1,fp);
    byteToOutput = (0<<0)|(0<<1)|(0<<2)|(0<<3);
    fwrite(&byteToOutput,1,1,fp);
    fclose(fp);

    fopen("plasma.bin", "rb");
    fclose(fp);


    Discovery
  • The Parallax website has been acting up today.

    Discovery
  • Without complete code it's very hard to determine what's causing your issues, but I suspect it's the data itself, not the reader / writer.

    First things first:
    fopen ("filename", "wr") is not a valid file mode. "w", "wb", "r", "rb" - all of these are good. "wr" - not good.
    They are, in turn: "w" write access, text. "wb" write access, binary. "r" read access, text. "rb" read access, binary.

    When operating in "text" mode the system assumes that an ascii value of 0 in the stream is a termination character. In binary mode, ascii values of 0 are treated no differently. You want binary mode.

    Next:
    The data itself is driving your motors. You're using stepper drivers that take pulses. If you write a sequence to the file that contains nothing but a static value written repeatedly, you're not toggling the motor pins, so they won't spin. How fast you are able to write to the file is completely independent of the data you are writing to that file. The rate and direction your motors spin is a direct result of the data being written to the file, so if that data is not consistent across your various means of testing the writes / reads, there's no reason to assume any correlation. If you want the motors to spin fast, leave the x & y direction pins alone, and toggle the x & y step pin values with each byte you output, whether it's in the buffered version or the "single write at a time" version.

    I really can't shake the feeling that I'm being punked here.
  • Spin motors fast:
      //Write data to SD memory      
    
      fp = fopen("plasma.bin", "wb"); // Open a file for writing
      for(i=0;i<4000000;i++)
      {
        char byteToOutput = 0;             // start with all pins cleared, but...
        if( i & 1 ) {                      // ...on every other iteration....
          byteToOutput = (1<<1) | (1<<3);  // ...toggle JUST the step pins
        }
    
        Buffer[0][ i & 511] = byteToOutput;  // Use the first 512-byte buffer to hold data until it's full....
    
        if( (i & 511) == 511 ) {  // when we get to the end of the 512 bytes (0 to 511)
          fwrite( Buffer[0], 1, 512, fp );  // ....write it to the SD card all at once
        }
    
        if( (i&16383) == 16383 ) {  // display some output to the screen so we know it's working...
          printi( "writing...  %d\r", i );
        }      
      }
      fclose(fp);
    
      // later....
    
      fp = fopen("plasma.bin", "rb"); // Open the same file for reading
    
  • Jason...The "wr" in my message to you was just a type "O"...

    As you will note in test three, all four bits are alternately set HIGH and LOW generating clocking pulses for xStep and yStep. The xDir and yDir signals are not used. Inputs to the motors are wired to zero volts. For testing, I am just interested in getting the 53,000 clockingRate to the motors.

    I don't understand "punked".

    I will checkout you code above shortly.

    Discovery

  • In my version the pins are assumed as follows:
    0 : XDir
    1 : XStep
    2 : YDir
    3 : YStep

    Technically the code doesn't care - it's just pulling the bottom 4 bits off each byte read from the file and sending them through pins 0 to 3 on the Prop, but the above is the convention I've been using during testing.

    Now, when you say "all four bits are alternately set", to me that sounds like it includes the direction bits, unless you have four motors instead of two... ?
  • Jason...The pins are correct and I monitor them on my scope.

    Your code had a compile error fp = fopen("plasma.bin"... [First use of the term]

    I changed it to FILE * fp = ... and it compiled and ran producing written numbers on the screen with no data on output pins (0,1,2,3).

    The "c" code is attached.

    Discovery
  • Jason...I set and clear all four bits to verify they are functioning from the memory read code. Only xStep and yStep outputs drive the motors. The xDir and yDir outputs are not sent to the motors. These signals are wired to zero volts. I am only interested in verifying that the 53 kHz clockRate drives the motors at this time. One step at a time.

    Discovery
  • JasonDorieJasonDorie Posts: 1,909
    edited April 19 Vote Up0Vote Down
    This is the CodeChecker(4).c file you posted. I changed the print() statements to printi() statements (integer only, uses less memory), and that's it. Keep in mind that 26.5 kHz is the cycle time for a high pulse + a low pulse. That is single bytes output at 53kHz exactly.

    Compiled in LMM mode:
    CompiledLMM.png
    Exactly as advertised.

    Compiled in CMM mode:
    CompiledCMM.png
    Also exactly as advertised.

    I'm not sure what's happening on your end, but it is most certainly on your end.



    801 x 442 - 48K
    801 x 442 - 48K
  • @Discovery

    The file name and extension of your reads have to be exactly the same as for your writes for this to work. If you write the data to test.bin you must read from test.bin to read back that data.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • I didn't change the filenames in the code - that part seemed to work, so I'm not sure what the issue is.
  • Jason...I am pleased to see the code working on your machine. Late last night, I ran your code and after 3 and a half minutes I figured that it wasn't working and shutdown. I should have waited 4 minutes since this morning I let it run and at the 4 minute mark...the code ran perfectly.

    I removed the writing statement and the memory load time was reduced to 3 minutes and 40 seconds for 4 mega nibbles which is really good. That represents a large amount of continuous cutting. I also increased the outputRate from 53 kHz to 60 kHz and the motors really turn fast. I estimate that the cutting head is moving about 6 times faster (maybe more) than your YouTube presentation drafting machine plotting head.

    Thank you very much Jason. Now I have to get my nibble patterns loaded into the SD memory to complete the next upgrade.

    This is really superb!

    Discovery
Sign In or Register to comment.