Sorry for all the questions. I've been using my own custom IDE with catalina for the last year but you have done so much brilliant work integrating catalina into code::blocks that I am now moving everything over to this program.
I'm running through the little tutorial in the document "codeblocks quickstart.rtf" and it is all working fine but I have a problem with the Tools menu. In the tutorial this has a whole lot of menus added, but on my new install of catalina code::blocks the Tools menu is blank (the only option is "configure tools..."). Does this get configured as part of the install? Or did I miss something with the install? Or is there a manual way to add those menus?
I think it might be catalina_tools.conf ?
It might be because the version I'm using was from a few months back. Worth a reinstall?
Also another question - say I'm experimenting with spin2cpp and it is generating lots of .h files. I've found by trial and error that the program compiles if I put these in c:\programfiles\catalina\include. But is that the best directory to put these files, or should they be in the demo directory or something?
Sorry for all the questions. I've been using my own custom IDE with catalina for the last year but you have done so much brilliant work integrating catalina into code::blocks that I am now moving everything over to this program.
I'm running through the little tutorial in the document "codeblocks quickstart.rtf" and it is all working fine but I have a problem with the Tools menu. In the tutorial this has a whole lot of menus added, but on my new install of catalina code::blocks the Tools menu is blank (the only option is "configure tools..."). Does this get configured as part of the install? Or did I miss something with the install? Or is there a manual way to add those menus?
I think it might be catalina_tools.conf ?
Many thanks in advance.
Yes, that happens if you installed Code::Blocks as a user other than the one currently logged in - the files containing the Tools menu configuration have been copied only into the AppData folder for that user, and need to be manually set up for any other users.
Try shutting down Code::Blocks, opening a Catalina command line window and executing the following command:
Reset_Codeblocks
Then restart Code::Blocks. The Tools menu should be correctly displayed. You can repeat this for any other user accounts on the machine as well.
And the output from Spin2c for that hello world demo is compiling with no errors. Now to test a download...
Almost there. Getting garbled ascii characters on the debug screen and I think it is because way back I had the baud rate set slower. Doing a new install of version 3.10 now as the version I have is a bit out of date now. Saving that old homespun file though as I'll be needing that.
All very exciting - all the bits seem to be working separately and I think it is getting close to running the output of a spin2c program.
Also another question - say I'm experimenting with spin2cpp and it is generating lots of .h files. I've found by trial and error that the program compiles if I put these in c:\programfiles\catalina\include. But is that the best directory to put these files, or should they be in the demo directory or something?
Don't put them in the catalina include directory! That's intended for the header files that go with Catalina's library. The .h files generated by spin2cpp should go in the same directory as the .c files generated by it -- they go together.
Getting closer. I had the program compiling but now it won't compile again. Not sure why. It says that fullduplexserial_start is undefined.
Tracing through the links, main.h is included, and this includes fullduplexserial.h and that includes fullduplexserial.c
I probably missed something on the new download. Attached is the codeblocks project. Click on the .cbp file and it should open into codeblocks and then try to rebuild.
I did change the file name from hello.c to main.c. I'm still not quite sure of the best way to bring the output from spin2c into codeblocks. If you double click on the main output, it opens the file but that is not a project. If you create a project and copy in the text of the program it seems to get confused.
For those interested in supporting other boards in Catalina, and also to dispel the myths (propagated by some in these forums) that this is a difficult thing to do, I am posting a beta version of a support package for Rayman's proposed new Rampage2 XMM board.
The RamPage2 will have 4Mb of FLASH, 256bytes of SRAM and a micro SD card slot. It will fit straight into the expansion sockets on either the Propeller Platform or QuickStart boards.
Supporting this in Catalina turned out to be quite straightforward, even though this particular board has a slightly peculiar XMM architecture (it is word-oriented rather than byte-oriented). Also, this version of the support package (while 100% functional) is a beta, and is primarily intended to show that it can indeed be done - this particular implementation is a bit inefficient, and will certainly not be winning any speed awards!
To use a support package such as this, you just unzip it into your Catalina target directory. Catalina will then use these files by default unless you specify a different platform on the command line, or select one in Code::Blocks.
The files in the package are as follows:
Custom_README.TXT - describes the features offered by the Rampage2 support package. Custom_DEF.inc - identifies the pins used by various peripherals, the clock speed, and various other board-specific parameters. Custom_HMI.inc - identifies which HMI options the board supports (in this case, only the various serial HMI options - TTY, PC etc) Custom_CFG.inc - a convenient place to include additional "#defines" (rather than having to specify them all on the command line). Custom_XMM.inc - the implementation of the XMM API for this board, which allows Catalina to access the FLASH and SRAM.
The XMM API is the only non-trivial file (as you might expect, given the peculiar architectures of each and every XMM implementation!) - but the XMM API is described in the Catalina Reference Manual (pp 137 - A Description of the Standard Catalina XMM API). All Catalina support packages implement the same XMM API.
For those interested in supporting other boards in Catalina, and also to dispel the myths (propagated by some in these forums) that this is a difficult thing to do, I am posting a beta version of a support package for Rayman's proposed new Rampage2 XMM board.
This is great! Thanks Ross! I wrote a PropGCC cache driver for the RamPage2 a while back but it only supports the flash chips. I could pretty easily support only the SRAM chips but I am currently running out of COG space so supporting both at the same time will involve some code cleanup. I'm anxious to look at how you did this to see if I can adapt your approach to my driver.
I just downloaded your files and unzipped them to an empty directory. I compiled and ran the program using the following commands:
catalina main.c fullduplexserial.c -lc -C NO_HMI
payload main -i
This works (at least I assume it does, since it prints "Hello, world!" on my terminal).
You should note the -C NO_HMI option. I added this because my default platform uses the same pins as your FullDuplexSerial for a serial HMI plugin. Just disable the HMI altogether to avoid this conflict and everything is sweet.
I'm off to bed now - if you can't figure it out, I'll have a look at doing the same thing in Code::Blocks tomorrow (personally I can't imagine how anyone thinks an IDE could be any easier, but there you go )
This is great! Thanks Ross! I wrote a PropGCC cache driver for the RamPage2 a while back but it only supports the flash chips. I could pretty easily support only the SRAM chips but I am currently running out of COG space so supporting both at the same time will involve some code cleanup. I'm anxious to look at how you did this to see if I can adapt your approach to my driver.
You are welcome to try - but may not want to! My implementation is space efficient but very time inefficient.
I find "brute force and ignorance" goes a long way in such matters
I find "brute force and ignorance" goes a long way in such matters .
That is the philosophy that got me code that barely fits in the COG and only handles the flash chips! :-)
How does your cache system work? I think part of my problem is that the cache handling logic is in the COG that accesses the external memory and takes up a fair amount of space. Does Catalina use a similar architecture or do you place the cache tag handling code in the kernel COG?
That is the philosophy that got me code that barely fits in the COG and only handles the flash chips! :-)
How does your cache system work? I think part of my problem is that the cache handling logic is in the COG that accesses the external memory and takes up a fair amount of space. Does Catalina use a similar architecture or do you place the cache tag handling code in the kernel COG?
I believe I use the same cache architecture as you do - since I am using cache code that was originally written by you and Steve
I'm working on a loader for the Propeller II and you may have noticed that there has been a little discussion about reserving the space at the end of the ROM ($0e80-$0fff) for data structures like mailboxes. This, of course, sounds a bit like the scheme that Catalina uses for managing "plug-ins". I think it would be great if we could create a loader for P2 that would satisfy the requirements of both Catalina and PropGCC as well as being able to load PASM and Spin programs. I know that Parallax will probably come up with their own loader for the Propeller Tool but Catalina and PropGCC currently each have their own custom loaders and I think this may be an opportunity to move to a common loader that can be used by both of our toolchains as well as languages supported by SimpleIDE including Spin and PASM. Can we start a discussion on the requirements for this common loader? My p2load program is currently quite simple. It just loads a flat binary file into hub memory starting at $0e80 and then starts the COG image at that address. While there has been discussion of using those low memory addresses for other purposes, I haven't done anything about it yet so nothing is set in stone at this point. Would you care to participate?
Thanks Ross! I'm still dreaming running Nethack on the Prop and maybe this will help get that done...
I hope to have RamPage2 available for purchase in one month.
For those interested in supporting other boards in Catalina, and also to dispel the myths (propagated by some in these forums) that this is a difficult thing to do, I am posting a beta version of a support package for Rayman's proposed new Rampage2 XMM board.
Ross, I do have one question for you (I'll have to ask David too)...
I'd like to share the 8-bit bus with other things (because of pin shortage...)
Would it be easy or hard to use something like the "locks" to allow the bus to be shared?
The PropGCC cache drivers let go of the bus when they are not processing a cache miss. That means that you can place code that needs to access those pins in hub memory and it will execute to completion without any interference from the cache COG. This won't, of course, work if the code that shares the bus is in external memory since executing the code can cause cache misses that will cause the cache driver COG to access the pins. It is easy in PropGCC to force a function into hub memory using the HUBTEXT qualifier. Since it will live in hub memory, you should try to make it as small as possible and do any "outer loop" stuff in code that lives in external memory.
If the HUBTEXT approach won't work for you, PropGCC also has a lock that allows the pins to be shared.
Tracing through the links, main.h is included, and this includes fullduplexserial.h and that includes fullduplexserial.c
No, I don't think fullduplexserial.c is included by fullduplexserial.h -- it certainly isn't in the default output of spin2cpp.
I think you may be misunderstanding what header files do. The .h files generally only have declarations of functions and variables that are available in another compilation unit (.c file). You still have to make sure to compile that other compilation unit. In this case, your codeblocks project needs to include both hello.c (or main.c, if you've renamed it) *and* fullduplexserial.c.
Ross, I do have one question for you (I'll have to ask David too)...
I'd like to share the 8-bit bus with other things (because of pin shortage...)
Would it be easy or hard to use something like the "locks" to allow the bus to be shared?
Calaina has a symbol (SHARED_XMM) that you define somewhere (e.g. in the Custom_CFG.inc file) to tell the kernel that other devices may also use the XMM bus. This is true on several of the existing XMM API implementations (e.g. the C3 and the RamBlade).
Just compiled your program in Code::Blocks. There are several ways to do this, but here is what I did ...
Downloaded your sources to a new directory (I only needed the .h and the .c files).
Started Code::Blocks
Do File->New->Project and selected the Catalina Project wizard.
Entered the information appropriate to my platform (note I also selected None when asked to specify the HMI options, to prevent any contention with FullDuplexSerial).
Select Project->Remove Files and remove the default 'main.c' file that the wizard adds to the project.
Select Project->Add Files and add the sources for your program (main.h, main.c, FullDuplexSerial.h, FullDuplexSerial.c)
No, I don't think fullduplexserial.c is included by fullduplexserial.h -- it certainly isn't in the default output of spin2cpp.
I think you may be misunderstanding what header files do. The .h files generally only have declarations of functions and variables that are available in another compilation unit (.c file). You still have to make sure to compile that other compilation unit. In this case, your codeblocks project needs to include both hello.c (or main.c, if you've renamed it) *and* fullduplexserial.c.
Ah, that makes sense. So does Ross' post #83.
I'll have a think about a way of automating this. Maybe there is a way of creating a codeblocks .cbp file as part of the spin2c process?
I'll have a think about a way of automating this. Maybe there is a way of creating a codeblocks .cbp file as part of the spin2c process?
Hey, if you can convince Eric to do this, then by all means! .
Personally, I don't think see this as a priority. In most cases it saves you only a couple of keystrokes, and once you do it the first time you typically never have to do it again for that project - even if you have to re-run spin2cpp.
Thanks Ross. I added files manually and that works fine. This is great!
Re the bit about disabling HMI, I see how you did that as a command line. Is there a way of doing the same thing from code::blocks?
Ok, answering my own question
In the list of boards, is there one where you just have a plain propeller chip? No vga, no keyboard, no mouse, no serial driver even. Maybe for those projects where you might just be flashing leds and nothing else.
I think I have got it right by clicking 'custom' and then 'no HMI interfaces'. Is that correct?
In the list of boards, is there one where you just have a plain propeller chip? No vga, no keyboard, no mouse, no serial driver even. Maybe for those projects where you might just be flashing leds and nothing else.
I think I have got it right by clicking 'custom' and then 'no HMI interfaces'. Is that correct?
Yes. As installed, the CUSTOM platform is nothing more than a Propeller with an 5Mhz clock and nothing else. No XMM, TV, VGA, Keyboard, Mouse, SDCard, etc etc.
If you do not even want a serial HMI option, you can specify -C NO_HMI on the command line. If even that seems too much like hard work then just define the NO_HMI flag in Custom_CFG.inc file. I'd recommend defining it as follows, just in case you also define it on the command line, or in Code::Blocks:
Ok, I started a new project, clicked custom, selected the "no hmi" interface.
It still says something about including hmi.spin in the compile process, but it also says something about sd cards and that isn't being included so it probably isn't. So removing the serial debug will presumably reduce the code space.
#include <stdio.h>
//#ifndef NO_HMI
//#define NO_HMI
//#endif
int main(int argc, char *argv[])
{
while(1) ; // the propeller reboots on exit - this line prevents that
return 0;
}
is 4976 bytes
uncommenting the ifndef no_hmi also is 4976 bytes.
commenting out everything above int main() is also 4976 bytes.
So I am assuming that because stdio never got used the serial debugger code was not included?
Add in a printf and the code size goes to 19k, and it is the same whether stdio is included or not included.
So I can use this bare bones program to, say, flash a led. Or to build a spin2c program from scratch...
With that 4k program, with all the hmi disabled, how many cogs will that be using? Is it like a Spin program - just using one cog, and so you have 7 free?
Ok, I started a new project, clicked custom, selected the "no hmi" interface.
It still says something about including hmi.spin in the compile process, but it also says something about sd cards and that isn't being included so it probably isn't. So removing the serial debug will presumably reduce the code space.
You can't include NO_HMI in the C file. As I mentioned, you can either include it in your Custom_CFG.inc file, specify it on the command line, or select it as an option in Code::Blocks. When I take your program ...
#include <stdio.h>
int main(int argc, char *argv[])
{
while(1) ; // the propeller reboots on exit - this line prevents that
return 0;
}
... and compile it as follows ...
catalina empty.c -C NO_HMI
... I get a code size of 80 bytes. If I add a few other flags (based on my simple observations that the program needs no argument processing, and also never exits) ...
catalina empty.c -C NO_HMI -C NO_ARGS -C NO_EXIT
... I get a final code size of 24 bytes (i.e. 6 PASM instructions).
During the compile you may see all sort of things ....
This is all perfectly normal - all these Spin files are scanned during every compilation, but unless you have asked them to do so, none of them result in any plugins being included with your program.
With that 4k program, with all the hmi disabled, how many cogs will that be using? Is it like a Spin program - just using one cog, and so you have 7 free?
Apologies - I just realized I hadn't answered this part of your post.
Yes, it is exactly like a Spin program, with only one cog used. This cog will be executing the Catalina LMM Kernel. The others are avalaible for whatever you want - to execute plugins, or to execute more C code.
The program I compiled above reports a file size of 2716 bytes, The first 16 bytes is the same as any Spin program, and 32 bytes is the program code and data size. The bulk of the rest (about 2k bytes) is the kernel itself, and the remainder is initialization code (such as the code required to set up the registry). Everything except the first 16 bytes, and the program code and data, is discarded before the program is started, so at run time the whole program uses under 50 bytes. Oh - plus the registry, which is another 100 bytes located in High RAM.
Comments
Brilliant! That works. Thanks Ross.
Sorry for all the questions. I've been using my own custom IDE with catalina for the last year but you have done so much brilliant work integrating catalina into code::blocks that I am now moving everything over to this program.
I'm running through the little tutorial in the document "codeblocks quickstart.rtf" and it is all working fine but I have a problem with the Tools menu. In the tutorial this has a whole lot of menus added, but on my new install of catalina code::blocks the Tools menu is blank (the only option is "configure tools..."). Does this get configured as part of the install? Or did I miss something with the install? Or is there a manual way to add those menus?
I think it might be catalina_tools.conf ?
It might be because the version I'm using was from a few months back. Worth a reinstall?
Also another question - say I'm experimenting with spin2cpp and it is generating lots of .h files. I've found by trial and error that the program compiles if I put these in c:\programfiles\catalina\include. But is that the best directory to put these files, or should they be in the demo directory or something?
Many thanks in advance.
Yes, that happens if you installed Code::Blocks as a user other than the one currently logged in - the files containing the Tools menu configuration have been copied only into the AppData folder for that user, and need to be manually set up for any other users.
Try shutting down Code::Blocks, opening a Catalina command line window and executing the following command:
Then restart Code::Blocks. The Tools menu should be correctly displayed. You can repeat this for any other user accounts on the machine as well.
Ross.
And the output from Spin2c for that hello world demo is compiling with no errors. Now to test a download...
Almost there. Getting garbled ascii characters on the debug screen and I think it is because way back I had the baud rate set slower. Doing a new install of version 3.10 now as the version I have is a bit out of date now. Saving that old homespun file though as I'll be needing that.
All very exciting - all the bits seem to be working separately and I think it is getting close to running the output of a spin2c program.
Don't put them in the catalina include directory! That's intended for the header files that go with Catalina's library. The .h files generated by spin2cpp should go in the same directory as the .c files generated by it -- they go together.
Eric
Tracing through the links, main.h is included, and this includes fullduplexserial.h and that includes fullduplexserial.c
I probably missed something on the new download. Attached is the codeblocks project. Click on the .cbp file and it should open into codeblocks and then try to rebuild.
I did change the file name from hello.c to main.c. I'm still not quite sure of the best way to bring the output from spin2c into codeblocks. If you double click on the main output, it opens the file but that is not a project. If you create a project and copy in the text of the program it seems to get confused.
Any help here would be most appreciated.
For those interested in supporting other boards in Catalina, and also to dispel the myths (propagated by some in these forums) that this is a difficult thing to do, I am posting a beta version of a support package for Rayman's proposed new Rampage2 XMM board.
The RamPage2 will have 4Mb of FLASH, 256bytes of SRAM and a micro SD card slot. It will fit straight into the expansion sockets on either the Propeller Platform or QuickStart boards.
Supporting this in Catalina turned out to be quite straightforward, even though this particular board has a slightly peculiar XMM architecture (it is word-oriented rather than byte-oriented). Also, this version of the support package (while 100% functional) is a beta, and is primarily intended to show that it can indeed be done - this particular implementation is a bit inefficient, and will certainly not be winning any speed awards!
To use a support package such as this, you just unzip it into your Catalina target directory. Catalina will then use these files by default unless you specify a different platform on the command line, or select one in Code::Blocks.
The files in the package are as follows:
Custom_DEF.inc - identifies the pins used by various peripherals, the clock speed, and various other board-specific parameters.
Custom_HMI.inc - identifies which HMI options the board supports (in this case, only the various serial HMI options - TTY, PC etc)
Custom_CFG.inc - a convenient place to include additional "#defines" (rather than having to specify them all on the command line).
Custom_XMM.inc - the implementation of the XMM API for this board, which allows Catalina to access the FLASH and SRAM.
The XMM API is the only non-trivial file (as you might expect, given the peculiar architectures of each and every XMM implementation!) - but the XMM API is described in the Catalina Reference Manual (pp 137 - A Description of the Standard Catalina XMM API). All Catalina support packages implement the same XMM API.
Ross.
This is great! Thanks Ross! I wrote a PropGCC cache driver for the RamPage2 a while back but it only supports the flash chips. I could pretty easily support only the SRAM chips but I am currently running out of COG space so supporting both at the same time will involve some code cleanup. I'm anxious to look at how you did this to see if I can adapt your approach to my driver.
Hi Dr_A,
I just downloaded your files and unzipped them to an empty directory. I compiled and ran the program using the following commands:
This works (at least I assume it does, since it prints "Hello, world!" on my terminal).
You should note the -C NO_HMI option. I added this because my default platform uses the same pins as your FullDuplexSerial for a serial HMI plugin. Just disable the HMI altogether to avoid this conflict and everything is sweet.
I'm off to bed now - if you can't figure it out, I'll have a look at doing the same thing in Code::Blocks tomorrow (personally I can't imagine how anyone thinks an IDE could be any easier, but there you go
Ross.
You are welcome to try - but may not want to! My implementation is space efficient but very time inefficient.
I find "brute force and ignorance" goes a long way in such matters
Ross.
How does your cache system work? I think part of my problem is that the cache handling logic is in the COG that accesses the external memory and takes up a fair amount of space. Does Catalina use a similar architecture or do you place the cache tag handling code in the kernel COG?
Ross.
I'm working on a loader for the Propeller II and you may have noticed that there has been a little discussion about reserving the space at the end of the ROM ($0e80-$0fff) for data structures like mailboxes. This, of course, sounds a bit like the scheme that Catalina uses for managing "plug-ins". I think it would be great if we could create a loader for P2 that would satisfy the requirements of both Catalina and PropGCC as well as being able to load PASM and Spin programs. I know that Parallax will probably come up with their own loader for the Propeller Tool but Catalina and PropGCC currently each have their own custom loaders and I think this may be an opportunity to move to a common loader that can be used by both of our toolchains as well as languages supported by SimpleIDE including Spin and PASM. Can we start a discussion on the requirements for this common loader? My p2load program is currently quite simple. It just loads a flat binary file into hub memory starting at $0e80 and then starts the COG image at that address. While there has been discussion of using those low memory addresses for other purposes, I haven't done anything about it yet so nothing is set in stone at this point. Would you care to participate?
Thanks,
David
Interesting! I'll take a look at your code. You are better at writing compact PASM code than I am I guess!
Happy to do so - just point me to the discussions you've had to date and I'll have a read.
Ross.
Great! I'm glad you're interested in contributing!
The thread starts here:
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1147538&viewfull=1#post1147538
I hope to have RamPage2 available for purchase in one month.
I'd like to share the 8-bit bus with other things (because of pin shortage...)
Would it be easy or hard to use something like the "locks" to allow the bus to be shared?
If the HUBTEXT approach won't work for you, PropGCC also has a lock that allows the pins to be shared.
I think you may be misunderstanding what header files do. The .h files generally only have declarations of functions and variables that are available in another compilation unit (.c file). You still have to make sure to compile that other compilation unit. In this case, your codeblocks project needs to include both hello.c (or main.c, if you've renamed it) *and* fullduplexserial.c.
Eric
Calaina has a symbol (SHARED_XMM) that you define somewhere (e.g. in the Custom_CFG.inc file) to tell the kernel that other devices may also use the XMM bus. This is true on several of the existing XMM API implementations (e.g. the C3 and the RamBlade).
Ross.
Hi Dr_A.,
Just compiled your program in Code::Blocks. There are several ways to do this, but here is what I did ...
- Downloaded your sources to a new directory (I only needed the .h and the .c files).
- Started Code::Blocks
- Do File->New->Project and selected the Catalina Project wizard.
- Entered the information appropriate to my platform (note I also selected None when asked to specify the HMI options, to prevent any contention with FullDuplexSerial).
- Select Project->Remove Files and remove the default 'main.c' file that the wizard adds to the project.
- Select Project->Add Files and add the sources for your program (main.h, main.c, FullDuplexSerial.h, FullDuplexSerial.c)
- Select Build->Rebuild.
Ross.Ah, that makes sense. So does Ross' post #83.
I'll have a think about a way of automating this. Maybe there is a way of creating a codeblocks .cbp file as part of the spin2c process?
Hey, if you can convince Eric to do this, then by all means!
Personally, I don't think see this as a priority. In most cases it saves you only a couple of keystrokes, and once you do it the first time you typically never have to do it again for that project - even if you have to re-run spin2cpp.
Ross.
Re the bit about disabling HMI, I see how you did that as a command line. Is there a way of doing the same thing from code::blocks?
Ok, answering my own question
In the list of boards, is there one where you just have a plain propeller chip? No vga, no keyboard, no mouse, no serial driver even. Maybe for those projects where you might just be flashing leds and nothing else.
I think I have got it right by clicking 'custom' and then 'no HMI interfaces'. Is that correct?
Yes. As installed, the CUSTOM platform is nothing more than a Propeller with an 5Mhz clock and nothing else. No XMM, TV, VGA, Keyboard, Mouse, SDCard, etc etc.
If you do not even want a serial HMI option, you can specify -C NO_HMI on the command line. If even that seems too much like hard work
Voil
Ok, I started a new project, clicked custom, selected the "no hmi" interface.
It still says something about including hmi.spin in the compile process, but it also says something about sd cards and that isn't being included so it probably isn't. So removing the serial debug will presumably reduce the code space.
#include <stdio.h> //#ifndef NO_HMI //#define NO_HMI //#endif int main(int argc, char *argv[]) { while(1) ; // the propeller reboots on exit - this line prevents that return 0; }is 4976 bytesuncommenting the ifndef no_hmi also is 4976 bytes.
commenting out everything above int main() is also 4976 bytes.
So I am assuming that because stdio never got used the serial debugger code was not included?
Add in a printf and the code size goes to 19k, and it is the same whether stdio is included or not included.
So I can use this bare bones program to, say, flash a led. Or to build a spin2c program from scratch...
With that 4k program, with all the hmi disabled, how many cogs will that be using? Is it like a Spin program - just using one cog, and so you have 7 free?
You can't include NO_HMI in the C file. As I mentioned, you can either include it in your Custom_CFG.inc file, specify it on the command line, or select it as an option in Code::Blocks. When I take your program ...
#include <stdio.h> int main(int argc, char *argv[]) { while(1) ; // the propeller reboots on exit - this line prevents that return 0; }... and compile it as follows ...
... I get a code size of 80 bytes. If I add a few other flags (based on my simple observations that the program needs no argument processing, and also never exits) ...
... I get a final code size of 24 bytes (i.e. 6 PASM instructions).
During the compile you may see all sort of things ....
This is all perfectly normal - all these Spin files are scanned during every compilation, but unless you have asked them to do so, none of them result in any plugins being included with your program.
Ross.
Apologies - I just realized I hadn't answered this part of your post.
Yes, it is exactly like a Spin program, with only one cog used. This cog will be executing the Catalina LMM Kernel. The others are avalaible for whatever you want - to execute plugins, or to execute more C code.
The program I compiled above reports a file size of 2716 bytes, The first 16 bytes is the same as any Spin program, and 32 bytes is the program code and data size. The bulk of the rest (about 2k bytes) is the kernel itself, and the remainder is initialization code (such as the code required to set up the registry). Everything except the first 16 bytes, and the program code and data, is discarded before the program is started, so at run time the whole program uses under 50 bytes. Oh - plus the registry, which is another 100 bytes located in High RAM.
Ross.
Hi David,
Haven't had time to look at this yet, and soon I'll be out of internet range for a few days. I'll try to get to this next week.
Ross.