Catalina Help?

MasterC · 2010-01-11 18:49

Hi,

Where does one go to seek help for issues with Catalina? Here?

I have a project for which I was planning to use the prop, but then I came across some c code that does 90% of what I want. So I thought, "Hey, I'll give that Catalina thing a try." I installed it, along with Code Blocks. Playing around with the example programs worked fine. However, when I try to build the project I need, I get the error: "Could not find include file "xxxxx.h" for each of the three .h files in my project. They are all there, right in the same directory as my .c files. What's going on? Do I need to do something to tell Catalina to look for these files in the same directory?

Thanks!

RossH · 2010-01-11 21:41

Hi MasterC,

Yes, this is currently the best place for getting Catalina help. Or you can email me directly - my email address is given in the Catalina Reference Manual.

You need to include the appropriate directory in the list of Code::Blocks search paths. No user directories are included by default (not even the local directory).

You can do this in the project's build options (select menu item "Project->Build Options", then select the "Search Directories" tab and then add the path you need (on the "Compiler" sub-tab). You can use relative paths (e.g. ".") as well as absolute paths (e.g. "C:\Program Files\Catalina\demos;").

Note the appending of a ";" to the path name if it contains a colon - this is because of a minor bug in Catalina that I will fix in the next release/

Let me know if you have any more problems.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Post Edited (RossH) : 1/11/2010 9:48:01 PM GMT

MasterC · 2010-01-11 23:44

Great, thanks Ross! So I guess it was more of a Code::Blocks issue than Catalina. I got over that hurdle soon after your helpful reply.

However, I am on to the next group of hurdles. When trying to build, I was getting an error saying stricmp is undefined. I guess it is supposed to be in strings.h, but none of the strings.h files that I can find on my computer actually have that...they only have strcmp.

Anyway, forgetting that issue for now (I just changed the stricmp to strcmp for the moment to move on), I started getting an error that the image was bigger than 32k. I tried changing the options to XMM and 128k, and now I get a new error: cannot open output file "bin\Release\filename.binary."

Not sure I'm getting anywhere with this....

Thanks again for your help.

RossH · 2010-01-12 00:03

Hi MasterC,

stricmp is not an ANSI C function - but assuming it is meant to be a case-insensitive version of strcmp, it is easy enough to write your own (note: I just got this version off the net, and I haven't tested it!):

int stricmp(const char *s1, const char *s2) {
  char f, l;

  do {
    f = ((*s1 <= 'Z') && (*s1 >= 'A')) ? *s1 + 'a' - 'A' : *s1;
    l = ((*s2 <= 'Z') && (*s2 >= 'A')) ? *s2 + 'a' - 'A' : *s2;
    s1++;
    s2++;
  } while ((f) && (f == l));

  return (int) (f - l);
}

As to your last problem, is sounds like a permission problem. Check that you have write permission to the directory in which you have created your project. Are you running under Linux or Windows? (this tends to be more of a problem under Linux).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

RossH · 2010-01-12 00:09

MasterC,

On the size issue, if your program doesn't need to include I/O functions for floating point, try compiling with libci rather than libc - this may make your program fit into 32kb. Otherwise, you will need a platform with XMM RAM - what Prop platform are you using?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

MasterC · 2010-01-12 01:37

Thanks again, Ross.

Still too big with "libci" and "-D NO_HMI." (Does the NO_HMI save space, or just cogs?)

I just have a demo board hooked up right now, but eventually it will be a custom PCB.

I don't think I have a permissions problem. It's Windows XP Pro, and other sample projects under the same directory worked just fine.

MasterC · 2010-01-12 01:41

If it helps, or if you want to try and see if it works for you, attached is what I'm trying to compile. The files in the "src" directory are what I added to the Code::Blocks project.

Thanks!

**EDIT: I zipped up only the "src" directory and uploaded it separately, in case you would rather download just the 20KB you really need instead of the whole 2MB I originally uploaded....***

Post Edited (MasterC) : 1/12/2010 1:46:42 AM GMT

RossH · 2010-01-12 02:02

Hi MasterC,

The NO_HMI option saves both space and cogs - but probably not enough space in this case to make a difference.

I'll try compiling with Code::Blocks when I get home this evening. In the meantime, you could try using the command-line compiler to see if the problem is a Code::Blocks issue. I just had a quick go at compiling your program (I had to include the stricmp routine above (renamed as _stricmp), and it compiled fine. I can't use Code::Blocks here (I don't have it installed) or execute it though.

The command I used was:

catalina -x2 micro.c lenval.c ports.c stricmp.c -I. -lc

The resulting micro.binary file was 77kb, which means you would definitely need XMM RAM to execute it. You could try using the ICC compiler - it generally produces smaller executables than Catalina.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

RossH · 2010-01-12 07:40

Hi MasterC,

I've compiled your program using Code::Blocks, and it compiles ok for me.

Did you use the 'Catalina' user template to create your Code::Blocks project? Maybe I still have something set up wrong in there that only works on my system. If you send me your project file (this will be in your project directory, and will have a '.cdb' extension) I might be able to see what is going wrong - this is an XML file, so you can just edit it with a text editor. You might also have a look in there and see if anything looks odd.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

MasterC · 2010-01-12 18:05

Well, that is interesting. I did use the Catalina template for the project. Not sure why, but I always seem to be lucky enough to have an issue where none should be.

I didn't see anything funny with my project file, but I have attached it if you want to take a look.

One other thing I noticed--the error is saying "cannot open output file 'bin\Release\JTAG Programmer.binary,'" but that file doesn't actually exist. What does exist is 'bin\Release\JTAG Programmer_temp.binary.'

Anyway, I really appreciate your prompt help with this, but I thought I should let you know that we may now be going a different direction. There is no particular reason to need the Prop. for this, and my coworker down the isle got the code to compile for the Atmel processors he uses without a hitch. That also takes care of the memory limitation issue, so it might just be easiest to go that way on this one.

Thanks again!

RossH · 2010-01-12 22:02

Hi MasterC,

Aha! It looks like I may still have a problem with spaces in filenames - try recreating your project using a project and executable name without any spaces (e.g. JTAG_Programmer).

I'll confirm that this is the problem when I get home tonight, but I think what is happening is that the compiler is working ok and generating the "_temp" file, but some of my own code is failing when it tries to combine that file with the target files and then write the final binary.

Ross.

P.S. I'm sorry you may end up not using a Propeller, but no worries if you don't end up using Catalina - thanks for helping me sort out the bug.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Post Edited (RossH) : 1/12/2010 10:18:00 PM GMT

RossH · 2010-01-13 08:40

MasterC,

As I suspected, Catalina doesn't like Code::Blocks projects that use spaces in the target file name. Eliminate the spaces and everything should work correctly.

Note that you don't need to rename your project - just go to "Project->Properties" and change the output filename on the "build targets" tab.

I will fix this in the next release.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

MasterC · 2010-01-13 17:28

Thanks Ross, I'll give that a try.

So, if we wanted to stay with the prop., does using XMM cause any complications? Do I just need to add a big external EEPROM? What advantages are there to using the prop. over another processor that is more typically used for c code?

Also, I couldn't quite tell from my quick skim of the documentation--is it possible to run c code compiled in Catalina along with additional SPIN and/or PASM code in other cogs?

Thanks again for all your help.

RossH · 2010-01-13 22:27

Hi MasterC,

Unfortunately XMM is a bit complicated - it requires external SRAM (not EEPROM) that can be accessed fast enough to be useful (i.e. it needs a parallel rather than a serial connection to the SRAM). This means that the Prop connection to the SRAM generally consumes quite a few of the Prop I/O pins. This is one reason multi-Prop boards are becoming popular - one Prop has the SRAM connected (and can run large C programs) while another looks after I/O (and can run either small C programs or SPIN programs).

External SRAM is currently supported on platforms that can use the Hydra HX512 SRAM expansion board (e.g. the Hydra or the Hybrid) and on the TriBladeProp and Morpheus boards. On any other board you will need to write your own XMM access routines.

The advantages of using the Prop over other microcontrollers is that the Prop gives you more raw processing power, a true 32 bit architecture and the possibility of real multiprocessing. They are also a lot more fun to work with. We mainly use Atmel processors where I work - after using the Prop, Atmel processors seem strangely archaic, very slow, and are also complex and tedious to program.

With Catalina you can use both SPIN and PASM code during program initialization, but once the C program starts, you can only be executing either C or PASM in each cog (i.e. not SPIN - this is because the SPIN usage of Hub RAM conflicts with the Catalina usage).

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Dave Hein · 2010-01-16 14:03

MasterC,

I'm developing a C-to-Spin converter, and I ran it on the source code you posted.· My converter doesn't handle function pointers and a few other C things at this point, but I was able to convert your code to Spin.· I had to replace the function pointer with a switch statement, and I had·to modify other parts of the code.

I ran the spin code and it produces the same ouput as the C code on my PC.·· I hard-coded the data from example.xsvf into the readBytes function.· I also reduced the value of MAX_LEN from 7000 to 2500 so it would fit in memory.· The comments in lenval.h say that 2500 is a safe value to use.

The spin code is in the attached micro.zip file.· This also includes clib.spin, which provides printf and a few string functions.

Dave

Post Edited (Dave Hein) : 1/16/2010 2:18:06 PM GMT

heater · 2010-02-24 03:06

I just tried compiling MasterC's project with GNU C for the ZPU architecture to run under Zog on the Prop.

The compiled binary ready to load and run is 30336 bytes !

Sadly I had to cheat a bit and replace the libraries "printf" which is huge.

Still a tad too big to fit in the Prop with the Zog VM, FullDuplexSerial, SD card driver etc.

Edit: I know this is off topic for a question on the use of Catalina and that MasterC has probably found his own satisfactory solution. I'm just fishing for some code size comparisons between Catalina, ICC and Zog and this example is to hand. Zog is slow but I was hoping it has something to offer in the space saving department.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 2/24/2010 3:35:51 AM GMT

RossH · 2010-02-24 04:13

@heater,

77kb for Catalina, but 32kb of that is initialization code (which is executed and dumped before C program execution begins) - so that makes it 45kb vs 30kb - but it's not much of a comparison without printf, which is just about the biggest function in the whole of libc! In Catalina, that function (plus it's support functions) can add about 15kb by itself. So that makes it 30kb vs 30kb - seems to be a tie!

Ross.

Edit: I haven't taken into account how much of your code is iniitalization code - but I don't think you execute that and then dump it before executing the C code. Since it continues to occupy memory I believe it still counts to your memory footprint, whereas it does not add to Catalina's - if the program is small enough to fit into a 64kb EEPROM (which it may be without printf) then it is loaded and executed in two parts, and can therefore be executed on a standard Prop using only 32kb RAM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Post Edited (RossH) : 2/24/2010 4:21:24 AM GMT

Dave Hein · 2010-02-24 04:20

The micro.c program includes a struct that contains 5 data buffers.· The default size of each buffer is 7,000 bytes, but I reduced it to 2,500 bytes each so it would fit in hub memory.· I believe this struct is declared as a stack variable, which means it won't appear in the static program size.

Dave

heater · 2010-02-24 04:22

Bah what! No speed and no space saving. Zog is not happy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater · 2010-02-24 04:28

Dave, Good point. Here I was just interested in code size so that's OK. Nice to know the program as stands has no chance to run in HUB.

Are you saying that after C to Spin conversion and reducing the buffer sizes this thing compiles to fit in HUB and run?

If so that's amazing!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater · 2010-02-24 04:37

RossH: What initialization code? If I compile an empty main() the resulting binary is 3100 bytes.

The first 1K is home for vectors for interrupt and SWIs (Actually the EMULATE ZPU instructions). Probably most of this is empty or redundant.

The remaining 2K contains crt0, crt_io initialization stuff, _premain, exit, multiply and divide and a few other odds and ends.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 2/24/2010 4:42:05 AM GMT

jazzed · 2010-02-24 05:00

I just love a great C thread! This is a good one. Thanks.

RossH · 2010-02-24 07:27

@heater,

I don't mean the C initialization code (that's minimal for Catalina - pretty much the first application instruction executed is "call #C_main") - I mean the code that loads all your device drivers into cogs - video, keyboard, mouse, SD card, RTC, FP libraries etc etc. In Catalina there is also the code that loads and starts the LMM kernel itself - in your case it would be the code that loads and starts the ZPU simulator. Catalina runs all this code once, then discards it all and re-uses the RAM it occupied for other purposes. Can ZOG do the same?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

heater · 2010-02-24 08:59

No. Currently Zog is just a normal everyday Spin main program that starts up a COG with the PASM ZPU interpreter. The only other object in there is FullDuplexSerial.

I have not even begun to think about those drivers and other things. It is very possible that Zog as a "ZPU for the Prop" will never include those things.

Why do I say that?

Well at the moment emulating the ZPU and getting GNU compiled code running from 512K or RAM on my TriBlade/RAM/Blade/DracBlade is the itch I have to scratch. Bill is being a great help here with the VM Cog. I'd like to see code Running from SPI RAM or FLASH, never mind how slowly we can have lots of it out there. So the pressure to save HUB space is not so great for me.

Arranging all those drivers and what is basically an OS to load and juggle them does not really appeal to me. It seems to me, not that I have checked any of them, that there are a number of operating type systems for the Prop already. I don't know what PropDos, Sphinx etc etc. That already provide drivers, loaders etc.

I'm lazy I'd rather say "Here is a lump of PASM and spec of Spin that is a ZPU and runs GNU C code from your SPI FLASH, use it where and how you like if you like." . Yep I'd rather borrow and adapt Zog to an existing Prop OS [noparse]:)[/noparse]

Still you never know. If I get interested and others have ideas Zog might start to "bloat" that way.

P.S. That binary size I quoted for micro.c was purely the binary output from GCC. None of the Zog VM or support was included.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99 · 2010-02-24 10:35

heater: I have the drivers being loaded by SphinxOS now... serial ( version of fdx), 1-pin TV (screen in hub but font and cursor controls & scroll in cog), 1-pin kbd. The fsrw is in cog (by mpark) but it takes 3 cogs currently. I will be getting ZiCog running under SphinxOS in the next couple of days. Just getting ed working (modified) in SphinxOS now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

heater · 2010-02-24 11:03

Clusso, wow! I have to have a play with this SphinxOS some time.

I have been pondering the future direction of Zog this morning.

Basically it comes to this:

Zog OS or not Zog OS?

See Zog thread for more on this thought.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dave Hein · 2010-02-24 18:28

The micro.spin program uses less than 8KB of program space.· That includes a simple printf function and a few other standard C functions.· Spin code is definitely very efficient with memory.

Catalina Help?

Comments