Catalina and BlackCat: Is it worth the trouble?
idbruce
Posts: 6,197
Hello Everyone
I finally got curious and started investigating some of the unknowns. I came across two items that were of particular interest to me, Catalina and BlackCat. I just wish I would have been curious a long time ago.
Anyhow, I don't have a lot of time to waste, so I thought I would ask a couple of direct questions.
Bruce
I finally got curious and started investigating some of the unknowns. I came across two items that were of particular interest to me, Catalina and BlackCat. I just wish I would have been curious a long time ago.
Anyhow, I don't have a lot of time to waste, so I thought I would ask a couple of direct questions.
- What is the learning curve of Catalina and BlackCat for a Visual Studio C++ programmer?
- Do you recommend both Catalina and BlackCat?
- I read in the documentation that programs compiled in Catalina run 4 - 8 times faster than Spin, is this true?
- Does it run faster than PASM?
- All things considered, is it worth the trouble to learn it?
Bruce
Comments
Hi Bruce,
Catalina (and BlackCat) are pure ANSI standard C (to be precise, C89). If you started out on C++, then C takes a little getting used to because C is a slightly lower level language than C++ (e.g. no classes!) - but for embedded work it is usually worth the trouble to learn C since it is by far the most widely used language in that domain. C++ may be a "better" language, but C++ runtimes are so large, and the resulting executables are so slow, that C++ doesn't get much use in embedded work (cue C++ programmers to protest vigorously!).
Also, if you like Visual environments, Catalina supports Code::Blocks, which provides the kind of interface that would be familiar to many Visual Studio users.
C programs do run much faster than SPIN - but are also slower than PASM. Between 4 and 8 times faster than SPIN is typical, and between 4 and 8 times slower than PASM is also typical. The downside is that C programs are larger than the equivalent SPIN or PASM programs - maybe 2 to 4 times larger than SPIN, and 2 to 3 times larger than PASM (the exact numbers are difficult to assess, since you can't actually have a PASM program larger than 496 longs).
As I have a vested interest, I'll let others decide if it is worth the trouble. In general, if you have a C background, or plan to do a lot of embedded work in the future, then Catalina is a good way of using the Propeller. If you don't have a C background, or don't plan to do much embedded work, then maybe not.
However, I should point out that Catalina also allows you to run much larger programs (on a suitably equipped Propeller) than are possible with SPIN or PASM, and it also saves you messing about with various SPIN drivers, since Catalina provides a rich set of "plugins" that drive the TV, VGA, Mouse, Keyboard, SD Card and Serial ports on many platforms.
Ross.
I seen that you were online earlier, but I missed the chance to chat with you. Through programming in Visual Studio, there were many SDK examples that I messed with. I can't say that I rightly know the difference between C and C++, but I believe the SDK examples were written in C. If that is the case, then I should not have a problem. I do want more speed from my programs, the question is how much more. I believe I could get a grasp on Catalina pretty quickly, but if PASM is faster, I am not sure which way to go.
Bruce
I'd suggest downloading Catalina and having a play with some of the demo programs. Then decide.
By the way, what Propeller board do you have? Catalina comes with built-in support for the Hydra, Hybrid, Demo, Morpheus, DracBlade and RamBlades (plus a few other boards which are compatible with one or the other of these). C3 and ASC support will be added in the next release. If you have another platform, I'd be happy to help you build a new CUSTOM target for it - but be aware that if you have a board without any external RAM (or at least a 64kb EEPROM) then you will be limited to 32kb LMM programs only.
Ross.
Yea, I believe I will look into it. The trouble is always time. I have been wasting a lot of it lately.
All of my boards are Propeller Proto Boards, however I also have several OEM chips to play with. And of course the Proto Boards come with 64KB. There is only one area where I really need the speed and that is for my stepper motor drivers.
Bruce
On the protoboard, you should at least be able to use the CUSTOM setup (it has the correct crystal speed) and the PC HMI option - i.e. use a compile command like the following: The first time you do this you will get an error like the following:
To get rid of this error, edit the file target\input\Catalina_Common_Input.spin and search for the symbol CUSTOM. Comment out the line that generates the above error. Also, while you are in there you could set any other values to suit how your proto board is configured.
The PC HMI option redirects stdin and stdout to the serial port (by default, on pins 30 & 31) - so you should be able to use the Parallax Serial Terminal (or any other terminal emulator) to see the output.
Ross.
I definitely appreciate the info. Within the next week, I will give it a test drive. Hopefully, I will pick it up rather quickly. Like I said, the language should be similar to SDK examples, or at least I would imagine. However, those always seemed much more difficult than MFC.
Bruce
Oh good, something to argue about:)
Run times can be big, also in C, so don't use them or use space optimized versions,
C++ executables are the same speed as C executables, in fact for the same constructs the code generated code can be exactly the same.
When using classes in C++ the generated code is as tight as if you made classes by hand in C with structs and pointers.
I've seen a lot of C++ in embedded work.
The Arduino guys use it all the time.
Using C++ classes prudently gives you an object system on a par with Spin. If it's good for Spin why not C++.
It proved to be a good choice FOR ME (maybe not for everyone) as once you start to get into PASM you realize it is well thought out and actually easy to learn the few instructions which when combined with the various flags become extremely flexible and FAST.
C I fully admit had NEVER been attractive to me as many of the hoops required just never made sense to me as in my opinion computers are supposed to work for us not the other way around. Just prejudice on my part for sure but if a higher language is needed I would rather have a VB6 like language which compiled to assembly. Still not faster than PASM but easier to learn.
If you are looking for RAW speed then you will not do better than PASM for the prop.
That was great. I love hearing all aspects, that way I can make a decent choice on which direction to go.
Thanks for the input.
Bruce
Agreed, if you stick to the same constructs. But if you do that you are really using C, not C++ - even if you are compiling it with a C++ compiler. This is basically what the Arduino does (see here)
Maybe, but who does this? And as soon as you start using templates or a class library, you are doomed to ending up with massive and slow executables. C++ on the Arduino is based on GNU C++, but it does not support the standard GNU libraries, such as libstdc++. Instead, it uses libc.
The statistics show the use of C++ in embedded work is small, and declining. C still has the bulk of that market, and its market share is increasing as the trend towards using C++ and other unsuitable languages (such as Java) subsides. C++ on the Arduino is much closer to C - so much so that it is recommended that you start out learning C, not C++ if you want to program an Arduino (e.g. see here) Aha! finally something we can agree on. Yes, I agree that SPIN and C++ are about equally well suited as languages for building complex embedded systems
Ross.
I am getting what I asked for. I am sure Catalina and BlackCat is a good setup. But I am leaning toward PASM just because I intend to build industrial equipment that I want to run fast. However, like I said before, I will take it for a test drive.
I do appreciate your input Ross
Bruce
Hi Wurlitzer,
I agree with everything you said. PASM is certainly the choice where you need speed. But for very large applications, assembly language is complex to write, hard to debug, and can also be hard to maintain.
I generally prefer to use C to embody the main program logic, and just use assembly wherever C can't do the job fast enough. Generally, I find that this means the need for assembly language is limited to small chunks of code (ideally suited to the Propeller, in fact!).
Also, don't forget that once you get over 496 assembly instructions on the Propeller, you have to resort to tricks like LMM, overlays, or co-operating cogs. And if you have to resort to these things you end up losing much of your speed advantage anyway. The end result is probably still going to be faster than C, but it will also be much more complex!
Ross.
Hi Bruce,
No worries - I just like a good argument!
PASM may indeed be a better choice for your application - but keep in mind that the propeller gets complex to program in PASM as soon as you have logic that cannot easily be embodied in 496 instructions. Then of course you can resort to a combination of SPIN and PASM - but the results will be slower than a combination of C and PASM.
Ross.
1) If you already know C++, you are not on the steep part of the learning curve any more and life is good
2) Yes
3) Yes, both based on Ross' comments and I can confirm this from experience.
4) No, but you can include pasm code in your program, and load cogs on the fly as required. That is something that is hard to do in Spin as you run out of memory if you have code for more than about 16 cogs. See below for screenshots.
5) Yes. I'll second some of Ross' general observations about C and embedded controllers. I come from the picaxe world, which is programmed in Basic. This works fine, but I get the general impression there is this tsunami of Arduino programmers about to overwhelm everybody with their curly braces *grin*.
I'm working on hybridising C and Pasm together - see attached. This also requires a new IDE so I'm writing that at the same time. Why, you may ask? Well, I ran out of program space in Spin, so I ended up adding an external ram chip, moving over to C, and putting all the C program into external memory. This has another benefit of freeing up virtually the entire hub ram for a video buffer.
Of course, if your programs are small you may never need to do this.
/* PASM demo for use with Catalina IDE Precompiler and Compiler */ #include <stdio.h> /* Global constants for both C and PASM */ const unsigned long graphicstart = 0; // start of space for video graphics buffer const unsigned long graphicsize = 19200; // size of graphics buffer = 19200 bytes const unsigned long keyboardstart = 19200; // start of space for keyboard const unsigned long keyboardsize = 100; // size of space for keyboard /* End global constants */ /* PASM Code for compilation using SpinC and inclusion as a data file PASM Start mycogject.spin CON ' add your values here _clkfreq = 80_000_000 ' 5Mhz Crystal _clkmode = xtal1 + pll16x ' x 16 graphicstart = 2048 ' precompiler will overwrite this PUB Main coginit(1,@cogstart,0) ' cog 1, cogstart, dummy value DAT org 0 cogstart wrbyte testvalue, testvariable ' test value A jmp #cogstart testvariable long graphicstart ' test memory location at graphicstart testvalue long 65 ' ascii A fit 496 PASM End */ void mycogject(int cognumber, unsigned long parameters) // this name copied from the .spin name in the pasm section - names must match eg void mycogject matches mycogject.spin. Also first code after this must be the .h array file. Put your code after the }; { /** * @file mycogject_array.h * Created with spin.binary PASM to C Array Converter. * Copyright (c) 2011, John Doe */ unsigned long mycogject_array[] = // dummy data or compiled above code or #include file.h { 0x003c0602, 0x5c7c0000, 0x00001388, 0x00000041 }; unsigned long par_cogject[] = { 1, 2, 3 }; // data to pass to cog - ignore if not used _coginit((int)par_cogject>>2, (int)mycogject_array>>2, cognumber); // array name built from spin file name } void clearscreen() // white text on dark blue background { int i; for (i=0;i<40;i++) { t_setpos(0,0,i); // move cursor to next line t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100 } } void sleep(int milliseconds) // sleep function { _waitcnt(_cnt()+(milliseconds*(_clockfreq()/1000))-4296); } char peek(int address) // function implementation of peek { return *((char *)address); } void poke(int address, char value) // function implementation of poke { *((char *)address) = value; } void main () { char c; int i; unsigned long parameters; clearscreen(); printf("Clock speed %u \n",_clockfreq()); // see page 28 of the propeller manual for other useful commands printf("Catalina running in cog number %i \n",_cogid()); // integer i=graphicstart; // location to peek and poke poke(i,66); // poke a B, the cog should change this to an A printf("load cogject into cog 7\n"); mycogject(7,parameters); // run in cog 7 c=peek(i); // peek byte at this location printf("Peek value at %i = character %c Ascii value %d \n",i,c,c); while (1); // Prop reboots on exit from main() }-Phil