@Ross no Sir. I dont currently use C.In the past Ive seen some projects that used Catalina and only started to do research on the topic.I quickly decided the overall complexity of the project was more than I could handle at that time.Thanks for all your comments.
No worries, graffix. Spin is a good starting point if you are new to microcontrollers and especially if you are new to the Propeller. Don't feel you have to start out with C - for most people C is the second or third language they learn (many people never learn it at all).
Anyway, there's no rush - C has been around for 30 years, and is not going to go away anytime soon
I've done an uninstall for Catalina, then a brand new install. Followed the guide (which is brilliant BTW). Only thing I did a bit different was select the XMM large memory instead of the tiny one.
Getting this error when compiling:
Launching tool 'Download to XMM RAM': payload.exe XMM Hello (in C:\Propeller\Hello\bin\Release)
stderr> Error: Unable to open file XMM.binary
Tool execution terminated with status 1
I have had problems before with xmm.binary and so I do have quite a few copies of it in various folders. This is a deliberate clean new install with the old directory renamed and archived as I didn't want any complexities with out of date files.
Addit: I tried "Build XMM Utilities" and this fixed this error. Any chance that could be added to the Getting Started manual as it seems to be an essential step?
Now there is another error. When I use Build/Build it runs through all the compilation process and then says "compiled image exceeds 65536 bytes".
Can you make it so that the compiler gives an error if cnst+init+data>32kB in "small" mode?
Also, is there some maximum extra required space, maxextra, you could use to give a warning if cnst+init+data+maxextra>32kB?
Any way put the "cnst" part onto flash?
Second: I don't understand the purpose or function of the "set memory size" build option. The "sst" example seems to work fine on RamPage without this option set... The executable is slightly smaller though. Could something go horribly wrong without this being set? I remember that you told me the original size of 384kB was too small and I had to increase it to 512kB. Is this some kind of upper limit? Can't it get that info from the "XMM_RO_SIZE" variable?
Ross, I think maybe you missed this question...
Also, I have a related question now... Regarding 1k versus 8k cache. Is there any way to tell if 8k is going to be too much? The sst example seems to work with 8k selected...
Addit: I tried "Build XMM Utilities" and this fixed this error. Any chance that could be added to the Getting Started manual as it seems to be an essential step?
It's in the Getting Started with CodeBlocks document - page 28. However, I'll make it more prominent in the next release.
Now there is another error. When I use Build/Build it runs through all the compilation process and then says "compiled image exceeds 65536 bytes".
The default memory size is 64k. You need to select the Set Memory Size option, and then specifiy another size using the MEM_SIZE custom variable (e.g. set it to 512k). This is described in the Getting Started with CodeBlocks document - page 19. I plan on making this just a warning in the next release.
Thanks Ross. I guess most people would be starting off with no external memory (though there do seem to be more external memory options around now).
I've been thinking more about caches. I posted a new thread yesterday about a new display that uses the arduino footprint. If this works, and it can be deselected (probably a matter of keeping /rd high or something), then you can allocate more pins for memory. Say 2 for download, 2 for eeprom, 2 for keyboard, 2 for mouse. Then, counting down from P23, three pins to a HC138 to select 1 of 8. This 1 of 8 selects SD card, other SPI devices, the display, and memory /rd and memory /wr, plus a single latch. That now leaves 21 propeller pins for memory access, which gives you 2^13 address pins = 8k. A single latch to select which 8k bank.
The memory access pins are shared with the display driver pins, and you might have a cog that handles block move of memory from a hub buffer into the external display.
That could give you fast cache access as you can refresh the cache with no latch changes. That ought to be almost as fast as Cluso's fastest driver.
Also, I have a related question now... Regarding 1k versus 8k cache. Is there any way to tell if 8k is going to be too much? The sst example seems to work with 8k selected...
Yes, I missed it - Sorry.
I can certainly add in a "this program cannot be run in SMALL mode" message if the size of the C segments exceeds 32k.
But figuring our how big the cache can be is much more difficult. I'll give that one some thought. Most likely I would need to add some kind of "tide mark" option for determining the maximum program stack usage at run time, - then you would need to test this out by actually running the program.
TINY, SMALL and LARGE are the memory modes. LMM, EMM, SMM, XMM are really more to do with the load option:
LMM: program <= 32k (i.e. TINY), one phase "Parallax" loader
SMM: program <= 32k (i.e. TINY), two phase "SDCARD" loader
EMM: program <= 32k (i.e. TINY), two phase "EEPROM" loader
XMM: program > 32k (could be either SMALL or LARGE), two phase "XMM" loader.
The don't the "two phase" ones SMM and EMM really have a 64k file size limit? I guess each phase has to be less than 32kB?
Thanks Ross. I guess most people would be starting off with no external memory (though there do seem to be more external memory options around now).
I've been thinking more about caches. I posted a new thread yesterday about a new display that uses the arduino footprint. If this works, and it can be deselected (probably a matter of keeping /rd high or something), then you can allocate more pins for memory. Say 2 for download, 2 for eeprom, 2 for keyboard, 2 for mouse. Then, counting down from P23, three pins to a HC138 to select 1 of 8. This 1 of 8 selects SD card, other SPI devices, the display, and memory /rd and memory /wr, plus a single latch. That now leaves 21 propeller pins for memory access, which gives you 2^13 address pins = 8k. A single latch to select which 8k bank.
The memory access pins are shared with the display driver pins, and you might have a cog that handles block move of memory from a hub buffer into the external display.
That could give you fast cache access as you can refresh the cache with no latch changes. That ought to be almost as fast as Cluso's fastest driver.
Catalina is geared to cope with XMM RAM pin conflicts - fast parallel XMM RAM takes so many pins that this is a common scenario on many boards.
The don't the "two phase" ones SMM and EMM really have a 64k file size limit? I guess each phase has to be less than 32kB?
Correct. The C program still needs to fit into 32k. What the two phase loader does is load all the cog code in phase 1, so that in phase 2 the space that code occupied can then be used as C program code space. Without the two phase loader, this space can be used as data space, but not as code space.
Ross, I just reinstalled, to make sure it wasn't me that changed things...
I'm looking at the CodeBlocks "emm_demos" and the startrek_emm project.
When, I build it, it works, but the file is 98kB. When I look it build options, "small" is selected.
I'm trying to reconcile this with what you said earlier about the different MMs...
There was no MEM_SIZE set either and it didn't complain... What does MEM_SIZE do? I don't get it...
Ross, I just reinstalled, to make sure it wasn't me that changed things...
I'm looking at the CodeBlocks "emm_demos" and the startrek_emm project.
When, I build it, it works, but the file is 98kB. When I look it build options, "small" is selected.
I'm trying to reconcile this with what you said earlier about the different MMs...
There was no MEM_SIZE set either and it didn't complain... What does MEM_SIZE do? I don't get it...
Sorry - my mistake. The list should have read:
LMM: program <= 32k (i.e. TINY), one phase "Parallax" loader SMM: program <= 32k (i.e. TINY), two phase "SDCARD" loader EMM: program <= 32k (i.,e. TINY) two phase "EEPROM" loader (LMM version) EMM: program > 32k (i.e. SMALL or LARGE), two phase "EEPROM" loader (XMM version) XMM: program > 32k (could be either SMALL or LARGE), two phase "XMM" loader.
I've corrected the original in the post above to avoid confusing others
The size of the startrek_xmm.eeprom file should be 96k (98,304). That''s 32k loaded during phase 1, and 64k (the default C program size unless you specify otherwise) of XMM code and data.
I made the default size 64k since many Propeller boards have 64k eeproms - but that was before I finalized the two-phase load functionality. The default size doesn't really make any sense now, and certainly doesn't make any sense for the XMM loader, and I should just remove it (or perhaps add it to the DEF file, so it is configurable per platform).
Thanks Ross, but I'm still a little confused (I even resorted to reading the documentation this time)... I think you must mean startrek_emm.eeprom in the above right?
How does an emm program execute 64kB of (emm?) code and data? Doesn't it still have to fit in 32kB of hub RAM?
Are you executing out of EEPROM (that sounds too slow to be true)?
Thanks Ross, but I'm still a little confused (I even resorted to reading the documentation this time)... I think you must mean startrek_emm.eeprom in the above right?
How does an emm program execute 64kB of (emm?) code and data? Doesn't it still have to fit in 32kB of hub RAM?
Are you executing out of EEPROM (that sounds too slow to be true)?
Ah! I see I've only added to the confusion by my last update (serves me right for trying to answer posts while in the middle of shifting a couple of chicken coops!). I've updated my posts above yet again.
Nothing ever executes out of EEPROM. Programs are only ever loaded out of EEPROM - either into Hub RAM (TINY programs) or into XMM RAM (SMALL or LARGE programs). And so there are actually two different EEPROM loaders - one for LMM (TINY) programs and one for XMM (SMALL and LARGE) programs.
I always find examples help...
Here is an example of a command that compiles a TINY LMM program that can be loaded out of EEPROM into Hub RAM but using only the normal Parallax one-phase loader (which means that only the space left after all the cog code has been included is available for C code):
catalina -lc hello_world.c -e
-e tells Catalina to create a .eeprom file (which is zero filled up to a specified size, or the default size of 32kb) instead of a .binary file. This option is actually not necessary, but is common when using the EEPROM loader since it ensures the whole EEPROM is initialized. So the final file size is 32k
Here is an example of a command that compiles a TINY LMM program to be loaded out of EEPROM into Hub RAM using a two-phase loader (which allows all 32k of Hub space to be used for C code):
catalina -lc hello_world.c -e -D EEPROM
-e tells Catalina to create a .eeprom file (as above, this is not strictly necessary - but it is quite common if you plan to program the file into EEPROM). -D EEPROM means to include the EEPROM loader. In this case it uses the LMM EEPROM loader. This adds a 32k phase 1 loader to the program, making the final file size 64k.
The file startrek_xmm.eeprom, on the other hand, is a SMALL XMM program built to be loaded out of EEPROM. Here is the command line used to compile it:
-D SMALL means this is an XMM program that uses the SMALL memory model (we could have said LARGE here instead). -e tells Catalina to create a .eeprom file (however, since this is an XMM program, the file size will now default to 64k, not 32k - this is the size that MEM_SIZE affects). -D EEPROM means to include the EEPROM loader. In this case it uses the XMM EEPROM loader. This adds a 32k phase 1 loader, making the final file 96k.
Ross.
P.S. I've just re-read the documentation, and I agree it is a bit confusing since it doesn't make the distinction between the two EEPROM loaders very clear either - I will update it.
Thanks Ross. I think I'm starting to get it. But, you mean "startrek_emm" not "startrek_xmm" right?
The xmm version is a Catalyst demo, I think.
But, I still don't completely understand the 96kB you mentioned a little earlier... Perhaps the actual program to be loaded into flash is stored in the 64kB eeprom and the loader part comes from somewhere else...
Anyway, my current understanding leads me to think that I should focus on "xmm" and Catalyst. I think that's were the real payoff is...
Thanks Ross. I think I'm starting to get it. But, you mean "startrek_emm" not "startrek_xmm" right?
The xmm version is a Catalyst demo, I think.
Ah, I see what you mean - I was referring to the one built by the build_all script in the demo folder. It's called startrek_xmm, and it uses the EEPROM loader. But in the Code::Blocks emm_demos workspace I called this version startrek_emm, and startrek_xmm is a version in the xmm_demos workspace that uses the default serial loader, and not the EEPROM loader.
I'll fix the terminology inconsistency in the next version. There's a few other cases as well.
But, I still don't completely understand the 96kB you mentioned a little earlier... Perhaps the actual program to be loaded into flash is stored in the 64kB eeprom and the loader part comes from somewhere else...
Anyway, my current understanding leads me to think that I should focus on "xmm" and Catalyst. I think that's were the real payoff is...
The MEM_SIZE option refers only to the C code size, not the final file size once the two-phase loader is added. The two phase loader always adds 32k, so if you have a 64k EEPROM you'd have to say MEM_SIZE=32k. If you had a 128k EEPROM you would have to say MEM_SIZE=96k.
Silly, I know - but I'm planning to rework the MEM_SIZE option for the next release, so don't worry about it too much. I may remove it altogether.
I have been having multiple problems with trying to get an xmm program running on code::blocks, so I have gone back to the command line for the moment. Still getting some odd behaviour. I am tracing it through and something has changed from v 3.0 to v 3.3
First test - go back to version 3.0 and run a download using vga and no xmm
this does not work and prints garbage yellow on blue characters on the screen.
This is using the command line (code::blocks has other problems to solve and I need to simplify the debug process) and with the July version of the dracblade hmi file that does not include TV (again, not ready for that new file as it adds another variable).
Firstly, can you replicate this problem? ie will this compile
catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA NEW.C
Second, is it correct that in version 3.0, in the Target directory, there are only a few ".inc" files but in version 3.3 there are many more? I am wondering if either your directory structure has changed, or a file location has changed?
Addit: Just hold answering that for the moment. I have a fudge solution by copying xmm.binary from an old directory into c:\program files\catalina\utilities
My problem now is that I have forked the debug process, as your default compiler does not have xmm.binary in that location, so I can't be sure I am comparing like with like esp wrt code::blocks compilations that are failing.
Sorry, more additional information. My IDE needs xmm.binary in the Demos folder and because it isn't there by default, it copies it from the Utilities folder. But in the latest version, I can't find it in the utilities folder either. I'll do a reinstall to double check that. brb
OK, yes, that is the issue at the command line level. With xmm.binary it works (I copy it from Utilities to Demo). In version 3.3 I did a search through the entire directory and can't find this file, but it works if I get it from an old version. If I do that, then I can get the TV working with the new .inc file. To be more precise, xmm.binary needs to be in the same folder as the file that is being compiled, and for me that is the Demos folder.
Now, on to code::blocks, which is not working with xmm.
Ross, Ok I think I'm getting closer to figuring out what you are doing...
But, I'm opened up again the CodeBlocks emm_demos and see this note:
IMPORTANT NOTES: The EMM projects in this directory each build a 64kb .eeprom file which must be loaded into the Propeller EEPROM using an external program, since EEPROM files larger than 64k cannot be loaded using either the normal Parallax serial loader or Payload.
Is it supposed to say "larger than 32k"? (Also, btw I think most people use "B" for byte and "b" for bit.)
I still don't really see how the second EMM (>32kB) option is supposed to work... Is this supposed to load XMM from a second EEPROM maybe?
If not, can you give an example of a system and where the 96kB goes?
One more question... I think it'd be really nice if it were possible to load a <64kB program in two steps via the serial connection.
I thought that was possible. But, now that I read you notes, it sounds like it is not...
Ross, on another topic... I've interested also on your multithreaded and multicog examples.
Visual Studio always gives a ton of warnings about old C functions not being "thread safe".
I see a not in the documentation that says multicog calls may not be "cog safe" in this free version.
But, what about multithreaded mode? Is every thing "safe" there?
I have been having multiple problems with trying to get an xmm program running on code::blocks, so I have gone back to the command line for the moment. Still getting some odd behaviour. I am tracing it through and something has changed from v 3.0 to v 3.3
First test - go back to version 3.0 and run a download using vga and no xmm
this does not work and prints garbage yellow on blue characters on the screen.
This is using the command line (code::blocks has other problems to solve and I need to simplify the debug process) and with the July version of the dracblade hmi file that does not include TV (again, not ready for that new file as it adds another variable).
Firstly, can you replicate this problem? ie will this compile
catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA NEW.C
Second, is it correct that in version 3.0, in the Target directory, there are only a few ".inc" files but in version 3.3 there are many more? I am wondering if either your directory structure has changed, or a file location has changed?
Addit: Just hold answering that for the moment. I have a fudge solution by copying xmm.binary from an old directory into c:\program files\catalina\utilities
My problem now is that I have forked the debug process, as your default compiler does not have xmm.binary in that location, so I can't be sure I am comparing like with like esp wrt code::blocks compilations that are failing.
Sorry, more additional information. My IDE needs xmm.binary in the Demos folder and because it isn't there by default, it copies it from the Utilities folder. But in the latest version, I can't find it in the utilities folder either. I'll do a reinstall to double check that. brb
OK, yes, that is the issue at the command line level. With xmm.binary it works (I copy it from Utilities to Demo). In version 3.3 I did a search through the entire directory and can't find this file, but it works if I get it from an old version. If I do that, then I can get the TV working with the new .inc file. To be more precise, xmm.binary needs to be in the same folder as the file that is being compiled, and for me that is the Demos folder.
Now, on to code::blocks, which is not working with xmm.
Hi Dr_A,
I will try to replicate the problem. Please post the code you are compiling, and also post the build log from the Code::Blocks compile.
As for XMM.binary, you need to explicitly compile this yourself by compiling the utilities - no pre-compiled binary is provided for this since it is platform dependent. If you are using an old binary, it may not be for the correct platform.
Ross.
EDIT: There is no need to copy XMM.binary around - when you build the utilities folder, it is copied to the bin folder, and payload knows to look for it there.
Ross, on another topic... I've interested also on your multithreaded and multicog examples.
Visual Studio always gives a ton of warnings about old C functions not being "thread safe".
I see a not in the documentation that says multicog calls may not be "cog safe" in this free version.
But, what about multithreaded mode? Is every thing "safe" there?
No. Some things are thread safe, and some are not. I'd have to check to be sure, but I think library functions like malloc() and free() are not inherently thread safe.
I'll check out each function when I get time, but best to assume for the moment that any complex library function is not thread safe. Most of the simple library functions probably are, but (for example) most of the stdio functions are probably not.
Ross, Question about the "sst" Star Trek example. I noticed it uses a cog for the math library...
Is this cog acting like a math coprocessor? Or, is there some other purpose?
Ross, Question about the "sst" Star Trek example. I noticed it uses a cog for the math library...
Is this cog acting like a math coprocessor? Or, is there some other purpose?
Yes, the extra cog is used like a floating point co-processor, exactly the way the Float32 OBEX package is used from Spin (in fact it is based on that code). Unlike the LMM kernel (which incorporates basic floating point functionality, and therefore doesn't need an extra cog) the XMM kernel cog uses so much space for the XMM access functions that it has no space available for even the basic floating point functions - therefore I pass all floating point requests off to another cog to execute.
Ross, I'm suddenly having trouble building the XMM utilities for SuperQuad... My project (startrek_xmm) has "SMALL" mode selected.
But, I'm getting an error that "LARGE" mode is not supported by SuperQuad.
I can't figure out why it wants to do large mode when I'm telling it to do small mode...
This used to work... Any ideas?
Ok, well I reinstalled Catalina and now it works... So, I must have done something to mess it up...
I think I see the "Large" option is used when building XMM tools even in small mode.
So, I must have done something wrong when I edited the Flashpoint_DEF.inc file...
Ross, I'm suddenly having trouble building the XMM utilities for SuperQuad... My project (startrek_xmm) has "SMALL" mode selected.
But, I'm getting an error that "LARGE" mode is not supported by SuperQuad.
I can't figure out why it wants to do large mode when I'm telling it to do small mode...
This used to work... Any ideas?
Ok, well I reinstalled Catalina and now it works... So, I must have done something to mess it up...
I think I see the "Large" option is used when building XMM tools even in small mode.
So, I must have done something wrong when I edited the Flashpoint_DEF.inc file...
There are some places internally where I use the LARGE flag when building things just to enable XMM functionality - I could have just as easily used SMALL.
If you still have your edited files, zip them up and post them and I'll take a look.
Ross I sent you another donation just now. For the code::blocks work.
I'll be taking a look at the xmm issues tonight after work. I want to get it working on one platform as I have some ideas now for different memory layouts now that I have discovered that the 320x240 displays Rayman et al have been using are available for less than a LCD TV. These work fastest with a 16 bit address. Am thinking that if you use one of these, you don't need TV or VGA pins, and that frees up some pins. Possibly don't need mouse either (2 more pins) because many of these displays come with a touchscreen. Probably need keyboard though. So 2 pins for eeprom, 2 for serial, 2 for keyboard and that leaves 26 pins to share with the ram, sd card and display in all sorts of cunning ways.
The big plus may be that these displays come with drivers written in C.
Well, i just got my first demo program working... For some strange reason the TV that was connected to the ASC turned blue and a blinking white cursor appeared at the left corner of the screen. Is it supposed to do that? And no "Hello world" message appeared either. Did i do something wrong?
@Dr_Acula... Yeah, that is the exact line of code i put between the brackets where it says //insert code here. I know it is not the board, because i have used it for other video applications already. Do you think it sent the message to the serial terminal?
Ross I sent you another donation just now. For the code::blocks work.
Thanks, Dr_A - it wasn't really necessary, but it is much appreciated.
By the way, I'm very glad you told me! It made me log into PayPal, which I haven't done for months - and it seems there have been some other contributors in recent months of which I was completely unaware - for some reason I have not been getting the PayPal emails that I used to receive.
To all those who have donated in the last few months - I'm sorry that I have not acknowledged your contributions! Everyone who has donated is entitled to a copy of the Catalina Optimizer, so I shall try and make sure I send out a copy to each of you.
Well, i just got my first demo program working... For some strange reason the TV that was connected to the ASC turned blue and a blinking white cursor appeared at the left corner of the screen. Is it supposed to do that? And no "Hello world" message appeared either. Did i do something wrong?
The blue screen with white cursor means the TV plugin is running correctly. Is it possible that you have compiled and downloaded the debug version, not the release version (the debug version will wait for the debugger to be started before proceeding).
Comments
No worries, graffix. Spin is a good starting point if you are new to microcontrollers and especially if you are new to the Propeller. Don't feel you have to start out with C - for most people C is the second or third language they learn (many people never learn it at all).
Anyway, there's no rush - C has been around for 30 years, and is not going to go away anytime soon
Getting this error when compiling:
I have had problems before with xmm.binary and so I do have quite a few copies of it in various folders. This is a deliberate clean new install with the old directory renamed and archived as I didn't want any complexities with out of date files.
Addit: I tried "Build XMM Utilities" and this fixed this error. Any chance that could be added to the Getting Started manual as it seems to be an essential step?
Now there is another error. When I use Build/Build it runs through all the compilation process and then says "compiled image exceeds 65536 bytes".
Ross, I think maybe you missed this question...
Also, I have a related question now... Regarding 1k versus 8k cache. Is there any way to tell if 8k is going to be too much? The sst example seems to work with 8k selected...
Ross.
I've been thinking more about caches. I posted a new thread yesterday about a new display that uses the arduino footprint. If this works, and it can be deselected (probably a matter of keeping /rd high or something), then you can allocate more pins for memory. Say 2 for download, 2 for eeprom, 2 for keyboard, 2 for mouse. Then, counting down from P23, three pins to a HC138 to select 1 of 8. This 1 of 8 selects SD card, other SPI devices, the display, and memory /rd and memory /wr, plus a single latch. That now leaves 21 propeller pins for memory access, which gives you 2^13 address pins = 8k. A single latch to select which 8k bank.
The memory access pins are shared with the display driver pins, and you might have a cog that handles block move of memory from a hub buffer into the external display.
That could give you fast cache access as you can refresh the cache with no latch changes. That ought to be almost as fast as Cluso's fastest driver.
I can certainly add in a "this program cannot be run in SMALL mode" message if the size of the C segments exceeds 32k.
But figuring our how big the cache can be is much more difficult. I'll give that one some thought. Most likely I would need to add some kind of "tide mark" option for determining the maximum program stack usage at run time, - then you would need to test this out by actually running the program.
Ross.
Catalina is geared to cope with XMM RAM pin conflicts - fast parallel XMM RAM takes so many pins that this is a common scenario on many boards.
Ross.
Correct. The C program still needs to fit into 32k. What the two phase loader does is load all the cog code in phase 1, so that in phase 2 the space that code occupied can then be used as C program code space. Without the two phase loader, this space can be used as data space, but not as code space.
Ross.
I'm looking at the CodeBlocks "emm_demos" and the startrek_emm project.
When, I build it, it works, but the file is 98kB. When I look it build options, "small" is selected.
I'm trying to reconcile this with what you said earlier about the different MMs...
There was no MEM_SIZE set either and it didn't complain... What does MEM_SIZE do? I don't get it...
Sorry - my mistake. The list should have read:
SMM: program <= 32k (i.e. TINY), two phase "SDCARD" loader
EMM: program <= 32k (i.,e. TINY) two phase "EEPROM" loader (LMM version)
EMM: program > 32k (i.e. SMALL or LARGE), two phase "EEPROM" loader (XMM version)
XMM: program > 32k (could be either SMALL or LARGE), two phase "XMM" loader.
The size of the startrek_xmm.eeprom file should be 96k (98,304). That''s 32k loaded during phase 1, and 64k (the default C program size unless you specify otherwise) of XMM code and data.
I made the default size 64k since many Propeller boards have 64k eeproms - but that was before I finalized the two-phase load functionality. The default size doesn't really make any sense now, and certainly doesn't make any sense for the XMM loader, and I should just remove it (or perhaps add it to the DEF file, so it is configurable per platform).
Ross.
How does an emm program execute 64kB of (emm?) code and data? Doesn't it still have to fit in 32kB of hub RAM?
Are you executing out of EEPROM (that sounds too slow to be true)?
Ah! I see I've only added to the confusion by my last update (serves me right for trying to answer posts while in the middle of shifting a couple of chicken coops!). I've updated my posts above yet again.
Nothing ever executes out of EEPROM. Programs are only ever loaded out of EEPROM - either into Hub RAM (TINY programs) or into XMM RAM (SMALL or LARGE programs). And so there are actually two different EEPROM loaders - one for LMM (TINY) programs and one for XMM (SMALL and LARGE) programs.
I always find examples help...
Here is an example of a command that compiles a TINY LMM program that can be loaded out of EEPROM into Hub RAM but using only the normal Parallax one-phase loader (which means that only the space left after all the cog code has been included is available for C code):
-D EEPROM means to include the EEPROM loader. In this case it uses the LMM EEPROM loader. This adds a 32k phase 1 loader to the program, making the final file size 64k.
-e tells Catalina to create a .eeprom file (however, since this is an XMM program, the file size will now default to 64k, not 32k - this is the size that MEM_SIZE affects).
-D EEPROM means to include the EEPROM loader. In this case it uses the XMM EEPROM loader. This adds a 32k phase 1 loader, making the final file 96k.
P.S. I've just re-read the documentation, and I agree it is a bit confusing since it doesn't make the distinction between the two EEPROM loaders very clear either - I will update it.
The xmm version is a Catalyst demo, I think.
But, I still don't completely understand the 96kB you mentioned a little earlier... Perhaps the actual program to be loaded into flash is stored in the 64kB eeprom and the loader part comes from somewhere else...
Anyway, my current understanding leads me to think that I should focus on "xmm" and Catalyst. I think that's were the real payoff is...
I'll fix the terminology inconsistency in the next version. There's a few other cases as well.
The MEM_SIZE option refers only to the C code size, not the final file size once the two-phase loader is added. The two phase loader always adds 32k, so if you have a 64k EEPROM you'd have to say MEM_SIZE=32k. If you had a 128k EEPROM you would have to say MEM_SIZE=96k.
Silly, I know - but I'm planning to rework the MEM_SIZE option for the next release, so don't worry about it too much. I may remove it altogether.
Ross.
I have been having multiple problems with trying to get an xmm program running on code::blocks, so I have gone back to the command line for the moment. Still getting some odd behaviour. I am tracing it through and something has changed from v 3.0 to v 3.3
First test - go back to version 3.0 and run a download using vga and no xmm
catalina -lc -D DRACBLADE -D HIRES_VGA NEW.C
this works.
add in XMM
catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA NEW.C
and this works too.
Now do the same thing with version 3.3
catalina -lc -D DRACBLADE -D HIRES_VGA NEW.C
which works
catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA NEW.C
this does not work and prints garbage yellow on blue characters on the screen.
This is using the command line (code::blocks has other problems to solve and I need to simplify the debug process) and with the July version of the dracblade hmi file that does not include TV (again, not ready for that new file as it adds another variable).
Firstly, can you replicate this problem? ie will this compile
catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA NEW.C
Second, is it correct that in version 3.0, in the Target directory, there are only a few ".inc" files but in version 3.3 there are many more? I am wondering if either your directory structure has changed, or a file location has changed?
Addit: Just hold answering that for the moment. I have a fudge solution by copying xmm.binary from an old directory into c:\program files\catalina\utilities
My problem now is that I have forked the debug process, as your default compiler does not have xmm.binary in that location, so I can't be sure I am comparing like with like esp wrt code::blocks compilations that are failing.
Sorry, more additional information. My IDE needs xmm.binary in the Demos folder and because it isn't there by default, it copies it from the Utilities folder. But in the latest version, I can't find it in the utilities folder either. I'll do a reinstall to double check that. brb
OK, yes, that is the issue at the command line level. With xmm.binary it works (I copy it from Utilities to Demo). In version 3.3 I did a search through the entire directory and can't find this file, but it works if I get it from an old version. If I do that, then I can get the TV working with the new .inc file. To be more precise, xmm.binary needs to be in the same folder as the file that is being compiled, and for me that is the Demos folder.
Now, on to code::blocks, which is not working with xmm.
But, I'm opened up again the CodeBlocks emm_demos and see this note:
IMPORTANT NOTES:
The EMM projects in this directory each build a 64kb .eeprom file which must be loaded into the Propeller EEPROM using an external program, since EEPROM files larger than 64k cannot be loaded using either the normal Parallax serial loader or Payload.
Is it supposed to say "larger than 32k"? (Also, btw I think most people use "B" for byte and "b" for bit.)
I still don't really see how the second EMM (>32kB) option is supposed to work... Is this supposed to load XMM from a second EEPROM maybe?
If not, can you give an example of a system and where the 96kB goes?
One more question... I think it'd be really nice if it were possible to load a <64kB program in two steps via the serial connection.
I thought that was possible. But, now that I read you notes, it sounds like it is not...
Visual Studio always gives a ton of warnings about old C functions not being "thread safe".
I see a not in the documentation that says multicog calls may not be "cog safe" in this free version.
But, what about multithreaded mode? Is every thing "safe" there?
Hi Dr_A,
I will try to replicate the problem. Please post the code you are compiling, and also post the build log from the Code::Blocks compile.
As for XMM.binary, you need to explicitly compile this yourself by compiling the utilities - no pre-compiled binary is provided for this since it is platform dependent. If you are using an old binary, it may not be for the correct platform.
Ross.
EDIT: There is no need to copy XMM.binary around - when you build the utilities folder, it is copied to the bin folder, and payload knows to look for it there.
No. Some things are thread safe, and some are not. I'd have to check to be sure, but I think library functions like malloc() and free() are not inherently thread safe.
I'll check out each function when I get time, but best to assume for the moment that any complex library function is not thread safe. Most of the simple library functions probably are, but (for example) most of the stdio functions are probably not.
Ross.
Is this cog acting like a math coprocessor? Or, is there some other purpose?
Yes, the extra cog is used like a floating point co-processor, exactly the way the Float32 OBEX package is used from Spin (in fact it is based on that code). Unlike the LMM kernel (which incorporates basic floating point functionality, and therefore doesn't need an extra cog) the XMM kernel cog uses so much space for the XMM access functions that it has no space available for even the basic floating point functions - therefore I pass all floating point requests off to another cog to execute.
Ross.
But, I'm getting an error that "LARGE" mode is not supported by SuperQuad.
I can't figure out why it wants to do large mode when I'm telling it to do small mode...
This used to work... Any ideas?
Ok, well I reinstalled Catalina and now it works... So, I must have done something to mess it up...
I think I see the "Large" option is used when building XMM tools even in small mode.
So, I must have done something wrong when I edited the Flashpoint_DEF.inc file...
There are some places internally where I use the LARGE flag when building things just to enable XMM functionality - I could have just as easily used SMALL.
If you still have your edited files, zip them up and post them and I'll take a look.
Ross.
I'll be taking a look at the xmm issues tonight after work. I want to get it working on one platform as I have some ideas now for different memory layouts now that I have discovered that the 320x240 displays Rayman et al have been using are available for less than a LCD TV. These work fastest with a 16 bit address. Am thinking that if you use one of these, you don't need TV or VGA pins, and that frees up some pins. Possibly don't need mouse either (2 more pins) because many of these displays come with a touchscreen. Probably need keyboard though. So 2 pins for eeprom, 2 for serial, 2 for keyboard and that leaves 26 pins to share with the ram, sd card and display in all sorts of cunning ways.
The big plus may be that these displays come with drivers written in C.
Have you told it to print anything on the screen? eg
printf("Hello World\n");Thanks, Dr_A - it wasn't really necessary, but it is much appreciated.
By the way, I'm very glad you told me! It made me log into PayPal, which I haven't done for months - and it seems there have been some other contributors in recent months of which I was completely unaware - for some reason I have not been getting the PayPal emails that I used to receive.
To all those who have donated in the last few months - I'm sorry that I have not acknowledged your contributions! Everyone who has donated is entitled to a copy of the Catalina Optimizer, so I shall try and make sure I send out a copy to each of you.
Ross.
The blue screen with white cursor means the TV plugin is running correctly. Is it possible that you have compiled and downloaded the debug version, not the release version (the debug version will wait for the debugger to be started before proceeding).
Please post your code::Blocks build log.
Ross.