@ersmith said:
@enorton there is a new version of FlexProp available now (6.1.0) which has support for very simple multi-file projects. A project file is just a text file containing a list of the files to compile, along with any definitions to be made a compile time. That may be sufficient for what you're doing.
@JRoark said:
Why do you think the Prop2 wont do I2C easily? Because it lacks “textbook” open-collector outputs?
Not so fast: The I2C bus has pull-ups to Vcc. For I2C you can either yank the P2 output pin to ground for a zero, or let it float for a one. You knew that, but you may have missed the ability for the P2 to float an output.
I’m doing I2C from FlexBASIC using PINLO(n) or PINFLOAT(n) and bit-bashing along at better than 1mhz without even trying. And kids… if I can do it…. Well… lets just say I think you’re probably a whole bunch smarter than I am, which tells me you just havent set your mind to it yet. 😁
I am sure it will do I2C very easily I am just a noob at this chip and seeing as how I just got the development board and started working with it last Thursday, I think I am doing ok so far. The IO legend is a bit confusing in the datasheet but that could be my own stupidity not seeing things the way it is supposed to be read. Ill get it but things take time for me and haven't reached my aha moment yet... more like blonde moments
@iseries said:
I have all my libraries on github that include spi, and i2c. as well as serial. They were built for flex prop though so you would need to maybe convert them for use with Catalina.
Ha! Very nice set of libraries - I just compiled a couple (i2c and spi) with Catalina, and all it took was a couple of trivial changes to make your C code ANSI compliant.
So, @enorton, I believe that's the last hurdle down!
Ross.
Oh REALLY :_D ??? Is it a new version of Catalina Geany I can download?
You don't need a new version of either Catalina or Geany - at least not yet**. You can just create your own libraries from Mike's code and then use them. If Mike doesn't want to make his code ANSI compliant then let me know which components you need, and I will do some to show you how to do it. It generally only requires changing a few lines of code.
** I may eventually need to tweak Catalina's assembler to accommodate a larger symbol table. I will do some experiments to see how large I can make it, since you will probably need it to compile the full 89000 lines. But, as others have suggested, start small and make sure the Propeller is up to the task first.
@iseries said:
I have all my libraries on github that include spi, and i2c. as well as serial. They were built for flex prop though so you would need to maybe convert them for use with Catalina.
Ha! Very nice set of libraries - I just compiled a couple (i2c and spi) with Catalina, and all it took was a couple of trivial changes to make your C code ANSI compliant.
So, @enorton, I believe that's the last hurdle down!
Ross.
Oh REALLY :_D ??? Is it a new version of Catalina Geany I can download?
You don't need a new version of either Catalina or Geany - at least not yet**. You can just create your own libraries from Mike's code and then use them. If Mike doesn't want to make his code ANSI compliant then let me know which components you need, and I will do some to show you how to do it. It generally only requires changing a few lines of code.
** I may eventually need to tweak Catalina's assembler to accommodate a larger symbol table. I will do some experiments to see how large I can make it, since you will probably need it to compile the full 89000 lines. But, as others have suggested, start small and make sure the Propeller is up to the task first.
Ross.
Ok well, I will port his I2C library over and see how that goes. I did notice that he uses usleep() which isn't part of the P2 libraries unless I am missing something? I know it is a microsecond delay and just don't see it anywhere. Also, I don't see the SPI library but will continue to look for it as I will need it at some point. I know there is the _waitus(uint32_t usecs); function but that is way off. Is there a minimum microsecond delay value for this microsecond function before it becomes accurate?
I will start porting over the code slowly and see how it goes. The serial and eeprom control and the system state machine are the first to port over and then I will test to see how that goes and report back.
@iseries said:
I have all my libraries on github that include spi, and i2c. as well as serial. They were built for flex prop though so you would need to maybe convert them for use with Catalina.
Ha! Very nice set of libraries - I just compiled a couple (i2c and spi) with Catalina, and all it took was a couple of trivial changes to make your C code ANSI compliant.
So, @enorton, I believe that's the last hurdle down!
Ross.
Oh REALLY :_D ??? Is it a new version of Catalina Geany I can download?
You don't need a new version of either Catalina or Geany - at least not yet**. You can just create your own libraries from Mike's code and then use them. If Mike doesn't want to make his code ANSI compliant then let me know which components you need, and I will do some to show you how to do it. It generally only requires changing a few lines of code.
** I may eventually need to tweak Catalina's assembler to accommodate a larger symbol table. I will do some experiments to see how large I can make it, since you will probably need it to compile the full 89000 lines. But, as others have suggested, start small and make sure the Propeller is up to the task first.
Ross.
One thing that concerns me is how am I going to stream the buffered data from the UART cog to the next cog and then from the processing cog to the stepper logic cog? Is this going to be stored in the hub RAM or does the program code go into the hub RAM only? I have some rather large structs of data that get passed from the motion planner to the stepper control processing logic in a ring buffer fashion. This is not to be confused with standard Grbl as this is another way of doing servo-based motion control with six-point and trapezoid curves etc. and true SPI motion control so that needs to be fast...
@enorton
So you are controlling steppers or servos or both? Steppers are open or closed loop?
What is the update rate of the motion planner and what is the PID loop rate?
On-the-fly accel/decel changes with/without s-curve?
What is "true SPI motion control"?
Craig
Edit: P2 is the most capable motion control processor, ever created....just needs firmware.
Ok well, I will port his I2C library over and see how that goes. I did notice that he uses usleep() which isn't part of the P2 libraries unless I am missing something?
Porting the i2c library is trivial. Here is what I did:
Unpack the P2Custom library to a suitable subdirectory (I called mine P2Custom-catalina)
modify i2c.h to add the following line somewhere near the top:
#define __fromfile(x)
compile the i2c library as follows (note the definition of usleep on the catalina command line - or you could add a suitable line to the file i2c.h):
cd P2Custom-catalina\libi2c
catalina -p2 -S -I.. *.c -D"usleep=_waitus"
catbind -i -e *.s -o catalina.index
cd ..
That's it! You now have a Catalina i2c library in subdirectory libi2c. I compiled a simple program to use the library (but did not test it):
#include "i2c.h"
void main() {
int scl;
int sda;
int spd;
i2c_t *x;
int b;
I2C_Init(scl, sda, spd);
I2C_Start(x);
I2C_WriteByte(x, b);
}
Create that file (I called it test_i2c.c) in P2Custom-catalina, then compile it with the command (note the -li2c on the catalina command line):
cd P2Custom-catalina
catalina -p2 -lc -li2c test_i2c.c
@enorton said:
I know it is a microsecond delay and just don't see it anywhere. Also, I don't see the SPI library but will continue to look for it as I will need it at some point. I know there is the _waitus(uint32_t usecs); function but that is way off. Is there a minimum microsecond delay value for this microsecond function before it becomes accurate?
The _waitus() function is ok for most purposes, but for very small timeouts it may not be accurate because it has to calculate the number of clock ticks to wait "on the fly" - i.e. it does _waitx(us*(_clockfreq()/1000000)). But for higher accuracy you can pre-calculate the number of clock ticks then just call _waitx() directly.
There is no generic SPI library AFAIK, but there are SPI access routines in (for example) the flash library.
Porting the flash library is almost as trivial as porting the i2c library, but there are a couple of instances of non-ANSI constructs like:
for (int i = 0; i < max; i++) {
...
}
That have to be translated to their ANSI equivalent:
One thing that concerns me is how am I going to stream the buffered data from the UART cog to the next cog and then from the processing cog to the stepper logic cog? Is this going to be stored in the hub RAM or does the program code go into the hub RAM only? I have some rather large structs of data that get passed from the motion planner to the stepper control processing logic in a ring buffer fashion. This is not to be confused with standard Grbl as this is another way of doing servo-based motion control with six-point and trapezoid curves etc. and true SPI motion control so that needs to be fast...
Simplest method is to use Hub RAM. Except in special cases, Catalina uses Hub RAM for both code and data (and also for the stack and heap). I don't think you will have a problem.
@Mickster said:
@enorton
So you are controlling steppers or servos or both? Steppers are open or closed loop?
What is the update rate of the motion planner and what is the PID loop rate?
On-the-fly accel/decel changes with/without s-curve?
What is "true SPI motion control"?
Craig
Edit: P2 is the most capable motion control processor, ever created....just needs firmware.
Both BLDC and stepper in closed loop with encoder feedback. Yes, on the fly acceleration and deceleration with or without s-curve or you can set it statically as a setting per axis up to nine axis control.
I don't use step and direction. I found a way to tightly syncronize multiple motion controllers via spi control and that's all I can say.
I originally had four risc v processors planned and was going to do all of this in an fpga but that solution is very expensive and I hate bga devices. The P2 is a neat device if I can just figure out the small details... I like the fact I can see the pins of the device and do solder touch ups if a pin didn't reflow fully...
Ok well, I will port his I2C library over and see how that goes. I did notice that he uses usleep() which isn't part of the P2 libraries unless I am missing something?
Porting the i2c library is trivial. Here is what I did:
Unpack the P2Custom library to a suitable subdirectory (I called mine P2Custom-catalina)
modify i2c.h to add the following line somewhere near the top:
#define __fromfile(x)
compile the i2c library as follows (note the definition of usleep on the catalina command line - or you could add a suitable line to the file i2c.h):
cd P2Custom-catalina\libi2c
catalina -p2 -S -I.. *.c -D"usleep=_waitus"
catbind -i -e *.s -o catalina.index
cd ..
That's it! You now have a Catalina i2c library in subdirectory libi2c. I compiled a simple program to use the library (but did not test it):
#include "i2c.h"
void main() {
int scl;
int sda;
int spd;
i2c_t *x;
int b;
I2C_Init(scl, sda, spd);
I2C_Start(x);
I2C_WriteByte(x, b);
}
Create that file (I called it test_i2c.c) in P2Custom-catalina, then compile it with the command (note the -li2c on the catalina command line):
cd P2Custom-catalina
catalina -p2 -lc -li2c test_i2c.c
@enorton said:
I know it is a microsecond delay and just don't see it anywhere. Also, I don't see the SPI library but will continue to look for it as I will need it at some point. I know there is the _waitus(uint32_t usecs); function but that is way off. Is there a minimum microsecond delay value for this microsecond function before it becomes accurate?
The _waitus() function is ok for most purposes, but for very small timeouts it may not be accurate because it has to calculate the number of clock ticks to wait "on the fly" - i.e. it does _waitx(us*(_clockfreq()/1000000)). But for higher accuracy you can pre-calculate the number of clock ticks then just call _waitx() directly.
There is no generic SPI library AFAIK, but there are SPI access routines in (for example) the flash library.
Porting the flash library is almost as trivial as porting the i2c library, but there are a couple of instances of non-ANSI constructs like:
for (int i = 0; i < max; i++) {
...
}
That have to be translated to their ANSI equivalent:
{
int i;
for (i = 0; i < max; i++) {
...
}
}
Ross.
This is awesome :-). Thank you Ross :-D. It's late but will try this later and let you know.
Not a fan, either. Torque limiting needs to be handled externally whereas good ol' +/-10v not only provides full control but also reflects the loading on the motor. Still the best way to go, IMO.
I had considered twelve axes/P2 but since the mid-90's, dual-loop feedback has kinda become a must-have for me and so I have scaled-back to six axes, each with a main and auxiliary encoder input.
89k including comments. Actual lines of C code are about 80k but as I said earlier it will likely grow. I'm not worried about that much at the moment.
I would be worried about if this will all fit inside P2.
@enorton said:
XMOS is better aligned with what I want to do. My application requires high-speed and reliable protocols that I don't have to spend hours trying to figure out how to create. ...
I was able to create what I needed in the XMOS IDE and it took me less than a few hours to do.
What binary size resulted from your XMOS build ?
What binary size and what MCU do you currently run this code on ?
Wait, really? How come your compiler doesn't support C99?
Catalina is an ANSI C compiler.
As long as we're being pedantic: Catalina supports the obsolete ANSI standard ANSI X3.159-1989. That standard has long since been superseded and is no longer an ANSI standard (you can't buy it from ANSI, for example). It was replaced by various ISO standards (ANSI being the American standards body which participates in the international ISO). The current ANSI standard for the C programming language is ISO/IEC 9899:2018 ("C17"), at least according to the ANSI blog at https://blog.ansi.org/?p=8147 and also according to Wikipedia.
So it would be clearer and less confusing if you referred to the language supported by Catalina as "C89" or "ANSI C89" (or even "Original ANSI C").
So it would be clearer and less confusing if you referred to the language supported by Catalina as "C89" or "ANSI C89" (or even "Original ANSI C").
You want confusing? ANSI C, ISO C, C89, C90, ANSI X3.159-1989, ISO/IEC 9899:1990, "Standard C" and "Clean C" all refer to essentially the same language.
ANSI C is probably the simplest, commonest and best understood term, although "Standard C" now seems to be becoming increasingly popular.
"The first standard for C was published by ANSI. Although this document was subsequently adopted by ISO/IEC and subsequent revisions published by ISO/IEC have been adopted by ANSI, "ANSI C" is still used to refer to the standard. While some software developers use the term ISO C, others are standards-body neutral and use Standard C. "
This version of C is important because it is the only version of C supported by all modern C and C++ compilers. If you want to write "portable" C code, this is the version of the language you should use. This is unlikely to change any time soon.
"C89 is supported by current C compilers, and most modern C code is based on it. Any program written only in Standard C and without any hardware-dependent assumptions will run correctly on any platform with a conforming C implementation, within its resource limits. Without such precautions, programs may compile only on a certain platform or with a particular compiler, due, for example, to the use of non-standard libraries, such as GUI libraries, or to a reliance on compiler- or platform-specific attributes such as the exact size of data types and byte endianness. "
So, I could switch to "Standard C" if people thought that would be less confusing. But speaking for myself, I think it would have the opposite effect.
But perhaps we should start a new topic for this? It has nothing to do with this one.
Which of the standards the compilers support may very much be relevant to @enorton if the C code they're using is less than 30 years old and follows standards that are actually still standards (as opposed to obsolete or superseded standards). For that reason I think it's useful to clearly label which ANSI C standard your compiler is trying to follow. Catalina is C89, FlexC is C99, clang is C17, and propgcc is ?? (probably C11). And of course none of these compilers strictly speaking follow the standard to the letter (which among other things requires a bunch of documentation that they're all lacking). But broadly speaking the newer one's C code, the more likely it is to require features from a newer standard.
@ersmith said:
For that reason I think it's useful to clearly label which ANSI C standard your compiler is trying to follow.
Everyone knows what "ANSI C" means. That's why the term is still in common use.
ANSI C. ISO C. C89. C90. Standard C. Clean C. They all represent essentially the same language with a difference in name only, with ANSI C being the original and probably still the most widely recognized term. I don't really see any need to change it, but if I did I would probably opt for Standard C as being another widely used (and perhaps more current) term for the same thing.
And of course none of these compilers strictly speaking follow the standard to the letter (which among other things requires a bunch of documentation that they're all lacking).
I am not aware of anything required by the ANSI C standard that Catalina lacks. If you know of something missing, let me know and I will add it. Catalina does have a few "additions" from later C standards (some of the more useful libraries etc), but this is not the same thing since you don't have to use them if you don't want to.
But perhaps you could do so on another thread. We should not continue to derail this one.
One thing that concerns me is how am I going to stream the buffered data from the UART cog to the next cog and then from the processing cog to the stepper logic cog? Is this going to be stored in the hub RAM or does the program code go into the hub RAM only? I have some rather large structs of data that get passed from the motion planner to the stepper control processing logic in a ring buffer fashion. This is not to be confused with standard Grbl as this is another way of doing servo-based motion control with six-point and trapezoid curves etc. and true SPI motion control so that needs to be fast...
Simplest method is to use Hub RAM. Except in special cases, Catalina uses Hub RAM for both code and data (and also for the stack and heap). I don't think you will have a problem.
Ross.
I ported all the files over to the project but have a bunch of Undefined or Redefined symbols and get warning unreachable code. How do I link all the files together in Catalina Geany? I have a master header file that has all the headers of all the other files. Any help would be great :-D
I ported all the files over to the project but have a bunch of Undefined or Redefined symbols and get warning unreachable code. How do I link all the files together in Catalina Geany? I have a master header file that has all the headers of all the other files. Any help would be great :-D
Thanks,
Eric
Not really enough information to answer. Can you post the actual Catalina command Geany executed and the output it produced? Or at least an extract?
As for the undefined/redefined symbols, let's start with just one symbol and try and track down the problem. Choose a simple one that you know where it is defined and used, and post an extract of the files (if not the whole files) that use and/or define it?
Unreachable code is probably exactly that. Some compilers may detect this, while others may not.
I ported all the files over to the project but have a bunch of Undefined or Redefined symbols and get warning unreachable code. How do I link all the files together in Catalina Geany? I have a master header file that has all the headers of all the other files. Any help would be great :-D
Thanks,
Eric
Not really enough information to answer. Can you post the actual Catalina command Geany executed and the output it produced? Or at least an extract?
As for the undefined/redefined symbols, let's start with just one symbol and try and track down the problem. Choose a simple one that you know where it is defined and used, and post an extract of the files (if not the whole files) that use and/or define it?
Unreachable code is probably exactly that. Some compilers may detect this, while others may not.
Ross.
I was afraid you would ask those questions. Due to the nature of the project, I cannot disclose too much information as this forum is public and searchable on the net. What I have done is created all sixty-seven header and c files and stored them in the project folder. One header file lists all the other header files. Here is an example:
ifndef m_controller_h
define m_controller_h
// Standard Libraries
include <propeller2.h>
include <math.h>
include <inttypes.h>
include <string.h>
include <stdlib.h>
include <stdint.h>
include <stdbool.h>
// System include files
include <file1.h>
include <file2.h>
include <file3.h>
.......
endif
/* [] END OF FILE */
Then for each C file, I include this at the top:
include <m_controller.h>
This way I can access all of the functions scattered throughout all of the C files within the project.
The first warning is: main.c:112: warning: unreachable code which points to return 0 at the end of main.
I know this doesn't give too much information, but it helps disclose what I am doing.
I have done the above in Keil, Eclipse, and PSOC Creator with no problems, and want to know why it doesn't work for Catalina Geany. How do I link them all together so the project as a whole compiles?
89k including comments. Actual lines of C code are about 80k but as I said earlier it will likely grow. I'm not worried about that much at the moment.
I would be worried about if this will all fit inside P2.
@enorton said:
XMOS is better aligned with what I want to do. My application requires high-speed and reliable protocols that I don't have to spend hours trying to figure out how to create. ...
I was able to create what I needed in the XMOS IDE and it took me less than a few hours to do.
What binary size resulted from your XMOS build ?
What binary size and what MCU do you currently run this code on ?
I have not tried the XMOS device as I am trying like hell to get the propeller chip to work. I currently run my code on the STM32H723 high-performance microcontroller. It is 550 MHz and runs ok but bogs down when data gets heavy which has been the case for other micros as well. I am hoping with extra processors I can take some of the load off the main processor by sharing the load...
89k including comments. Actual lines of C code are about 80k but as I said earlier it will likely grow. I'm not worried about that much at the moment.
I would be worried about if this will all fit inside P2.
@enorton said:
XMOS is better aligned with what I want to do. My application requires high-speed and reliable protocols that I don't have to spend hours trying to figure out how to create. ...
I was able to create what I needed in the XMOS IDE and it took me less than a few hours to do.
What binary size resulted from your XMOS build ?
What binary size and what MCU do you currently run this code on ?
Sorry, forgot to mention the code size on the current chip STM32H723 which is a little under 180k
I have done the above in Keil, Eclipse, and PSOC Creator with no problems, and want to know why it doesn't work for Catalina Geany. How do I link them all together so the project as a whole compiles?
What you are doing looks fine in general. Except perhaps that you should be saying #include "m_controller.h" instead of #include <m_controller.h> if the file m_controller.h is in the local (project) directory. Some compilers are less picky about this than Catalina - with Catalina you must use "file.h" for local include files - <file.h> works only for system include files. But you should see messages something like "Could not find include file <file.h>" in such cases.
Next, to compile a project containing multiple source files, you must first use the Geany command Compile All and then Link All - if you just say Build File then Geany assumes your program consists of only the currently selected file, and will compile and link only that file. This is probably why you are getting undefined symbols.
I have done the above in Keil, Eclipse, and PSOC Creator with no problems, and want to know why it doesn't work for Catalina Geany. How do I link them all together so the project as a whole compiles?
What you are doing looks fine in general. Except perhaps that you should be saying #include "m_controller.h" instead of #include <m_controller.h> if the file m_controller.h is in the local (project) directory. Some compilers are less picky about this than Catalina - with Catalina you must use "file.h" for local include files - <file.h> works only for system include files. But you should see messages something like "Could not find include file <file.h>" in such cases.
Next, to compile a project containing multiple source files, you must first use the Geany command Compile All and then Link All - if you just say Build File then Geany assumes your program consists of only the currently selected file, and will compile and link only that file. This is probably why you are getting undefined symbols.
Ross.
Ok phew, I thought I was doing something wrong, and it was a matter of just building the current file not compiling the whole project :-D. Good catch!!
I changed all the "local" includes to "" instead of <>.
By the way I got the I2C working. I can write and read the eeprom.
I just want to take time out and thank each and every one of you for helping me through this. I know you all have better things to do than to help me. Helping me and encouraging me to keep going has given me hope to be able to use the Propeller 2 chip for my project and finally achieve something I have been dreaming about for the past two years. I have created such a sophisticated project and it is almost a reality. Thanks again for all your support it is truly appreciated
Oh, and one more Geany quirk - you not only have to have a project open, but you have to have a C file selected in Geany to see the appropriate commands on the Build menu - and Geany will name the executable according to the name of the file you have selected.
For instance, suppose your project has the following files:
file.h
file1.c
file2.c
program.c
Then you must have either file1.c, file2.c or program.c open and selected to be able to build the project. If you have file.h open and selected instead, you won't even see the Build All or Link All commands in the Build menu. Also, if you have program.c selected, Geany will name the compiled output program.bin, but if you have file1.c selected, Geany will name the compiled output file1.bin.
@RossH said:
Oh, and one more Geany quirk - you not only have to have a project open, but you have to have a C file selected in Geany to see the appropriate commands on the Build menu - and Geany will name the executable according to the name of the file you have selected.
For instance, suppose your project has the following files:
file.h
file1.c
file2.c
program.c
Then you must have either file1.c, file2.c or program.c open and selected to be able to build the project. If you have file.h open and selected instead, you won't even see the Build All or Link All commands in the Build menu. Also, if you have program.c selected, Geany will name the compiled output program.bin, but if you have file1.c selected, Geany will name the compiled output file1.bin.
Silly, I know. That's Geany.
Ross.
oh wow ok thanks for pointing that out to me :-)
Btw here are the screenshots of the i2c transactions:
@RossH said:
Oh, and one more Geany quirk - you not only have to have a project open, but you have to have a C file selected in Geany to see the appropriate commands on the Build menu - and Geany will name the executable according to the name of the file you have selected.
For instance, suppose your project has the following files:
file.h
file1.c
file2.c
program.c
Then you must have either file1.c, file2.c or program.c open and selected to be able to build the project. If you have file.h open and selected instead, you won't even see the Build All or Link All commands in the Build menu. Also, if you have program.c selected, Geany will name the compiled output program.bin, but if you have file1.c selected, Geany will name the compiled output file1.bin.
Silly, I know. That's Geany.
Ross.
The eeprom code works great now. Once I get all the errors taken care of in the code I will start working on getting SPI sorted out. I ended up having to modify some of the i2c code for my purposes. All in all I am a happy camper :-)
Comments
Hmm very interesting. I will check this out....
I am sure it will do I2C very easily I am just a noob at this chip and seeing as how I just got the development board and started working with it last Thursday, I think I am doing ok so far. The IO legend is a bit confusing in the datasheet but that could be my own stupidity not seeing things the way it is supposed to be read. Ill get it but things take time for me and haven't reached my aha moment yet... more like blonde moments
You don't need a new version of either Catalina or Geany - at least not yet**. You can just create your own libraries from Mike's code and then use them. If Mike doesn't want to make his code ANSI compliant then let me know which components you need, and I will do some to show you how to do it. It generally only requires changing a few lines of code.
** I may eventually need to tweak Catalina's assembler to accommodate a larger symbol table. I will do some experiments to see how large I can make it, since you will probably need it to compile the full 89000 lines. But, as others have suggested, start small and make sure the Propeller is up to the task first.
Ross.
Ok well, I will port his I2C library over and see how that goes. I did notice that he uses usleep() which isn't part of the P2 libraries unless I am missing something? I know it is a microsecond delay and just don't see it anywhere. Also, I don't see the SPI library but will continue to look for it as I will need it at some point. I know there is the _waitus(uint32_t usecs); function but that is way off. Is there a minimum microsecond delay value for this microsecond function before it becomes accurate?
I will start porting over the code slowly and see how it goes. The serial and eeprom control and the system state machine are the first to port over and then I will test to see how that goes and report back.
Thanks,
Eric
One thing that concerns me is how am I going to stream the buffered data from the UART cog to the next cog and then from the processing cog to the stepper logic cog? Is this going to be stored in the hub RAM or does the program code go into the hub RAM only? I have some rather large structs of data that get passed from the motion planner to the stepper control processing logic in a ring buffer fashion. This is not to be confused with standard Grbl as this is another way of doing servo-based motion control with six-point and trapezoid curves etc. and true SPI motion control so that needs to be fast...
@enorton
So you are controlling steppers or servos or both? Steppers are open or closed loop?
What is the update rate of the motion planner and what is the PID loop rate?
On-the-fly accel/decel changes with/without s-curve?
What is "true SPI motion control"?
Craig
Edit: P2 is the most capable motion control processor, ever created....just needs firmware.
Porting the i2c library is trivial. Here is what I did:
#include "i2c.h" void main() { int scl; int sda; int spd; i2c_t *x; int b; I2C_Init(scl, sda, spd); I2C_Start(x); I2C_WriteByte(x, b); }The _waitus() function is ok for most purposes, but for very small timeouts it may not be accurate because it has to calculate the number of clock ticks to wait "on the fly" - i.e. it does _waitx(us*(_clockfreq()/1000000)). But for higher accuracy you can pre-calculate the number of clock ticks then just call _waitx() directly.
There is no generic SPI library AFAIK, but there are SPI access routines in (for example) the flash library.
Porting the flash library is almost as trivial as porting the i2c library, but there are a couple of instances of non-ANSI constructs like:
for (int i = 0; i < max; i++) { ... }That have to be translated to their ANSI equivalent:
{ int i; for (i = 0; i < max; i++) { ... } }Ross.
Simplest method is to use Hub RAM. Except in special cases, Catalina uses Hub RAM for both code and data (and also for the stack and heap). I don't think you will have a problem.
Ross.
Both BLDC and stepper in closed loop with encoder feedback. Yes, on the fly acceleration and deceleration with or without s-curve or you can set it statically as a setting per axis up to nine axis control.
I don't use step and direction. I found a way to tightly syncronize multiple motion controllers via spi control and that's all I can say.
I originally had four risc v processors planned and was going to do all of this in an fpga but that solution is very expensive and I hate bga devices. The P2 is a neat device if I can just figure out the small details... I like the fact I can see the pins of the device and do solder touch ups if a pin didn't reflow fully...
This is awesome :-). Thank you Ross :-D. It's late but will try this later and let you know.
@enorton
Not a fan, either. Torque limiting needs to be handled externally whereas good ol' +/-10v not only provides full control but also reflects the loading on the motor. Still the best way to go, IMO.
Craig
@enorton
I had considered twelve axes/P2 but since the mid-90's, dual-loop feedback has kinda become a must-have for me and so I have scaled-back to six axes, each with a main and auxiliary encoder input.
Craig
Wait, really? How come your compiler doesn't support C99?
Catalina is an ANSI C compiler.
I would be worried about if this will all fit inside P2.
What binary size resulted from your XMOS build ?
What binary size and what MCU do you currently run this code on ?
As long as we're being pedantic: Catalina supports the obsolete ANSI standard ANSI X3.159-1989. That standard has long since been superseded and is no longer an ANSI standard (you can't buy it from ANSI, for example). It was replaced by various ISO standards (ANSI being the American standards body which participates in the international ISO). The current ANSI standard for the C programming language is ISO/IEC 9899:2018 ("C17"), at least according to the ANSI blog at https://blog.ansi.org/?p=8147 and also according to Wikipedia.
So it would be clearer and less confusing if you referred to the language supported by Catalina as "C89" or "ANSI C89" (or even "Original ANSI C").
You want confusing? ANSI C, ISO C, C89, C90, ANSI X3.159-1989, ISO/IEC 9899:1990, "Standard C" and "Clean C" all refer to essentially the same language.
ANSI C is probably the simplest, commonest and best understood term, although "Standard C" now seems to be becoming increasingly popular.
https://en.wikipedia.org/wiki/ANSI_C
"The first standard for C was published by ANSI. Although this document was subsequently adopted by ISO/IEC and subsequent revisions published by ISO/IEC have been adopted by ANSI, "ANSI C" is still used to refer to the standard. While some software developers use the term ISO C, others are standards-body neutral and use Standard C. "
This version of C is important because it is the only version of C supported by all modern C and C++ compilers. If you want to write "portable" C code, this is the version of the language you should use. This is unlikely to change any time soon.
https://en.wikipedia.org/wiki/C_(programming_language)
"C89 is supported by current C compilers, and most modern C code is based on it. Any program written only in Standard C and without any hardware-dependent assumptions will run correctly on any platform with a conforming C implementation, within its resource limits. Without such precautions, programs may compile only on a certain platform or with a particular compiler, due, for example, to the use of non-standard libraries, such as GUI libraries, or to a reliance on compiler- or platform-specific attributes such as the exact size of data types and byte endianness. "
So, I could switch to "Standard C" if people thought that would be less confusing. But speaking for myself, I think it would have the opposite effect.
But perhaps we should start a new topic for this? It has nothing to do with this one.
Ross.
Which of the standards the compilers support may very much be relevant to @enorton if the C code they're using is less than 30 years old and follows standards that are actually still standards (as opposed to obsolete or superseded standards). For that reason I think it's useful to clearly label which ANSI C standard your compiler is trying to follow. Catalina is C89, FlexC is C99, clang is C17, and propgcc is ?? (probably C11). And of course none of these compilers strictly speaking follow the standard to the letter (which among other things requires a bunch of documentation that they're all lacking). But broadly speaking the newer one's C code, the more likely it is to require features from a newer standard.
Everyone knows what "ANSI C" means. That's why the term is still in common use.
ANSI C. ISO C. C89. C90. Standard C. Clean C. They all represent essentially the same language with a difference in name only, with ANSI C being the original and probably still the most widely recognized term. I don't really see any need to change it, but if I did I would probably opt for Standard C as being another widely used (and perhaps more current) term for the same thing.
I am not aware of anything required by the ANSI C standard that Catalina lacks. If you know of something missing, let me know and I will add it. Catalina does have a few "additions" from later C standards (some of the more useful libraries etc), but this is not the same thing since you don't have to use them if you don't want to.
But perhaps you could do so on another thread. We should not continue to derail this one.
Ross.
I ported all the files over to the project but have a bunch of Undefined or Redefined symbols and get warning unreachable code. How do I link all the files together in Catalina Geany? I have a master header file that has all the headers of all the other files. Any help would be great :-D
Thanks,
Eric
Not really enough information to answer. Can you post the actual Catalina command Geany executed and the output it produced? Or at least an extract?
As for the undefined/redefined symbols, let's start with just one symbol and try and track down the problem. Choose a simple one that you know where it is defined and used, and post an extract of the files (if not the whole files) that use and/or define it?
Unreachable code is probably exactly that. Some compilers may detect this, while others may not.
Ross.
I was afraid you would ask those questions. Due to the nature of the project, I cannot disclose too much information as this forum is public and searchable on the net. What I have done is created all sixty-seven header and c files and stored them in the project folder. One header file lists all the other header files. Here is an example:
ifndef m_controller_h
define m_controller_h
// Standard Libraries
include <propeller2.h>
include <math.h>
include <inttypes.h>
include <string.h>
include <stdlib.h>
include <stdint.h>
include <stdbool.h>
// System include files
include <file1.h>
include <file2.h>
include <file3.h>
.......
endif
/* [] END OF FILE */
Then for each C file, I include this at the top:
include <m_controller.h>
This way I can access all of the functions scattered throughout all of the C files within the project.
The first warning is: main.c:112: warning: unreachable code which points to return 0 at the end of main.
Then I get:
Undefined or Redefined symbols:
Examples:
function1 undefined
function2 undefined
function3 undefined
....
I know this doesn't give too much information, but it helps disclose what I am doing.
I have done the above in Keil, Eclipse, and PSOC Creator with no problems, and want to know why it doesn't work for Catalina Geany. How do I link them all together so the project as a whole compiles?
I have not tried the XMOS device as I am trying like hell to get the propeller chip to work. I currently run my code on the STM32H723 high-performance microcontroller. It is 550 MHz and runs ok but bogs down when data gets heavy which has been the case for other micros as well. I am hoping with extra processors I can take some of the load off the main processor by sharing the load...
Sorry, forgot to mention the code size on the current chip STM32H723 which is a little under 180k
What you are doing looks fine in general. Except perhaps that you should be saying #include "m_controller.h" instead of #include <m_controller.h> if the file m_controller.h is in the local (project) directory. Some compilers are less picky about this than Catalina - with Catalina you must use "file.h" for local include files - <file.h> works only for system include files. But you should see messages something like "Could not find include file <file.h>" in such cases.
Next, to compile a project containing multiple source files, you must first use the Geany command Compile All and then Link All - if you just say Build File then Geany assumes your program consists of only the currently selected file, and will compile and link only that file. This is probably why you are getting undefined symbols.
Ross.
Ok phew, I thought I was doing something wrong, and it was a matter of just building the current file not compiling the whole project :-D. Good catch!!
I changed all the "local" includes to "" instead of <>.
By the way I got the I2C working. I can write and read the eeprom.
I just want to take time out and thank each and every one of you for helping me through this. I know you all have better things to do than to help me. Helping me and encouraging me to keep going has given me hope to be able to use the Propeller 2 chip for my project and finally achieve something I have been dreaming about for the past two years. I have created such a sophisticated project and it is almost a reality. Thanks again for all your support it is truly appreciated
Oh, and one more Geany quirk - you not only have to have a project open, but you have to have a C file selected in Geany to see the appropriate commands on the Build menu - and Geany will name the executable according to the name of the file you have selected.
For instance, suppose your project has the following files:
file.h
file1.c
file2.c
program.c
Then you must have either file1.c, file2.c or program.c open and selected to be able to build the project. If you have file.h open and selected instead, you won't even see the Build All or Link All commands in the Build menu. Also, if you have program.c selected, Geany will name the compiled output program.bin, but if you have file1.c selected, Geany will name the compiled output file1.bin.
Silly, I know. That's Geany.
Ross.
oh wow ok thanks for pointing that out to me :-)
Btw here are the screenshots of the i2c transactions:
The eeprom code works great now. Once I get all the errors taken care of in the code I will start working on getting SPI sorted out. I ended up having to modify some of the i2c code for my purposes. All in all I am a happy camper :-)