You must also comment out or delete the lines that start with "const int". This will compile as a C file, as long as you have the "c99" option set. If you don't want to use the "c99" option you will have to change a few other things.
If you follow the "project view mode" steps I linked earlier you can just set the compiler type to C++ in the bottom panel, in addition to making it MUCH simpler to manage your project, add specifically named files, etc. SimpleIDE is *too simple* when not set to project mode.
C++ allows you a few conveniences in the way you code and while it wouldn't be terribly hard to change, I'm already into this for about 2 hours of coding, and it's your project, not mine. If you want me to write it for you beyond what I've already done we can work out an hourly rate.
Hi Dave...I inserted your five lines of define statements into my SimpleIDC "C" SDTest program and removed the const portion of two instructions as you requested. I got a "does not compile" error on:
#define bool int
I commented out the #define bool int instruction to see if there were any other compile errors. I got a "does not compile" error on:
int BufferCount = 4; of my code. The error states that it expected an identifier or "(" before the constant.
"You must also comment out or delete the lines that start with "const int". "
You have to comment out or delete the whole line, not just the "const" portion. My changes define BufferSize and OutputStackSize as symbols using #define instead of the constant ints that Jason used. C does not like declaring arrays using a const int for the size. It requires the size to be an explicit value. Using #define satisfies this requirement.
Jason...You most likely do not comprehend the amount of appreciation that I have for you and your 2 hours of coding. Thank you very much. Regarding your request to write the code...I see additional work that is required.
The current code, it appears, implements a LIFO of the SD memory. The code needs to be modified for a FIFO. This suggests that at the end of calculating all the step data and making entries into the SD memory, the code must include a trailer that states the number of entries in the SD memory. This number must be included in your program to read out the steps in the correct sequence. Or, you may know of a technique to readout the data in reverse without a trailer. Regarding your request for work, the following is supplied.
It is required on all work requests that the board-of-directors of the corporation weigh-in on the effort expected in the funded task. Their observations are the following:
1. What was supposed to be a "C" project in SimpleIDE to upgrade the plasma cutter controller and steppers to new ClearPath stepper motors with assistance from the Parallax Forum experts does not appear viable due to complications with programming languages.
2. The hourly rate to be negotiated with Jason Dorie is not a problem. The problem is that he appears to be the only person who can code the propeller to do the job and he is not a member of the company nor any of its affiliates. Any modifications to the code cannot be done "in-house" and thus requires a continual work contract. Jason represents a single point of failure that takes on significant risk for the company.
3. None of the "C++" code supplied by Jason has successfully compiled for the propeller. The company has no indication that it will since the configuration of the company's computers are not consistent with his expectations. Current attempts to find work-around's for the problems have not yielded any progress.
4. Unless a major simplification factor is found that streamlines the development of the plasma cutter code in SimpleIDE "C" then the board-of-directors recommends that some other solution be found for upgrading the plasma cutter.
The company's BOD are some really smart folks and I agree with their findings.
Jason...You most likely do not comprehend the amount of appreciation that I have for you and your 2 hours of coding. Thank you very much. Regarding your request to write the code...I see additional work that is required.
The current code, it appears, implements a LIFO of the SD memory. The code needs to be modified for a FIFO. This suggests that at the end of calculating all the step data and making entries into the SD memory, the code must include a trailer that states the number of entries in the SD memory. This number must be included in your program to read out the steps in the correct sequence. Or, you may know of a technique to readout the data in reverse without a trailer. Regarding your request for work, the following is supplied.
It is required on all work requests that the board-of-directors of the corporation weigh-in on the effort expected in the funded task. Their observations are the following:
1. What was supposed to be a "C" project in SimpleIDE to upgrade the plasma cutter controller and steppers to new ClearPath stepper motors with assistance from the Parallax Forum experts does not appear viable due to complications with programming languages.
2. The hourly rate to be negotiated with Jason Dorie is not a problem. The problem is that he appears to be the only person who can code the propeller to do the job and he is not a member of the company nor any of its affiliates. Any modifications to the code cannot be done "in-house" and thus requires a continual work contract. Jason represents a single point of failure that takes on significant risk for the company.
3. None of the "C++" code supplied by Jason has successfully compiled for the propeller. The company has no indication that it will since the configuration of the company's computers are not consistent with his expectations. Current attempts to find work-around's for the problems have not yielded any progress.
4. Unless a major simplification factor is found that streamlines the development of the plasma cutter code in SimpleIDE "C" then the board-of-directors recommends that some other solution be found for upgrading the plasma cutter.
The company's BOD are some really smart folks and I agree with their findings.
Discovery
The one point of this that I disagree with is "he appears to be the only person who can code the propeller to do the job."
He is not the only one that can do this. Many people in this thread have proven their ability to get this job done based on the ideas (and code) that have been put forth here. I hope it's simply a language barrier/misunderstanding, but to state that in this thread that Jason is the only one that can do this is a bit insulting.
Okay... I'm breathing. I'm okay.
With that said, your biggest problem is solved. Hire Jason to do the initial work and trust that future work can be taken care of either by Jason, or most any other competent C or C++ developer that you might find. In fact, I might argue that your best bet is to try and hire Peter (or another Tachyon developer) for this. If he built both your hardware and software for this modification, he'd be able to remotely debug it and fix any problems that may arise or apply enhancements in the future.
@DavidZemon - Hey! I did it ages back but it wasn't in C and it wasn't even acknowledged. The "board-of-directors" might not approve though
@Discovery - Tachyon Forth is so much like assembler, it is the assembly language of a virtual stack machine, very fast and compact, with a direct correspondence between the source and the code. What you see is what executes, just like assembler. Better still, you only need a terminal and a text editor as well as the Prop tool. Load the kernel with the Prop tool and thereafter the Prop chip is the compiler and debugger.
Hi David...the BOD said that "he appears to be the only person who can code the propeller to do the job". Please note that they used the word appears! Some people these days are easily insulted.
The BOD is interested in receiving an implementation plan for developing the software only that compiles on SimpleIDE. Working a contract with Jason is fine. It appears that he has a really good understanding what is involved.
Hi Peter...your suggestion sounds very good; however, the BOD will only implement a plan that uses SimpleIDE for the plasma upgrade task.
For future projects, I really like the assembly approach you described.
Discovery
A plan that implements only SimpleIDE seems to indicate some astuteness on their part but if that were the case then that would mean that they know more than you or I in this matter. I thought you said "The company's BOD are some really smart folks and I agree with their findings". A decision is a decision but a decision reached after consultation and research is an informed decision.
Discovery, I don't understand the issues that you and the BOD are having with implementing this on the Prop. I can compile Jason's code without any problems. I've done it using the .cpp extension, and with a .c extension by setting the C++ mode. I've also compiled it in the C mode by making the changes I posted earlier. Are you not able to compile it in any of the three modes?
I don't understand why you think that Jason's code implements a LIFO. It looks like a FIFO to me. His code reads the file sequentially into a circular buffer. The read cog processes the circular buffer in the same order. Assuming the file was written in the correct order the output will be in the correct order.
Maintaining this program should be easy for anybody that understands C. It's a very small program, and it is extremely easy to follow. I don't understand the problem here.
Maybe the C++ aspect of Jason's code is confusing you. However, it is really just C code with a few C++ features that make it slightly cleaner. This can easily be converted to pure C if that's the problem you're having.
I don't understand what computer configuration you have that prevents you from compiling the code. This should work on any Windows machine you would have at your company. All you have to do is install SimpleIDE on the computer and open the SIDE file that Jason posted.
What kind of simplification factor do you need to develop the code on SimpleIDE.
If your company's BOD are really smart folks they shouldn't have any problems understanding how easy this is to implement on the Prop in C using SimpleIDE?
BTW, I ran some test with FSRW and was able to read sequential sectors at 880 kB/s. That's 1.76 million nybbles/second. I converted the FSRW Spin code to C and got the same results. I didn't try the standard PropGCC file drives, but they will be somewhat slower than FSRW. However, they could be sped up if the low-level driver routines are called directly instead of going through stdio.
The standard Prop / Simple libraries get about 250kb/sec, even in CMM mode, which is already 5x faster than necessary for this application. And yes, it reads the file data sequentially and is a FIFO, not a LIFO.
Hi Peter...your suggestion sounds very good; however, the BOD will only implement a plan that uses SimpleIDE for the plasma upgrade task.
For future projects, I really like the assembly approach you described.
Discovery
In addition you can mention to the BOD, that Tachyon running on Peter's IOT5500+P8 will just need an Ethernet cable to give remote access for troubleshooting with interactive console and Telnet as well as FTP and WebServer .. - all while the machine is running ...
I even made the webserver scriptable in a previous version of Tachyon
Jason...Have you run Dave Hein's suggestion of inserting five #define statements, removing all const int statements, and compiling with the "C" compiler?
I am curious since the line in your SDTest program includes
const int DO = 22, CLK = 23, DI = 24, CS = 25;
If this line is removed, how will the compiler know how to use your instruction
sd_mount(DO, CLK, DI, CS); ?
MJB...my company does not have personnel with expertise in the disciplines you mentioned that is why Jason's approach is the most attractive.
I will be out of communication for the next few days.
Discovery, keep the "const int DO..." line. When I made my suggestion in an earlier post I didn't notice that this line also contained "const int". You only need to comment out the other two lines and replace them with the #define lines.
Jason...I began testing your code today. I wrote code that I inserted into your project that writes 1,000 bytes into the SD memory then prints those 1,000 bytes to the screen to verify the data is correct followed by your code. I get no output on propeller pins p0, p1, p2, and p3. The only output is a single line of numeral 0123. I wonder why?
I was expecting 1,000 bytes of data driving the output pins p0-p3.
Jason...The 500kHz number came from the ClearPath motor User Manual and is the maximum clocking frequency for the motor.
I read the same sheet, but that number means nothing if your motor won't spin at the speed that step frequency corresponds to. Part of the reason I was pressing on the project requirements was exactly this - It's a common mistake to read a sheet and immediately start planning based on raw technical specs, but that's only half the picture. Lots of mechanical systems are constrained more by physical limits than technical ones.
As for the missing outputs, without seeing your code changes it's impossible to say.
My first guess is that this code stops when it's done reading the file. If you only put 1000 bytes of data into it, at 53khz that will last you exactly 1/53rd of a second - if you don't have some kind of capture scope connected, and you aren't slowing down the output frequency, you've probably just missed it.
It's worth mentioning that I didn't actually *test* the P0-P3 output, so the first thing you should do is just put a moderately large file in the root of the SD card called "testdata.txt", connect the ActivityBoard to a scope, and run the original code. If you don't see output from that, you know the original version didn't work either. If you *do* see output, then the issue is with whatever was changed / added, or the teeny file problem.
The 0123... output is just a "progress tick" to show you the code is still doing something (same with the blinking LED). In fact, since you didn't mention that, *is* the LED still blinking? If it isn't, that means the code that's outputting the data to the pins isn't running.
You didn't write 1000 zero's to the file, did you?
// 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) );
It doesn't "call" that function - it launches a cog that does, so it runs independently on another hardware thread.
You shouldn't print from that thread or you'll likely cause all kinds of problems. Two independent cogs (hardware threads) attempting to print to the same device at the same time is not safe, unless that object is thread-safe, and I doubt it is. It's also not fast enough to put in the loop that's supposed to run at 53khz, so if you add a lot of additional work in that output loop it'll most likely stall.
The reason the output loop will stall is this:
// add however long we need to wait to the clock tick number
clockTick += OutputDelay;
// wait until that time arrives
waitcnt( clockTick );
Now, you could add code to check if that time had already gone by, and if so, skip waiting, but then your "with no jitter" requirement is out the window.
I suspect that ultimately you're going to need to use something like a Raspberry Pi or Cortex M4 chip. The Prop isn't a terribly forgiving device if you don't have some idea of what you're doing.
Jason...Aw yes there it is in the cogstart instruction.
Over the last few days, I made some changes to my Plasma Cutter "C" code, cut two traces on the printed wire board, and added two wires to the printed circuit board. The result is that the ClearPath motors are now clocked at 29.5859 kHz moving the cutting head at 138 inches per minute and having a computed step precision of 78 micro inches. It can cut a 1/8" rectangular sheet of steel (8" by 10") in about 15 seconds. The machine falls short of cutting really thin sheet metal but right now it cuts 90% of the materials I use most often.
With these changes I call the Plasma Cutter upgrade project completed. And I would like to thank everyone who contributed to its success.
Comments
Discovery
C++ allows you a few conveniences in the way you code and while it wouldn't be terribly hard to change, I'm already into this for about 2 hours of coding, and it's your project, not mine. If you want me to write it for you beyond what I've already done we can work out an hourly rate.
#define bool int
I commented out the #define bool int instruction to see if there were any other compile errors. I got a "does not compile" error on:
int BufferCount = 4; of my code. The error states that it expected an identifier or "(" before the constant.
Discovery
You have to comment out or delete the whole line, not just the "const" portion. My changes define BufferSize and OutputStackSize as symbols using #define instead of the constant ints that Jason used. C does not like declaring arrays using a const int for the size. It requires the size to be an explicit value. Using #define satisfies this requirement.
Jim
The current code, it appears, implements a LIFO of the SD memory. The code needs to be modified for a FIFO. This suggests that at the end of calculating all the step data and making entries into the SD memory, the code must include a trailer that states the number of entries in the SD memory. This number must be included in your program to read out the steps in the correct sequence. Or, you may know of a technique to readout the data in reverse without a trailer. Regarding your request for work, the following is supplied.
It is required on all work requests that the board-of-directors of the corporation weigh-in on the effort expected in the funded task. Their observations are the following:
1. What was supposed to be a "C" project in SimpleIDE to upgrade the plasma cutter controller and steppers to new ClearPath stepper motors with assistance from the Parallax Forum experts does not appear viable due to complications with programming languages.
2. The hourly rate to be negotiated with Jason Dorie is not a problem. The problem is that he appears to be the only person who can code the propeller to do the job and he is not a member of the company nor any of its affiliates. Any modifications to the code cannot be done "in-house" and thus requires a continual work contract. Jason represents a single point of failure that takes on significant risk for the company.
3. None of the "C++" code supplied by Jason has successfully compiled for the propeller. The company has no indication that it will since the configuration of the company's computers are not consistent with his expectations. Current attempts to find work-around's for the problems have not yielded any progress.
4. Unless a major simplification factor is found that streamlines the development of the plasma cutter code in SimpleIDE "C" then the board-of-directors recommends that some other solution be found for upgrading the plasma cutter.
The company's BOD are some really smart folks and I agree with their findings.
Discovery
The one point of this that I disagree with is "he appears to be the only person who can code the propeller to do the job."
He is not the only one that can do this. Many people in this thread have proven their ability to get this job done based on the ideas (and code) that have been put forth here. I hope it's simply a language barrier/misunderstanding, but to state that in this thread that Jason is the only one that can do this is a bit insulting.
Okay... I'm breathing. I'm okay.
With that said, your biggest problem is solved. Hire Jason to do the initial work and trust that future work can be taken care of either by Jason, or most any other competent C or C++ developer that you might find. In fact, I might argue that your best bet is to try and hire Peter (or another Tachyon developer) for this. If he built both your hardware and software for this modification, he'd be able to remotely debug it and fix any problems that may arise or apply enhancements in the future.
@Discovery - Tachyon Forth is so much like assembler, it is the assembly language of a virtual stack machine, very fast and compact, with a direct correspondence between the source and the code. What you see is what executes, just like assembler. Better still, you only need a terminal and a text editor as well as the Prop tool. Load the kernel with the Prop tool and thereafter the Prop chip is the compiler and debugger.
The BOD is interested in receiving an implementation plan for developing the software only that compiles on SimpleIDE. Working a contract with Jason is fine. It appears that he has a really good understanding what is involved.
Discovery
For future projects, I really like the assembly approach you described.
Discovery
A plan that implements only SimpleIDE seems to indicate some astuteness on their part but if that were the case then that would mean that they know more than you or I in this matter. I thought you said "The company's BOD are some really smart folks and I agree with their findings". A decision is a decision but a decision reached after consultation and research is an informed decision.
So, do you have any interest in future projects that would implement the assembly language approach you mentioned?
Discovery
I don't understand why you think that Jason's code implements a LIFO. It looks like a FIFO to me. His code reads the file sequentially into a circular buffer. The read cog processes the circular buffer in the same order. Assuming the file was written in the correct order the output will be in the correct order.
Maintaining this program should be easy for anybody that understands C. It's a very small program, and it is extremely easy to follow. I don't understand the problem here.
Maybe the C++ aspect of Jason's code is confusing you. However, it is really just C code with a few C++ features that make it slightly cleaner. This can easily be converted to pure C if that's the problem you're having.
I don't understand what computer configuration you have that prevents you from compiling the code. This should work on any Windows machine you would have at your company. All you have to do is install SimpleIDE on the computer and open the SIDE file that Jason posted.
What kind of simplification factor do you need to develop the code on SimpleIDE.
If your company's BOD are really smart folks they shouldn't have any problems understanding how easy this is to implement on the Prop in C using SimpleIDE?
BTW, I ran some test with FSRW and was able to read sequential sectors at 880 kB/s. That's 1.76 million nybbles/second. I converted the FSRW Spin code to C and got the same results. I didn't try the standard PropGCC file drives, but they will be somewhat slower than FSRW. However, they could be sped up if the low-level driver routines are called directly instead of going through stdio.
Discovery
In addition you can mention to the BOD, that Tachyon running on Peter's IOT5500+P8 will just need an Ethernet cable to give remote access for troubleshooting with interactive console and Telnet as well as FTP and WebServer .. - all while the machine is running ...
I even made the webserver scriptable in a previous version of Tachyon
I am curious since the line in your SDTest program includes
const int DO = 22, CLK = 23, DI = 24, CS = 25;
If this line is removed, how will the compiler know how to use your instruction
sd_mount(DO, CLK, DI, CS); ?
MJB...my company does not have personnel with expertise in the disciplines you mentioned that is why Jason's approach is the most attractive.
I will be out of communication for the next few days.
Discovery
Jason and Dave...After making all the changes that are in Jason's "C" project above, the project compiled correctly.
Thank you Jason. Now to generate coordinate data and run tests.
Discovery
I was expecting 1,000 bytes of data driving the output pins p0-p3.
Discovery
FYI
Discovery
I read the same sheet, but that number means nothing if your motor won't spin at the speed that step frequency corresponds to. Part of the reason I was pressing on the project requirements was exactly this - It's a common mistake to read a sheet and immediately start planning based on raw technical specs, but that's only half the picture. Lots of mechanical systems are constrained more by physical limits than technical ones.
As for the missing outputs, without seeing your code changes it's impossible to say.
My first guess is that this code stops when it's done reading the file. If you only put 1000 bytes of data into it, at 53khz that will last you exactly 1/53rd of a second - if you don't have some kind of capture scope connected, and you aren't slowing down the output frequency, you've probably just missed it.
It's worth mentioning that I didn't actually *test* the P0-P3 output, so the first thing you should do is just put a moderately large file in the root of the SD card called "testdata.txt", connect the ActivityBoard to a scope, and run the original code. If you don't see output from that, you know the original version didn't work either. If you *do* see output, then the issue is with whatever was changed / added, or the teeny file problem.
The 0123... output is just a "progress tick" to show you the code is still doing something (same with the blinking LED). In fact, since you didn't mention that, *is* the LED still blinking? If it isn't, that means the code that's outputting the data to the pins isn't running.
You didn't write 1000 zero's to the file, did you?
void OutputDataThread(void *par);
where the data should be output at 53 kHz.
To verify, I put a print statement in your subroutine and sure enough...it is not invoked.
p0, p1, p2, p3 are not responding.
Discovery
It doesn't "call" that function - it launches a cog that does, so it runs independently on another hardware thread.
You shouldn't print from that thread or you'll likely cause all kinds of problems. Two independent cogs (hardware threads) attempting to print to the same device at the same time is not safe, unless that object is thread-safe, and I doubt it is. It's also not fast enough to put in the loop that's supposed to run at 53khz, so if you add a lot of additional work in that output loop it'll most likely stall.
The reason the output loop will stall is this:
// add however long we need to wait to the clock tick number clockTick += OutputDelay; // wait until that time arrives waitcnt( clockTick );Now, you could add code to check if that time had already gone by, and if so, skip waiting, but then your "with no jitter" requirement is out the window.
I suspect that ultimately you're going to need to use something like a Raspberry Pi or Cortex M4 chip. The Prop isn't a terribly forgiving device if you don't have some idea of what you're doing.
Over the last few days, I made some changes to my Plasma Cutter "C" code, cut two traces on the printed wire board, and added two wires to the printed circuit board. The result is that the ClearPath motors are now clocked at 29.5859 kHz moving the cutting head at 138 inches per minute and having a computed step precision of 78 micro inches. It can cut a 1/8" rectangular sheet of steel (8" by 10") in about 15 seconds. The machine falls short of cutting really thin sheet metal but right now it cuts 90% of the materials I use most often.
With these changes I call the Plasma Cutter upgrade project completed. And I would like to thank everyone who contributed to its success.
Sincerely,
Discovery
The pathway was unusual, but the outcome was more usual