However, from my perspective this is all good because it has meant a lift in the number of downloads of Catalina - which is currently the onlyfully functional ANSI C compiler available for the Propeller, providing both a command line and a GUI (sorry, have to get my sales up while this is still the case!).
You are right about that. You've done an excellent job of developing and supporting Catalina and have produced a good product. Congratulations! I'm glad others think so too!
Just to make sure there's no misunderstanding - I use the CLI and I was surprised about the way -D worked, but I knew about that long before I started using Catalina and it was only that, a slight surprise - I have no problems with it. As was said by another poster, there are no bugs, it's documented and it works as documented. So to me it's just a "duly noted", no problem. I don't mind if it's changed, but I would rather see the focus on more important things, including anything that Ross thinks is more fun to work on. (After all, the only reason I myself work in the software industry is to have fun doing it. So I program as a hobby and I got a job where I can do the same. Fun is important and is more often than not the reason for great products, as a side effect).
My 2 cents worth on the command line / GUI debate. As a non power user with Vista I prefer the GUI. I can and have done the command line also even though I have to look up the syntax each time which is a bit of a bother. Is there a place for both? Definately! To each his own! If there is subtle differences so be it its documented!! Get over it!
I kinda equate command line / gui to ham radios CW mode. Is it viable to use CW yes a simpiler system to create can get through in the worst of band conditions. Is it my choice of operating modes..NO but I feel it has its place. Please no holy wars on ham radio modes!!
I personaly think Ross has done an excellent job with Catalina and he and Raymond have always been here to hold my hand and answer my questions, Thanks guys!
And this thread has recently taken on a negative tone and I debated several days before responding. Any project/ software that promotes the Prop should be embraced!
Just my feeling and I will go back to lurking for awhile.....
On another note, what are people using Catalina for? I'd be interested to hear about what sorts of projects it is being used for and how well it is working out. I'm interested in all applications of C on the Propeller. I'm even a card-carrying Catalina optimizer owner so I would certainly like to see Catalina continue to flourish. Can people talk about their experiences with using it to develop serious applications on the Propeller?
It's easier to stay quiet. What I write here is meant with the best intentions. Please accept that.
I've stayed out of this thread except for trying to be an honest user in a few posts with questions. One observation probably distracted from keeping the best dress on the presentation of Catalina 3.4 - it was just a statement of fact and something I could get used to. An alternative was mentioned by Ross which seems fine.
Everyone has their own tastes and interpretations of things. Everyone can also read and filter information however they like. However just reading and writing on a forum is no substitute for in person communications. Every first personal meeting I've had with forumists from here in Rocklin has been positive without exception and has positively changed any previous perceptions.
RossH and I have seemingly come to an "on the level" resolution of whatever conflicts seem to have come about for one reason or another. Ross is a good guy just like many who post here. We have mis-communicated at times which has led to misunderstanding; that makes me sad considering some of the greater things that could have emerged. I "voted for" his Parallax contributor recognition at UPEW when I had that chance, and I would do it again because of his dedication.
Ross has been very patient with me and my suggestions and questions for years now, and I appreciate that. He "sticks to his guns" (principles) which is respected in many cultures, though sometimes questioned. He produces what he is happy to produce.
Catalina does things the way Ross wants it to work and it's his baby. I accept that. It's his product his way. Many will like his full vision, others may not. It is a matter of personal choice.
I've never been in a workplace room with more than 4 C programmers where everyone has exactly the same preferences. There are always differences of opinions, perceptions, and personal choices whether they are communicated or not. In the end though, with the right spirit things always come out right.
Finding the right spirit is harder for some than others and spirit does require motivation. Motivation here should be the desire to lift all boats in all contributions. Well that's my take. I'm sure there are other takes too. Mine is not the only one.
Ross, Any new thoughts about porting Catalina to Prop2, now that you've seen the instruction set?
Any chance I can write an MP3 decoding function now that will run (very slowly) on Prop1 and have that same code magically work (much faster) when you and Parallax are finished with Prop2?
Ross, Any new thoughts about porting Catalina to Prop2, now that you've seen the instruction set?
Any chance I can write an MP3 decoding function now that will run (very slowly) on Prop1 and have that same code magically work (much faster) when you and Parallax are finished with Prop2?
LMM/XMM on the Prop2 should be very interesting. The quad fetch and the CLUT seem like they offer opportunities for speed improvement beyond just what we get with the faster clock speed. I think Bill Henning is working on this as well. Maybe Ross and Bill can work together to come up with a common LMM/XMM platform for Prop2.
Ross, Any new thoughts about porting Catalina to Prop2, now that you've seen the instruction set?
Any chance I can write an MP3 decoding function now that will run (very slowly) on Prop1 and have that same code magically work (much faster) when you and Parallax are finished with Prop2?
LMM/XMM on the Prop2 should be very interesting. The quad fetch and the CLUT seem like they offer opportunities for speed improvement beyond just what we get with the faster clock speed. I think Bill Henning is working on this as well. Maybe Ross and Bill can work together to come up with a common LMM/XMM platform for Prop2.
I haven't really had time to look at the Prop 2 instruction set in detail yet - I'm not in a great hurry since I think the Prop 2 is still quite a long way away.
My initial intention (which probably still stands) was just to do a "minimal" port of Catalina to the Prop 2, and then extend it bit by but to take advantage of some of the neat features available only on that chip. The quad fetch has potential for dramatic speedups, and should pretty much eliminate the need for FCACHEing stuff (not that FCACHE is bad - I'm quite impressed by how much it speeds up small programs - it's just that it doesn't speed up the kind of programs I write much at all, whereas I think the quad fetch probably will). I'm not so sure about the CLUT yet. I've kind of lost track of that. I think someone implied it might be able to be used for an "in-cog" stack? Neat, but I'd probably not use it for that myself for two reasons: (1) it would be too much like ICC all over again, and (2) I don't think the compiler should limit what you can do in a cog yourself. The latter is the reason Catalina doesn't take advantage of some of the really neat tricks that can currently be done with the special registers in the current Prop (e.g. the "b" registers or the counters) - if Catalina used them, then your program couldn't.
But updating the code generator to suit the Prop 2 is the simplest part - modifying it (and the LMM kernel) would take only a few days. The main problem is the HAL. That there is as yet no Spin compiler or PASM assembler for the Prop II, and it seems neither Brad C nor Michael Park are interested in writing one (I've asked them). The Parallax one (assuming there even is one!) will probably never be adequate for this type of work since I doubt that they will implement all the really neat extensions that Michael and Brad implemented and which Catalina now uses (#ifdef, longer symbol names, listings, decent symbol table sizes etc). This means I would probably have to "roll my own". Assemblers are not such a problem - I started work on my own a while ago, and (from memory) I think Bill Henning also has one???. But I also make use of Spin in the HAL - without a Spin compiler I couldn't so easily use a lot of the OBEX stuff I currently use. So then I have the choice of either rewriting the HAL in PASM, or writing my own Spin compiler - the first is not much fun and the second (i.e. writing my own Spin compiler just so I can port my own C compiler) seems just a little stoopid.
On another note, what are people using Catalina for? I'd be interested to hear about what sorts of projects it is being used for and how well it is working out. I'm interested in all applications of C on the Propeller. I'm even a card-carrying Catalina optimizer owner so I would certainly like to see Catalina continue to flourish. Can people talk about their experiences with using it to develop serious applications on the Propeller?
Hi David,
I'm aware of a couple of commercial developments using Catalina - but they don't seem to want publicity (I'm not sure they even frequent these forums, unless they do so under different names) so I can't give you any details. Actually, I couldn't even if I wanted to - I just get odd support requests by email, and have to try and figure out from those what the heck they are trying to do with it!
One thing though - even though I don't know what they are using it for, I was a bit surprised myself by who is using it.
Ross.
P.S. Another interesting datum - now that I host on SourceForge I can see where Catalina is being downloaded from. That's also very surprising!
I'm aware of a couple of commercial developments using Catalina - but they don't seem to want publicity (I'm not sure they even frequent these forums, unless they do so under different names) so I can't give you any details. Actually, I couldn't even if I wanted to - I just get odd support requests by email, and have to try and figure out from those what the heck they are trying to do with it!
One thing though - even though I don't know what they are using it for, I was a bit surprised myself by who is using it.
Ross.
P.S. Another interesting datum - now that I host on SourceForge I can see where Catalina is being downloaded from. That's also very surprising!
Thanks for the information. I didn't mean only commercial developments. I just wondered what anyone was doing with Catalina. There seem to be quite a few people interested but I haven't heard much about what they're doing. I did some Catalina work a while back with a simple Basic bytecode compiler. I'm intending to resurrect that now that I have Catalina 3.4 installed in a VM on my Macintosh. It wasn't really fast enough to be practical before but I never had a chance to try the optimizer and I think 3.4 has some improvements as well.
I am using Catalina on a commercial project that I cannot disclose. What I can say is this...
I am using 3 prop chips. One is on a handheld device and is primarily pasm. The second and third props are on a different pcb mounted in it's own box. The second handles the interface to the outside world and is pasm & spin. The third prop is a RamBlade (production pcb is RamBlade3 with 512KB SRAM, microSD, RTC and battery). This is the prop that uses Catalina (XMM mode) which handles the user interface (menu's, database on microSD, and controls the external devices, etc). Catalina calls fast pasm cogs for maths, etc. All comms off chip is via 2pin high speed serial.
Thanks for the information. I didn't mean only commercial developments. I just wondered what anyone was doing with Catalina. There seem to be quite a few people interested but I haven't heard much about what they're doing. I did some Catalina work a while back with a simple Basic bytecode compiler. I'm intending to resurrect that now that I have Catalina 3.4 installed in a VM on my Macintosh. It wasn't really fast enough to be practical before but I never had a chance to try the optimizer and I think 3.4 has some improvements as well.
Probably mostly playing - like me
Catalina 3.4 does not incorporate any performance or code size improvements (except one very small one) - I'm still working on those. These will be in Catalina 3.5 (I hope).
So far on the standard benchmarks I've got around 40% improvement in speed, and around a 5% reduction in code size. I'm not really driving for performance (Catalina will never beat GCC on small benchmark programs since it doesn't use FCACHE) but I'd really like to get the code size down further. Ideally, I'd like to get it down by another 10-15% - but that's proving to be very difficult!
Cluso99: Your project sounds quite ambitious. Sounds like XMM mode on the RamBlade should work quite well. Will you be able to tell us more about this once it's done?
Ross: Sounds like you're making great progress in optimization for Catalina 3.5. I agree that getting the code size down is a good goal. The more code you can fit in LMM mode the better and even XMM mode will benefit because of a higher cache hit ratio since more code will fit in a cache line.
Oops... I got bitten by something in my code I had forgotten about. I'm using unnamed unions in some of my structures in xbasic and Catalina doesn't support them. I ran into this once before and had to change them. To be honest, it was Catalina that made me aware that unnamed unions are not a standard ANSI C feature. I believe they are supported in C++ and in GCC even in C mode. I really need to change this because it is a non-standard feature and it was Catalina that made me aware of this!
Oops... I got bitten by something in my code I had forgotten about. I'm using unnamed unions in some of my structures in xbasic and Catalina doesn't support them. I ran into this once before and had to change them. To be honest, it was Catalina that made me aware that unnamed unions are not a standard ANSI C feature. I believe they are supported in C++ and in GCC even in C mode. I really need to change this because it is a non-standard feature and it was Catalina that made me aware of this!
Yes, if you want to write portable C when using GCC you really should compile with -std=c90 and/or -ansi (not sure if both are required - check the GCC documentation). The same is probably true of LCC (the option is -W-A for Catalina) but the extensions LCC supports are mostly to do with backward compatibility (e.g. functions without prototypes) and tend to be pretty portable anyway.
GCC has lots of nice extensions, but it also has lots of things that you can all too easily come to depend on - and end up with a completely unportable program. Unlike Micro$oft, I don't think they do this as deliberate policy to hogtie you into only using their compiler - but even so it is better not to get caught.
Normally I would try to stick with straight ANSI C. I just didn't know that anonymous unions were not part of ANSI C and GCC didn't warn me about that. It's easy to fix this problem. In fact, I thought I had already done this the last time I compiled xbasic with Catalina but somehow I must have lost that update. There is a lot more that needs to be cleaned up in xbasic anyway so I'll just add this to the list. I will also try the -std=c90 or -ansi options as you suggested.
I'm trying to use Code::Blocks and I'm wondering if I'm having trouble related to running it under a VM on my Mac. I'm trying to fix my anonymous union bug and I get lots of errors when I try compiling. This is what I would expect until I get this bug fixed. My question is, shouldn't I be able to double click on one of the error messages in the dialog box at the bottom of the Code::Blocks window to get the source code of the line with th error displayed in the source window? Nothing happens when I double click on one of the error messages.
I'm trying to use Code::Blocks and I'm wondering if I'm having trouble related to running it under a VM on my Mac. I'm trying to fix my anonymous union bug and I get lots of errors when I try compiling. This is what I would expect until I get this bug fixed. My question is, shouldn't I be able to double click on one of the error messages in the dialog box at the bottom of the Code::Blocks window to get the source code of the line with th error displayed in the source window? Nothing happens when I double click on one of the error messages.
Hi David
It depends on the error message itself. Code::Blocks is not "magic" - if there is no line number information in the error message itself then Code::Blocks can't take you to it. I have to manually parse every single error message generated by cpp, lcc, homespun, catalina, catbind etc etc to extract the line number information - and it is entirely possible I'm doing that incorrectly in some cases.
It depends on the error message itself. Code::Blocks is not "magic" - if there is no line number information in the error message itself then Code::Blocks can't take you to it. I have to manually parse every single error message generated by cpp, lcc, homespun, catalina, catbind etc etc to extract the line number information - and it is entirely possible I'm doing that incorrectly in some cases.
Post an example and I'll check it out.
Ross.
ummmm... I don't know what was going wrong before but I can't make it happen again. Forget it. Sorry for the false alarm!
xbasic is now compiling with Catalina 3.4 but the "Run" button isn't working for me. I get the following error:
Process returned 4217728 (0x405B80) execution time : 0.000 s
Press any key to continue.
Any idea what might be going wrong? I guess this could have something to do with the VM having trouble accessing the Propeller USB device.
xbasic is now compiling with Catalina 3.4 but the "Run" button isn't working for me. I get the following error:
Process returned 4217728 (0x405B80) execution time : 0.000 s
Press any key to continue.
Any idea what might be going wrong? I guess this could have something to do with the VM having trouble accessing the Propeller USB device.
The Run button won't work - that will try to execute it locally - which should fail. Do you mean the "Download to XMM RAM" Tool? Have you built the XMM utilities?
I run Linux in a VM, and sometimes have trouble accessing the USB ports, so it could indeed be that.
Sorry. I just instinctively pressed the "Run" button. This time I built the XMM utilities for the C3 and then selected "Download to XMM RAM". This started doing the download but ended up with some errors.
Launching tool 'Download to XMM RAM': payload.exe XMM xbasic (in C:\work\xbasic\xbasic-cat\bin\Release)
stderr> Using Propeller (version 1) on port COM5 for first download
stderr> Using Secondary Loader on port COM5 for subsequent download
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Error: too many retries for addr 00008000
Tool execution terminated with status 0
Sorry. I just instinctively pressed the "Run" button. This time I built the XMM utilities for the C3 and then selected "Download to XMM RAM". This started doing the download but ended up with some errors.
Launching tool 'Download to XMM RAM': payload.exe XMM xbasic (in C:\work\xbasic\xbasic-cat\bin\Release)
stderr> Using Propeller (version 1) on port COM5 for first download
stderr> Using Secondary Loader on port COM5 for subsequent download
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Warning: no sync received for addr 00008000
stderr> Error: too many retries for addr 00008000
Tool execution terminated with status 0
Hi David,
Odd. Can you download successfully from a non-VM machine? What options did you use when building the XMM utilities, and are they the same options you used for the program (cache, flash etc).
If you post your binary then I'll try loading it here.
Odd. Can you download successfully from a non-VM machine? What options did you use when building the XMM utilities, and are they the same options you used for the program (cache, flash etc).
If you post your binary then I'll try loading it here.
Ross.
I guess I had forgotten that I needed to enable an 8K cache in both the compiler options and the build options for XMM. I fixed that but still had the same problem. I suspect this has to do with running from a VM. I'll have to move this project over to my real Windows 7 machine and try it again.
I've seen that error a lot! There are lots of ways to make a mistake in Code::Blocks...
In my FlashPoint guide, I've tried to point out many of the things that can go wrong...
One thing to check is that you don't have conflicting build options in the "target" and "release" build options windows...
Odd. Can you download successfully from a non-VM machine? What options did you use when building the XMM utilities, and are they the same options you used for the program (cache, flash etc).
If you post your binary then I'll try loading it here.
Ross.
I just moved my code over to a Windows 7 machine and tried loading it into a different C3 board with the same results. I'm attaching my entire xbasic project in case you want to verify my build options. I was careful to build the XMM utilities with CACHE=8K and targetting the C3 board and my project settings for the xbasic project are the same. The Code::Blocks project is in xbasic/xbasic-cat.
I see 8K Cache selected in both "release" and project build options. That might be a problem (or might not be).
You also need to select "Flash Loader" in the build options.
I made those changes (and also selected "RamPage" instead of C3) and it seems to load OK.
I'm not sure if it's doing what it is supposed to do though... If I enter something, it comes back with "xV"...
I just moved my code over to a Windows 7 machine and tried loading it into a different C3 board with the same results. I'm attaching my entire xbasic project in case you want to verify my build options. I was careful to build the XMM utilities with CACHE=8K and targetting the C3 board and my project settings for the xbasic project are the same. The Code::Blocks project is in xbasic/xbasic-cat.
Thanks,
David
Hi David,
Rayman is right. I added the FLASH loader option and removed the duplicate 8K CACHE option and it downloaded and runs ok (but I get a syntax error whenever I try to execute a basic program containing a "print" statement).
I guess this error situation is one to add to the FAQ.
I think in the next release I will enhance the "Catalina Project Wizard" so that it also asks about caching and loader options. Then it could build the XMM utilities appropriately for the project as the last step in setting it up.
Ross.
EDIT: I just checked the FAQ to add it, and discovered it is already there! First question in the list!. However, I can't really claim "I told you so" since the answer is out of date - it has not been updated since I moved from using -x3 and -x4 to specify the flash loader to using -D FLASH. I will correct it in the next release.
Rayman is right. I added the FLASH loader option and removed the duplicate 8K CACHE option and it downloaded and runs ok (but I get a syntax error whenever I try to execute a basic program containing a "print" statement).
I guess this error situation is one to add to the FAQ.
I think in the next release I will enhance the "Catalina Project Wizard" so that it also asks about caching and loader options. Then it could build the XMM utilities appropriately for the project as the last step in setting it up.
Ross.
Ross and Rayman,
Thanks for the fix. I'm not sure I understand what you mean by "duplicate 8K CACHE option". Don't I have to enable the cache when using external memory?
I get a syntax error whenever I try to execute a basic program containing a "print" statement).
Ummm... for various reasons this version of Basic uses printf not print. So a program to count from 1 to 10 would look like this:
100 for x=1 to 10
110 printf("%d\n", x)
120 next x
I would change this to the more traditional "print" but I'm not sure this version of basic is likely to be used. It was more of a proof-of-concept that I could get the compiler running on small MCUs like the PIC24 and the Atmega328p. I chose this version to port to the Propeller because I was hoping it would fit in LMM mode (your TINY memory model) but it's still too big.
Thanks for the fix. I'm not sure I understand what you mean by "duplicate 8K CACHE option". Don't I have to enable the cache when using external memory?
Yes, on the C3 (or any other platform with Flash RAM, you must enable the cache - but you had it enabled twice. If you open the Build Options dialog, you will notice there is more than one node you can select in the left hand pane - and each node has the same set of options, so you can select it twice. You had the 8k cache option set for (I think) both the xbasic node and the Release node. Homespun generally spits the dummy if you define the same symbol twice.
This is the aspect of Code::Blocks that confuses most people. I can see the reason for it, but it sure is annoying sometimes!
Comments
So I'm not voting 'yes'.
-Tor
I kinda equate command line / gui to ham radios CW mode. Is it viable to use CW yes a simpiler system to create can get through in the worst of band conditions. Is it my choice of operating modes..NO but I feel it has its place. Please no holy wars on ham radio modes!!
I personaly think Ross has done an excellent job with Catalina and he and Raymond have always been here to hold my hand and answer my questions, Thanks guys!
And this thread has recently taken on a negative tone and I debated several days before responding. Any project/ software that promotes the Prop should be embraced!
Just my feeling and I will go back to lurking for awhile.....
I've stayed out of this thread except for trying to be an honest user in a few posts with questions. One observation probably distracted from keeping the best dress on the presentation of Catalina 3.4 - it was just a statement of fact and something I could get used to. An alternative was mentioned by Ross which seems fine.
Everyone has their own tastes and interpretations of things. Everyone can also read and filter information however they like. However just reading and writing on a forum is no substitute for in person communications. Every first personal meeting I've had with forumists from here in Rocklin has been positive without exception and has positively changed any previous perceptions.
RossH and I have seemingly come to an "on the level" resolution of whatever conflicts seem to have come about for one reason or another. Ross is a good guy just like many who post here. We have mis-communicated at times which has led to misunderstanding; that makes me sad considering some of the greater things that could have emerged. I "voted for" his Parallax contributor recognition at UPEW when I had that chance, and I would do it again because of his dedication.
Ross has been very patient with me and my suggestions and questions for years now, and I appreciate that. He "sticks to his guns" (principles) which is respected in many cultures, though sometimes questioned. He produces what he is happy to produce.
Catalina does things the way Ross wants it to work and it's his baby. I accept that. It's his product his way. Many will like his full vision, others may not. It is a matter of personal choice.
I've never been in a workplace room with more than 4 C programmers where everyone has exactly the same preferences. There are always differences of opinions, perceptions, and personal choices whether they are communicated or not. In the end though, with the right spirit things always come out right.
Finding the right spirit is harder for some than others and spirit does require motivation. Motivation here should be the desire to lift all boats in all contributions. Well that's my take. I'm sure there are other takes too. Mine is not the only one.
Best to all.
--Steve
Any chance I can write an MP3 decoding function now that will run (very slowly) on Prop1 and have that same code magically work (much faster) when you and Parallax are finished with Prop2?
I haven't really had time to look at the Prop 2 instruction set in detail yet - I'm not in a great hurry since I think the Prop 2 is still quite a long way away.
My initial intention (which probably still stands) was just to do a "minimal" port of Catalina to the Prop 2, and then extend it bit by but to take advantage of some of the neat features available only on that chip. The quad fetch has potential for dramatic speedups, and should pretty much eliminate the need for FCACHEing stuff (not that FCACHE is bad - I'm quite impressed by how much it speeds up small programs - it's just that it doesn't speed up the kind of programs I write much at all, whereas I think the quad fetch probably will). I'm not so sure about the CLUT yet. I've kind of lost track of that. I think someone implied it might be able to be used for an "in-cog" stack? Neat, but I'd probably not use it for that myself for two reasons: (1) it would be too much like ICC all over again, and (2) I don't think the compiler should limit what you can do in a cog yourself. The latter is the reason Catalina doesn't take advantage of some of the really neat tricks that can currently be done with the special registers in the current Prop (e.g. the "b" registers or the counters) - if Catalina used them, then your program couldn't.
But updating the code generator to suit the Prop 2 is the simplest part - modifying it (and the LMM kernel) would take only a few days. The main problem is the HAL. That there is as yet no Spin compiler or PASM assembler for the Prop II, and it seems neither Brad C nor Michael Park are interested in writing one (I've asked them). The Parallax one (assuming there even is one!) will probably never be adequate for this type of work since I doubt that they will implement all the really neat extensions that Michael and Brad implemented and which Catalina now uses (#ifdef, longer symbol names, listings, decent symbol table sizes etc). This means I would probably have to "roll my own". Assemblers are not such a problem - I started work on my own a while ago, and (from memory) I think Bill Henning also has one???. But I also make use of Spin in the HAL - without a Spin compiler I couldn't so easily use a lot of the OBEX stuff I currently use. So then I have the choice of either rewriting the HAL in PASM, or writing my own Spin compiler - the first is not much fun and the second (i.e. writing my own Spin compiler just so I can port my own C compiler) seems just a little stoopid.
But it is early days yet - watch this space!
Ross.
Hi David,
I'm aware of a couple of commercial developments using Catalina - but they don't seem to want publicity (I'm not sure they even frequent these forums, unless they do so under different names) so I can't give you any details. Actually, I couldn't even if I wanted to - I just get odd support requests by email, and have to try and figure out from those what the heck they are trying to do with it!
One thing though - even though I don't know what they are using it for, I was a bit surprised myself by who is using it.
Ross.
P.S. Another interesting datum - now that I host on SourceForge I can see where Catalina is being downloaded from. That's also very surprising!
I am using 3 prop chips. One is on a handheld device and is primarily pasm. The second and third props are on a different pcb mounted in it's own box. The second handles the interface to the outside world and is pasm & spin. The third prop is a RamBlade (production pcb is RamBlade3 with 512KB SRAM, microSD, RTC and battery). This is the prop that uses Catalina (XMM mode) which handles the user interface (menu's, database on microSD, and controls the external devices, etc). Catalina calls fast pasm cogs for maths, etc. All comms off chip is via 2pin high speed serial.
Probably mostly playing - like me
Catalina 3.4 does not incorporate any performance or code size improvements (except one very small one) - I'm still working on those. These will be in Catalina 3.5 (I hope).
So far on the standard benchmarks I've got around 40% improvement in speed, and around a 5% reduction in code size. I'm not really driving for performance (Catalina will never beat GCC on small benchmark programs since it doesn't use FCACHE) but I'd really like to get the code size down further. Ideally, I'd like to get it down by another 10-15% - but that's proving to be very difficult!
Ross.
Ross: Sounds like you're making great progress in optimization for Catalina 3.5. I agree that getting the code size down is a good goal. The more code you can fit in LMM mode the better and even XMM mode will benefit because of a higher cache hit ratio since more code will fit in a cache line.
Yes, if you want to write portable C when using GCC you really should compile with -std=c90 and/or -ansi (not sure if both are required - check the GCC documentation). The same is probably true of LCC (the option is -W-A for Catalina) but the extensions LCC supports are mostly to do with backward compatibility (e.g. functions without prototypes) and tend to be pretty portable anyway.
GCC has lots of nice extensions, but it also has lots of things that you can all too easily come to depend on - and end up with a completely unportable program. Unlike Micro$oft, I don't think they do this as deliberate policy to hogtie you into only using their compiler - but even so it is better not to get caught.
Ross.
Hi David
It depends on the error message itself. Code::Blocks is not "magic" - if there is no line number information in the error message itself then Code::Blocks can't take you to it. I have to manually parse every single error message generated by cpp, lcc, homespun, catalina, catbind etc etc to extract the line number information - and it is entirely possible I'm doing that incorrectly in some cases.
Post an example and I'll check it out.
Ross.
xbasic is now compiling with Catalina 3.4 but the "Run" button isn't working for me. I get the following error: Any idea what might be going wrong? I guess this could have something to do with the VM having trouble accessing the Propeller USB device.
The Run button won't work - that will try to execute it locally - which should fail. Do you mean the "Download to XMM RAM" Tool? Have you built the XMM utilities?
I run Linux in a VM, and sometimes have trouble accessing the USB ports, so it could indeed be that.
Ross.
Hi David,
Odd. Can you download successfully from a non-VM machine? What options did you use when building the XMM utilities, and are they the same options you used for the program (cache, flash etc).
If you post your binary then I'll try loading it here.
Ross.
I've seen that error a lot! There are lots of ways to make a mistake in Code::Blocks...
In my FlashPoint guide, I've tried to point out many of the things that can go wrong...
One thing to check is that you don't have conflicting build options in the "target" and "release" build options windows...
Also, make sure you haven't run out of cogs...
Thanks,
David
You also need to select "Flash Loader" in the build options.
I made those changes (and also selected "RamPage" instead of C3) and it seems to load OK.
I'm not sure if it's doing what it is supposed to do though... If I enter something, it comes back with "xV"...
Hi David,
Rayman is right. I added the FLASH loader option and removed the duplicate 8K CACHE option and it downloaded and runs ok (but I get a syntax error whenever I try to execute a basic program containing a "print" statement).
I guess this error situation is one to add to the FAQ.
I think in the next release I will enhance the "Catalina Project Wizard" so that it also asks about caching and loader options. Then it could build the XMM utilities appropriately for the project as the last step in setting it up.
Ross.
EDIT: I just checked the FAQ to add it, and discovered it is already there! First question in the list!. However, I can't really claim "I told you so" since the answer is out of date - it has not been updated since I moved from using -x3 and -x4 to specify the flash loader to using -D FLASH. I will correct it in the next release.
Thanks for the fix. I'm not sure I understand what you mean by "duplicate 8K CACHE option". Don't I have to enable the cache when using external memory?
100 for x=1 to 10
110 printf("%d\n", x)
120 next x
I would change this to the more traditional "print" but I'm not sure this version of basic is likely to be used. It was more of a proof-of-concept that I could get the compiler running on small MCUs like the PIC24 and the Atmega328p. I chose this version to port to the Propeller because I was hoping it would fit in LMM mode (your TINY memory model) but it's still too big.
Yes, on the C3 (or any other platform with Flash RAM, you must enable the cache - but you had it enabled twice. If you open the Build Options dialog, you will notice there is more than one node you can select in the left hand pane - and each node has the same set of options, so you can select it twice. You had the 8k cache option set for (I think) both the xbasic node and the Release node. Homespun generally spits the dummy if you define the same symbol twice.
This is the aspect of Code::Blocks that confuses most people. I can see the reason for it, but it sure is annoying sometimes!
Ross.