PropWare Cogc_Demo.cpp
AS
Posts: 149
in Propeller 1
David Zemon, I need you help with this issue. Thanks a lot!
2 Questions:
I have a error when trying "make" this "Cogc" example:
I don´t have the CMAKE compiler? is everything compiling ok!! need other?
Where is called the file "blinky.cogcpp" from the file "Cogc_Demo.cpp"? How you do that? :P
The example is for blinky two leds in separate PIN´s, P16 (main Cog) and P23 (new cog). ok! :thumb:
2 Questions:
I have a error when trying "make" this "Cogc" example:
pi@raspberrypi:~/PropellerProjects/PropWare/Examples/Cogc/bin $ make Scanning dependencies of target Cogc_Demo [ 33%] Building CXX object CMakeFiles/Cogc_Demo.dir/Cogc_Demo.cpp.obj [ 66%] Building COGCXX object CMakeFiles/Cogc_Demo.dir/blinky.cogcpp.cog make[2]: CMAKE_C_COMPILER: Command not found CMakeFiles/Cogc_Demo.dir/build.make:86: recipe for target 'CMakeFiles/Cogc_Demo.dir/blinky.cogcpp.cog' failed make[2]: *** [CMakeFiles/Cogc_Demo.dir/blinky.cogcpp.cog] Error 127 CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/Cogc_Demo.dir/all' failed make[1]: *** [CMakeFiles/Cogc_Demo.dir/all] Error 2 Makefile:94: recipe for target 'all' failed make: *** [all] Error 2
I don´t have the CMAKE compiler? is everything compiling ok!! need other?
Where is called the file "blinky.cogcpp" from the file "Cogc_Demo.cpp"? How you do that? :P
The example is for blinky two leds in separate PIN´s, P16 (main Cog) and P23 (new cog). ok! :thumb:
Comments
And provide the output. That will help me figure out what is wrong. Along with that, also please create a zip of the entire ~/PropellerProjects/PropWare/Examples/Cogc directory and post that here.
the files go attached
thanks!
and this time provide all of the output (all three commands) instead of just the make command. No need for the zip this time around.
the output is:
How you do to "call" the "blinky.cogcpp" from the "Cogc_Demo.cpp" ?
Creating a it will "call" the "blinky.cogcpp"?
Where you define the size of the stack cog? You use the [cog] model memory it will be 2kb per cog, don´t need define stack?
The linker automagically generates a symbol called "load_start_<your file>_cog" and it points to a binary blob in your program. That binary blob is the compiled output of <your_file>.cogc or <your_file>.cogcpp depending on whether it is C or C++
I suspected something like that, but is not usual for a definition of a file :P
I already see that you have some examples of "cogs", I will try for sure.
But one last question (for now):
Where you define the size of the stack cog? You use the [cog] model memory it will be 2kb per cog, don´t need define stack in this case?
If you use other memory model? (I will see your examples)
I want a robust solution to understand almost everything about the propeller cogs. :P essencial in Propeller
Sorry, I know you asked that question earlier and I completely forgot to answer it.
A stack is not provided in COG mode. HUB memory is not accessible (except through direct use of HUB instructions like rdlong) in COG mode so your only memory is what is available in the COG's 2kB of local memory. This is why is it has a very limited use case, but it's fantastic for writing little drivers and such. COG memory model works along the same principles as PASM code in a Spin file - it is completely independent of the rest of the code and carries none of the high-level features provided by the calling language such as stacks/heaps/etc. You're getting native assembly... but at the high price of developer time.
I need make some experiences!
Really thanks!
PropGCC also always has a stack, although frequently the optimizer can keep variables in memory and not in the stack. The address of the stack is passed to a new COGC program in the PAR register. The size of the stack has to be set by the programmer. Some COGC programs won't need any stack at all, some might need a few dozen bytes; it's rare for any to need more than 100 bytes (unless they're calling printf or some similar complicated function).
You can reduce the need for a stack by declaring functions as _NATIVE (so they don't need to save their return address on the stack before calling other functions) and by using variables explicitly declared as _COGMEM (so they get stored in COG memory rather than HUB).
OH! That's very interesting. Thanks for the detailed info