Catalina 3.4
RossH
Posts: 5,512
All,
UPDATE: Catalina 3.5 is now available. See here.
Catalina 3.4 is now available on SourceForge (here). A Windows "one touch" installer is provided which installs both Catalina and Code::Blocks, as well as Linux (32 and 64 bit) tar/gzip files.
Release 3.4 is a full release of Catalina. Here is a list of the changes:
UPDATE: Some users have reported their Code::Blocks Tools menu is empty (apart from a single Configure Tools... entry) after installing Catalina and Code::Blocks. This situation occurs when installing Catalina as a user that does not have administrator rights. In this case, you will have to manually set up the Code::Blocks default.conf file for that user (which is where the menu entries are stored). You will also have to set this up for each additional user on the same PC that wants to use Code::Blocks.
Attached to this post is a sample default.conf file. You will have to put this file in the windows %APPDATA%\codeblocks folder. One way to do this is to shut down Code::Blocks, open a Winodws command window and then type the following commands:
UPDATE: Catalina 3.5 is now available. See here.
Catalina 3.4 is now available on SourceForge (here). A Windows "one touch" installer is provided which installs both Catalina and Code::Blocks, as well as Linux (32 and 64 bit) tar/gzip files.
Release 3.4 is a full release of Catalina. Here is a list of the changes:
- Fixed a bug in setjmp()/longjmp() implementation - these routines were not correctly saving/restoring the registers, which meant register variables were being lost.
- Fixed a bug in the code generator which meant that multiply, divide and mod operations were not being "spilled" properly in case another such operation was performed before the result of the first was saved, leading to corrupt values. This occurred most commonly in parameter lists that contained arithmetic expressions for more than one such parameter.
- The Windows "One touch" installer now does not install the Catalina source code by default - it is now an option. This was done to improve the install speed on slower Windows machines.
- The Windows "One touch" installer now prompts before overwriting any modified versions of "Custom" configuration files – these are any files with a name like Custom_*.* in the basic, simple or target folders - this ensures any custom modifications are not accidentally lost just because an upgrade to a new version of Catalina is installed. However, note that completely uninstalling Catalina will delete these files.
- Fixed error message detection for Homespun errors - some messages were not being correctly identified as errors.
- Fixed an error in building the utilities for the SuperQuad – the script used tried to build them using the LARGE memory mode, but this gave an error message about the mode being not supported. Now it builds them with the SMALL memory model (this makes no difference to boards that support both SMALL and LARGE).
- Modified the DracBlade_HMI.inc file to allow TV HMI options, since some DracBlades now support TV output. However, the default is still HIRES_VGA, so for TV support you must specifically define the TV symbol (or HIRES_TV or LORES_TV).
- The default size for all XMM programs is now 16M (16777216), so it is no longer necessary to specify the -M option in most circumstances (except when also using the -e option, or all .eeprom files will end up 16M in size).
- Rewrote the LMM Support, XMM Support and EMM Support sections in the Catalina Reference Manual to clarify the different targets and loader options.
- Fixed the demo build_all scripts to make the program names align with the Code::Blocks names for the same programs.
UPDATE: Some users have reported their Code::Blocks Tools menu is empty (apart from a single Configure Tools... entry) after installing Catalina and Code::Blocks. This situation occurs when installing Catalina as a user that does not have administrator rights. In this case, you will have to manually set up the Code::Blocks default.conf file for that user (which is where the menu entries are stored). You will also have to set this up for each additional user on the same PC that wants to use Code::Blocks.
Attached to this post is a sample default.conf file. You will have to put this file in the windows %APPDATA%\codeblocks folder. One way to do this is to shut down Code::Blocks, open a Winodws command window and then type the following commands:
cd %APPDATA% mkdir codeblocks cd codeblocks notepad default.confThen copy the contents of the attached file to this file (you should delete any existing content). Then save it and restart Code::Blocks. Note that if the codeblocks directory already exists (i.e. you have already run Code::Blocks at least once) you will see an error message when you try to create it - just igore it and carry on.
zip
808B
Comments
The version of the XMM EEPROM loader causes an error because symbols I2C_PIN and I2C_DEV are being redefined. Replace the version in the Catalina\target folder with the attached version. This will only affect you if you are building XMM programs to be programmed into EEPROM.
Also, I have attached here the new version of payload (Windows only). Replace the version in the Catalina/bin folder with the attached version for faster downloads, and with the new interactive terminal mode added.
Ross.
Ray
BTW: Did you use my versions of FlashPoint_Def and Inc for this release? I'll change my guides if you did...
Is there some kind of hidden stack space somewhere, like there is in Spin.
There was a recent thread where a Spin code went bezerk because it ran out of stack space.
Can this happen in Catalina too?
What do you mean by "hidden stack space" in Spin?
As far as I can see it is all out in plain sight.
The top level object has it's stack in the free space at the top of HUB. Methods run in other COGs have their stacks where the programmer has defined them to be.
It might be a bit tricky knowing how much stack you need for your objects and that is true in C as well.
Yes, it's hidden in plain sight. You don't tell it where it is or how big it is, the stack just takes up residence in left over space.
The worst part is that there are no errors or warnings if stack space is breached...
I'm a fan of SPIN, but the stack is one weak point.
I am just wondering if Catalina has the same issues...
Ah yes, hidden in plain sight.
This is not really Spin's fault. Languages like C, Pascal, Ada etc have the same problem.
In general it's impossible for the compiler to know your run time stack usage at compile time. Especially if there is any possibility of recursion.
Some compilers for some languages do count up all the params and local variables used by functions and allocate stacks or issue errors accordingly. This is quite a complex thing for a compiler to do an still fails in the face of recursion.
In fact I have only seen one compiler do this, for the X chip.
Of course on operating systems like Windows and linux this issue is really hidden as potentially gigantic stacks that are never actually fully used can be created as virtual memory.
So, when threads arrived you would often have to do things like
pthread_attr_getstacksize (&thread_attributes, &stack_size); if (stack_size < 200*1024) { /* If less than 200KB */ pthread_attr_setstacksize (&thread_attributes, (200*1024)); ..The default thread stack size has increased a bit nowadays, but it still pays to check it if you have code which e.g. allocates big arrays on the stack (that's just declaring an array inside a function).-Tor
Oops! I forgot all about that. Sorry - next release.
Ross.
Yes, there are propeller-specific functions described in the Catalina Reference Manual - see the section "Cog Functions" on page 42.
Ross.
Yes, running out of stack space is possible in Catalina (as it is in most languages). But (unlike Spin) at least you don't have to reserve a specific amount in advance - Catalina will use whatever Hub Ram is available as stack space.
Ross.
Does a program just go haywire, like with Spin, when it runs out of stack space?
In procedural stack-based languages like C, the stack is critical. For example, all parameters and local variables in all functions are allocated on the stack (or else in registers). So having the stack in SRAM would be way too slow. However, with the LARGE memory model, the heap and all global variables are in SRAM
And yes, your program will just go haywire if it runs out of stack space. Typically, it would start overwriting the heap, or perhaps some plugin data (like the screen buffer). One day I'll add a stack "tide mark" capability to Catalina to allow you to assess your stack usage at run-time. It's on my "to do" list
Ross.
Ross: I put Catalina in C:\Catalina34 folder. I did not uninstall Catalina3.3 that resides in another folder. I modified the "use_catalina.bat" file to point to the Catalina folder. Was this necessary (didn't check beforehand).?
Probably not. What determines which version of Catalina will be used is the setting of the LCCDIR environment variable. Just make sure this is set to which ever version you want to use, and then use_catalina should not need to be modified.
Ross.
Thanks Ross!
It's very convenient. Only downside is the download takes >1 minute. I think I need to figure out how to load from SD card...
Can I do this from within Code::Blocks? I think I need to copy over the sst.binary file to the SD card myself, right?
Then what? Can I start it then from inside Code::Blocks?
Hi Rayman,
You can build Catalyst from the Code::Blocks Tools menu (this will build the core binary, which is all you really need - you don't need any of the utilities or demo programs). Then program the resulting catalyst.bin (which will be in the catalyst\bin subdirectory) into EEPROM. From then on you can just copy any binary from the Code::Blocks release folder to an SD card and then launch it within Catalyst. Be sure to rename the file to have a DOS 8.3 filename, with a .bin extension - this is the one thing I have not figured out how to make Code::Blocks do!
Ross.
I was thinking the "Program EEPROM" tool would program the eeprom with the sst file and not Catalyst. Is that wrong?
Yes, that's wrong
I didn't create a specific tool for programming Catalyst. I can do so in the next release if you would like. Or you can create one yourself. The command to add would be very simple:
You can just run this from a Catalina Command Line window, or add a new entry to the Code::Blocks Tool menu.
Ross.
I suppose I can't just download Catalyst to RAM and have it run sst.binary off of the SD card, right?
Maybe another nice addition would be a Tool that brought up an explorer window with my sst.binary file in it, so I wouldn't have to hunt for it.
(Pretty lazy, aren't I?)
It seems we are both at the 'cutting edge' of using this.
Rather than put Catalyst in eeprom, I took the initial step of keeping Kyedos as my OS and running Catalyst (another OS) from Kyedos. This works well. However I'm not quite ready to make Catalyst my eeprom OS as I ran into problems with Catalyst rebooting once it had run a program. In fact I couldn't get programs to 'reboot' at all (which on my setup ought to run Kyedos). As a simple test, I tried running Catalyst from itself and that hung the system.
I am not sure how much of Catalyst stays around after it runs another program. Kyedos does not stay around at all, but any program running under Kyedos "ends" by issuing a reboot to the propeller. Because Kyedos loads off the eeprom very quickly (about a second) this approach seems to work. Catalyst seems fast too.
But I'm not sure what approach Ross has taken with Catalyst. What would happen for instance, if you had Catalyst in eeprom and you ran a C program that just had an empty "main"? Would that jump back into Catalyst again?
Sure are!
Ross.
Dr_A, Catalyst leaves nothing in memory. When your C program exits it reboots the Propeller, and if Catalyst is loaded in EEPROM it will restart.
Ross.
Great - that will make it pretty much the same as Kyedos.
I must say that I am really getting to like the code::blocks/catalina combo. It makes programming a pleasure!
Ross.
Yes oops, got that the wrong way round LOL.
Though seriously, one thing that might be an issue is that there may be some who do not know what 'catalyst' is. KyeDOS has 'DOS' in the name for a reason, and I wonder if Catalyst is not getting the recognition it deserves because it is not entirely obvious what it is? Maybe in the future the word 'catalyst' could be associated with a one line statement saying that it is a simple operating system for the propeller that allows you to run programs stored on an SD card.
Or whatever one line description you like.
Hmm - maybe we need a promo photo. Here is a photo of 'catalyst' - an operating system for the propeller. And here it is running a compiled version of "Hello World". And here is the source for "Hello World".
I'm looking at the full page ad from Parallax on the back page of Circuit Cellar right now. Maybe one day Catalina could be in that photo
LOL! You're showing your age, Dr_A
Ask any kid what DOS means and they'd probably think you mean either the Nintendo game Dawn of Shadow - of if they were real geeks they might think you meant Denial of Service (although come to think of it, the latter is surprisingly accurate when describing a Microsoft O/S).
Ross.