However, there is no way of seeing what the IDE actually used ?!
Open the project manager clicking on the icon at the bottom-left of the window, there you can see the board configuration. Additionally, the build status window (click on the icon in the middle of the status bar at the bottom of the window to open it) shows the command line used:
Since I can see a TX flash, and to underline my point of the need for good reports, I attached another COM port and terminal @ 115200. (Of course a new SimpleIDE user should not have to do this....)
QuickStart.Sniff.RX shows 1480 chars, and download fails.
Seems quite a few, (but much less than expected chars to carry 8140 bytes) so maybe this almost works ?
QuickStart.Sniff.TX shows 225 chars, (includes 'Hello!4' echo) and download works
? wtf ? Adding a COM sniffer wire makes this work ?!
Try a 1.5k pullup instead, (QS.TX) and same result: download now works.
Conclude: Something dodgy on the QS, almost like Prop is set open drain and not CMOS ?
Thank you for the informative exchange of ideas and suggestions.
You guys are experts in the coding and problem solving field...I am a simple user who wants to get a project designed and built as easily as possible. That is why:
I was hoping and expecting that there was a method that I, as a shaky "C" programmer, could insert in my SimpleIDE project to by-pass the slow Propeller "mount SD card" code so that the Propeller could read the SD memory on the Propeller Activity Board and clock words out up to 500kHz. Once that works...the hardware would be transferred to a new printed circuit board and be inserted in the plasma cutter control box.
The depth of the memory was scaled back to a few tens of mega words.
It appeared that there was a way to use two COGs and their memory to read 512 word pages in a ping-pong fashion then output the words at a rate that I select for the plasma cutting application.
The suggestion was that I can write "spin" or some other language code to accomplish this and it should work perfectly well. The problem is that I cannot write that code...I have enough trouble just writing "C" in SimpleIDE. I don't have the experience you folks have. So, I was hoping to receive chunks of "C" code or other code that I could insert into my "C" code and solve the problem.
I was also hoping that some one might have a Propeller Activity Board handy and could verify the code before sending it on to me. Just hoping!
Do you have a file generated, like a circle, or a random shape, that contains the format of the pulses you want? If so, could you post it somewhere and make it available? Is there a reason it needs to be on an SD card? A Prop can receive serial data quite quickly - 250kb/sec isn't terribly hard, and with the kind of data you're talking about, 2:1 lossless compression should be trivial.
Jason...I don't have a file currently that I can post but Monday I should have a file that contains the steps for cutting a five inch radius quarter circle.
The individual words are the numbers contained in this list (2, 3, 8, 10, 11, 12, 14,and 15). The SD memory will act as a FIFO. When the data are read out, you will see a string of numbers that may look like:
8,8,8,8,2,2,2,3,11,11,14,14,14,14...........
These numbers are then decoded into x-axis motor direction and step pulses plus y-axis motor direction and step pulses and defined as:
output (A) high == x-axis stepper motor clockwise rotation direction
output (A) low == x-axis stepper motor counter-clockwise rotation direction
output (B) low-high-low == x-axis stepper motor single step
output (C) high == y-axis stepper motor clockwise rotation direction
output (C) low == Y-axis stepper motor counter-clockwise rotation direction
output (D) low-high-low == y-axis stepper motor single step
The propeller will decode the SD memory numbers and output signals on A, B, C, and D that are then buffered and sent to the two high-speed stepper motors.
As an example: if the x-axis stepper motor is directed to make a straight line 10 inches long and the y-axis motor does not step then the output string of numbers from the SD memory will be 3, 3, 3, 3, 3, 3, 3.... until the 10 inch line is cut.
The reason for the SD memory card is it is currently on my Propeller Activity Board ready to test the code.
Also, depending upon the application, the SD memory read and propeller output of signals A, B, C, and D must vary anywhere from 0 kHz to around 500 kHz. For cutting 5/8" thick mild steel, the clock rate will be set to move the cutter head at 13 inches per minute. For thin mild steel, 22 gauge, the clock rate will be set to move the cutter head at 822 inches per minute.
So if I understand correctly, you need 4 bits of output at 500khz, correct?
So your bits are:
0 1 2 3
| | | +-- X direction (0 = cw, 1 = ccw)
| | +--------X step (toggles for a single step)
| +-------------Y direction (0 = cw, 1 = ccw)
+------------------Y step (toggles for a single step)
If this is true, then there are a couple things you could do, most notably and simply, if your "step" pins are 0 you don't step, if they're 1, you do the toggle low-high-low in code. That would cut your bandwidth requirements in half, would it not?
You could also pack two outputs into a single byte, so the upper four bits are your first value, and the lower four are the second value. That again cuts your bandwidth requirements in half, so now instead of needing to read 500Kb/sec from the SD card, you need 125Kb/sec. With one cog reading from the SD card, and another doing the decode and output, you wouldn't even need compression to hit your speed mark. Simple compression would only improve things.
Consider this: At your step rate, most of your signals are going to be very repetitive. Directions don't change often, and you generally won't be stepping at full speed. I'd suggest this instead:
0 1 2 3
| | | +-- X direction CHANGE (0 = same direction, 1 = change direction)
| | +--------X step (0 = don't step, 1 = take a step)
| +-------------Y direction CHANGE (0 = same direction, 1 = change direction)
+------------------Y step (0 = don't step, 1 = take a step)
On top of this, I'd output 1 value to mean "how many times to repeat the next value", followed by an actual value.
So now your straight line of 10 inches looks like:
15, 0, 15, 0, 15, 0 . ..
Each of those 15's means "repeat the next output 15 times". You could use two zeros in a row as a special case to reset the directions to a known state. You're still only working in nybbles, so you could still pack pairs of them together. This would get you, best case, about 14:1 compression, and again reduce your bandwidth requirements pretty dramatically. It would also be quite simple to implement.
Also, 822ipm is only 13.7 inches/sec. If you take 2000 steps per inch, that's a maximum step rate of 27,400 steps/sec, so why do you need 500khz? That implies you're taking ~50,000 steps per inch, which seems overkill. There's no way your machine is that accurate, so you'll be wasting steps, unless there's some other reason for this requirement. Lowering the micro-step setting on your stepper drivers would mean fewer steps, lower step frequency required, and could gain you a lot of flexibility on the implementation.
Jason...your understanding of the bits is correct. Your suggestions will be considered after the current design is operational. Improvements come one step at a time.
The current design data are the following:
The ClearPath stepper motor takes 800 steps to make 1 revolution.
The threaded rod that moves the cutting head pitch is 16 revolutions per inch.
That makes 12,800 steps per inch.
To move the cutting head 7 feet along the x-axis takes 1,075,200 steps.
To move the cutting head 3.5 feet along the y-axis takes half the number of the x-axis or 537,600 steps.
To cut a rectangle 7 feet by 3.5 feet therefore takes 3,225,600 steps.
Each step represents one nibble of SD memory or 3,225,600 4-bit nibbles. Not much memory at all.
The ClearPath stepper motor can turn at 4,000 revolutions per minute and thus cover 7 feet in 0.3360 minutes.
To cut the complete rectangle takes 60.48 seconds or just over one minute.
The precision of one step is 0.0013 inches.
All I need is the code to run the Propeller COGs, decode the SD memory, output the x-axis step/direction signals and output the y-axis step/direction signals which I designated A, B, C, and D from the propeller.
If it's possible to lower that 800 number to 400 or 200 it would make sense to do so. 1 inch / 12800 is 0.000078125 inches. If your machine is only able to achieve a precision of about 1/1000th of an inch, you're taking 16 times more steps than you need to take to get that precision. Lowering the steps per turn number, if you can, would reduce the kb/sec number you need to hit by a significant factor.
The reason I suggested using compression of some kind or even just packing nybbles together is that too will lower the bandwidth requirement. By doing that, you make the system possible with the code you have trivially available to you. You keep saying "I'll try that after I get the first version up and running". If your initial requirement is 500kb/sec and you can't achieve that without learning a new language, and there's code that will demonstrably achieve 250kb/sec right now with tools you have, learning how to pack nybbles together makes more sense than buying a new computer, installing linux, and learning PropWare.
You said the ClearPath stepper can turn at a maximum of 4000rpm. That's 66.6 turns per second. You also said it takes 800 steps per turn. 66.66 turns per second x 800 steps per turn is a maximum step rate of 53,333 steps per second, which is nowhere close to the 500khz the driver itself will accept. So you don't need 500khz, you need 53khz, or 53kb/sec. You could write that in anything. The SD card reader that's linked on the "Learn the Simple Libraries" page I posted will read 256kb/sec and it only needs about 4 lines of code to do so.
Have you worked through these numbers before? Is there something I'm missing that means you really do need the 500khz rate?
If it's possible to lower that 800 number to 400 or 200 it would make sense to do so. 1 inch / 12800 is 0.000078125 inches. If your machine is only able to achieve a precision of about 1/1000th of an inch, you're taking 16 times more steps than you need to take to get that precision. Lowering the steps per turn number, if you can, would reduce the kb/sec number you need to hit by a significant factor.
The Prop could do the x16 scaling, even if the machine cannot, and I'd expect this also needs a Timebase scale and a Step scale, both of which can be in the file heading, or, you could even embed the Timebase and Step into the spare fields in the nibbles, and have it entirely run-time dynamic.
Same playback codes, but a superset.
Jason...going back over my calculations, I find the same numbers as you posted. 53.33 kHz and 78 micro inches. Down on the corner of one of the pages I did find some "what if" calculations including the 500 kHz number I posted which has nothing to do with the actual project...same with the 0.0013 precision that is wrong. Thanks for catching that.
The ClearPath motors can be set via USB cable connection to several different parameters and the number of steps per revolution is adjustable. At this point I have the option of changing the screw pitch and the number of steps per revolution.
The fastest I could read data from the SD memory was 39.062 kHz using the "mount SD card" instruction in SimpleIDE which apparently reads one word at a time. You must be using page read of 512 words. I will check the "Learn the Simple Libraries" page for the correct instruction.
I have future plans for the second nibble in the SD memory word involving advanced control features so the first implementation will only use the first four bits of the word. No compression at this time.
Do you think this project could be coded in "C" using 2 COG's 512X32 bit memories in a ping-pong mode to write/read 512 word pages to/from the SD memory? The output clocking rate must be uniform and adjustable from 0 kHz to 53 kHz. Can you provide some sample code?
As mentioned quite a few posts back, I have written code for a nibbler cog that reads nibbles continually from two consecutive 512 byte buffers. The foreground task just fills up the buffers with the next sector from the SD FAT32 file while checking the nibbler's read pointer to make sure the buffer is finished with before filling it again while the nibbler is busy on the other buffer. In Tachyon of course, not C, but you can run at over 1.2 million nibbles/sec.
Do you think this project could be coded in "C" using 2 COG's 512X32 bit memories in a ping-pong mode to write/read 512 word pages to/from the SD memory? The output clocking rate must be uniform and adjustable from 0 kHz to 53 kHz. Can you provide some sample code?
You wouldn't need two cogs reading from the SD card - in fact, that would make it harder.
The best way to do this would be to have two cogs (so you have the right idea) but the division of labor would be a little different.
You'd have two 512-byte buffers in memory. Each buffer would be accompanied by a flag to specify whether it was "full" or not. You could go more general than this and make a "ring buffer" - the concept and implementation is nearly identical, but it would make it easier to change the size.
Simply put, one cog fills one of the buffers while the other cog is emptying the other one. The "filling" cog checks to see if a buffer is empty. If so, it reads data from the SD card into the buffer and marks that section as full, and moves on to the next buffer. The other buffer, on startup, will also be empty, and so it'll immediately start filling that one too.
Meanwhile, another cog checks to see if a buffer is full. If so, it reads one byte at a time, at 53.33khz, setting the output pins as appropriate. When it reaches the end of the buffer, it marks it as empty and moves to the next buffer immediately. This buffer, by now, has been filled, so it simply starts reading from this one while the other cog fills the other buffer.
They're basically playing leapfrog with the buffers (commonly referred to as double-buffering). Since the "filling" cog can read data from the SD card MUCH faster than the "emptying" cog needs it, there's basically no chance you'll ever fall behind, so two buffers is plenty. That said, SD card performance isn't always perfect, so having a 3rd or 4th buffer just in case wouldn't hurt.
In C/C++, the flags that specify if a buffer is full would need to be marked as volatile so the compiler knows they have to be reloaded from memory on every use because someone else might change them.
If I get some time tomorrow I'll try to bang something out quickly - it shouldn't take very long.
It's just like the WAVE-player works. You may find the source code for the waveplayer in SimpleIDE or on Github.
If you change the output from the FRQA/FRQB register to OUTA in the assembly part of the waveplayer, and then generate an 8bit mono WAV file with 53kHz sample rate that contains the steps for your machine, you can just play the WAV file to route the path with your stepper motors.
The WAV format is quite simple, just the raw byte data with a header which describes the format and rate.
This is a SimpleIDE project with a single cpp file. I've attached the file and project to this post, but also copied the source here in case people just want to read it without the hassle of downloading & unzipping.
It's about as simple as I could make it while still doing a reasonable job of error checking and indicating status. If you run a serial terminal you'll see the block reads go by as the characters 0,1,2,3 get printed to the screen on each buffer read. The output thread toggles an LED on pin 26 so you can tell it's working, and the actual outputs are sent to P0 - P3. Only the low nybbles are output.
/*
SDTest.side
Read data from an SD card, output it to pins at a specified rate
*/
#include "simpletools.h" // Include simpletools header
const int DO = 22, CLK = 23, DI = 24, CS = 25;// SD card pins on Propeller BOE
// use four SD buffers to cycle through = 2Kb total data - you can change this to anything from 2 or greater
const int BufferCount = 4;
// each buffer is 512 bytes
char Buffer[BufferCount][512];
// these flags tell us if a buffer has been read from the SD card or not (volatile means another thread might change it)
volatile bool BufferFull[BufferCount];
// Set this flag to true when it's time for the output thread to quit
volatile bool StopSending = false;
// Forward declaration of the output function so we can launch it
void OutputDataThread(void *par);
const int OutputStackSize = 40 + 32; // stack needs to accommodate thread control structure (40) plus some room for locals and functions (32)
static int OutputStack[OutputStackSize]; // allocate space for the output function stack
// main function - this is the cog that reads SD data and fills buffers
int main(void)
{
// Initialize buffers (just mark them all as empty)
for( int i=0; i<BufferCount; i++ )
{
BufferFull[i] = false;
}
// Now that the buffers are all marked as empty, it's safe to start the reader thread
StopSending = false; // make sure it knows it's reading data
// Start the thread that sends the data, giving it the size and pointer to the stack memory we set aside for it
cogstart( &OutputDataThread, 0, OutputStack, sizeof(OutputStack) );
// Set up the SD card reader
sd_mount(DO, CLK, DI, CS); // Mount SD card
FILE *fp;
fp = fopen("testdata.txt", "rb"); // Open file for reading - need to change filename here probably
int bufferToRead = 0; // which buffer we're currently reading into
int readResult = 0; // how many bytes we got back from the file read
while(true) // repeat forever (until we break out of the loop)
{
while( BufferFull[bufferToRead] == true )
{
; // sit here and do nothing until a buffer empties
}
// If you run a serial terminal, you can see which buffer we're about to fill because it prints 0123...
putChar( '0' + bufferToRead ); // so we see reads go by
readResult = fread( Buffer[bufferToRead], 1, 512, fp); // Read 512 characters
// Did we read any bytes?
if( readResult > 0 )
{
// yes - check to see if we got all we asked for
if( readResult < 512 ) // did we not get a full 512 bytes?
{
// We didn't get all 512 bytes, so clear whatever we didn't overwrite
memset( Buffer[bufferToRead] + readResult, 0, 512 - readResult );
}
BufferFull[ bufferToRead ] = true; // mark this buffer as containing data
bufferToRead = (bufferToRead+1) % BufferCount; // move on to the next buffer index, wrapping around to zero if necessary
}
else
{
// didn't read any bytes, so the file is finished; break out of this loop and end
break;
}
}
StopSending = true; // Tell the output thread we're done
fclose(fp); // Close the file
while( true ) {
; // do nothing forever when we're done
}
}
// This thread waits for data in a buffer, then clocks it out at whatever the specified rate is
void OutputDataThread(void *par)
{
int OutputRate = 53000; // 53khz output rate
int OutputDelay = _clkfreq / OutputRate; // how long to delay between outputting bytes
int bufferToSend = 0; // Which buffer are we sending data from?
// We're going to output to pins 0, 1, 2, 3
int PinMask = (1<<0) | (1<<1) | ( 1<< 2) | (1<<3);
int DataShift = 0; // How much to shift up the data we're reading in to send it to the right output pins
DIRA |= PinMask; // set these pins to outputs
DIRA |= (1 << 26); // ... and also pin 26 because that one has an LED connected to it
// Record the current clock tick
int clockTick = CNT;
// the output loop - keep going until we're told not to
while( StopSending == false )
{
while( BufferFull[bufferToSend] == false )
{
// re-record the clock tick value, in case it takes a while to get a buffer of data
// this SHOULD only happen at the very beginning, but if anything ever goes wrong with
// an SD read and it takes longer than expected, this will prevent the code from
// locking up
clockTick = CNT;
}
for( int i=0; i<512; i++ ) // loop through all the bytes in this buffer
{
int data = Buffer[bufferToSend][i] & 0x0F; // Only keep the bottom 4 bits (0b00001111 would work here too)
// add however long we need to wait to the clock tick number
clockTick += OutputDelay;
// wait until that time arrives
waitcnt( clockTick );
// Set the output pins by ANDing off whatever was there before, and ORing in the new bits
OUTA = (OUTA & ~PinMask) | (data << DataShift);
}
if( bufferToSend == 0 ) {
OUTA = OUTA ^ (1<<26); // this is just so we know it's still working - toggle an LED on the first buffer of each cycle
}
// we've consumed and send this buffer - mark it free so the reader thread will refill it
BufferFull[bufferToSend] = false;
// move on to the next buffer, wrapping around to zero if necessary
bufferToSend = (bufferToSend+1) % BufferCount;
}
}
Jason...last night I had my computer try to unzip your SDTest file and the machine spun its wheels for 25 minutes locking the keyboard out. I was unable to gain control of the machine...so I forced a power off and restarted the machine.
I copied your readable code and entered the project by hand into my Propeller Activity Board processor. I checked your code against my entered code and found one discrepancy. There was an underline character before the clock word in your code...I flagged it on the attached file.
I was unable to make sense of the error messages. Maybe they make sense to you.
You're compiling it as C, and I'm using C++ features, like variables declared mid-scope in a function. Rename the file from SDTest.c to SDTest.cpp, or tell the compiler to compile as C++ and it should all work.
And for future, just plain text files are easiest for the forums, unless there's some need for additional formatting or something. I downloaded the SDTest.zip file trivially and everything is ok. For some reason the forums wouldn't let me upload a .side file (which is just text).
The above file is .ODT and my not be readable so I included below a .PDF file.
Discovery
Sounds like you are using LibreOffice or open office, both of which can save the files in several MS formats including .txt and .doc. I save in .odt for myself and generally save as word 97-2003 .doc or .txt when sending to others.
Jason...I am having some trouble here. When I go to file SDTest.c and try to change the name to SDTest.cpp, there is no function to make a name change.
So the "or" part of your directive is to tell the compiler to compile as C++. How do I do that?
If you are unable to rename a file, you may be pursuing the wrong career path.
If you have a text editor, copy the content of the block I pasted above into it and save it as an ascii text file called SDTest.side. Put the SDTest.c file in the same folder and rename that file to SDTest.cpp. That should be it.
As another option, if you create a new SimpleIDE project, and call it something else, like "MachineController", it'll make you a .c file with that name. Empty the content of that .c file, and just add the SDTest.cpp file to the project. That should work too.
When I use the Windows 10 file editor to high lite the SimpleIDE file SDTest.side, I can change that file to anything I want since there is rename function. But when I high lite the SDTest.c file there is no rename function available. That's where I thought you wanted the file name changed...apparently not.
I did what you described...inserting the block above into my SDTest.side file and saved it as SDTest.cpp however, when I ran the compiler it gave the errors I posted and wrote the companion file SDTest.cpp.c which I was not expecting.
You apparently have Windows set to hide file extensions, so it's leaving the extension in place when you rename the file, which is why you're seeing what you're seeing. Windows is "helpfully" keeping the .c extension for you, and changing "SDTest.c" to "SDTest.cpp.c" for you. I hate that they obscure that from you.
In a Windows Explorer, look along the top of the window and you'll see "File Home Share View ..." Click on "View", then toward the right side of the panel that comes up you should see "Item check boxes", "File name extensions", and "Hidden items" checkboxes. Check the "File name extensions" box and your rename woes should disappear.
I also have no difficulty opening the original .zip file. I downloaded it on my work machine, which is a Windows 10 system, and it opens just fine. You should be able to right-click the file and just choose "extract all". It'll suggest a folder to extract them to which is fine. Find that folder when done and you should be able to just double-click the SDTest.side file to open the project.
Jason...I used to program fighter aircraft digital computers in assembly code. There was no "f..ing" operating system that made decisions to check the time of day, or if email was waiting, or anything else. The machine did exactly what I told it to do, it read "offset coordinates" sent to it from Cheyenne mountain operations control via GCI. The program flew the fighter to the "offset" then received additional coordinates for target intercept. The program told the pilot what mach number to keep the aircraft at. Yes, the program actually flew the aircraft as the front line defense of north America in the 1960's and 1970's. The program did a lot more but you should get the point. I cannot stand computers that take control away from my program.
As an example, I have a dedicated Dell computer that controls several BS2 micro controllers and a propeller micro controller. The machine was setup by a Geek at Staples to make the computer completely stand alone, no Internet connection, no sleeping, constant screen, and a few other features. I tried to make the machine into just a computer. After four months of perfect system operations the Dell computer screen went black and there was no video from the NTSC interface port. I took the computer back to the Geek and he pulled up various files, deleted this, deleted that, so fast that it was a blur. The computer is back in system operations but who knows when some other hidden feature will bite my Smile.
With regard to the current project development computer that is giving me grief, I did not set it to hide anything. That is the way Microsoft downloaded the blasted thing. It looks like I will have to do some Geek stuff after all.
Jason...the project development computer has practically no Windows programs on it so I am unable to follow your directives. There are good reasons to keep as much Windows off the machine as possible. Editing is done with Open Office when I need to print and save files. Since I have a new lap top computer available, I plan to load the necessary Windows programs and follow your directives.
You shouldn't need them. Run a command prompt and do the renames from there. You can create the .side file from any computer by pasting the text in the above post into notepad and saving as a .side file instead of .txt, and OpenOffice should be able to do this too. There's no magic here.
Comments
Well, yes that is rather my point.
What I think an even basic download pgm should report is more along these lines :
Notice now you can see what proploader is actually trying to do.
The command line report is a good start, but there are forms for DTR.RTS and Delays, but no sign of if those are used, or not ?
You'll have to agree
ERROR: Download failed: -1
is a poor analysis tool...
Even the earlier
Done. Build Succeeded!
lacks information on final code Size ?!
I can see flashes on both LEDs, so that suggests some echo is made, in this case the report would become
Since I can see a TX flash, and to underline my point of the need for good reports, I attached another COM port and terminal @ 115200. (Of course a new SimpleIDE user should not have to do this....)
QuickStart.Sniff.RX shows 1480 chars, and download fails.
Seems quite a few, (but much less than expected chars to carry 8140 bytes) so maybe this almost works ?
QuickStart.Sniff.TX shows 225 chars, (includes 'Hello!4' echo) and download works
? wtf ? Adding a COM sniffer wire makes this work ?!
Try a 1.5k pullup instead, (QS.TX) and same result: download now works.
Conclude: Something dodgy on the QS, almost like Prop is set open drain and not CMOS ?
You guys are experts in the coding and problem solving field...I am a simple user who wants to get a project designed and built as easily as possible. That is why:
I was hoping and expecting that there was a method that I, as a shaky "C" programmer, could insert in my SimpleIDE project to by-pass the slow Propeller "mount SD card" code so that the Propeller could read the SD memory on the Propeller Activity Board and clock words out up to 500kHz. Once that works...the hardware would be transferred to a new printed circuit board and be inserted in the plasma cutter control box.
The depth of the memory was scaled back to a few tens of mega words.
It appeared that there was a way to use two COGs and their memory to read 512 word pages in a ping-pong fashion then output the words at a rate that I select for the plasma cutting application.
The suggestion was that I can write "spin" or some other language code to accomplish this and it should work perfectly well. The problem is that I cannot write that code...I have enough trouble just writing "C" in SimpleIDE. I don't have the experience you folks have. So, I was hoping to receive chunks of "C" code or other code that I could insert into my "C" code and solve the problem.
I was also hoping that some one might have a Propeller Activity Board handy and could verify the code before sending it on to me. Just hoping!
Sincerely,
Discovery
The individual words are the numbers contained in this list (2, 3, 8, 10, 11, 12, 14,and 15). The SD memory will act as a FIFO. When the data are read out, you will see a string of numbers that may look like:
8,8,8,8,2,2,2,3,11,11,14,14,14,14...........
These numbers are then decoded into x-axis motor direction and step pulses plus y-axis motor direction and step pulses and defined as:
output (A) high == x-axis stepper motor clockwise rotation direction
output (A) low == x-axis stepper motor counter-clockwise rotation direction
output (B) low-high-low == x-axis stepper motor single step
output (C) high == y-axis stepper motor clockwise rotation direction
output (C) low == Y-axis stepper motor counter-clockwise rotation direction
output (D) low-high-low == y-axis stepper motor single step
The propeller will decode the SD memory numbers and output signals on A, B, C, and D that are then buffered and sent to the two high-speed stepper motors.
As an example: if the x-axis stepper motor is directed to make a straight line 10 inches long and the y-axis motor does not step then the output string of numbers from the SD memory will be 3, 3, 3, 3, 3, 3, 3.... until the 10 inch line is cut.
The reason for the SD memory card is it is currently on my Propeller Activity Board ready to test the code.
Also, depending upon the application, the SD memory read and propeller output of signals A, B, C, and D must vary anywhere from 0 kHz to around 500 kHz. For cutting 5/8" thick mild steel, the clock rate will be set to move the cutter head at 13 inches per minute. For thin mild steel, 22 gauge, the clock rate will be set to move the cutter head at 822 inches per minute.
Discovery
So your bits are:
If this is true, then there are a couple things you could do, most notably and simply, if your "step" pins are 0 you don't step, if they're 1, you do the toggle low-high-low in code. That would cut your bandwidth requirements in half, would it not?
You could also pack two outputs into a single byte, so the upper four bits are your first value, and the lower four are the second value. That again cuts your bandwidth requirements in half, so now instead of needing to read 500Kb/sec from the SD card, you need 125Kb/sec. With one cog reading from the SD card, and another doing the decode and output, you wouldn't even need compression to hit your speed mark. Simple compression would only improve things.
On top of this, I'd output 1 value to mean "how many times to repeat the next value", followed by an actual value.
So now your straight line of 10 inches looks like:
15, 0, 15, 0, 15, 0 . ..
Each of those 15's means "repeat the next output 15 times". You could use two zeros in a row as a special case to reset the directions to a known state. You're still only working in nybbles, so you could still pack pairs of them together. This would get you, best case, about 14:1 compression, and again reduce your bandwidth requirements pretty dramatically. It would also be quite simple to implement.
The current design data are the following:
The ClearPath stepper motor takes 800 steps to make 1 revolution.
The threaded rod that moves the cutting head pitch is 16 revolutions per inch.
That makes 12,800 steps per inch.
To move the cutting head 7 feet along the x-axis takes 1,075,200 steps.
To move the cutting head 3.5 feet along the y-axis takes half the number of the x-axis or 537,600 steps.
To cut a rectangle 7 feet by 3.5 feet therefore takes 3,225,600 steps.
Each step represents one nibble of SD memory or 3,225,600 4-bit nibbles. Not much memory at all.
The ClearPath stepper motor can turn at 4,000 revolutions per minute and thus cover 7 feet in 0.3360 minutes.
To cut the complete rectangle takes 60.48 seconds or just over one minute.
The precision of one step is 0.0013 inches.
All I need is the code to run the Propeller COGs, decode the SD memory, output the x-axis step/direction signals and output the y-axis step/direction signals which I designated A, B, C, and D from the propeller.
Improvements will be considered later.
Discovery
The reason I suggested using compression of some kind or even just packing nybbles together is that too will lower the bandwidth requirement. By doing that, you make the system possible with the code you have trivially available to you. You keep saying "I'll try that after I get the first version up and running". If your initial requirement is 500kb/sec and you can't achieve that without learning a new language, and there's code that will demonstrably achieve 250kb/sec right now with tools you have, learning how to pack nybbles together makes more sense than buying a new computer, installing linux, and learning PropWare.
You said the ClearPath stepper can turn at a maximum of 4000rpm. That's 66.6 turns per second. You also said it takes 800 steps per turn. 66.66 turns per second x 800 steps per turn is a maximum step rate of 53,333 steps per second, which is nowhere close to the 500khz the driver itself will accept. So you don't need 500khz, you need 53khz, or 53kb/sec. You could write that in anything. The SD card reader that's linked on the "Learn the Simple Libraries" page I posted will read 256kb/sec and it only needs about 4 lines of code to do so.
Have you worked through these numbers before? Is there something I'm missing that means you really do need the 500khz rate?
Same playback codes, but a superset.
The ClearPath motors can be set via USB cable connection to several different parameters and the number of steps per revolution is adjustable. At this point I have the option of changing the screw pitch and the number of steps per revolution.
The fastest I could read data from the SD memory was 39.062 kHz using the "mount SD card" instruction in SimpleIDE which apparently reads one word at a time. You must be using page read of 512 words. I will check the "Learn the Simple Libraries" page for the correct instruction.
I have future plans for the second nibble in the SD memory word involving advanced control features so the first implementation will only use the first four bits of the word. No compression at this time.
Do you think this project could be coded in "C" using 2 COG's 512X32 bit memories in a ping-pong mode to write/read 512 word pages to/from the SD memory? The output clocking rate must be uniform and adjustable from 0 kHz to 53 kHz. Can you provide some sample code?
Discovery
You wouldn't need two cogs reading from the SD card - in fact, that would make it harder.
The best way to do this would be to have two cogs (so you have the right idea) but the division of labor would be a little different.
You'd have two 512-byte buffers in memory. Each buffer would be accompanied by a flag to specify whether it was "full" or not. You could go more general than this and make a "ring buffer" - the concept and implementation is nearly identical, but it would make it easier to change the size.
Simply put, one cog fills one of the buffers while the other cog is emptying the other one. The "filling" cog checks to see if a buffer is empty. If so, it reads data from the SD card into the buffer and marks that section as full, and moves on to the next buffer. The other buffer, on startup, will also be empty, and so it'll immediately start filling that one too.
Meanwhile, another cog checks to see if a buffer is full. If so, it reads one byte at a time, at 53.33khz, setting the output pins as appropriate. When it reaches the end of the buffer, it marks it as empty and moves to the next buffer immediately. This buffer, by now, has been filled, so it simply starts reading from this one while the other cog fills the other buffer.
They're basically playing leapfrog with the buffers (commonly referred to as double-buffering). Since the "filling" cog can read data from the SD card MUCH faster than the "emptying" cog needs it, there's basically no chance you'll ever fall behind, so two buffers is plenty. That said, SD card performance isn't always perfect, so having a 3rd or 4th buffer just in case wouldn't hurt.
In C/C++, the flags that specify if a buffer is full would need to be marked as volatile so the compiler knows they have to be reloaded from memory on every use because someone else might change them.
If I get some time tomorrow I'll try to bang something out quickly - it shouldn't take very long.
I am looking forward to loading your code and running it on my Propeller Activity Board...Wonderful!
To bang that code out would take me an eternity.
Thank you.
Discovery
If you change the output from the FRQA/FRQB register to OUTA in the assembly part of the waveplayer, and then generate an 8bit mono WAV file with 53kHz sample rate that contains the steps for your machine, you can just play the WAV file to route the path with your stepper motors.
The WAV format is quite simple, just the raw byte data with a header which describes the format and rate.
Andy
It's about as simple as I could make it while still doing a reasonable job of error checking and indicating status. If you run a serial terminal you'll see the block reads go by as the characters 0,1,2,3 get printed to the screen on each buffer read. The output thread toggles an LED on pin 26 so you can tell it's working, and the actual outputs are sent to P0 - P3. Only the low nybbles are output.
/* SDTest.side Read data from an SD card, output it to pins at a specified rate */ #include "simpletools.h" // Include simpletools header const int DO = 22, CLK = 23, DI = 24, CS = 25;// SD card pins on Propeller BOE // use four SD buffers to cycle through = 2Kb total data - you can change this to anything from 2 or greater const int BufferCount = 4; // each buffer is 512 bytes char Buffer[BufferCount][512]; // these flags tell us if a buffer has been read from the SD card or not (volatile means another thread might change it) volatile bool BufferFull[BufferCount]; // Set this flag to true when it's time for the output thread to quit volatile bool StopSending = false; // Forward declaration of the output function so we can launch it void OutputDataThread(void *par); const int OutputStackSize = 40 + 32; // stack needs to accommodate thread control structure (40) plus some room for locals and functions (32) static int OutputStack[OutputStackSize]; // allocate space for the output function stack // main function - this is the cog that reads SD data and fills buffers int main(void) { // Initialize buffers (just mark them all as empty) for( int i=0; i<BufferCount; i++ ) { BufferFull[i] = false; } // Now that the buffers are all marked as empty, it's safe to start the reader thread StopSending = false; // make sure it knows it's reading data // Start the thread that sends the data, giving it the size and pointer to the stack memory we set aside for it cogstart( &OutputDataThread, 0, OutputStack, sizeof(OutputStack) ); // Set up the SD card reader sd_mount(DO, CLK, DI, CS); // Mount SD card FILE *fp; fp = fopen("testdata.txt", "rb"); // Open file for reading - need to change filename here probably int bufferToRead = 0; // which buffer we're currently reading into int readResult = 0; // how many bytes we got back from the file read while(true) // repeat forever (until we break out of the loop) { while( BufferFull[bufferToRead] == true ) { ; // sit here and do nothing until a buffer empties } // If you run a serial terminal, you can see which buffer we're about to fill because it prints 0123... putChar( '0' + bufferToRead ); // so we see reads go by readResult = fread( Buffer[bufferToRead], 1, 512, fp); // Read 512 characters // Did we read any bytes? if( readResult > 0 ) { // yes - check to see if we got all we asked for if( readResult < 512 ) // did we not get a full 512 bytes? { // We didn't get all 512 bytes, so clear whatever we didn't overwrite memset( Buffer[bufferToRead] + readResult, 0, 512 - readResult ); } BufferFull[ bufferToRead ] = true; // mark this buffer as containing data bufferToRead = (bufferToRead+1) % BufferCount; // move on to the next buffer index, wrapping around to zero if necessary } else { // didn't read any bytes, so the file is finished; break out of this loop and end break; } } StopSending = true; // Tell the output thread we're done fclose(fp); // Close the file while( true ) { ; // do nothing forever when we're done } } // This thread waits for data in a buffer, then clocks it out at whatever the specified rate is void OutputDataThread(void *par) { int OutputRate = 53000; // 53khz output rate int OutputDelay = _clkfreq / OutputRate; // how long to delay between outputting bytes int bufferToSend = 0; // Which buffer are we sending data from? // We're going to output to pins 0, 1, 2, 3 int PinMask = (1<<0) | (1<<1) | ( 1<< 2) | (1<<3); int DataShift = 0; // How much to shift up the data we're reading in to send it to the right output pins DIRA |= PinMask; // set these pins to outputs DIRA |= (1 << 26); // ... and also pin 26 because that one has an LED connected to it // Record the current clock tick int clockTick = CNT; // the output loop - keep going until we're told not to while( StopSending == false ) { while( BufferFull[bufferToSend] == false ) { // re-record the clock tick value, in case it takes a while to get a buffer of data // this SHOULD only happen at the very beginning, but if anything ever goes wrong with // an SD read and it takes longer than expected, this will prevent the code from // locking up clockTick = CNT; } for( int i=0; i<512; i++ ) // loop through all the bytes in this buffer { int data = Buffer[bufferToSend][i] & 0x0F; // Only keep the bottom 4 bits (0b00001111 would work here too) // add however long we need to wait to the clock tick number clockTick += OutputDelay; // wait until that time arrives waitcnt( clockTick ); // Set the output pins by ANDing off whatever was there before, and ORing in the new bits OUTA = (OUTA & ~PinMask) | (data << DataShift); } if( bufferToSend == 0 ) { OUTA = OUTA ^ (1<<26); // this is just so we know it's still working - toggle an LED on the first buffer of each cycle } // we've consumed and send this buffer - mark it free so the reader thread will refill it BufferFull[bufferToSend] = false; // move on to the next buffer, wrapping around to zero if necessary bufferToSend = (bufferToSend+1) % BufferCount; } }Discovery
I copied your readable code and entered the project by hand into my Propeller Activity Board processor. I checked your code against my entered code and found one discrepancy. There was an underline character before the clock word in your code...I flagged it on the attached file.
I was unable to make sense of the error messages. Maybe they make sense to you.
Discovery
Discovery
And for future, just plain text files are easiest for the forums, unless there's some need for additional formatting or something. I downloaded the SDTest.zip file trivially and everything is ok. For some reason the forums wouldn't let me upload a .side file (which is just text).
If you open the .side file, it looks like this:
...and the exact contents of the SDTest.cpp file are what I posted above. It's attached here for completeness.
Sounds like you are using LibreOffice or open office, both of which can save the files in several MS formats including .txt and .doc. I save in .odt for myself and generally save as word 97-2003 .doc or .txt when sending to others.
So the "or" part of your directive is to tell the compiler to compile as C++. How do I do that?
Discovery
If you have a text editor, copy the content of the block I pasted above into it and save it as an ascii text file called SDTest.side. Put the SDTest.c file in the same folder and rename that file to SDTest.cpp. That should be it.
You're probably also using SimpleIDE in simple mode instead of "project view" mode, which gives you fewer options. See here for how to change that: http://forums.parallax.com/discussion/163411/simpleide-s-project-view
As another option, if you create a new SimpleIDE project, and call it something else, like "MachineController", it'll make you a .c file with that name. Empty the content of that .c file, and just add the SDTest.cpp file to the project. That should work too.
When I use the Windows 10 file editor to high lite the SimpleIDE file SDTest.side, I can change that file to anything I want since there is rename function. But when I high lite the SDTest.c file there is no rename function available. That's where I thought you wanted the file name changed...apparently not.
I did what you described...inserting the block above into my SDTest.side file and saved it as SDTest.cpp however, when I ran the compiler it gave the errors I posted and wrote the companion file SDTest.cpp.c which I was not expecting.
I will take a look at your other options.
Discovery
In a Windows Explorer, look along the top of the window and you'll see "File Home Share View ..." Click on "View", then toward the right side of the panel that comes up you should see "Item check boxes", "File name extensions", and "Hidden items" checkboxes. Check the "File name extensions" box and your rename woes should disappear.
I also have no difficulty opening the original .zip file. I downloaded it on my work machine, which is a Windows 10 system, and it opens just fine. You should be able to right-click the file and just choose "extract all". It'll suggest a folder to extract them to which is fine. Find that folder when done and you should be able to just double-click the SDTest.side file to open the project.
As an example, I have a dedicated Dell computer that controls several BS2 micro controllers and a propeller micro controller. The machine was setup by a Geek at Staples to make the computer completely stand alone, no Internet connection, no sleeping, constant screen, and a few other features. I tried to make the machine into just a computer. After four months of perfect system operations the Dell computer screen went black and there was no video from the NTSC interface port. I took the computer back to the Geek and he pulled up various files, deleted this, deleted that, so fast that it was a blur. The computer is back in system operations but who knows when some other hidden feature will bite my Smile.
With regard to the current project development computer that is giving me grief, I did not set it to hide anything. That is the way Microsoft downloaded the blasted thing. It looks like I will have to do some Geek stuff after all.
I will follow your suggestions...in a bit.
Discovery
Sorry to be such a pain.
Discovery