PDA

View Full Version : Catalina 3.4



Pages : [1] 2

RossH
10-26-2011, 10:42 AM
All,

UPDATE: Catalina 3.5 is now available. See here (http://forums.parallax.com/showthread.php?139744-Catalina-3.5).

Catalina 3.4 is now available on SourceForge (here (https://sourceforge.net/projects/catalina-c/files/releases/3.4)). A Windows "one touch (http://sourceforge.net/projects/catalina-c/files/releases/3.4/Catalina_3.4_Setup.exe/download)" 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.

Ross.

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.conf

Then 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.

RossH
10-26-2011, 10:42 AM
Looks like I found my first bug in release 3.4 ...

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.

Dr_Acula
10-26-2011, 11:29 AM
Nice work Ross. Easy to setup and run.

Rsadeika
10-26-2011, 11:58 AM
Just a general question, does this version have a Propeller specific lib? Some common commands that are used would be: pause/wait, high, low, ..., etc. Before I try to do it myself, has this been done already?

Ray

Rayman
10-26-2011, 02:50 PM
Cool. I'll have to try out the Toledo Chess again...
BTW: Did you use my versions of FlashPoint_Def and Inc for this release? I'll change my guides if you did...

Rayman
10-26-2011, 05:39 PM
Ross, I have a basic question about Catalina for you...
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?

Heater.
10-26-2011, 05:53 PM
Rayman,
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.

Cluso99
10-26-2011, 05:59 PM
Thanks Ross. I will install later today.

Rayman
10-26-2011, 06:32 PM
Rayman,
What do you mean by "hidden stack space" in Spin?
As far as I can see it is all out in plain sight.

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...

Heater.
10-26-2011, 08:39 PM
Rayman,
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.

Tor
10-26-2011, 09:00 PM
Even on Linux and *nix platforms the stack issue came back again with POSIX threads.. initially the default stack space for threads was typically just 8 KB, which is way too low in case your thread is just a pthread_create() wrapper around a normal large multi-function program, or otherwise coded without stack concerns (as that is almost never a concern for non-threaded programs.. your stack size is in the order of your entire virtual memory availability for your process, i.e. at least hundreds of megs).
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

RossH
10-26-2011, 09:56 PM
Cool. I'll have to try out the Toledo Chess again...
BTW: Did you use my versions of FlashPoint_Def and Inc for this release? I'll change my guides if you did...

Oops! I forgot all about that. Sorry - next release.

Ross.

RossH
10-26-2011, 09:58 PM
Just a general question, does this version have a Propeller specific lib? Some common commands that are used would be: pause/wait, high, low, ..., etc. Before I try to do it myself, has this been done already?

Ray

Yes, there are propeller-specific functions described in the Catalina Reference Manual - see the section "Cog Functions" on page 42.

Ross.

RossH
10-26-2011, 09:59 PM
Ross, I have a basic question about Catalina for you...
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?

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.

Rayman
10-26-2011, 11:39 PM
That's interesting... Is the stack space only in HUB ram? If you're in "large" mode, would it be in SRAM instead?

Does a program just go haywire, like with Spin, when it runs out of stack space?

RossH
10-27-2011, 12:28 AM
That's interesting... Is the stack space only in HUB ram? If you're in "large" mode, would it be in SRAM instead?

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 :smile:.

Ross.

Cluso99
10-27-2011, 07:26 AM
I have downloaded and been running all afternoon. Nice.

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).?

RossH
10-27-2011, 07:43 AM
I have downloaded and been running all afternoon. Nice.

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.

KMyers
10-27-2011, 05:36 PM
Wow!!! Down 10 days with the flu, come back at look at all the activity and development going on with Catalina!! Uninstalled 3.2 and installed 3.4 on my Vista laptop, No problems all looks like its running great!

Thanks Ross!

Rayman
10-27-2011, 09:35 PM
Ross, I'm using Super Star Trek (sst) now to test out my RamPage modules.
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?

RossH
10-27-2011, 09:45 PM
Ross, I'm using Super Star Trek (sst) now to test out my RamPage modules.
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.

Rayman
10-27-2011, 10:20 PM
How do I program catalyst to EEPROM within Code::Blocks?
I was thinking the "Program EEPROM" tool would program the eeprom with the sst file and not Catalyst. Is that wrong?

RossH
10-27-2011, 10:40 PM
How do I program catalyst to EEPROM within Code::Blocks?
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:


payload -e "%LCCDIR%\catalyst\bin\catalyst.bin"

You can just run this from a Catalina Command Line window, or add a new entry to the Code::Blocks Tool menu.

Ross.

Rayman
10-28-2011, 01:21 AM
Ok, I think a new "Tool" for the next version that would program Catalyst into EEPROM would be nice.
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?)

Dr_Acula
10-28-2011, 02:16 AM
Hi Rayman,

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?

RossH
10-28-2011, 02:33 AM
Ok, I think a new "Tool" for the next version that would program Catalyst into EEPROM would be nice.
I suppose I can't just download Catalyst to RAM and have it run sst.binary off of the SD card, right?
Yes, you could do that - just add a suitable AUTOEXEC.TXT file to the SD Card so Catalyst finds it when it starts.

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?)

Sure are! :)

Ross.

RossH
10-28-2011, 02:35 AM
Hi Rayman,

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?

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.

Dr_Acula
10-28-2011, 03:18 AM
Catalyst leaves nothing in memory.

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!

RossH
10-28-2011, 03:23 AM
Great - that will make it pretty much the same as Kyedos.
Hrummph!.... I think you mean Kyedos is beginning to look like Catalyst! :smile:

I must say that I am really getting to like the code::blocks/catalina combo. It makes programming a pleasure!
Certainly does!

Ross.

Dr_Acula
10-28-2011, 03:49 AM
Hrummph!.... I think you mean Kyedos is beginning to look like Catalyst!

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 :)

RossH
10-28-2011, 04:04 AM
...there may be some who do not know what 'catalyst' is. KyeDOS has 'DOS' in the name for a reason ...

LOL! You're showing your age, Dr_A :smile:

Ask any kid what DOS means and they'd probably think you mean either the Nintendo game Dawn of Shadow (http://en.wikipedia.org/wiki/Castlevania:_Dawn_of_Sorrow) - of if they were real geeks they might think you meant Denial of Service (http://en.wikipedia.org/wiki/Denial-of-service_attack) (although come to think of it, the latter is surprisingly accurate when describing a Microsoft O/S).

Ross.

Dr_Acula
10-28-2011, 04:08 AM
LOL! You're showing your age, Dr_A

Guilty as charged. My kids don't know what to do with a ">" prompt. They just tell me to get online and buy them an ipad touch.

Cluso99
10-28-2011, 05:45 AM
I just misread your post Drac. Its an iPad2 they want ;) Thought you originally meant an iPod Touch which is an iPhone without the phone part.

Obviously they don't frequent your workshop much if they don't know what an ">" means!

Dr_Acula
10-28-2011, 07:04 AM
Yes I'm not even quite sure what it is called. I was told it was made by Apple, started with "i", everyone has one, and hand over the credit card.

I need to get the kids to learn C :)

frank freedman
10-28-2011, 08:20 AM
My son has one to encourage exploration and for use as an augmentative comm device. My wife has one to preview some apps and books for him. I refuse to drink that brand of kool aid. They are great devices if you can accept apples my way or no way (highway not optional) approach to ipad use and apps. Want to save video you just shot to jump drive? Save a file to same or worse read one like a file system ? You get to experience the NO way! Just waiting for the right pad to evolve.........

Frank

Sorry to deviate...

David Betz
10-28-2011, 03:28 PM
Has anyone run Catalina under Mac OS X recently? Any tips on building it? I got LCC to build but I had trouble getting the catalina driver program to build. I'll have to look at it more closely later. I just wondered if anyone else had tried and had any advice.

Thanks,
David

David Betz
10-28-2011, 09:28 PM
With a little fooling around I got everything except payload to compile on the Mac. I'm now trying to build the demos. If I run the build_all script in the demos folder I get lots of instances of this error:


Catalina Compiler 3.4
lcc: fatal error in /Users/dbetz/Catalina_3.4/bin/rcc

Any idea what might be causing this?

RossH
10-28-2011, 10:47 PM
With a little fooling around I got everything except payload to compile on the Mac. I'm now trying to build the demos. If I run the build_all script in the demos folder I get lots of instances of this error:


Catalina Compiler 3.4
lcc: fatal error in /Users/dbetz/Catalina_3.4/bin/rcc

Any idea what might be causing this?

Hi David,

One of the 2.X releases was built on OS/X - but I now no longer remember who built it, and I never heard any more about it.

Also, remember that LCC supports other targets. To test out LCC independently of the Catlaina components, try a command like:


lcc -target=x86/linux hello_world.c -v -c

Note 1: the assembly language output will be put in hello_world.obj (remember that Catalina uses assembly language as its object format).

Note 2: you need the -c flag as there is no assembler, linker or libraries provided for any target other than the Propeller - but this command will at least test out the lcc, cpp and rcc components. Once you have those working I can help you with the Catalina components.

Ross.

David Betz
10-29-2011, 01:45 AM
Thanks Ross! What does the rcc program do? I wasn't able to find any documentation on it. Is it the code generator for lcc?

RossH
10-29-2011, 02:04 AM
Thanks Ross! What does the rcc program do? I wasn't able to find any documentation on it. Is it the code generator for lcc?

Hi David,

rcc is the actual compiler - the various code generators (including Catalina's) are just part of it.

lcc is really just a wrapper program that marshalls all the arguments to rcc and then invokes it.

Similarly, catalina is really just a wrapper program that marshalls all the arguments to lcc and then invokes it.

Ross.

David Betz
10-29-2011, 02:19 AM
Hi David,

One of the 2.X releases was built on OS/X - but I now no longer remember who built it, and I never heard any more about it.

Also, remember that LCC supports other targets. To test out LCC independently of the Catlaina components, try a command like:


lcc -target=x86/linux hello_world.c -v -c

Note 1: the assembly language output will be put in hello_world.obj (remember that Catalina uses assembly language as its object format).

Note 2: you need the -c flag as there is no assembler, linker or libraries provided for any target other than the Propeller - but this command will at least test out the lcc, cpp and rcc components. Once you have those working I can help you with the Catalina components.

Ross.

I guess I'm in trouble because lcc even failed generating x86 code. Here is the output I got from the command line you suggested:


david-betzs-macbook-pro:~ dbetz$ lcc -target=x86/linux fibo.c -v -c
lcc $Id: lcc.c 355 2007-02-18 22:08:49Z drh $
/Users/dbetz/Catalina_3.4/bin/cpp -U__GNUC__ -D_POSIX_SOURCE -D__STDC__=1 -D__STRICT_ANSI__ -Dunix -Di386 -Dlinux -D__extension__= -D__cdecl= -D__CATALINA__ -D__unix__ -D__i386__ -D__linux__ -D__signed__=signed -D__LCC__ -I/Users/dbetz/Catalina_3.4/include fibo.c /var/folders/84/9fr230z16p5fb9x9qq3p_z640000gn/T/lcc198850.i
/Users/dbetz/Catalina_3.4/bin/rcc -target=catalina/linux -target=x86/linux -v /var/folders/84/9fr230z16p5fb9x9qq3p_z640000gn/T/lcc198850.i /var/folders/84/9fr230z16p5fb9x9qq3p_z640000gn/T/lcc198851.s
/Users/dbetz/Catalina_3.4/bin/rcc $Name$($Id: main.c 355 2007-02-18 22:08:49Z drh $)
lcc: fatal error in /Users/dbetz/Catalina_3.4/bin/rcc
rm /var/folders/84/9fr230z16p5fb9x9qq3p_z640000gn/T/lcc198851.s /var/folders/84/9fr230z16p5fb9x9qq3p_z640000gn/T/lcc198850.i

RossH
10-29-2011, 02:45 AM
...


lcc: fatal error in /Users/dbetz/Catalina_3.4/bin/rcc

...


Yup - that looks bad. Run it under gdb and trap any exceptions - it's probably a memory violation or something. If you can narrow it down to a particular line of code (or library function call) then I'll take a look and see if I can think of anything.

Ross.

David Betz
10-29-2011, 11:49 AM
Is it possible that my problems running on the Mac have to do with the fact that the Mac is running a 64 bit compiler? Is there anything special that needs to be done to LCC to run in 64 bits?

RossH
10-29-2011, 01:25 PM
Is it possible that my problems running on the Mac have to do with the fact that the Mac is running a 64 bit compiler? Is there anything special that needs to be done to LCC to run in 64 bits?

Hi David,

I doub it. But if you are using gcc, just tell it to compiler the program in 32 bit mode. Can't remember the exact option - maybe -m32?

Ross.

David Betz
10-29-2011, 04:19 PM
Hi David,

I doub it. But if you are using gcc, just tell it to compiler the program in 32 bit mode. Can't remember the exact option - maybe -m32?

Ross.
Actually, I'm using Apple's LLVM C compiler. I suspect it has a similar option though. Thanks for the suggestion.

jazzed
11-01-2011, 04:25 PM
I downloaded Catalina 3.4 for some testing. The InnoIDE installer does a nice job - I use it too.

Some comments, then a question: Codeblocks makes Catalina look more attractive. Good job.

I selected the C3 and Tiny mode, did a build, and hub download.
After 1 minute 15 second download, I finally see the traditional greeting on my TV.

Question:
I almost never use TV, so I set the build options to select PC expecting to use a serial terminal.
How do I open a serial port to work with that?

Rayman
11-01-2011, 04:51 PM
jazzed, this guide might help you with that:
http://www.rayslogic.com/Propeller/Products/FlashPoint/Catalina/Catalina_InstallGuide.htm

Cats92
11-01-2011, 05:50 PM
Thanks RossH and Rayman.

Rayman this <test_suite> program works nicely with my demoboard ( in fact I have no large memory board)

Hope some other simple programs for beginners.

For leds , servos or ping ?

I used Arduino before because it comes with a lot of small programs and explanations.

Jean Paul

jazzed
11-01-2011, 06:02 PM
jazzed, this guide might help you with that:
http://www.rayslogic.com/Propeller/Products/FlashPoint/Catalina/Catalina_InstallGuide.htm
Thanks Rayman.

That helped. Somehow the baud-rate got set to 57600 though - no idea how that happened.

There are only a few ways to avoid needing to use an extra terminal window.
Built into the loader seems easiest and let's you see all output without struggling.

Guess I'm forced to use TV for some things for now especially since I can't modify some code.

RossH
11-01-2011, 10:48 PM
After 1 minute 15 second download, I finally see the traditional greeting on my TV.

... and ...

There are only a few ways to avoid needing to use an extra terminal window.


TINY programs don't need a special loader. They can be downloaded with Propellent, or with the Parallax Spin tool if you prefer. Or, if you prefer a downloader that comes combined with a terminal emulator, use PropTerm (compile your program with -D PROPTERM).

Ross.

RossH
11-02-2011, 01:34 AM
All,

Just a heads up!

I think I may have a problem with dynamic memory management in this version of Catalina. Not sure exactly which version the bug crept in, but it will only affect programs that use malloc() etc.

I need to do some more investigating. I'll post an update when I know more.

Ross.

RossH
11-02-2011, 12:19 PM
All,

Just a heads up!

I think I may have a problem with dynamic memory management in this version of Catalina. Not sure exactly which version the bug crept in, but it will only affect programs that use malloc() etc.

I need to do some more investigating. I'll post an update when I know more.

Ross.

Ok - on further investigation it appears I was just running out of memory :)

I'm working on some code generaotr optimizations to allow Catalina to squeeze more C code into Hub RAM, and I think I just miscalculated. Sorry for the false alarm!

Ross.

David Betz
11-02-2011, 03:12 PM
I need to be able to define preprocessor symbols on the Catalina command line and it doesn't seem that -D does what I expect. How do I define the symbol PROPELLER_CAT such that I can use the following conditional code in my C files?


#ifdef PROPELLER_CAT

// stuff that is only used for Catalina compiles.

#endif


I tried this and it didn't work:


catalina -c -DPROPELLER_CAT my_file.c

David Betz
11-02-2011, 03:48 PM
I need to be able to define preprocessor symbols on the Catalina command line and it doesn't seem that -D does what I expect. How do I define the symbol PROPELLER_CAT such that I can use the following conditional code in my C files?


#ifdef PROPELLER_CAT

// stuff that is only used for Catalina compiles.

#endif


I tried this and it didn't work:


catalina -c -DPROPELLER_CAT my_file.c

Never mind. I figured it out. For Catalina, I need -W-DPROPELLER_CAT rather than just -DPROPELLER_CAT. While this works it is different than every other C compiler I have ever used.

RossH
11-02-2011, 09:55 PM
Never mind. I figured it out. For Catalina, I need -W-DPROPELLER_CAT rather than just -DPROPELLER_CAT. While this works it is different than every other C compiler I have ever used.

Hi David,

Yes, I had the choice of using -D for PASM symbols or for C symbols (there are various technical reasons why I didn't want the same flag to define a symbol for both). I suppose I could revert to using -D for C symbols and use another flag for PASM symbols.

It seems a minor point, but if there is enough opinion one way or another it is easy to change. It seems to me that not many people use the command line anyway. You and I are probably the last of a dying breed :)

Ross.

David Betz
11-02-2011, 10:04 PM
Hi David,

Yes, I had the choice of using -D for PASM symbols or for C symbols (there are various technical reasons why I didn't want the same flag to define a symbol for both). I suppose I could revert to using -D for C symbols and use another flag for PASM symbols.

It seems a minor point, but if there is enough opinion one way or another it is easy to change. It seems to me that not many people use the command line anyway. You and I are probably the last of a dying breed :)

Ross.
It certainly isn't a blocking issue but I will say that I ran into this the last time I used Catalina as well. It's hard to break the habit of assuming -D can be used for C defines like most other C compilers allow. Keeping it this way may cause minor startup problems for people who want to port C code from another platform if the code uses conditional compilation.

Wouldn't you still have this problem with the GUI? When I use Xcode or Visual C++ I often use conditional compilation and have to define symbols for the compile. Does the Code::Blocks GUI automatically supply the needed -W in front of any definitions that the user asks for?

RossH
11-02-2011, 10:51 PM
Wouldn't you still have this problem with the GUI? When I use Xcode or Visual C++ I often use conditional compilation and have to define symbols for the compile. Does the Code::Blocks GUI automatically supply the needed -W in front of any definitions that the user asks for?

Yes - adding <symbol> in the #define tab in Code::Blocks defines a C symbol as you would expect. If you ever need to add a PASM symbol you must specify -D<symbol> on the other options tab - but since Catalina is integrated fully in Code::Blocks, you hardly ever need to do this (you just select the appropriate build option instead).

So using -D vs -W-D to define a C symbol really only affects command line users. My only hesitation in changing it is the amount of places I need to update documentation :frown: - but if I get one more request for this change then I will do so for the next release :smile:

Ross.

David Betz
11-02-2011, 11:23 PM
Oh boy, I guess I just need to create another forum account and make another request! :-)

RossH
11-02-2011, 11:51 PM
Oh boy, I guess I just need to create another forum account and make another request! :-)

Blast! I obviously need to be more specific - I'll do it if I get "one more request from a person registered on these forums prior to 2/11/2011 who sends me a certified extract of their birth certificate and who is unrelated to David Betz" :smile:

Ross.

Rayman
11-03-2011, 12:57 AM
Ross, I wouldn't spend any time updating command line stuff. The GUI is great, I'd focus on that.
Command-line people are used to suffering anyway...

David Betz
11-03-2011, 01:31 AM
Ross, I wouldn't spend any time updating command line stuff. The GUI is great, I'd focus on that.
Command-line people are used to suffering anyway...
I don't feel as though using command line tools is suffering. They offer far more flexiblity than GUI tools. Pretty much every company I've ever worked for built their systems using command line tools. Do you think Microsoft uses Visual Studio to build Windows? Is Linux built using a GUI? I doubt that Mac OS X is. Command line tools are still used by many people for important work. They aren't just a relic of the past.

Rayman
11-03-2011, 01:48 AM
Was only half serious, half joking...
But, you do bring up an interesting question: Do Microsoft programmers use an IDE? I bet they do... Here's all I could find on Wikepedia:

On the various Microsoft Windows (http://forums.parallax.com/wiki/Microsoft_Windows) platforms, command-line tools for development are seldom used.

David Betz
11-03-2011, 01:56 AM
Was only half serious, half joking...
But, you do bring up an interesting question: Do Microsoft programmers use an IDE? I bet they do... Here's all I could find on Wikepedia:

On the various Microsoft Windows (http://forums.parallax.com/wiki/Microsoft_Windows) platforms, command-line tools for development are seldom used.

What about for Windows itself? It's easy to use a GUI to develop simple programs but not so easy for complex configurable systems. They may use VC Studio. I'm not saying they don't. I have no inside knowledge, I'm just guessing. I use a GUI myself but I find that building complex programs that run on multiple platforms is much easier using a more batch-oriented build process. In any case, I think Catalina would be a better product if it followed common conventions and -D is a defacto-standard for defining symbols on the command line.

RossH
11-03-2011, 02:16 AM
What about for Windows itself? It's easy to use a GUI to develop simple programs but not so easy for complex configurable systems. They may use VC Studio. I'm not saying they don't. I have no inside knowledge, I'm just guessing. I use a GUI myself but I find that building complex programs that run on multiple platforms is much easier using a more batch-oriented build process. In any case, I think Catalina would be a better product if it followed common conventions and -D is a defacto-standard for defining symbols on the command line.

David is correct: -D is the defacto standard for defining symbols on the command line - this is why I chose it for defining PASM symbols. With Catalina, defining PASM symbols on the command line is very common, but most people will never find a need to define a C symbol on the command line. I accept that it is common for Makefiles to do so - but I'm still only half convinced, since most people will never use "make" to compile their propeller programs - they will instead use Code::Blocks (which has its own build engine built-in).

As for command line tools - the reason Windows command line tools are so little used is that they're just crap. It is not in Micro$oft's interest to improve them since they'd be undercutting their own business model. But on Linux, where you have a choice of many decent command line tools, I don't think you'd find many "power users" who ever use anything else.

Ross.

David Betz
11-03-2011, 02:20 AM
David is correct: -D is the defacto standard for defining symbols on the command line - this is why I chose it for defining PASM symbols. With Catalina, defining PASM symbols on the command line is very common, but most people will never find a need to define a C symbol on the command line. I accept that it is common for Makefiles to do so - but I'm still only half convinced, since most people will never use "make" to compile their propeller programs - they will instead use Code::Blocks (which has its own build engine built-in).

As for command line tools - the reason Windows command line tools are so little used is that they're just crap. It is not in Micro$oft's interest to improve them since they'd be undercutting their own business model. But on Linux, where you have a choice of many decent command line tools, I don't think you'd find many "power users" who ever use anything else.

Ross.
One thing I don't really understand about your comment is why defining PASM symbols has to be different than defining C symbols. Why can't both use -D in the same way?

RossH
11-03-2011, 02:42 AM
One thing I don't really understand about your comment is why defining PASM symbols has to be different than defining C symbols. Why can't both use -D in the same way?

Several reasons, but the main one is that the PASM symbols are really only intended for configuring the Hardware Abstraction Layer (HAL) - and they actually have nothing to do with the C program. I do allow symbols to propagate from the HAL to the C program, but I wanted the PASM symbols to remain human readable (e.g. CLOCK, PC or DEMO) yet not conflict with any symbols that might commonly appear in C programs (e.g. CLOCK, PC or DEMO!). Otherwise someone could write (for example) a C program that relies on the symbol PC and this program would mysteriously behave differently from one compilation to another! My solution was to propagate the symbol from the HAL to C, but prefix them with "__CATALINA_" - so the PASM symbol PC becomes the C symbol __CATALINA_PC - and any existing C symbol PC is undisturbed. I could have done it the other way round (e.g. made -D PC define the C symbol PC and the HAL symbol __HAL_PC) but think of all the extra typing I would have had to do!

Ross.

David Betz
11-03-2011, 02:51 AM
Several reasons, but the main one is that the PASM symbols are really only intended for configuring the Hardware Abstraction Layer (HAL) - and they actually have nothing to do with the C program. I do allow symbols to propagate from the HAL to the C program, but I wanted the PASM symbols to remain human readable (e.g. CLOCK, PC or DEMO) yet not conflict with any symbols that might commonly appear in C programs (e.g. CLOCK, PC or DEMO!). Otherwise someone could write (for example) a C program that relies on the symbol PC and this program would mysteriously behave differently from one compilation to another! My solution was to propagate the symbol from the HAL to C, but prefix them with "__CATALINA_" - so the PASM symbol PC becomes the C symbol __CATALINA_PC - and any existing C symbol PC is undisturbed. I could have done it the other way round (e.g. made -D PC define the C symbol PC and the HAL symbol __HAL_PC) but think of all the extra typing I would have had to do!

Ross.
Okay, whatever.

RossH
11-03-2011, 03:07 AM
Okay, whatever.

Well, you asked! :smile:

Ross.

Heater.
11-03-2011, 06:01 AM
As we are often talking standards here how about this:
I have have just written the ultimate killer app for the Prop, that program that is going to make every MCU user in the world want to use a Prop above all else. I have written in C. Because I want everyone to benefit I want Catalina users and propgcc users and ICC users and so on to be able to easily compile and run it after a quick download from OBEX.

I have no idea, nor do I care, what IDE the users may have or prefer or even if they have an IDE so a a quick "make" should build it.

I need to use a lot of symbol defining to to get the code to compile under all the major propeller C compilers or indeed other C platforms compilers whilst testing on a PC.

It would help if the compiler command line options were similar.

Cluso99
11-03-2011, 06:51 AM
Maybe I am just an old dumb windoze user these days. But, I don't care about command line programs - they are yesteryears way. The modern way is by GUIs. Code::Blocks solves this so I am happy to stay away from the command line. I view *nix the same way. Isn't that why we now have Android???

If you look at the Arduino, doesn't it use a GUI to make it simple for the users. If I am not mistaken, they don't even refer to programs anymore, but rather refer to them as sketches. Everything to remove the user from the intricies. (I am not an arduino user, so I could be wrong here - it's just what of have seen on the periphery).

RossH
11-03-2011, 08:52 AM
Heater,

Cluso is correct.The download stats for Catalina show Windows downloads outnumber Linux downloads by 10:1 - and most Windows users would never even have heard of make (even if they are sometimes forced to resort to the command line for some obscure operations). If you also assume that some substantial fraction of Linux users (at least those under the age of 40!) would probably also prefer to use an IDE if one were available (which it is), then this means only something like 1 in 20 C programmers might ever need to use a command line option.

Much as we old fogeys might like to pretend otherwise, C programming on the Propeller will take place via an IDE - or not at all. But this is actually a good thing, since it means that users can just download plain old C code from the OBEX and compile it. They won't need to know about make or ranlib or addr2line or ar or readelf or any of the other arcana that belong to the days of relics like us :(

This will be true even if I decide it is worth changing Catalina to use -D instead of -W-D - such a detail would be of interest to only about 1 user in 20. Possibly even less - only you, me and David Betz seem at all interested so far! :)

Ross.

Heater.
11-03-2011, 10:04 AM
Cluso,



I don't care about command line programs - they are yesteryears way.


I do love this never ending command line vs IDE debate.

If I want to travel from A to B do I take that economy seat in a Jumbo jet
or the train/bus/tram. Then again I could use my car, or motorcycle or bicycle.
Then again it might be as well to walk. Or perhaps I end up having to swim or
crawl through a swamp. It all depends on distance and what's in between.

How about if I like to build my own furniture from flat packs. Probably I
don't need much more than an electric screwdriver. But if I want to do more
custom jobs I might need a whole array of screwdrivers, spanners and other
tools. Perhaps manually operated is better in many cases.

The invention the the airplane did not make those ancient wheels "yesteryear"
or redundant. The invention of the electric screwdriver did not make hand tools
useless.

See where I'm going with this? We should not throw out a good thing just
because we have a new thing. Like the ancient wheel the command line is damn
useful and should be perfected. Sadly MS has not bothered much with that so
everyone thinks command lines are stuck in the time of CP/M and DOS.

I have no problem with IDE's if people want to use them and I often use them
myself. My biggest gripe is that there are so many of the damn things all
different. For example:

Propeller - Prop Tool or BST or PZST or now Code::Blocks/Eclipse/Netbeans
PIC chips - MPLAB
ATMEL chips - AVR studio.
X chips - A customized Eclipse
Android - A different customized Eclipse
Qt programming - Qt Creator
C# on Linux - MonoDevelop
STM32 - Whatever it is that only runs on Windows.
Pascal - Lazarus
And so on....

Given my work and hobby activities I end up having to hop between a number of
these quite regularly. Having to keep up with the quirks of all of them is a
real pain in the...

I end up praying for a simple.

# make
# make run

which during a dev session reduces to just hitting up arrow and return or I
attach it to a button in an editor.

Luckily Cluso, you have a command line interface, the text box I am typing this
into. I don't have to download, install and open up some funky "Cluso IDE",
after having installed Windows because it only runs there, and figure out which
buttons to press to say something to you. And god help me if the "Cluso IDE"
does not have the buttons for the ideas I want to convey:)

David Betz
11-03-2011, 10:32 AM
Well, you asked! :smile:

Ross.
You know, this is one thing that I dislike about the Catalina community. Not only are requests often met with rejection even when they are reasonable and would serve to improve the product. Also, many of the Catalina "fans" then jump in to say how stupid the idea is and how their way of working is the only one that makes sense and everyone who does something else is stupid.

Tor
11-03-2011, 10:39 AM
Hi David,Yes, I had the choice of using -D for PASM symbols or for C symbols (there are various technical reasons why I didn't want the same flag to define a symbol for both). I suppose I could revert to using -D for C symbols and use another flag for PASM symbols. It seems a minor point, but if there is enough opinion one way or another it is easy to change. It seems to me that not many people use the command line anyway. You and I are probably the last of a dying breed :)Ross.I'm another command liner.. I prefer to manage my own makefiles, I basically use the same methods (with Git version control etc) as I do for all other software projects. I was also a bit surprised by how -D was used for a different purpose than "standard".. but it's no big deal for me as it's easy enough to handle via my makefiles (I set CFLAGS or similar just one place and use the variable where needed, so it matters little. I'm used to compilers having slightly different options, although -D isn't usually one of them. No big deal though, as I said.).

-Tor

RossH
11-03-2011, 10:46 AM
You know, this is one thing that I dislike about the Catalina community. Not only are requests often met with rejection even when they are reasonable and would serve to improve the product. Also, many of the Catalina "fans" then jump in to say how stupid the idea is and how their way of working is the only one that makes sense and everyone who does something else is stupid.

Huh? C'mon, David. You asked why, so I explained. Your response was "whatever". Where I live, that is generally considered quite a rude and dismissive answer, and I think I showed quite a lot of restraint by not getting annoyed by such a response when I took the time and trouble to try and answer your question.

If you weren't interested in the answer, then why did you ask the question in the first place? Just to score some kind of obscure debating point?

Also, I didn't reject your suggestion - I said I would change it in the next release if anyone else agreed it was a good idea. Are you seriously suggesting I should just agree to make a change that will take me several days of work - and add no benefit whatsoever for most users - just because one person asks for it?

What the heck is wrong with these forums these days?

Ross.

David Betz
11-03-2011, 10:48 AM
Huh? C'mon, David. You asked why, so I explained. Your response was "whatever".

If you weren't interested in the answer, then why did you ask the question in the first place?

Ross.
I wasn't primarily talking about your response although I see there is now at least one other person who said a traditional -D would be helpful (Heater) so I assume it will be implemented in the next release.

RossH
11-03-2011, 11:35 AM
...

I end up praying for a simple.

# make
# make run

...



Heater,

This is a bit simplistic. I've developed a lot of Unix software in my time, and written and modified (and fought with!) a lot of versions of make and Makefiles. In my experience it is hardly ever the case that you can move a program from one platform to another - or one compiler to another - without needing to make at least some changes to the Makefile - and sometimes very subtle ones (Got a space instead of a tab? - fail! Missing a blank line? - fail!).

People who think Makefiles are as easy as you seem to be implying have probably never written a complex one - although they may well have used one that someone else has spent a lot of skull sweat on to make work right. This whole issue is why make files are not often written directly any more. These days one would tend to use a makefile generator like the GNU autotools (http://en.wikipedia.org/wiki/Autotools). Unfortunately, for novice users this just brings yet another layer of complexity to the problem.

The alternative (again, especially for novices) is to use an IDE - one of the key things that IDEs do for you is avoid this whole issue. I agree that it is annoying that every IDE on every platform is different. If there was a perfect one no doubt we would all use it - but I have never found one.

Ross.

RossH
11-03-2011, 11:43 AM
I wasn't primarily talking about your response although I see there is now at least one other person who said a traditional -D would be helpful (Heater) so I assume it will be implemented in the next release.

David, I added to my original response after first posting it, so we seem to have cross-posted a bit. However, I won't go back and edit it again - that would only make things even more confusing.

To be honest, I'm finding these forums very tiresome at the moment, and after your response I'm now not really inclined to go to the effort required to make such a change. Perhaps I'll reconsider tomorrow, but for now, I'm calling it a day.

Ross.

David Betz
11-03-2011, 11:45 AM
Heater,

This is a bit simplistic. I've developed a lot of Unix software in my time, and written and modified (and fought with!) a lot of versions of make and Makefiles. In my experience it is hardly ever the case that you can move a program from one platform to another - or one compiler to another - without needing to make at least some changes to the Makefile - and sometimes very subtle ones (Got a space instead of a tab? - fail! Missing a blank line? - fail!).

People who think Makefiles are as easy as you seem to be implying have probably never written a complex one - although they may well have used one that someone else has spent a lot of skull sweat on to make work right. This whole issue is why make files are not often written directly any more. These days one would tend to use a makefile generator like the GNU autotools (http://en.wikipedia.org/wiki/Autotools). Unfortunately, for novice users this just brings yet another layer of complexity to the problem.

The alternative (again, especially for novices) is to use an IDE - one of the key things that IDEs do for you is avoid this whole issue. I agree that it is annoying that every IDE on every platform is different. If there was a perfect one no doubt we would all use it - but I have never found one.

Ross.
I don't understand why some people here seem to think we need to resolve the question of "IDE or command line". To me it isn't a choice of one or the other. I use both and I think both have value. Why do we insist on always degenerating into a "my way is better than yours" debate?

potatohead
11-03-2011, 02:31 PM
I use GUI environments and like them. Generally, they are easier for the fact that one doesn't need to maintain anywhere near the number of details and or state information to progress on a project.

(I like GUI environments better when they are managed, freeing me from files entirely, or nearly entirely, leaving just objects. Nice way to work, and that's how I work in MCAD land more often than not.)

I also use command line interfaces. I like them too, and I came up on 8bitters and UNIX. Never did mind if they vary. Always did mind when they are poorly documented, or work in inconsistent ways. Verbosity on the command line can be painful too.

To me, this change boils down to a chunk of time to do the change, debug, release.. There is finite time and it competes with features. Personally, I would take new features in Catalina over command line cleanups. Any user of sufficient experience to use a command line can very easily deal with variances in said commands, and has done so over their computing life so far.

I am the one who advocated for "Catalina Command Prompt", and it works great, I can learn what is going on, test things, and then just run the rather posh GUI otherwise, keeping my mental investment in the tools lean. That rocks hard.

GIven how we see Catalina developed to date, a change that impacts the progress of features is a sales job. Some discussion on worth is entirely warranted. That change will quite literally put some nice feature into the future. No worries on that, but one must ask, "Is that worth it?", which is being asked and quite rationally. I vote no.

To clarify, if it were actually broken, then I would vote yes, but it isn't broken. Works as designed and documented. Reasonably well documented I might add.

David Betz
11-03-2011, 02:42 PM
To me, this change boils down to a chunk of time to do the change, debug, release.. There is finite time and it competes with features. Personally, I would take new features in Catalina over command line cleanups. Any user of sufficient experience to use a command line can very easily deal with variances in said commands, and has done so over their computing life so far.
I understand and agree with this philosophy. What I object to is all of the people who took this as an opportunity to essentially say that command line tools have no value and should not be given any thought or effort. I don't think I've ever said that the way someone works is wrong but the GUI advocates refuse to acknowledge any way but their own as having any value at all.

It doesn't matter though. Ross said he'd make the change if he had two people ask for it and I think two have asked for it at this point. Since almost everyone here uses the GUI pretty much exclusively, changes to the command line syntax won't have any impact on anyone.

potatohead
11-03-2011, 02:57 PM
Yeah, that's rough. I too feel frustration over "who cares about the command line?"

The thing is, without the command line folks, there would be no great GUI environments. The core of computing hasn't changed much. Today, we've boot strapped GUI environments to the point where people can simply ignore the "voodoo" under the hood, and that's fine, and something I am glad we can do. I often CHOOSE to do this, just for my own time management.

Why can't we just get more hobby time? :)

But, I cannot justify marginalizing basic computing skills. They are invaluable, often they are NECESSARY too, particularly where we've not boot strapped the GUI into functionality that meets general requirements.

What we've never really done in GUI land is develop SYNTAX. That, to me, is the biggest limitation. We've managed blocks, connectors, boxes and all manner of clever things to attempt to encode what is essentially language into the GUI and it's all been a big FAIL, for the most part. Edit: Not a fail in terms of helping people get stuff done. We progress nicely there. It's a fail in terms of replacing the fundamental computing elements we need to build out and boot strap new things to the point where most anybody can make use of, and benefit from, that's all.

Because of that reality, the command line is the de-facto language of note for computing. We won't see that change anytime soon, until we see what is basic computing change anytime soon, and a lot of PhD's are writing thesis on how that may potentially occur sometime in the distant future.

Here are a couple of great references to grok something about command line computing:

http://www.cryptonomicon.com/beginning.html

That author wrote a GREAT essay on this aspect of computing. Recommended because it's a good, solid, fun read, and because there is some culture there, hinted at with broad strokes, worth knowing about to better understand one another. A lot of the friction we see here is that we simply do not understand one another well, and we are communicating with text. Let's keep that in mind. I botch it often. We all do.

I must assemble the other one, coming soon to my blog, as it's long.

Edit: It's up there. That author captures perfectly where the friction is. From where I stand, simply understanding that, whatever our personal position is, helps to put comments into context. We need one another more than we don't, and that's what I'm trying to communicate here.

RossH
11-03-2011, 11:36 PM
I understand and agree with this philosophy. What I object to is all of the people who took this as an opportunity to essentially say that command line tools have no value and should not be given any thought or effort. I don't think I've ever said that the way someone works is wrong but the GUI advocates refuse to acknowledge any way but their own as having any value at all.
I don't think this is a fair interpretation of what's been said. Personally, I still prefer to use a command line - but I've come to realize (especially over the last year or so) that I am now part of a fairly small minority. Command lines may remain the interface of choice for power users, but most others will simply not use a command line no matter what it offers. They may try it once or twice, but they won't persevere with it long enough to learn all the obscure syntax that those of us who grew up with them regard as perfectly normal. This doesn't mean such things don't have value - it is simply facing reality that the potential benefit of improving them is small, and that the time required to do so may in fact be better spent elsewhere.

It doesn't matter though. Ross said he'd make the change if he had two people ask for it and I think two have asked for it at this point. Since almost everyone here uses the GUI pretty much exclusively, changes to the command line syntax won't have any impact on anyone.
Yes, I did. But since we all seem to now agree that it affects so few users, and also because I am in the middle of some new features and enhancements that I want to release as soon as I can finish them, it won't make in the next release. Sorry.

Ross.

David Betz
11-04-2011, 12:01 AM
Yes, I did. But since we all seem to now agree that it affects so few users, and also because I am in the middle of some new features and enhancements that I want to release as soon as I can finish them, it won't make in the next release. Sorry.
Well, maybe some future release then. :-)
Just out of curiosity, why didn't you just use some other letter for defining assembly symbols, maybe -K? Then both could be expressed concisely.

Dr_Acula
11-04-2011, 01:05 AM
Re command line vs non command line, I think Catalina has the best of both worlds. When I wrote an IDE for catalina in VB.Net, all I did was use check boxes and radio buttons to select options rather than typing them in. I took that IDE further by doing things like translating Basic into C, and then translating different variants of C, but it is still terribly convenient to write those modules as command line programs that are then 'shelled' from an IDE.

The command line nature of Catalina means that it can work with my IDE and code::blocks and any other front end you might choose. For my IDE, and indeed for code::blocks, the command line nature of the program can be completely hidden from the user. Or you can shell a dos window if you want to. I like that flexibility.

And if Ross changes the syntax for the command line, no problem for my IDE as it will be just a couple of lines of vb.net code.

RossH
11-04-2011, 01:16 AM
Well, maybe some future release then. :-)
Just out of curiosity, why didn't you just use some other letter for defining assembly symbols, maybe -K? Then both could be expressed concisely.

That's probably what I will end up doing. I just naturally used -D ... which I guess is as good an argument for making this change as any :)

David Betz
11-04-2011, 02:07 AM
That's probably what I will end up doing. I just naturally used -D ... which I guess is as good an argument for making this change as any :)
Well, as I said when I first made the observation that maybe -D should have it's traditional meaning, this isn't a blocking issue for me. In fact, if it never gets done it won't be the end of the world. I just thought becoming a bit more standard would be a benefit for those who are trying to adopt Catalina and are used to the conventions of other compilers. I can certainly type -W-D until the more traditional syntax is implemented (if ever).

Cluso99
11-04-2011, 02:26 AM
David: You have really taken the GUI comments out of context. I just explained why I am not interested in the command line - I very explicitly said it maybe just me. I have moved into the modern world where GUIs rain supreme by volume of uses (as borne out here too).

I have a mate who has a production package, originally written in an old form of basic. It used a command line interface. When I helped him rewrite in VB3/4/5/6 one user refused to move to the new GUI. THis meant all the extras included in the new VB code had to be back-ported into the old basic code. What a pain. It held up progress on the new code. I must say that the new VB code was slower, but then PCs have improved in speed. Finally that user has succumbed to the modern GUI interface and the old basic support for one in a hundred users could be dropped.

I dare say that if *nix had a common GUI, then more users would use *nix than they currently do.

Just for the record, I am foremost a pasm/assembler programmer by choice. That means I love the nuts and bolts. But I don't really care for yesteryear tools. Just my opinion, just as everyone else is entitled to theirs.

Is it just me, or does it seem the GCC group (now more than one) are trying to find fault with Catalina. And is this in order to push their own barrow??? Certainly food for thought. This forum is really degenerating since GCC started!

David Betz
11-04-2011, 02:36 AM
Is it just me, or does it seem the GCC group (now more than one) are trying to find fault with Catalina. And is this in order to push their own barrow??? Certainly food for thought. This forum is really degenerating since GCC started!
I don't even know how to respond to this. I have never said anything against Catalina. I have made suggestions about how it could be improved. I hope you make suggestions as to how PropGCC can be improved as well. I'm not interested in arguments about whose compiler is better. I'm working on GCC because I want to help Parallax not because I want to hurt Catalina.

David Betz
11-04-2011, 02:40 AM
But I don't really care for yesteryear tools. Just my opinion, just as everyone else is entitled to theirs.
Calling something "yesteryear tools" is a derogatory term in my opinion intended to belittle anyone who choses to use those tools. This is exactly what I'm talkiing about.

RossH
11-04-2011, 03:43 AM
Calling something "yesteryear tools" is a derogatory term in my opinion intended to belittle anyone who choses to use those tools. This is exactly what I'm talkiing about.

Well, I might not have chosen the term "yesteryear tools" - but I did call them "arcana that belong to the days of relics like us". :)

There is a lot of high feeling floating around because the GCC team is currently trying to showcase their stuff. Whether it was your intention or not, raising minor issues like command line syntax incompatibilities with "other compilers" at this point does make it look a lot like you are trying to raise a point of differentiation between GCC and Catalina. But whether or not that was not your intention, I think we have dealt with it and I for one am happy to move on.

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 only fully 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!).

Ross.

David Betz
11-04-2011, 03:50 AM
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 only fully 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!

Tor
11-04-2011, 10:34 AM
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).

So I'm not voting 'yes'. :)

-Tor

KMyers
11-04-2011, 04:08 PM
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.....

David Betz
11-04-2011, 04:23 PM
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?

jazzed
11-04-2011, 06:00 PM
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.

Best to all.
--Steve

Rayman
11-04-2011, 06:21 PM
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?

David Betz
11-04-2011, 06:33 PM
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.

RossH
11-04-2011, 10:34 PM
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.

But it is early days yet - watch this space!

Ross.

RossH
11-04-2011, 10:42 PM
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!

David Betz
11-04-2011, 11:52 PM
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!
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.

Cluso99
11-05-2011, 12:21 AM
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.

RossH
11-05-2011, 12:43 AM
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!

Ross.

David Betz
11-05-2011, 01:00 AM
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.

David Betz
11-05-2011, 01:22 AM
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!

RossH
11-05-2011, 01:35 AM
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.

Ross.

David Betz
11-05-2011, 02:14 AM
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.

David Betz
11-05-2011, 02:24 AM
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.

RossH
11-05-2011, 02:55 AM
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.

Post an example and I'll check it out.

Ross.

David Betz
11-05-2011, 03:02 AM
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.
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.

RossH
11-05-2011, 03:19 AM
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.

Ross.

David Betz
11-05-2011, 03:30 AM
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

RossH
11-05-2011, 05:13 AM
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.

Ross.

David Betz
11-05-2011, 01:09 PM
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 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.

Rayman
11-05-2011, 01:27 PM
David,

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...

David Betz
11-05-2011, 01:36 PM
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 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

Rayman
11-05-2011, 03:38 PM
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"...

RossH
11-06-2011, 12:17 AM
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.

David Betz
11-06-2011, 12:25 AM
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.
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?

David Betz
11-06-2011, 12:37 AM
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.

RossH
11-06-2011, 01:30 AM
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?

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.

RossH
11-06-2011, 01:31 AM
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.

Yes, by quite a long way. It would easily run on the Prop 2 in TINY mode though :)

Ross.

David Betz
11-06-2011, 01:04 AM
The download of xbasic is now working but how do I open a terminal window using Code::Blocks so I can interact with the program?

David Betz
11-06-2011, 01:54 AM
I just tried using Hyperterminal and I'm getting very weird results. First, it seems the RETURN key generates a linefeed. Second, I get strange characters as well as the ones I'm printing myself.

For example, this program prints the following results:


100 printf("Hello")
110 printf("Goodbye\n")




HVHVHVHVHVHelloGoodbye


Any idea why this might be happening?

RossH
11-06-2011, 02:38 AM
I just tried using Hyperterminal and I'm getting very weird results. First, it seems the RETURN key generates a linefeed. Second, I get strange characters as well as the ones I'm printing myself.

For example, this program prints the following results:


100 printf("Hello")
110 printf("Goodbye\n")




HVHVHVHVHVHelloGoodbye


Any idea why this might be happening?

I don't have hyperterminal - maybe it has a problem. Using putty (or PST) I get:

list
10 printf("hello")
20 printf("goodbye\n")
OK
run
H:228 O:3 D:48 V:0 T:54
hellogoodbye
OK

Note that if your terminal emularor needs an explicit CR along with each LF as a terminator on the output stream then you can enable the CR_ON_LF option. PST in particular is not very configurable, so I had to add that as a option along with NO_CR_TO_LF (if you want your program to see a CR instead of LF as a terminator on the input stream). All this is strictly non-ANSI standard behaviour, but unfortunately necessary under Windows unless you are using an ANSI standard terminal emulator (e.g. putty).

Ross.

RossH
11-06-2011, 02:39 AM
The download of xbasic is now working but how do I open a terminal window using Code::Blocks so I can interact with the program?

Just use putty or PST. I didn't put a specific option on the Tools menu to start a terminal emulator since I don't know what terminal emulator people will be using.

Ross.

David Betz
11-06-2011, 02:51 AM
I just tried PST and I'm still having trouble. I suspect I still have some configuration option wrong. I'll go back and look again.

David Betz
11-06-2011, 02:55 AM
I just tried PST and I'm still having trouble. I suspect I still have some configuration option wrong. I'll go back and look again.
Here are the options I have set. They are all set in the "xbasic" tab. Nothing is set in the "Release" tab. I assume that means it will inherit all settings from the "xbasic" tab.



C3
libci
SMALL
8K Cache
FLASH
PC


Do I need anything else?

RossH
11-06-2011, 03:34 AM
Here are the options I have set. They are all set in the "xbasic" tab. Nothing is set in the "Release" tab. I assume that means it will inherit all settings from the "xbasic" tab.



C3
libci
SMALL
8K Cache
FLASH
PC


Do I need anything else?

Aha! I built it with libcx and it works. If I build with libc or libci I see (approximately) what you see. That is very odd. Does your program make any assumptions about the way the I/O subsystem works, or try to mess about with internal data structures?

Ross.

RossH
11-06-2011, 04:28 AM
Hi David,

I see the problem. Your program uses vsprintf, which depends on the streams infrastructure, which is not inlcuded when using the simplified libc or libci libraries - these libraries only include support for the three predefined streams stdin, stdout and stderr. Support for other streams is only included in the full libcx library (or libcix).

This would affect sprintf as well - I don't think there's much I can do about this in the short term, except document it as an unexpected limitation of using libc or libci. For the moment, if you need vsprintf or sprintf you will need to compile with either the libcx or libcix libraries.

I'll see if I can include a fixed version in 3.5.

Ross.

David Betz
11-06-2011, 11:01 AM
Hi David,

I see the problem. Your program uses vsprintf, which depends on the streams infrastructure, which is not inlcuded when using the simplified libc or libci libraries - these libraries only include support for the three predefined streams stdin, stdout and stderr. Support for other streams is only included in the full libcx library (or libcix).

This would affect sprintf as well - I don't think there's much I can do about this in the short term, except document it as an unexpected limitation of using libc or libci. For the moment, if you need vsprintf or sprintf you will need to compile with either the libcx or libcix libraries.

I'll see if I can include a fixed version in 3.5.

Ross.
Switching to libcix worked for me. Thanks for pointing that out. I notice I'm getting a bunch of warnings when I compile xbasic that I think shouldn't be there. Doesn't ANSI C allow NULL (which is defined as a void*) to be assigned to any pointer value? I shouldn't have to case NULL to assign it to some other type of pointer should I?



..\db_generate.c|42|warning: conversion from `pointer to void' to `pointer to void function(pointer to ParseContext,PValOp,pointer to struct PVAL)' is compiler dependent|


Here is the code in question:



typedef struct PVAL PVAL;
struct PVAL {
void (*fcn)(ParseContext *c, PValOp op, PVAL *pv);
union {
String *str;
int val;
} u;
};

...

PVAL *pv;

...

pv->fcn = NULL;

RossH
11-06-2011, 09:13 PM
Doesn't ANSI C allow NULL (which is defined as a void*) to be assigned to any pointer value? I shouldn't have to case NULL to assign it to some other type of pointer should I?


Pointers to functions are not guaranteed to be the same as data pointers, and NULL is a data pointer. This is specifically discussed in the ANSI C standard (in the "Common Extensions" section - specifically, the section titled "Function pointer casts").

The general description of all such extensions is:


The following extensions are widely used in many systems, but are not portable to all implementations. The inclusion of any extension that may cause a strictly conforming program to become invalid renders an implementation nonconforming. Examples of such extensions are new keywords, extra library functions declared in standard headers, or predefined macros with names that do not begin with an underscore.

So a warning that this is implementation-specific is appropriate (if perhaps a little over-zealous!). In the particular case of LCC/Catalina this extension is supported, but when porting the same code to other compilers it may not be.

Ross.

David Betz
11-06-2011, 09:24 PM
Pointers to functions are not guaranteed to be the same as data pointers, and NULL is a data pointer. This is specifically discussed in the ANSI C standard (in the "Common Extensions" section - specifically, the section titled "Function pointer casts").

The general description of all such extensions is:



So a warning that this is implementation-specific is appropriate (if perhaps a little over-zealous!). In the particular case of LCC/Catalina this extension is supported, but when porting the same code to other compilers it may not be.

Ross.
So what is the equivilent NULL function pointer? Maybe NULL should simply be defined as 0 rather than (void *)0. I've never gotten this warning in anything other than Catalina and I've used *lots* of different C compilers. Maybe this warning should be off by default and enabled by a command line option.

David Betz
11-06-2011, 09:28 PM
So what is the equivilent NULL function pointer? Maybe NULL should simply be defined as 0 rather than (void *)0. I've never gotten this warning in anything other than Catalina and I've used *lots* of different C compilers. Maybe this warning should be off by default and enabled by a command line option.

Here is how NULL is defined in the simple library we built for GCC:


#ifndef NULL
#define NULL (0)
#endif

RossH
11-06-2011, 09:49 PM
So what is the equivilent NULL function pointer? Maybe NULL should simply be defined as 0 rather than (void *)0. I've never gotten this warning in anything other than Catalina and I've used *lots* of different C compilers. Maybe this warning should be off by default and enabled by a command line option.

Catalina supports this particular extension, so a NULL function pointer is the same as a NULL data pointer (which is after all just an agreed value that tells you the pointer doesn't currently point to anything).

I agree LCC can be a bit over-zealous about its warnings (the one that always worries me is when it tells you it has "elided" some of your code!). You can disable warning like this using the "Suppress all warnings" option (-W-w).

Ross.

David Betz
11-06-2011, 09:51 PM
Catalina supports this particular extension, so a NULL function pointer is the same as a NULL data pointer (which is after all just an agreed value that tells you the pointer doesn't currently point to anything).

I agree LCC can be a bit over-zealous about its warnings (the one that always worries me is when it tells you it has "elided" some of your code!). You can disable warning like this using the "Suppress all warnings" option (-W-w).

Ross.
I don't believe in disabling warnings. They can be very useful in finding errors in the code. That is why it is important that you don't get extraneous warnings.

FYI, newlib also defines NULL as 0 with no cast.

RossH
11-06-2011, 10:31 PM
I don't believe in disabling warnings. They can be very useful in finding errors in the code. That is why it is important that you don't get extraneous warnings.

FYI, newlib also defines NULL as 0 with no cast.

Either 0 or (void *)0 is acceptable as the definition of NULL. The latter has some advantages - specifically that it does generate more warnings about potentially non-portable code.

There is a (very extensive!) discussion of NULL here (http://c-faq.com/%7Escs/cgi-bin/faqcat.cgi?sec=null) - who knew there was so much to know about nothing?

Ross.

David Betz
11-07-2011, 12:47 AM
Either 0 or (void *)0 is acceptable as the definition of NULL. The latter has some advantages - specifically that it does generate more warnings about potentially non-portable code.

There is a (very extensive!) discussion of NULL here (http://c-faq.com/%7Escs/cgi-bin/faqcat.cgi?sec=null) - who knew there was so much to know about nothing?

Ross.
Since I believe the ANSI standard says that any pointer can be assigned the value zero it seems like it would be best for NULL to just be zero. That eliminates the need for zillions of different NULL-like values for each possible pointer type. It is also clearer to assign NULL to a pointer variable than the constant zero.

RossH
11-07-2011, 01:03 AM
Since I believe the ANSI standard says that any pointer can be assigned the value zero it seems like it would be best for NULL to just be zero. That eliminates the need for zillions of different NULL-like values for each possible pointer type. It is also clearer to assign NULL to a pointer variable than the constant zero.

This is explicitly addressed in the reference I posted as question 5.16 (http://c-faq.com/null/confusion4.html):


Q: Given all the confusion surrounding null pointers, wouldn't it be easier simply to require them to be represented internally by zeroes?
A: Some implementations naturally represent null pointers by special, nonzero bit patterns, particularly when it can be arranged that inadvertently using those values triggers automatic hardware traps. Requiring null pointers to be represented internally as 0, and therefore disallowing use of the special, nonzero values, would be an unfortunate step backwards, because catching errors which result in invalid accesses is a Good Thing.
Besides, what would such a requirement really accomplish? Proper understanding of null pointers does not require knowledge of the internal representation, whether zero or nonzero. Assuming that null pointers are internally zero does not make any code easier to write (except for a certain ill-advised usage of calloc; see question 7.31 (http://c-faq.com/%7Escs/cgi-bin/faqcat.cgi?sec=malloc#calloc)). Known-zero internal pointers would not reduce the need for casts in function calls, because the size of the pointer might still be different from that of an int. (If ``nil'' were used to request null pointers, as mentioned in question 5.14 (http://c-faq.com/%7Escs/cgi-bin/faqcat.cgi?sec=null#confusion), the urge to assume an internal zero representation would not even arise.)

Ross.

RossH
11-07-2011, 01:54 AM
I wish you luck with Catalina. I won't be using it anymore myself. I find that it diverges from standard practice enough that it is unpleasant to use and that any requests to make it conform more closely invariably result in obscure references to standards documents rather than an effort to make the tool more useful. Others of course enjoy Catalina and I wish them well with it.

Hi David,

Wow! I guess it is not too hard for anyone to read between the lines here. But for my part I wish you more success in your future endeavors.

Ross.

David Betz
11-07-2011, 02:01 AM
Hi David,

Wow! I guess it is not too hard for anyone to read between the lines here. But for my part I wish you more success in your future endeavors.

Ross.
There is nothing between the lines. I started working with Catalina long before there was any GCC project and had similar problems then. This isn't an attempt to promote any other solution but more a frustration with working with something I'm not comfortable with and which seems rigid and unwilling to conform to common practice. I acknowledge that it is liked by many people and I am happy for them that it satisfies their needs. I guess it's me that is the problem.

RossH
11-07-2011, 02:31 AM
There is nothing between the lines. I started working with Catalina long before there was any GCC project and had similar problems then. This isn't an attempt to promote any other solution but more a frustration with working with something I'm not comfortable with and which seems rigid and unwilling to conform to common practice. I acknowledge that it is liked by many people and I am happy for them that it satisfies their needs. I guess it's me that is the problem.

Yes, I can see how the fact that Catalina successfully compiles and runs your xbasic program on the Propeller could easily be outweighed by the fact that you have to specify -W-D to define a symbol on the command line instead of -D, and that Catalina throws a warning message about xbasic using compiler dependent language features.

Your decision, of course - but again I just have to say ... Wow!

Ross.

David Betz
11-07-2011, 02:38 AM
Yes, I can see how the fact that Catalina successfully compiles and runs your xbasic program on the Propeller could easily be outweighed by the fact that you have to specify -W-D to define a symbol on the command line instead of -D, and that Catalina throws a warning message about xbasic using compiler dependent language features.

Your decision, of course - but again I just have to say ... Wow!

Ross.
Yes, it does run my xbasic proof-of-concept program. It is very slow at downloading it though. We've discussed this before I think but I may have an option to offer you now. I have a loader that I think can be made to download Catalina programs faster than payload. I know you prefer to use an SD card and catalyst but some of your users might like a faster serial loader. If so, I'd be happy to work with you to adapt my loader so that it can handle Catalina executables. It can currently handle ELF and Spin Binary files but I could extend it to support Catalina binaries as well. Of course I'm mostly talking about XMM executables since we both use the standard Propeller loader protocol for programs that fit in hub memory.

RossH
11-07-2011, 02:53 AM
Yes, it does run my xbasic proof-of-concept program. It is very slow at downloading it though.

Oops - should have added this one to the list as well, since it seems to be a biggie with both you and Jazzed. But I do appreciate the offer. Post your code and I'll have a look at it.

Ross.

David Betz
11-07-2011, 02:56 AM
Hi David,

Wow! I guess it is not too hard for anyone to read between the lines here. But for my part I wish you more success in your future endeavors.

Ross.

One more comment on your reply. You may have noticed that I deleted the message to which your reply was written. I did this before your reply appeared but apparently you had started writing the reply before I finished the delete. I deleted it because I thought better of it and decided it was a bit rash and probably not what I really intend to do but more a reaction to being overtired. I shouldn't post messages when in this state. Sorry!

David Betz
11-07-2011, 02:58 AM
Oops - should have added this one to the list as well, since it seems to be a biggie with both you and Jazzed. But I do appreciate the offer. Post your code and I'll have a look at it.

Ross.

The code is on Google Code in the "propgcc" project under the "loader" directory. But, it might be easier if I just collect the information I need from you about your executable file format and add it myself. I'm afraid that the code may not be that easy to navigate. :-(

Dr_Acula
11-07-2011, 03:07 AM
Yes, it does run my xbasic proof-of-concept program. It is very slow at downloading it though. We've discussed this before I think but I may have an option to offer you now. I have a loader that I think can be made to download Catalina programs faster than payload.

I did some speed tests and I seem to recall payload was about as fast as it goes. 115k which is about 11 kilobytes a second (8 data bits, one stop bit, one start bit = 10 bits per 'byte' so the number of bytes per second is about 1/10th of the baud rate). If you have a 200 kilobyte program it is going to take nearly 20 seconds. Some of my Catalina programs have grown to 300kilobytes.

I looked at faster baud rates but there seem to be limitations coming up - eg within vb.net, within some usb to serial drivers. Some terminal programs max out at 57k. So pushing the baud rate up is difficult.

I have this idea (I even have some boards half soldered up) where you take a $2 USB to sd card adaptor, take off the case, solder the board to a custom made board and then add a 4PDT toggle switch to switch the SD card between the propeller and as a PC drive.

It doesn't matter what language we are talking, GCC, large xbasic, Catalina, sooner or later we are going to have to find some solution to downloading megabyte sized files in a reasonable time.

Another possibility is to talk USB directly. Can the propeller be setup as a USB slave? Could you send a file at max prop speeds (12 megabits???) and store it into external ram (Shift-F10?) or to SD card (Shift-F11). A supersized prop for big programs?

RossH
11-07-2011, 03:13 AM
The code is on Google Code in the "propgcc" project under the "loader" directory. But, it might be easier if I just collect the information I need from you about your executable file format and add it myself. I'm afraid that the code may not be that easy to navigate. :-(

Now what was it I said earlier about "reading between the lines"?

However, you have now successfully made your point about propgcc having a faster downloader than Catalina. Not to mention propgcc using -D for defining command line symbols etc etc.

I'll have a look at your loader code when I get time. Now can we please all agree to move on to more substantive issues?

Ross.

Tor
11-07-2011, 06:43 AM
FWIW, I remember a huge discussion about NULL during the early years of Linux development. What I remember from that is that using (void *) 0 for NULL was considered too clever by half and created more problems than it solved. The value 0 is defined to be acceptable as valid for (all) pointers, and unless that changed with C99 it's still the case. I just checked AIX 6.1, Tru64 5.1, Solaris 10 and IRIX 6.30 and they all #define NULL as just 0.

-Tor

RossH
11-07-2011, 07:47 AM
FWIW, I remember a huge discussion about NULL during the early years of Linux development. What I remember from that is that using (void *) 0 for NULL was considered too clever by half and created more problems than it solved. The value 0 is defined to be acceptable as valid for (all) pointers, and unless that changed with C99 it's still the case. I just checked AIX 6.1, Tru64 5.1, Solaris 10 and IRIX 6.30 and they all #define NULL as just 0.

-Tor

Hi Tor.

Which is "better" is entirely a matter of personal preference. The ANSI C standard specifically allows both 0 and (void *)0. Actually, the situation is even worse - the standard does not actually mandate any specific value for NULL - it just has a bunch of rules about what a constant value of zero actually means in a pointer context (which is not the same thing at all). Other values than zero can satisfy these rules quite well - and other values have indeed been used in various compilers. See question 5.17 (http://c-faq.com/null/machexamp.html) in the FAQ on the subject I posted earlier.

It is quite reasonable to argue that people are "used to" the definition of NULL being zero, since it is usually true on most modern compilers (including both GCC and Catalina). But the actual rules around NULL are just a complication of C that many people simply do not understand.

Ross.

David Betz
11-07-2011, 09:58 AM
Hi Tor.

Which is "better" is entirely a matter of personal preference. The ANSI C standard specifically allows both 0 and (void *)0. Actually, the situation is even worse - the standard does not actually mandate any specific value for NULL - it just has a bunch of rules about what a constant value of zero actually means in a pointer context (which is not the same thing at all). Other values than zero can satisfy these rules quite well - and other values have indeed been used in various compilers. See question 5.17 (http://c-faq.com/null/machexamp.html) in the FAQ on the subject I posted earlier.

It is quite reasonable to argue that people are "used to" the definition of NULL being zero, since it is usually true on most modern compilers (including both GCC and Catalina). But the actual rules around NULL are just a complication of C that many people simply do not understand.

Ross.
I don't understand why you spend so much time justifying your choice of (void *)0 as the value of NULL. It may be that it is allowed by the standard but it certainly doesn't seem to be the more common definition and since 0 is also allowed by the standard why not use the value that will cause the least trouble for people who are familiar with other compilers?

David Betz
11-07-2011, 10:00 AM
Now what was it I said earlier about "reading between the lines"?

However, you have now successfully made your point about propgcc having a faster downloader than Catalina. Not to mention propgcc using -D for defining command line symbols etc etc.

I'll have a look at your loader code when I get time. Now can we please all agree to move on to more substantive issues?

Ross.
I didn't mention GCC. I only pointed to propgcc as the Google Code repository containing the loader code. I seem to remember mentioning this earlier when I had written the loader for ZOG. If you'd like me to send you a zip file containing the sources so you don't have to look in the propgcc project that would be fine with me.

What you don't seem to realize is that I've never used just one compiler in my entire career. I like to have my code compile and run on whatever compilers are available for the platforms I use. In the case of the Propeller, this would include Catalina, ZOG, and PropGCC. I considered buying ICC as well but it seems to be a dead product. I don't just pick one because I like to write portable code and I know that people who use my code may chose different compilers for their own reasons. I *want* my code to run on Catalina. What I don't like is to have to decorate it with lots of typecasts and alternate constructs just because they are required by one compiler. Some of this is of course always necessary since C programs are usually not perfectly portable but it would be nice if something like NULL which is sprinkled over all of my code didn't have to be modified for one target compiler.

By the way, I'm not only interested in Catalina and PropGCC. I also continue to bug Heater about getting the little-endian ZOG working because I think it offers the ability to fit more code in LMM mode which may be helpful both for Propeller-1 and Propeller-2. Even the 128k of hub memory we've been told to expect on P2 is small when used with the huge code sizes generated by the LMM instruction set. The executable for xbasic on a PIC24 is only about 32k but the Catalina executable for the Propeller is almost 200k.

RossH
11-07-2011, 10:12 AM
I don't understand why you spend so much time justifying your choice of (void *)0 as the value of NULL. It may be that it is allowed by the standard but it certainly doesn't seem to be the more common definition and since 0 is also allowed by the standard why not use the value that will cause the least trouble for people who are familiar with other compilers?

David, just what is your problem here? I'm not justifying anything, nor was my post intended to rile you. Tor made a reasonable point, and I responded in kind since I thought he (and others) might possibly be interested in learning something they may not have known. If you yourself are no longer interested - even though you raised the issue in the first place - then please feel free to not respond any further.

Ross.

RossH
11-07-2011, 10:18 AM
I didn't mention GCC. I only pointed to propgcc as the Google Code repository containing the loader code. I seem to remember mentioning this earlier when I had written the loader for ZOG. If you'd like me to send you a zip file containing the sources so you don't have to look in the propgcc project that would be fine with me.

What you don't seem to realize is that I've never used just one compiler in my entire career. I like to have my code compile and run on whatever compilers are available for the platforms I use. In the case of the Propeller, this would include Catalina, ZOG, and PropGCC. I considered buying ICC as well but it seems to be a dead product. I don't just pick one because I like to write portable code and I know that people who use my code may chose different compilers for their own reasons. I *want* my code to run on Catalina. What I don't like is to have to decorate it with lots of typecasts and alternate constructs just because they are required by one compiler. Some of this is of course always necessary since C programs are usually not perfectly portable but it would be nice if something like NULL which is sprinkled over all of my code didn't have to be modified for one target compiler.

By the way, I'm not only interested in Catalina and PropGCC. I also continue to bug Heater about getting the little-endian ZOG working because I think it offers the ability to fit more code in LMM mode which may be helpful both for Propeller-1 and Propeller-2. Even the 128k of hub memory we've been told to expect on P2 is small when used with the huge code sizes generated by the LMM instruction set. The executable for xbasic on a PIC24 is only about 32k but the Catalina executable for the Propeller is almost 200k.

David, I will heed your advice and not respond to your post when I am probably overtired.

Ross.

David Betz
11-07-2011, 10:47 AM
David, just what is your problem here? I'm not justifying anything, nor was my post intended to rile you. Tor made a reasonable point, and I responded in kind since I thought he (and others) might possibly be interested in learning something they may not have known. If you yourself are no longer interested - even though you raised the issue in the first place - then please feel free to not respond any further.

Ross.
Can you explain why you won't consider changing your definition of NULL to just zero? I make this same unfortunate choice a while back when I was working on a runtime for ZOG. It seems perfectly reasonable to use a void* cast since it makes an integer into a pointer. However, as you yourself have pointed out, a pointer can point to different address spaces on some processors (Harvard architecture machines mostly) so the cast just gets in the way. Some of the articles you've pointed to mention that zero can always be used to initialize a pointer (except in obscure varargs cases) and that the compiler will arrange to translate the zero into whatever bit pattern indicates a null pointer for that particular machine. This suggests to me that NULL should be zero so it can take advantage of those rules. What is the problem with changing that one define in your library? I know what you have is allowable but why not choose the value that will cause your users the least trouble? One of the biggest advantages of C is that code can be moved from system to system with very little change if it is written in a portable fashion. My goal is to maintain that portability as much as possible and that suggests that all compilers should make similar choices on things like this if possible. Some people will only care about running code on a single platform and for them these issues are not important but they are to people who want to write portable code not tied to a particular compiler on a particular platform.

RossH
11-07-2011, 12:40 PM
Can you explain why you won't consider changing your definition of NULL to just zero? I make this same unfortunate choice a while back when I was working on a runtime for ZOG. It seems perfectly reasonable to use a void* cast since it makes an integer into a pointer. However, as you yourself have pointed out, a pointer can point to different address spaces on some processors (Harvard architecture machines mostly) so the cast just gets in the way. Some of the articles you've pointed to mention that zero can always be used to initialize a pointer (except in obscure varargs cases) and that the compiler will arrange to translate the zero into whatever bit pattern indicates a null pointer for that particular machine. This suggests to me that NULL should be zero so it can take advantage of those rules. What is the problem with changing that one define in your library? I know what you have is allowable but why not choose the value that will cause your users the least trouble? One of the biggest advantages of C is that code can be moved from system to system with very little change if it is written in a portable fashion. My goal is to maintain that portability as much as possible and that suggests that all compilers should make similar choices on things like this if possible. Some people will only care about running code on a single platform and for them these issues are not important but they are to people who want to write portable code not tied to a particular compiler on a particular platform.
David,

I'm breaking my own promise about posting when tired here - but you really are beginning to try my patience!

I don't feel a need to explain any further a design decision that is not only perfectly legitimate according to the ANSI C standard, but is also described by those who would seem to know a bit more than either of us (here (http://c-faq.com/null/safermacs.html)) to be potentially useful for diagnostic purposes since it enables the compiler to generate a warning message about C code that may not be portable between compilers. If your goal was truly to maintain maximum portability, I would think you would be all in favor of this feature.

I'm sorry that your experience leads you to conclude that 0 is the only reasonable value for NULL, but this is simply not the case - as I have tried to point out. I am also sorry that you have grown so used to being able to use NULL when you really mean the constant value 0 on the compilers you use, but these are simply not the same thing. At the risk of annoying you further, I will point out that this issue is also addressed in the reference I have given you several times now, in answer to question 5.10 (http://c-faq.com/null/macsochange.html).

Seriously David, I have tried to point out reasonably politely that perhaps your understanding of these issues may be incomplete - and I have given you references to explain each point I have tried to make. I could have chosen simply to tell you to go and read the ANSI C standard itself, but given how impenetrable the specification can be, you have quite rightly complained that this would not be appropriate.

You are perfectly entitled to ask me for the rationale behind my design decisions, and I have generally been happy to oblige - even to the point of putting up with some quite rude responses from you when you disagree with them. You are also perfectly entitled to make different design decisions on your own C compiler when you eventually get around to writing one. Since Catalina is open source, you are even perfectly entitled to take Catalina and modify it to suit your own needs if you don't like specific decisions I have made.

What you are not entitled to do is raise a continual stream of fairly insignificant issues and make each one out to be some kind of fatal flaw in the design of Catalina, and then demand that I change my compiler for no reason other than just because it would better suit your own particular C programming style. Why you would do such a thing when you have already declared your intention not to use Catalina again I will leave to others to figure out.

Ross.

David Betz
11-07-2011, 01:34 PM
I guess any attempts to change your mind on this issue or probably any issue are pointless. Sorry I bothered you.

In the future I will just add the following code to my program's header file:



#ifdef __CATALINA__
#undef NULL
#define NULL 0
#endif


I guess that's not such a big pain. I'll drop this discussion now.

David Betz
11-07-2011, 02:14 PM
You'll all be happy to learn that I've given up my crusade to get Ross to change the definition of NULL in Catalina so I've decided to solve it for my program using the following code:


#undef NULL
#define NULL 0

I tried this just now and I get an error message from the compiler complaining of a macro redefinition of NULL. Anyone have any idea why this might be happening? Is NULL a special identifier that can't be redefined?

David Betz
11-07-2011, 02:18 PM
You'll all be happy to learn that I've given up my crusade to get Ross to change the definition of NULL in Catalina so I've decided to solve it for my program using the following code:


#undef NULL
#define NULL 0

I tried this just now and I get an error message from the compiler complaining of a macro redefinition of NULL. Anyone have any idea why this might be happening? Is NULL a special identifier that can't be redefined?
Never mind. I guess many of the standard include files define NULL as (void *)0 so just adding my one redefinition of it is never going to work unless I can guarantee in all cases that my include file is included last. Sorry! This was foggy thinking on my part and won't work unless all redefinitions of NULL in the standard header files are protected by #ifndef NULL.

RossH
11-07-2011, 10:12 PM
Never mind. I guess many of the standard include files define NULL as (void *)0 so just adding my one redefinition of it is never going to work unless I can guarantee in all cases that my include file is included last. Sorry! This was foggy thinking on my part and won't work unless all redefinitions of NULL in the standard header files are protected by #ifndef NULL.

Hi David,

The most (in fact the only) truly portable solution is to not use NULL when you really mean 0. The constant value 0 is a valid initializer for all pointers, including function pointers. It is a common misconception to assume that NULL is defined as a macro to mean 0, but this is compiler dependent.

However, in a spirit of goodwill, I will look at changing Catalina. I can't promise anything though, since it was not actually my decision in the first place - NULL was defined this way in the original Amsterdam Compiler Kit by Andrew Tanenbaum and Cereil Jacobs (for Minix I believe). Changing it may have other undesirable consequences.

Ross.

Rayman
11-08-2011, 12:33 AM
It's an interesting point... I would have thought that NULL==0, but I have never really used it in a way that it matters...
I think that in c++, null always is 0, right? I wonder how it is in other C compilers, like Imagecraft and the PIC compiler...

David Betz
11-08-2011, 03:00 AM
Hi David,

The most (in fact the only) truly portable solution is to not use NULL when you really mean 0. The constant value 0 is a valid initializer for all pointers, including function pointers. It is a common misconception to assume that NULL is defined as a macro to mean 0, but this is compiler dependent.

However, in a spirit of goodwill, I will look at changing Catalina. I can't promise anything though, since it was not actually my decision in the first place - NULL was defined this way in the original Amsterdam Compiler Kit by Andrew Tanenbaum and Cereil Jacobs (for Minix I believe). Changing it may have other undesirable consequences.

Ross.
If it's part of a standard library that you're using I think it would probably be a bad idea to change it without discussing it with the original authors. I'll work around this rather minor problem. Sorry this got blown out of proportion!

RossH
11-08-2011, 03:41 AM
It's an interesting point... I would have thought that NULL==0, but I have never really used it in a way that it matters...
I think that in c++, null always is 0, right? I wonder how it is in other C compilers, like Imagecraft and the PIC compiler...

Yes it is interesting. While null is always equated to some form of zero, there are in fact many alternatives. Here are just a few:

0
0L
(void *)0
(const *)0


All of these will have different behaviour, and none of them mean the value of a pointer assigned this value will actually have the binary value of zero. And yet the C standard does specify that you must be able to compare such a pointer with zero, and it must return the result as if it was zero. There are a few other rules that mean people naturally assume a null pointer has the binary value equivalent to the integer value 0 - but the two may not even be the same size in bits, let alone have the same value!

Ross.

Heater.
11-08-2011, 04:05 AM
Is it me or is this nuts?
A pointer may not be the size of an int or any other numeric type. E.g. 8086 FAR pointers were 20 bits when ints were 16 bits.
A NULL, basically invalid pointer, may not have all bits equal zero. Many machines in the past had special values for it.
The compiler tries to be clever with the result that writing:
int * p;
p = 0;
may result in p having a binary representation that is not all bits zero!!
Or conversley writing:
int z = 0;
p = (int *)z;
may result in a pointer that is not a null pointer on some machine. I.e. it has the bits all zero when it should not.
So, if I happen to have some data that actually lives at address zero and my machine uses all bits zero to indicate NULL I have a bit of a problem.
Just seems that having the compiler automatically convert that "0" in my pointer assignment to a non zero value is very weird. No wonder null pointers get debated a lot.

RossH
11-08-2011, 04:21 AM
Is it me or is this nuts?
A pointer may not be the size of an int or any other numeric type. E.g. 8086 FAR pointers were 20 bits when ints were 16 bits.
A NULL, basically invalid pointer, may not have all bits equal zero. Many machines in the past had special values for it.
The compiler tries to be clever with the result that writing:
int * p;
p = 0;
may result in p having a binary representation that is not all bits zero!!
Or conversley writing:
int z = 0;
p = (int *)z;
may result in a pointer that is not a null pointer on some machine. I.e. it has the bits all zero when it should not.
So, if I happen to have some data that actually lives at address zero and my machine uses all bits zero to indicate NULL I have a bit of a problem.
Just seems that having the compiler automatically convert that "0" in my pointer assignment to a non zero value is very weird. No wonder null pointers get debated a lot.

I guess a lot of it comes from the weird architectures that C has been ported to. One machine had to have a special instruction added to compare C pointers with null values, and in another machine (a lisp machine) the null pointer is not an integral value at all!

Ross.

RossH
11-09-2011, 09:08 AM
Even the 128k of hub memory we've been told to expect on P2 is small when used with the huge code sizes generated by the LMM instruction set. The executable for xbasic on a PIC24 is only about 32k but the Catalina executable for the Propeller is almost 200k.

Hi David,

Sorry - in our heated discussion over nothing last night :) I missed this point.

As we have since discussed elsewhere, the 200k you are seeing is the binary file size, not the C program size. When compiling with Catalina on the C3 you need to subtract around 128k.

I just compiled your xbasic program with Catalina 3.5 and the code size is about 55k with data size about 16k. I expect to get that down futher, but I doubt it will ever fit in the 32k Hub RAM available on the Prop 1. However, it will easily fit on the Prop 2!

I also tried compiling xbasic with GCC but here the boot is on the other foot - I don't understand how to interpret the sizes it reports. The xbasic.elf file is 124k but obviously that is way too big to just be the C program. Presumably you need to subtract something as I have to do with Catalina?. But then when I try loading it, it says it is loading over 180k. So presumably your loader also adds stuff (drivers, libraries etc) that are not in the xbasic.elf file? Is there an easy way to figure out the actual C program size?

At least Catalina reports the actual C program segment sizes for each compile!

Ross.

David Betz
11-09-2011, 10:42 AM
Hi David,

Sorry - in our heated discussion over nothing last night :) I missed this point.

As we have since discussed elsewhere, the 200k you are seeing is the binary file size, not the C program size. When compiling with Catalina on the C3 you need to subtract around 128k.

I just compiled your xbasic program with Catalina 3.5 and the code size is about 55k with data size about 16k. I expect to get that down futher, but I doubt it will ever fit in the 32k Hub RAM available on the Prop 1. However, it will easily fit on the Prop 2!

Okay, I now understand some of the reason that the Catalina executable file is so big. It contains a second stage loader and some drivers as well as the program itself. You've pointed me to a section of your documentation describing the binary file format. I'll try to look at that more closely in the next day or so to determine how to make propeller-load able to handle Catalina binaries in addition to what it currently handles.


I also tried compiling xbasic with GCC but here the boot is on the other foot - I don't understand how to interpret the sizes it reports. The xbasic.elf file is 124k but obviously that is way too big to just be the C program. Presumably you need to subtract something as I have to do with Catalina?. But then when I try loading it, it says it is loading over 180k. So presumably your loader also adds stuff (drivers, libraries etc) that are not in the xbasic.elf file? Is there an easy way to figure out the actual C program size?

At least Catalina reports the actual C program segment sizes for each compile!

Ross.
You can get the sizes of the various sections of an ELF file using the objdump utility although you have to know how to interpret the results.

This gives a list of all of the sections in the ELF file:


propeller-elf-objdump -h xbasic.elf


This is a little verbose and contains only sections that contribute to the program size. The ELF file contains lots of other stuff including a symbol table and debugging information.


propeller-elf-objdump -p xbasic.elf


Also, I have to admit that the sizes reported by propeller-load were nearly double the correct sizes because of a bug. I've fixed the bug and have checked in the fix. It should appear in the next release. I won't go into this any more because it is off topic for this thread but you're certainly welcome to file a bug report for any problems like this that you see.

RossH
11-09-2011, 11:11 AM
This gives a list of all of the sections in the ELF file:


propeller-elf-objdump -h xbasic.elf



Ok - thanks! Here is what I get for xbasic.elf (note that I used 'elf-strip' to remove all the debug stuff):


Sections:
Idx Name Size VMA LMA File off Algn
0 .xmmkernel 0000065c 00000000 e0000000 00015870 2**2
CONTENTS, ALLOC, LOAD, CODE
1 .header 0000000c 30000000 30000000 000000b8 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .init 000000ac 3000000c 3000000c 000000c4 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .text 00014298 300000b8 300000b8 00000170 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .fini 00000038 30014350 30014350 00014408 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .hub 00001420 00000000 30014388 00014440 2**2
CONTENTS, ALLOC, LOAD, CODE
6 .ctors 00000008 00001420 300157a8 00015860 2**2
CONTENTS, ALLOC, LOAD, CODE
7 .dtors 00000008 00001428 300157b0 00015868 2**2
CONTENTS, ALLOC, LOAD, CODE
8 .bss 00003238 00001430 300157b8 00015870 2**2
ALLOC
9 .heap 00000004 00004668 00004668 000000b4 2**0
CONTENTS, ALLOC, LOAD, DATA


(Yikes! And some people say Catalina is complex! :smile:)

According to my GCC documentation, the .text segment contains both the code and the read-only data. For this program the read-only data is quite small (2.5k according to Catalina, but this may vary slightly between compilers). That means the code is 80k - or Is there something else in the .text segment as well?

Ross.

David Betz
11-09-2011, 11:22 AM
Ok - thanks! Here is what I get for xbasic.elf (note that I used 'elf-strip' to remove all the debug stuff):


Sections:
Idx Name Size VMA LMA File off Algn
0 .xmmkernel 0000065c 00000000 e0000000 00015870 2**2
CONTENTS, ALLOC, LOAD, CODE
1 .header 0000000c 30000000 30000000 000000b8 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .init 000000ac 3000000c 3000000c 000000c4 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .text 00014298 300000b8 300000b8 00000170 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .fini 00000038 30014350 30014350 00014408 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .hub 00001420 00000000 30014388 00014440 2**2
CONTENTS, ALLOC, LOAD, CODE
6 .ctors 00000008 00001420 300157a8 00015860 2**2
CONTENTS, ALLOC, LOAD, CODE
7 .dtors 00000008 00001428 300157b0 00015868 2**2
CONTENTS, ALLOC, LOAD, CODE
8 .bss 00003238 00001430 300157b8 00015870 2**2
ALLOC
9 .heap 00000004 00004668 00004668 000000b4 2**0
CONTENTS, ALLOC, LOAD, DATA


(Yikes! And some people say Catalina is complex! :smile:)

According to my GCC documentation, the .text segment contains both the code and the read-only data. For this program the read-only data is quite small (2.5k according to Catalina, but this may vary slightly between compilers). That means the code is 80k - or Is there something else in the .text segment as well?

Ross.
My guess is that you didn't use any optimization when you compiled this. GCC does a remarkably bad job of generating efficient code when no optimization is done. This is partially to allow easier debugging. We always use at least -Os when compiling GCC programs. This optimizes for size. The section header output when compiled in that mode looks like this:


Sections:
Idx Name Size VMA LMA File off Algn
0 .xmmkernel 0000065c 00000000 e0000000 0000c274 2**2
CONTENTS, ALLOC, LOAD, CODE
1 .header 0000000c 30000000 30000000 000000f8 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .init 000000ac 3000000c 3000000c 00000104 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .text 0000a41c 300000b8 300000b8 000001b0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .fini 00000038 3000a4d4 3000a4d4 0000a5cc 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .hub 00001ac0 00000000 3000a50c 0000a604 2**2
CONTENTS, ALLOC, LOAD, CODE
6 .ctors 00000008 00001ac0 3000bfcc 0000c0c4 2**2
CONTENTS, ALLOC, LOAD, CODE
7 .dtors 00000008 00001ac8 3000bfd4 0000c0cc 2**2
CONTENTS, ALLOC, LOAD, CODE
8 .bss 00003240 00001ad0 3000bfdc 0000c274 2**2
ALLOC
9 .cogsys0 000001a0 00000000 3000bfdc 0000c0d4 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .heap 00000004 00004d10 00004d10 000000f4 2**0
CONTENTS, ALLOC, LOAD, DATA

By the way, I think .cogsys0 got added to this because the full duplex serial driver was compiled in rather than the simpler no-COG serial driver that is used by default.

David Betz
11-09-2011, 11:22 AM
Ok - thanks! Here is what I get for xbasic.elf (note that I used 'elf-strip' to remove all the debug stuff):


Sections:
Idx Name Size VMA LMA File off Algn
0 .xmmkernel 0000065c 00000000 e0000000 00015870 2**2
CONTENTS, ALLOC, LOAD, CODE
1 .header 0000000c 30000000 30000000 000000b8 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .init 000000ac 3000000c 3000000c 000000c4 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .text 00014298 300000b8 300000b8 00000170 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .fini 00000038 30014350 30014350 00014408 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .hub 00001420 00000000 30014388 00014440 2**2
CONTENTS, ALLOC, LOAD, CODE
6 .ctors 00000008 00001420 300157a8 00015860 2**2
CONTENTS, ALLOC, LOAD, CODE
7 .dtors 00000008 00001428 300157b0 00015868 2**2
CONTENTS, ALLOC, LOAD, CODE
8 .bss 00003238 00001430 300157b8 00015870 2**2
ALLOC
9 .heap 00000004 00004668 00004668 000000b4 2**0
CONTENTS, ALLOC, LOAD, DATA


(Yikes! And some people say Catalina is complex! :smile:)

According to my GCC documentation, the .text segment contains both the code and the read-only data. For this program the read-only data is quite small (2.5k according to Catalina, but this may vary slightly between compilers). That means the code is 80k - or Is there something else in the .text segment as well?

Ross.
My guess is that you didn't use any optimization when you compiled this. GCC does a remarkably bad job of generating efficient code when no optimization is done. This is partially to allow easier debugging. We always use at least -Os when compiling GCC programs. This optimizes for size. The section header output when compiled in that mode looks like this:


Sections:
Idx Name Size VMA LMA File off Algn
0 .xmmkernel 0000065c 00000000 e0000000 0000c274 2**2
CONTENTS, ALLOC, LOAD, CODE
1 .header 0000000c 30000000 30000000 000000f8 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .init 000000ac 3000000c 3000000c 00000104 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .text 0000a41c 300000b8 300000b8 000001b0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .fini 00000038 3000a4d4 3000a4d4 0000a5cc 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .hub 00001ac0 00000000 3000a50c 0000a604 2**2
CONTENTS, ALLOC, LOAD, CODE
6 .ctors 00000008 00001ac0 3000bfcc 0000c0c4 2**2
CONTENTS, ALLOC, LOAD, CODE
7 .dtors 00000008 00001ac8 3000bfd4 0000c0cc 2**2
CONTENTS, ALLOC, LOAD, CODE
8 .bss 00003240 00001ad0 3000bfdc 0000c274 2**2
ALLOC
9 .cogsys0 000001a0 00000000 3000bfdc 0000c0d4 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .heap 00000004 00004d10 00004d10 000000f4 2**0
CONTENTS, ALLOC, LOAD, DATA

By the way, I think .cogsys0 got added to this because the full duplex serial driver was compiled in rather than the simpler no-COG serial driver that is used by default.

jazzed
11-09-2011, 12:36 PM
Hi David,

Sorry - in our heated discussion over nothing last night :) I missed this point.

As we have since discussed elsewhere, the 200k you are seeing is the binary file size, not the C program size. When compiling with Catalina on the C3 you need to subtract around 128k.

I just compiled your xbasic program with Catalina 3.5 and the code size is about 55k with data size about 16k. I expect to get that down futher, but I doubt it will ever fit in the 32k Hub RAM available on the Prop 1. However, it will easily fit on the Prop 2!

I also tried compiling xbasic with GCC but here the boot is on the other foot - I don't understand how to interpret the sizes it reports. The xbasic.elf file is 124k but obviously that is way too big to just be the C program. Presumably you need to subtract something as I have to do with Catalina?. But then when I try loading it, it says it is loading over 180k. So presumably your loader also adds stuff (drivers, libraries etc) that are not in the xbasic.elf file? Is there an easy way to figure out the actual C program size?

At least Catalina reports the actual C program segment sizes for each compile!

Ross.

All we have to do is use the strip program to find the size of the image.

The loader bug reported in the Alpha thread had me confused on this a while and I could not confirm it even in a PM.
The loader is fixed now, but not distributed yet.

After using David's propgcc/demos/xbasic make:


$ ls -l xbasic.elf
-rwxr-xr-x 1 steve sudo 85842 Nov 9 04:58 xbasic.elf
propeller-elf-strip xbasic.elf
$ ls -l xbasic.elf
-rwxr-xr-x 1 steve sudo 52016 Nov 9 05:00 xbasic.elf

It is odd that you get 124K. Maybe you removed the optimization?



$ propeller-load -t -r xbasic.elf -b eeprom
Propeller Version 1 on /dev/ttyUSB0
Writing 4552 bytes to Propeller RAM.
Verifying ... Upload OK!
Loading cache driver
1500 bytes sent
Loading program image
49804 bytes sent
Loading .xmmkernel
1628 bytes sent
[ Entering terminal mode. Type ESC or Control-C to exit. ]
xBasic 0.001


The loader reveals the code size. The approximate load time: 16 seconds.

Not bad for the Titanic :)

RossH
11-09-2011, 09:16 PM
Not bad for the Titanic :)

You appear to have missed the moral of the Titanic - the design flaws that made its sinking almost inevitable became obvious only in hindsight. Prior to that, everyone was sucked in by the hype. :smile:

I thought about "strip" (and even used it) but even this doesn't give you the correct result - you still have to know to run objdump and then get out the hex calculator - and even then it seems you can't figure out the real code size. I am not an elf expert - s this simply not possible because of the way the elf object format works?

I do think you will need make it a bit easier to figure out the various segment sizes - GCC code sizes seem to be quite large, so you are going to need a way to figure out how much you need to prune the code to get your programs to fit. I understand this is an alpha release, but so far all I get is compiler crashes or load failures once the code size exceeds some maximum permissible size.

I guess I will wait till you release the fixed loader and then try again.

Ross.

jazzed
11-09-2011, 09:33 PM
I understand this is an alpha release, but so far all I get is compiler crashes or load failures once the code size exceeds some maximum permissible size.
Hi Ross,

If you post compiler crash information somewhere it would be helpful, assuming you want to be helpful. Just saying you get them is not helpful.

I've never seen a GCC compiler crash except once back in 1998. I've seen error messages that explain problems. We are producing GCC C/C++. If Parallax wants more than that, they will tell me.

I'm waiting on some information before posting another test package - it could be a few days. Meanwhile, you could follow instructions on the loader (http://forums.parallax.com/showthread.php?135710-Loader-Bug-Fixed&p=1050151&viewfull=1#post1050151) like Martin did if you're really curious.

Thanks,
--Steve

RossH
11-09-2011, 09:56 PM
Hi Ross,

If you post compiler crash information somewhere it would be helpful, assuming you want to be helpful. Just saying you get them is not helpful.
If I find something that has not already been posted, I will let you know. So far I have not seen anything that is not already well known. Perhaps my use of the term "crash" was too loose - I just mean when the compiler fails to compile because of some internal error. In all cases I have seen, it does indeed spit out an error message (usually something about the bss segment). I am not trying really to troubleshoot either the compiler or the loader - just understand it's output.

I've never seen a GCC compiler crash except once back in 1998. I've seen error messages that explain problems. We are producing GCC C/C++. If Parallax wants more than that, they will tell me.
Ok, I get it - like Rolls Royces don't breakdown, they just "fail to proceed". And Macs don't crash - they just "bomb". Got it now.

I'm waiting on some information before posting another test package - it could be a few days. Meanwhile, you could follow instructions on the loader (http://forums.parallax.com/showthread.php?135710-Loader-Bug-Fixed&p=1050151&viewfull=1#post1050151) like Martin did if you're really curious.


I don't see the relevance of that link. Can you elucidate?

Ross.

jazzed
11-09-2011, 10:11 PM
I don't see the relevance of that link. Can you elucidate?

It's regarding building a loader image. I'm a little tired here so I guess I assumed a bit much. Sorry about that.
Martin has a clone of the repository, so all he has to do is pull/update changes and I was able to work him through some things.

I could zip you a package here with a pre-built loader if you like. I have some things to do outside though so I might be delayed.

Thanks,
--Steve

David Betz
11-09-2011, 10:16 PM
I thought about "strip" (and even used it) but even this doesn't give you the correct result - you still have to know to run objdump and then get out the hex calculator - and even then it seems you can't figure out the real code size. I am not an elf expert - s this simply not possible because of the way the elf object format works?
I don't understand why you can't just add up the section sizes? That will give you exactly the number of bytes that the image takes in memory. The loader will report a slightly larger number because it has to add a header onto the image before downloading it. This is assuming, of course, that you use a version of the loader that doesn't have the recently reported size reporting bug. I don't see why you would hold the existence of a bug against the entire tool chain especially when the bug was fixed minutes after it was reported. This toolchain is only a few months old at this point and is only in an alpha release state.

However, you are correct that not everyone (including me) will be able to decipher every detail of an elf file dump. We should probably add a brief description of how the various file sections are used by the compiler and linker. Of course, that isn't fixed. A user is perfectly free to add sections of their own and direct the linker to place in them whatever they want. We should describe the standard sections though. In fact, it is very likely that there is already a description of things like .text, .data, and .bss in some of the many hundreds of pages of GCC documentation that already exist as part of the GCC project.

RossH
11-10-2011, 12:10 AM
I don't understand why you can't just add up the section sizes? That will give you exactly the number of bytes that the image takes in memory. The loader will report a slightly larger number because it has to add a header onto the image before downloading it. This is assuming, of course, that you use a version of the loader that doesn't have the recently reported size reporting bug. I don't see why you would hold the existence of a bug against the entire tool chain especially when the bug was fixed minutes after it was reported. This toolchain is only a few months old at this point and is only in an alpha release state.

Just add the section sizes? How will that tell you anything if you need to figure out whether you need to prune code or data to make your program fit? I guess many people don't realize just how constraining 32k actually is for LMM programs - a random C program downloaded from the internet could easily use that much space just in error messages! But sometimes I can make a program fit in Hub RAM on the Prop just by cutting down the size of some of the strings - much easier than attempting to rewrite parts of the code. I accept your point about the toolchain being a bit immature yet - but Propeller LMM C users will face this problem almost immediately (note this is just as true of Catalina as GCC - but at least Catalina makes it easy to see where your Hub RAM has gone!).

However, you are correct that not everyone (including me) will be able to decipher every detail of an elf file dump. We should probably add a brief description of how the various file sections are used by the compiler and linker. Of course, that isn't fixed. A user is perfectly free to add sections of their own and direct the linker to place in them whatever they want. We should describe the standard sections though. In fact, it is very likely that there is already a description of things like .text, .data, and .bss in some of the many hundreds of pages of GCC documentation that already exist as part of the GCC project.
So PropGCC is currently only intended mainly for power users well versed in the innards of GCC?

Ross.

RossH
11-10-2011, 12:14 AM
It's regarding building a loader image. I'm a little tired here so I guess I assumed a bit much. Sorry about that.
Martin has a clone of the repository, so all he has to do is pull/update changes and I was able to work him through some things.

I could zip you a package here with a pre-built loader if you like. I have some things to do outside though so I might be delayed.

Thanks,
--Steve

Hi Steve,

Thanks for the offer, but don't bother - I'm ok to wait till the fixed version of the loader is released officially. This is all really at a tangent to the original discussion, which was why David thought Catalina binaries were 200k - and I think we've resolved that. The only reason I looked at GCC as part of this was I assumed that was what he was comparing the size against (which I think was true) - and it turns out they are very similar sizes under both compilers anyway.

Ross.

David Betz
11-10-2011, 12:26 AM
Hi Steve,

Thanks for the offer, but don't bother - I'm ok to wait till the fixed version of the loader is released officially. This is all really at a tangent to the original discussion, which was why David thought Catalina binaries were 200k - and I think we've resolved that. The only reason I looked at GCC as part of this was I assumed that was what he was comparing the size against (which I think was true) - and it turns out they are very similar sizes under both compilers anyway.

Ross.
I actually compared Catalina's size to a PIC24. You are the one who brought up PropGCC. The only reason I even looked at the size was to try to understand why the load was taking so long. I wanted to make my loader able to handle Catalina binaries and it occurred to me that there might not be that much difference between the speeds of propeller-load and payload if payload was loading a much larger file. I was making no value judgements about your compiler. I was just trying to figure out if I could help improve its load speed. I'll admit that this was mostly for selfish reasons because I like to do serial downloads rather than swapping SD cards when I port code to Catalina.

Rayman
11-10-2011, 12:55 AM
Ross,

Just thinking about possible future stuff...

Does Code:Blocks support breakpoints? I don't see any way to set breakpoints in the editor...

I remember you said small and large debugging isn't ready yet. Could you just turn off caching to allow debugging and just let it run super slow?

RossH
11-10-2011, 03:23 AM
I actually compared Catalina's size to a PIC24. You are the one who brought up PropGCC. The only reason I even looked at the size was to try to understand why the load was taking so long. I wanted to make my loader able to handle Catalina binaries and it occurred to me that there might not be that much difference between the speeds of propeller-load and payload if payload was loading a much larger file. I was making no value judgements about your compiler. I was just trying to figure out if I could help improve its load speed. I'll admit that this was mostly for selfish reasons because I like to do serial downloads rather than swapping SD cards when I port code to Catalina.

I didn't think a comparison of code size to a PIC24 was meaningful comparison for LMM Propeller code sizes, so I used the only available alternative to try and get a more reasonable one - just to try and emphasize the point that Catalina's code sizes were not excessive (if anything, they are just the opposite!)

Ross.

RossH
11-10-2011, 03:31 AM
Ross,

Just thinking about possible future stuff...

Does Code:Blocks support breakpoints? I don't see any way to set breakpoints in the editor...

I remember you said small and large debugging isn't ready yet. Could you just turn off caching to allow debugging and just let it run super slow?

Code::Blocks does not support Catalina breakpoints - you need to use the BlackBox or BlackCat debuggers, which are stand-alone programs.

My solution for debugging programs stored in Flash is to actually use the cache to store the breakpoints - i.e. to simulate the debugger writing to what would normally be read-only Flash memory, by instead caching the writes but not writing the dirty pages back to XMM RAM.

The main thing I am not happy about is that I can only store a small number breakpoints that way - I need to make the cache more efficient in the way it stores each breakpoint - it can't simply leave all the pages with breakpoints hanging around in Hub RAM (as it does now) - this simply runs out of space too quickly!

Ross.

David Betz
11-10-2011, 10:51 AM
I didn't think a comparison of code size to a PIC24 was meaningful comparison for LMM Propeller code sizes, so I used the only available alternative to try and get a more reasonable one - just to try and emphasize the point that Catalina's code sizes were not excessive (if anything, they are just the opposite!)

Ross.
As I think I've said, I wasn't criticising the quality of Catalina code generation. I was trying to understand loader speeds.

Rayman
11-10-2011, 07:23 PM
Ross, another basic question for you...

I'm looking at some C code for the Vinculum II right now... I'm a little surprised to see that they never use a semicolon after braces {};
Is this not required in regular C?
I think it is required in all C++, right?
Just curious...

David Betz
11-10-2011, 07:28 PM
Ross, another basic question for you...

I'm looking at some C code for the Vinculum II right now... I'm a little surprised to see that they never use a semicolon after braces {};
Is this not required in regular C?
I think it is required in all C++, right?
Just curious...
It is never required in C or C++ as far as I know. The semicolon after a closing brace will be parsed as an empty statement and could cause syntax errors in the case of something like this:


if (a == b)
{ printf("a equals b\n"); };
else
{ printf("a does not equal b"\n"); };

David Betz
11-10-2011, 07:30 PM
Well, a semicolon after a closing brace is *sometimes* necessary in variable declarations with initializers:


int my_array[] = { 1, 2, 3 };

It is also used in other declarations but not in executable statements.

Rayman
11-10-2011, 08:43 PM
Interesting... Goes to show you how much I know... I did just try leaving off some semicolons in Visual Studio C++ and it doesn't complain...

Still, it just looks wrong to me to leave them off...

David Betz
11-10-2011, 08:45 PM
Interesting... Goes to show you how much I know... I did just try leaving off some semicolons in Visual Studio C++ and it doesn't complain...

Still, it just looks wrong to me to leave them off...
Try compiling the example from my previous message with Visual Studio C++. I bet you'll get an error.

RossH
11-10-2011, 10:04 PM
Rayman, David ...

In C braces are used to delimit both block structures and type structures (including type initializers). The semicolon in C is a statement terminator, so it is required after each statement, even if that statement ends in a type structure or a type initializer - such as a declaration. It is not required after a block structure - there it would represent an empty statement, so it looks like it is "optional" whereas in fact it should not be there at all.

However, I think C# (and possibly some C/C++ implementations) make the semicolon optional in places where it would be mandatory in "pure" C.

Ross.

RossH
11-11-2011, 09:52 AM
All,

Catalina 3.5 is not ready for release yet, but attached is a preview of the new payload loader that will be included (Windows only executable at this stage).

EDIT : attachment has been removed - you will find an updated version in the second post in this thread (http://forums.parallax.com/showthread.php?135424-Catalina-3.4&p=1046615&viewfull=1#post1046615)

This new version of payload is significantly faster - it downloads Catalina LMM as well as normal Spin binaries in the same time as the Parallax Propeller Tool (to within a second on my machine). It is also faster downloading Catalina XMM programs.

Just unzip the attached file into your Catalina\bin directory.

One of the things that slows the download process is leaving it to payload to locate the correct port to use each time (it does this by trying them all in turn). For faster speeds, explicitly specify the ports to use (if you don't know the ports, just use payload - once - without specifying any ports, and it will tell you!).

For example, for a Catalina LMM or Spin binary, specify the port to use for the download via -p:


payload -p2 hello_world
or, for an XMM program, specify both the primary and secondary ports to use (on most platforms they are the same) via -p and -s:

payload -p2 -s2 XMM startrek

If anyone has any problems with this version, please let me know!

Ross.

David Betz
11-11-2011, 11:57 AM
All,

Catalina 3.5 is not ready for release yet, but attached is a preview of the new payload loader that will be included (Windows only executable at this stage).

This new version of payload is significantly faster - it downloads Catalina LMM as well as normal Spin binaries in the same time as the Parallax Propeller Tool (to within a second on my machine). It is also faster downloading Catalina XMM programs.

Just unzip the attached file into your Catalina\bin directory.

One of the things that slows the download process is leaving it to payload to locate the correct port to use each time (it does this by trying them all in turn). For faster speeds, explicitly specify the ports to use (if you don't know the ports, just use payload - once - without specifying any ports, and it will tell you!).

For example, for a Catalina LMM or Spin binary, specify the port to use for the download via -p:


payload -p2 hello_world
or, for an XMM program, specify both the primary and secondary ports to use (on most platforms they are the same) via -p and -s:

payload -p2 -s2 XMM startrek

If anyone has any problems with this version, please let me know!

Ross.
Good work Ross! I guess there is no need for me to add Catalina support to propeller-load anymore!

RossH
11-11-2011, 08:09 PM
Good work Ross! I guess there is no need for me to add Catalina support to propeller-load anymore!

Hi David,

I appreciate the work you've done. At this point I'm not sure whether to ask that you continue or not - but I guess it would make sense for you to at least put it on hold for a bit. This version mostly improves the propeller detection/connection time, and so should significantly improve the load time for Spin and LMM programs up to 32k. But a download of an XMM program of a meagabyte or more will still take minutes rather than seconds. That's where your loader may improve things.

I hope people will report whether this version is faster, since I have only so far tested it on one machine - and the download times do seem to be at least partly machine-dependent.

Ross.

RossH
11-12-2011, 06:29 AM
All,

Found a bug when compiling XMM programs that use the EEPROM loader. The fix is in the second post in this thread (http://forums.parallax.com/showthread.php?135424-Catalina-3.4&p=1046615&viewfull=1#post1046615).

Ross.

pinedust
11-14-2011, 11:43 PM
I am relatively new with the propeller, but not C programming. After a few months of spin, I have decided I want to give Catalina 3.4 and Codeblocks a shot.
This may be more of a codeblocks issue, but I will ask anyway. Everything works fine on my XP laptop, but I am almost exclusively a linux user. I have tried twice on two different boxes, Ubuntu 9.1 and 10.4, both with the same result. I can create a project but I cannot select the build target from the dropdown box, nor can I select it via the build menu... both are empty. What am I overlooking? I am sure it is something, I am pretty good at doing that.
Although I haven't tried it, I have no problem with a CLI, so if that is what I have to do no biggie.

Thanks, Dusty

RossH
11-15-2011, 12:57 AM
I am relatively new with the propeller, but not C programming. After a few months of spin, I have decided I want to give Catalina 3.4 and Codeblocks a shot.
This may be more of a codeblocks issue, but I will ask anyway. Everything works fine on my XP laptop, but I am almost exclusively a linux user. I have tried twice on two different boxes, Ubuntu 9.1 and 10.4, both with the same result. I can create a project but I cannot select the build target from the dropdown box, nor can I select it via the build menu... both are empty. What am I overlooking? I am sure it is something, I am pretty good at doing that.
Although I haven't tried it, I have no problem with a CLI, so if that is what I have to do no biggie.

Thanks, Dusty

Hi Dusty,

The Code::Blocks installation on Linux is a bit more manual than on Windows, but it works ok. I have not tried it on Ubuntu recently, but I have done so in the past. I think I still have a virtual for Ubuntu (not sure which version), so I will try it when I get home.

I'm not exactly sure from your description what you mean by "empty". In the "build target" dropdown, you should see "Release" and/Or "Debug" (depending on what configurations you selected in the project wizard. You should see the same thing on the "Build->Select Target" menu. Do you see nothing at all?

Can you provide a screenshot?

Also, on Linux you probably also have GCC installed - can you create a normal GCC project successfully in Code::Blocks?

EDIT: Could you also let me know what version of Code::Blocks you are using?

Thanks,

Ross.

P.S. to use the Catalina from the command line, just open a bash shell and type:


source /usr/local/lib/catalina/use_catalina

pinedust
11-15-2011, 02:36 AM
Hi Dusty,

The Code::Blocks installation on Linux is a bit more manual than on Windows, but it works ok. I have not tried it on Ubuntu recently, but I have done so in the past. I think I still have a virtual for Ubuntu (not sure which version), so I will try it when I get home.

I'm not exactly sure from your description what you mean by "empty". In the "build target" dropdown, you should see "Release" and/Or "Debug" (depending on what configurations you selected in the project wizard. You should see the same thing on the "Build->Select Target" menu. Do you see nothing at all?

Can you provide a screenshot?

Also, on Linux you probably also have GCC installed - can you create a normal GCC project successfully in Code::Blocks?

EDIT: Could you also let me know what version of Code::Blocks you are using?

Thanks,

Ross.

P.S. to use the Catalina from the command line, just open a bash shell and type:


source /usr/local/lib/catalina/use_catalina
Yes, the install process is a little more hands on than with windows, but I've been through worse. I started off in the 90s compiling redhat 4.2 and enlightenment for a window manager, but that is a whole different topic.:nerd:
Both the dropdown and menu options are there, but the controls are empty, hopefully the screenshots help explain what I meant.
I verified both release and debug targets were selected when creating the project.
Yes, I was able to create a gcc project, but am unable to compile it due to the same problem, unable to select a target.
I may try to build codeblocks from sources, I just need to install the development files, I was hoping not to do that, though. It makes for an easier sell to PHBs. :smile:
Thanks for your time, Ross.
8686386864

RossH
11-15-2011, 03:04 AM
Yes, I was able to create a gcc project, but am unable to compile it due to the same problem, unable to select a target.
Now, that's very odd - does this happen with a "clean" install of Code::Blocks 10.05? - i.e. before you install the Catalina replacement compiler plugin?

Ross.

RossH
11-15-2011, 08:47 AM
... I have tried twice on two different boxes, Ubuntu 9.1 and 10.4, both with the same result. I can create a project but I cannot select the build target from the dropdown box, nor can I select it via the build menu... both are empty. What am I overlooking?

Hi Dusty,

I didn't have either of these versions of Ubuntu, so I am downloading a clean install of Ubuntu 10.4.

While I was waiting I just did a full install of Code::Blocks 10.05 and Catalina 3.5 under Fedora FC12 (32 bit), and everything worked as expected.

Some questions you may be able to answer:

Are you using 32 bit or 64 bit Ubuntu?
Can you tell me what version of wx you have installed? You can find out by executing wx-config --version
On the images you posted, the "Build target" dropdown list has a funny horizontal bar across half of it - is that what you actually see?

Thanks,

Ross.

pinedust
11-15-2011, 01:31 PM
I am using Codeblocks 10.05, Catalina 3.4, 64 bit Ubuntu, and wx-config --version returns 2.8.12.
Yes, that funny little horizontal bar is all I see.
...
Rather than fight it, I just went ahead and rebuilt Codeblocks from sources and now everything looked as if it is working.
...
Well, that was until I uninstalled the default compiler plugin and installed the 64bit libcompiler-0.99.cbplugin plugin, now it is back to the original problem.

Dusty

RossH
11-15-2011, 06:53 PM
I am using Codeblocks 10.05, Catalina 3.4, 64 bit Ubuntu, and wx-config --version returns 2.8.12.
Yes, that funny little horizontal bar is all I see.
...
Rather than fight it, I just went ahead and rebuilt Codeblocks from sources and now everything looked as if it is working.
...
Well, that was until I uninstalled the default compiler plugin and installed the 64bit libcompiler-0.99.cbplugin plugin, now it is back to the original problem.

Dusty

Hi Dusty,

I didn't manage to get Ubuntu installed yet, but I think it is the version of wx that is the problem. My compiler plugin was built with 2.8.11.

I will post the source of the compiler plugin tonight and you can rebuild that as well. That should fix it.

Ross.

Dr_Acula
11-16-2011, 02:09 AM
Hi Ross,

I'm experimenting with various displays at the moment and am hoping to get this one working http://www.ebay.com.au/itm/170709358010?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 which uses an ILI9325. Scroll down that product description for the pinout which is a standard 40 pin header.

Rayman has done some drivers in Spin and I believe there are other drivers out there as well.

I'm hoping this can be done in C, and I'm encouraged to find that a search for some C code turns up some code that ought to be portable to Catalina. I'm not sure yet of the optimum pin arrangement eg 8 bit using 8 (or more) prop pins vs 16 bit via latches and share with the external ram driver. The latter is a bit more messy, but it does free up more propeller pins to be used for other things, eg reading the touch screen.

There is some C source code here http://code.google.com/p/lpc1343codebase/source/browse/trunk/drivers/lcd/tft/hw/ILI9325.c?r=137

Do you think this is something we can integrate into Catalina?



/************************************************** ************************/
/*!
@file ILI9325.c
@author K. Townsend (microBuilder.eu)


@section DESCRIPTION


Driver for ILI9325 240x320 pixel TFT LCD displays.

This driver uses an 8-bit interface and a 16-bit RGB565 colour palette.
Should also work with SPFD5408B, ST7783 or OTM3225A-based LCDs, though
there are sometimes minor differences (for example vertical scrolling
via register 0x6A isn't supported with the ST7783 controller).


@section UPDATES


26-11-2010: ili9325ReadData contributed by Adafruit Industries


@section LICENSE


Software License Agreement (BSD License)


Copyright (c) 2010, microBuilder SARL
All rights reserved.


Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holders nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ''AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/************************************************** ************************/
#include "ILI9325.h"
#include "core/systick/systick.h"
#include "drivers/lcd/tft/touchscreen.h"


/*************************************************/
/* Private Methods */
/*************************************************/


/*************************************************/
void ili9325Delay(unsigned int t)
{
unsigned char t1;
while(t--)
for ( t1=10; t1 > 0; t1-- )
{
__asm("nop");
}
}


/*************************************************/
void ili9325WriteCmd(uint16_t command)
{
// Compiled with -Os on GCC 4.4 this works out to 25 cycles
// (versus 36 compiled with no optimisations). I'm not sure it
// can be improved further, so that means 25 cycles/350nS for
// continuous writes (cmd, data, data, data, ...) or ~150 cycles/
// ~2.1uS for a random pixel (Set X [cmd+data], Set Y [cmd+data],
// Set color [cmd+data]) (times assumes 72MHz clock).


CLR_CS_CD_SET_RD_WR; // Saves 18 commands compared to "CLR_CS; CLR_CD; SET_RD; SET_WR;"
ILI9325_GPIO2DATA_DATA = (command >> (8 - ILI9325_DATA_OFFSET));
CLR_WR;
SET_WR;
ILI9325_GPIO2DATA_DATA = command << ILI9325_DATA_OFFSET;
CLR_WR;
SET_WR_CS; // Saves 7 commands compared to "SET_WR; SET_CS;"
}


/*************************************************/
void ili9325WriteData(uint16_t data)
{
CLR_CS_SET_CD_RD_WR; // Saves 18 commands compared to SET_CD; SET_RD; SET_WR; CLR_CS"
ILI9325_GPIO2DATA_DATA = (data >> (8 - ILI9325_DATA_OFFSET));
CLR_WR;
SET_WR;
ILI9325_GPIO2DATA_DATA = data << ILI9325_DATA_OFFSET;
CLR_WR;
SET_WR_CS; // Saves 7 commands compared to "SET_WR, SET_CS;"
}


/*************************************************/
uint16_t ili9325ReadData(void)
{
// ToDo: Optimise this method!


uint16_t high, low;
high = low = 0;
uint16_t d;


SET_CD_RD_WR; // Saves 14 commands compared to "SET_CD; SET_RD; SET_WR"
CLR_CS;

// set inputs
ILI9325_GPIO2DATA_SETINPUT;
CLR_RD;
ili9325Delay(100);
high = ILI9325_GPIO2DATA_DATA;
high >>= ILI9325_DATA_OFFSET;
high &= 0xFF;
SET_RD;

CLR_RD;
ili9325Delay(100);
low = ILI9325_GPIO2DATA_DATA;
low >>= ILI9325_DATA_OFFSET;
low &=0xFF;
SET_RD;

SET_CS;
ILI9325_GPIO2DATA_SETOUTPUT;


d = high;
d <<= 8;
d |= low;

return d;
}


/*************************************************/
uint16_t ili9325Read(uint16_t addr)
{
ili9325WriteCmd(addr);
return ili9325ReadData();
}


/*************************************************/
void ili9325Command(uint16_t command, uint16_t data)
{
// Provided for convenience sake ... shouldn't be used
// in critical sections since it adds an extra
// branch, etc.
ili9325WriteCmd(command);
ili9325WriteData(data);
}


/*************************************************/
uint16_t ili9325BGR2RGB(uint16_t color)
{
uint16_t r, g, b;

b = (color>>0) & 0x1f;
g = (color>>5) & 0x3f;
r = (color>>11) & 0x1f;

return( (b<<11) + (g<<5) + (r<<0) );
}


/*************************************************/
/* Returns the 4-hexdigit controller code */
/*************************************************/
uint16_t ili9325Type(void)
{
ili9325WriteCmd(0x0);
return ili9325ReadData();
}


/*************************************************/
void ili9325SetCursor(uint16_t x, uint16_t y)
{
ili9325Command(0x0020, x); // GRAM Address Set (Horizontal Address) (R20h)
ili9325Command(0x0021, y); // GRAM Address Set (Vertical Address) (R21h)
}


/*************************************************/
void ili9325InitDisplay(void)
{
// Clear data line
GPIO_GPIO2DATA &= ~ILI9325_DATA_MASK;

SET_RD;
SET_WR;
SET_CS;
SET_CD;


// Reset display
CLR_RESET;
ili9325Delay(10000);
SET_RESET;
ili9325Delay(500);


ili9325Command(0x00FF, 0x0001);
ili9325Command(0x00F3, 0x0008);
ili9325WriteCmd(0x00F3);


ili9325Command(0x0001, 0x0100); // Driver Output Control Register (R01h)
ili9325Command(0x0002, 0x0700); // LCD Driving Waveform Control (R02h)
ili9325Command(0x0003, 0x1030); // Entry Mode (R03h)
ili9325Command(0x0008, 0x0302);
ili9325Command(0x0009, 0x0000);
ili9325Command(0x0010, 0x0000); // Power Control 1 (R10h)
ili9325Command(0x0011, 0x0007); // Power Control 2 (R11h)
ili9325Command(0x0012, 0x0000); // Power Control 3 (R12h)
ili9325Command(0x0013, 0x0000); // Power Control 4 (R13h)
ili9325Delay(1000);
ili9325Command(0x0010, 0x14B0); // Power Control 1 (R10h)
ili9325Delay(500);
ili9325Command(0x0011, 0x0007); // Power Control 2 (R11h)
ili9325Delay(500);
ili9325Command(0x0012, 0x008E); // Power Control 3 (R12h)
ili9325Command(0x0013, 0x0C00); // Power Control 4 (R13h)
ili9325Command(0x0029, 0x0015); // NVM read data 2 (R29h)
ili9325Delay(500);
ili9325Command(0x0030, 0x0000); // Gamma Control 1
ili9325Command(0x0031, 0x0107); // Gamma Control 2
ili9325Command(0x0032, 0x0000); // Gamma Control 3
ili9325Command(0x0035, 0x0203); // Gamma Control 6
ili9325Command(0x0036, 0x0402); // Gamma Control 7
ili9325Command(0x0037, 0x0000); // Gamma Control 8
ili9325Command(0x0038, 0x0207); // Gamma Control 9
ili9325Command(0x0039, 0x0000); // Gamma Control 10
ili9325Command(0x003C, 0x0203); // Gamma Control 13
ili9325Command(0x003D, 0x0403); // Gamma Control 14
ili9325Command(0x0050, 0x0000); // Window Horizontal RAM Address Start (R50h)
ili9325Command(0x0051, 0x00EF); // Window Horizontal RAM Address End (R51h)
ili9325Command(0x0052, 0X0000); // Window Vertical RAM Address Start (R52h)
ili9325Command(0x0053, 0x013F); // Window Vertical RAM Address End (R53h)
ili9325Command(0x0060, 0xa700); // Driver Output Control (R60h)
ili9325Command(0x0061, 0x0001); // Driver Output Control (R61h)
ili9325Command(0x0090, 0X0029); // Panel Interface Control 1 (R90h)


// Display On
ili9325Command(0x0007, 0x0133); // Display Control (R07h)
ili9325Delay(500);
ili9325WriteCmd(0x0022);
}


/*************************************************/
void ili9325Home(void)
{
ili9325Command(0x0020, 0X0000); // GRAM Address Set (Horizontal Address) (R20h)
ili9325Command(0x0021, 0X0000); // GRAM Address Set (Vertical Address) (R21h)
ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h)
}


/*************************************************/
void ili9325SetWindow(uint16_t x, uint16_t y, uint16_t x1, uint16_t y1)
{
ili9325Command(0x0050, x); // Window Horizontal RAM Address Start (R50h)
ili9325Command(0x0051, x1); // Window Horizontal RAM Address End (R51h)
ili9325Command(0x0052, y); // Window Vertical RAM Address Start (R52h) )
ili9325Command(0x0053, y1); // Window Vertical RAM Address End (R53h)
}


/*************************************************/
/* Public Methods */
/*************************************************/


/*************************************************/
void lcdInit(void)
{
// Set control line pins to output
gpioSetDir(ILI9325_CS_PORT, ILI9325_CS_PIN, 1);
gpioSetDir(ILI9325_CD_PORT, ILI9325_CD_PIN, 1);
gpioSetDir(ILI9325_WR_PORT, ILI9325_WR_PIN, 1);
gpioSetDir(ILI9325_RD_PORT, ILI9325_RD_PIN, 1);

// Set data port pins to output
ILI9325_GPIO2DATA_SETOUTPUT;


// Disable pullups
ILI9325_DISABLEPULLUPS();

// Set backlight pin to input and turn it on
gpioSetDir(ILI9325_BL_PORT, ILI9325_BL_PIN, 1); // set to output
lcdBacklightOn();


// Set reset pin to output
gpioSetDir(ILI9325_RES_PORT, ILI9325_RES_PIN, 1); // Set to output
gpioSetValue(ILI9325_RES_PORT, ILI9325_RES_PIN, 0); // Low to reset
systickDelay(50);
gpioSetValue(ILI9325_RES_PORT, ILI9325_RES_PIN, 1); // High to exit


// Initialize the display
ili9325InitDisplay();


// Fill black
lcdFillRGB(COLOR_BLACK);

// Initialise the touch screen (and calibrate if necessary)
tsInit();
}


/*************************************************/
void lcdBacklightOn(void)
{
// Enable backlight
gpioSetValue(ILI9325_BL_PORT, ILI9325_BL_PIN, 0);
}


/*************************************************/
void lcdBacklightOff(void)
{
// Disable backlight
gpioSetValue(ILI9325_BL_PORT, ILI9325_BL_PIN, 1);
}


/*************************************************/
void lcdTest(void)
{
uint32_t i,j;
ili9325Home();

for(i=0;i<320;i++)
{
for(j=0;j<240;j++)
{
if(i>279)ili9325WriteData(COLOR_WHITE);
else if(i>239)ili9325WriteData(COLOR_BLUE);
else if(i>199)ili9325WriteData(COLOR_GREEN);
else if(i>159)ili9325WriteData(COLOR_CYAN);
else if(i>119)ili9325WriteData(COLOR_RED);
else if(i>79)ili9325WriteData(COLOR_MAGENTA);
else if(i>39)ili9325WriteData(COLOR_YELLOW);
else ili9325WriteData(COLOR_BLACK);
}
}
}


/*************************************************/
void lcdFillRGB(uint16_t data)
{
unsigned int i;
ili9325Home();

uint32_t pixels = 320*240;
for ( i=0; i < pixels; i++ )
{
ili9325WriteData(data);
}
}


/*************************************************/
void lcdDrawPixel(uint16_t x, uint16_t y, uint16_t color)
{
ili9325WriteCmd(0x0020); // GRAM Address Set (Horizontal Address) (R20h)
ili9325WriteData(x);
ili9325WriteCmd(0x0021); // GRAM Address Set (Vertical Address) (R21h)
ili9325WriteData(y);
ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h)
ili9325WriteData(color);
}


/*************************************************/
void lcdDrawHLine(uint16_t x0, uint16_t x1, uint16_t y, uint16_t color)
{
// Allows for slightly better performance than setting individual pixels
uint16_t x, pixels;


if (x1 < x0)
{
// Switch x1 and x0
x = x1;
x1 = x0;
x0 = x;
}
ili9325WriteCmd(0x0020); // GRAM Address Set (Horizontal Address) (R20h)
ili9325WriteData(x0);
ili9325WriteCmd(0x0021); // GRAM Address Set (Vertical Address) (R21h)
ili9325WriteData(y);
ili9325WriteCmd(0x0022); // Write Data to GRAM (R22h)
for (pixels = 0; pixels < x1 - x0 + 1; pixels++)
{
ili9325WriteData(color);
}
}


/*************************************************/
uint16_t lcdGetPixel(uint16_t x, uint16_t y)
{
uint16_t preFetch = 0;


ili9325SetCursor(x, y);
ili9325WriteCmd(0x0022);
preFetch = ili9325ReadData();


// Eeek ... why does this need to be done twice for a proper value?!?
ili9325SetCursor(x, y);
ili9325WriteCmd(0x0022);
return ili9325ReadData();
}


/*************************************************/
void lcdScroll(int16_t pixels, uint16_t fillColor)
{
// Note: Not all ILI9325 imitations support HW vertical scrolling!
// ST7781 - Not supported (ex. RFTechWorld 2.8" displays)
// OTM3225A - Supported
int16_t y = pixels;
while (y < 0)
y += 320;
while (y >= 320)
y -= 320;
ili9325WriteCmd(0x6A);
ili9325WriteData(y);
}

RossH
11-16-2011, 03:16 AM
Do you think this is something we can integrate into Catalina?

Hi Dr_A,

Apart from the obviously non-portable stuff, it should compile - but it may not run fast enough to be useful. This would be better (and probably much simpler) to write as a PASM plugin - and even then you'd have trouble achieving the kinds of speeds mentioned in the code comments. This code would seem to have been originally written for a faster processor - do you know what it runs on?

In general, when you see C code written quite that badly, it's usually a sign that it has been rewritten in C after being developed in another language - in this case, most likely it was originally written in assembler. There are even comments in there to the effect that "this function should not be used because it adds an extra branch instruction" - if the timing is that critical, it means assembler is probably the answer.

Ross.

Dr_Acula
11-16-2011, 03:59 AM
Good point. I have the display drivers in C for the existing VGA/TV drivers and generally it is easier to debug in C and then port things over to pasm once they are working. That code above would probably fit in a cog. Then you could do things like move a picture from sd card to hub ram, then another routine to tell a cog where the picture is in hub, and then fire off a cog routine to move that data out to the display.

Hopefully it should be possible to build it up in blocks of code so that you can do a 'printf" in a variety of fonts/font sizes etc.

RossH
11-16-2011, 08:44 AM
All,

I have just uploaded the source for the version of Code::Blocks that supports Catalina to SourceForge (here (http://sourceforge.net/projects/catalina-c/files/releases/3.4/catalina_3.4_codeblocks_10.05_source.tar%2Cgz/download)). This includes the source for the updated Compiler plugin with Catalina compiler support.

Anyone who is having trouble installing Code::Blocks (like those reported on Ubuntu by pinedust) can now rebuild Code::Blocks from source instead of using the binary version included in the various Catalina downloads.

Ross.

pinedust
11-16-2011, 02:13 PM
All,

I have just uploaded the source for the version of Code::Blocks that supports Catalina to SourceForge (here (http://sourceforge.net/projects/catalina-c/files/releases/3.4/catalina_3.4_codeblocks_10.05_source.tar%2Cgz/download)). This includes the source for the updated Compiler plugin with Catalina compiler support.

Anyone who is having trouble installing Code::Blocks (like those reported on Ubuntu by pinedust) can now rebuild Code::Blocks from source instead of using the binary version included in the various Catalina downloads.

Ross.
Ross,
This version works great!
Thank you!

RossH
11-20-2011, 12:27 AM
All,

Earlier in this thread, Jazzed asked for a loader that included serial terminal capability so that users would not need to open a separate terminal emulator window. I can see this would be very useful for boards (like the Parallax QuickStart board) which have no keyboard, TV or VGA ports - so I have now added this capability to payload.

Payload now has an interactive mode (enabled via -i) that makes it act as a simple terminal emulator once the program has been downloaded. This simplifies loading and running programs for those who use the PC HMI option (which does all stdio via a serial port on pins 30 & 31).

I have added the new executable to the second post in this thread (http://forums.parallax.com/showthread.php?135424-Catalina-3.4&p=1046615&viewfull=1#post1046615) (Windows only at this stage!).

Here is how you might use it:


catalina othello.c -lc -D PC
payload othello -i

Note the addition of -D PC to the catalina command (to tell catalina to compile the program to use the PC terminal emulator HMI option) and the addition of the -i to the payload command (to tell payload to enter the interactive mode when the download has completed).

To exit the interactive terminal mode, just press CTRL+D (i.e. the EOT character) at any time.

Note that interactive mode can be used with any Catalina program (i.e. LMM or XMM) and also with any Spin binary (compiled to use the normal Parallax serial port at 115200 baud).

To use interactive mode from within Code::Blocks, just select Tools-> Configure tools... and add the new -i option to the relevant tool parameters (e.g. to the Download to Hub RAM tool)

If anyone has any problems with the interactive mode, or any suggestions for improvements, please let me know.

Ross.

Cluso99
11-20-2011, 06:12 AM
This is a nice and welcome feature Ross. I will let you know how I go with it in a few days.

RossH
11-22-2011, 09:48 PM
All,

I'm having some trouble with the Linux version of the new Payload loader (specifically, with the interactive terminal mode). I am almost sure it is because I run Linux in a virtual machine - but I just need to confirm this.

I don't want to release the code until I'm sure it is working, so I need a few Catalina Linux users (I know there aren't many in these forums!) willing to run a simple test. You just need to have Catalina 3.4 installed, and have Linux installed "natively" (i.e. not in a virtual machine).

Please send me a PM (with you email address) and I will post you an executable and some instructions on the test I need run - it will only take a couple of minutes.

Thanks!

Ross.

David Betz
11-22-2011, 10:05 PM
All,

I'm having some trouble with the Linux version of the new Payload loader (specifically, with the interactive terminal mode). I am almost sure it is because I run Linux in a virtual machine - but I just need to confirm this.

I don't want to release the code until I'm sure it is working, so I need a few Catalina Linux users (I know there aren't many in these forums!) willing to run a simple test. You just need to have Catalina 3.4 installed, and have Linux installed "natively" (i.e. not in a virtual machine).

Please send me a PM (with you email address) and I will post you an executable and some instructions on the test I need run - it will only take a couple of minutes.

Thanks!

Ross.
In case you're interested, here is the terminal code I use in propeller-load.


#define ESC 0x1b /* escape from terminal mode */

/**
* simple terminal emulator
*/
extern int check_for_exit;

void terminal_mode(void)
{
struct termios oldt, newt;
char buf[128];
ssize_t cnt;
fd_set set;
int exit_char = 0xdead; /* not a valid character */
int sawexit_char = 0;
int sawexit_valid = 0;
int exitcode = 0;
int continue_terminal = 1;

tcgetattr(STDIN_FILENO, &oldt);
newt = oldt;
newt.c_lflag &= ~(ICANON | ECHO);
tcsetattr(STDIN_FILENO, TCSANOW, &newt);

if (check_for_exit)
{
exit_char = 0xff;
}

#if 0
/* make it possible to detect breaks */
tcgetattr(hSerial, &newt);
newt.c_iflag &= ~IGNBRK;
newt.c_iflag |= PARMRK;
tcsetattr(hSerial, TCSANOW, &newt);
#endif

do {
FD_ZERO(&set);
FD_SET(hSerial, &set);
FD_SET(STDIN_FILENO, &set);
if (select(hSerial + 1, &set, NULL, NULL, NULL) > 0) {
if (FD_ISSET(hSerial, &set)) {
if ((cnt = read(hSerial, buf, sizeof(buf))) > 0) {
int i;
// check for breaks
ssize_t realbytes = 0;
for (i = 0; i < cnt; i++) {
if (sawexit_valid)
{
exitcode = buf[i];
continue_terminal = 0;
}
else if (sawexit_char) {
if (buf[i] == 0) {
sawexit_valid = 1;
} else {
buf[realbytes++] = exit_char;
buf[realbytes++] = buf[i];
sawexit_char = 0;
}
} else if (((int)buf[i] & 0xff) == exit_char) {
sawexit_char = 1;
} else {
buf[realbytes++] = buf[i];
}
}
write(fileno(stdout), buf, realbytes);
}
}
if (FD_ISSET(STDIN_FILENO, &set)) {
if ((cnt = read(STDIN_FILENO, buf, sizeof(buf))) > 0) {
int i;
for (i = 0; i < cnt; ++i)
if (buf[i] == ESC)
goto done;
write(hSerial, buf, cnt);
}
}
}
} while (continue_terminal);

done:
tcsetattr(STDIN_FILENO, TCSANOW, &oldt);

if (sawexit_valid)
{
exit(exitcode);
}

}

Dr_Acula
11-22-2011, 11:17 PM
Ross - I think some time ago you posted something about running Spin and C together. I was wondering - is it possible to run two C threads at the same time? Let's say, hypothetically, that each thread had access to half the hub ram and 4 cogs. Or, if that is too complicated, one thread is the Input/Output thread which would handle keyboard/mouse/display via stdio, and the other thread talks to the I/O thread via common hub memory?

What I am thinking of is an 'operating system' thread that handles input and output, and a 'program' thread where programs can be loaded and unloaded. Or more specifically, I am trying to write a program in C and it ends up with huge overheads running OS type stuff like loading in fonts from sd card and putting them on a display, and it may be easier to split the task into two.

I'm doing some experiments with 320x240 displays and these have their own internal memory, so this has opened up a whole new way of doing things because no hub is needed for a screen buffer, so essentially all the hub is free.

If the above is possible, is it also possible to have separate caches for each thread? Maybe 4k for each or something?

Rayman
11-22-2011, 11:19 PM
Ross, how much of ctime does Catalina include?

Is it everything in the usual time.h?

RossH
11-23-2011, 01:01 AM
Ross, how much of ctime does Catalina include?

Is it everything in the usual time.h?

As far as I know, yes.

There is a test program (test_time.c) in the Catalina/demos directory that turns your Prop into a digital clock. Requires TV or VGA output, and it should be compiled with the CLOCK option defined - e.g:


catalina test_time.c -lc -D CLOCK

Ross.

RossH
11-23-2011, 01:08 AM
In case you're interested, here is the terminal code I use in propeller-load.

Thanks, David - but the problem is definitely serial comms related. I use the curses library (which means the terminal emulation code is only a few lines) and everything works fine under Windows. Under Linux everything works functionally, but the output keeps pausing as if the I/O was being buffered somewhere. Tried non-buffered I/O and flushing etc - it appears it is being buffered within the virtual USB ports used when running Linux under Windows.

Ross.

RossH
11-23-2011, 01:17 AM
Ross - I think some time ago you posted something about running Spin and C together. I was wondering - is it possible to run two C threads at the same time? Let's say, hypothetically, that each thread had access to half the hub ram and 4 cogs. Or, if that is too complicated, one thread is the Input/Output thread which would handle keyboard/mouse/display via stdio, and the other thread talks to the I/O thread via common hub memory?
Of course. You can either run two kernels on two cogs, or run two threads in one kernel on the one cog - or do both. And any cog not being used for C (or plugins) can be used to run Spin.

What I am thinking of is an 'operating system' thread that handles input and output, and a 'program' thread where programs can be loaded and unloaded. Or more specifically, I am trying to write a program in C and it ends up with huge overheads running OS type stuff like loading in fonts from sd card and putting them on a display, and it may be easier to split the task into two.
Certainly possible, although I'd not recommend a Prop 1 for such a task. Perhaps on the Prop 2 ...

I'm doing some experiments with 320x240 displays and these have their own internal memory, so this has opened up a whole new way of doing things because no hub is needed for a screen buffer, so essentially all the hub is free.

If the above is possible, is it also possible to have separate caches for each thread? Maybe 4k for each or something?
I'm working on this. This is required to run multi-cog XMM programs effectively. I have to say again, though - I don't think the Prop 1 is ever going to be very suitable for projects like this - I'd at least wait for the Prop 2.

Ross.

Dr_Acula
11-23-2011, 03:05 AM
Very interesting.

One thing that has struck me with many propeller programs is that you have 8 cogs that can run in parallel, and the first thing you do is write a program that is one single program. I find it hard to *think* in parallel, but if you have cogs running in parallel, why not kernels running in parallel, and XMM programs running in parallel? Each has its own cog, hub and external memory.

I think the prop I could be eminently suitable doing this. eg there is a post active at the moment where someone wants to run a robot with 5 propellers - one does legs, one does vision etc. If you had XMM C programs you could (maybe) run 5 kernels in C on one propeller, or 5 kernels on separate propellers, and the process of changing from one to the other should be fairly simple as it is all just C code. So you start off trying to fit it all in one propeller but if you run out of cogs then you can move code into other propellers.

Ok, say this is possible, how would kernels talk to each other? Can you define a common block of memory for "inter-kernal communications"?

RossH
11-23-2011, 07:26 AM
Very interesting.

One thing that has struck me with many propeller programs is that you have 8 cogs that can run in parallel, and the first thing you do is write a program that is one single program. I find it hard to *think* in parallel, but if you have cogs running in parallel, why not kernels running in parallel, and XMM programs running in parallel? Each has its own cog, hub and external memory.
Yes, this is generally a very difficult things to do. Ideally, you want a language that does it for you automagically - but to date there isn't a good candidate language available (by that I mean a usable one - I know there have been many attempts).

I think the prop I could be eminently suitable doing this. eg there is a post active at the moment where someone wants to run a robot with 5 propellers - one does legs, one does vision etc. If you had XMM C programs you could (maybe) run 5 kernels in C on one propeller, or 5 kernels on separate propellers, and the process of changing from one to the other should be fairly simple as it is all just C code. So you start off trying to fit it all in one propeller but if you run out of cogs then you can move code into other propellers.
If I get time, I'll add the work I've done on multi-core XMM support to the next release of Catalina. I'm not getting as much time to work on this as I'd like at the moment.

Ok, say this is possible, how would kernels talk to each other? Can you define a common block of memory for "inter-kernal communications"?

In most cases, you can just use global variables. Where this is not sufficient (e.g. due to race conditions) Catalina also provides low level support for mutexes, from which any higher level inter-process comms mechanism you want can be constructed.

Ross.

Heater.
11-23-2011, 07:37 AM
Dr_A,

For a change I am going to agree with RossH:)



...if you have cogs running in parallel, why not kernels running in parallel,
and XMM programs running in parallel? Each has its own cog, hub and external
memory...


Because it would be mind bendingly slow. In the simple case each XMM program
fetches it's instructions and data from external memory directly with no
caching. So the kernel(cog) currently accessing external memory holds up all
the other kernels until the access is done. Result being that everything
proceeds at a snails pace.

Next up up put a cache in HUB, or even one per kernel, still all the kernels
are fighting over external memory when they need their caches updating. Plus
you have lost all your HUB space.

This is a thousand time worse than cogs waiting for their HUB slots to access
HUB RAM. At this point you are better off running your code on some other MCU
that has the address space for large programs and interrupts to schedule
tasks/threads,



If you had XMM C programs you could (maybe) run 5 kernels in C on one propeller,
or 5 kernels on separate propellers, and the process of changing from one to the
other should be fairly simple as it is all just C code. So you start off trying
to fit it all in one propeller but if you run out of cogs then you can move code
into other propellers.


"Fairly simple as it's all just C code" except for:



Ok, say this is possible, how would kernels talk to each other? Can you define a
common block of memory for "inter-kernal communications.


In one chip they would probably communicate via shared HUB. In many chips they
would need to use some inter chip coms link. Migrating code around like this
is not so simple.

This is exactly the problem addressed by the old Transputer chip from the 1980's and today the chip from the company that shall remain nameless here.

RossH
11-23-2011, 08:03 AM
Dr_A,

For a change I am going to agree with RossH:)

Oh dear! This means I must have been completely wrong! :)


Because it would be mind bendingly slow. In the simple case each XMM program
fetches it's instructions and data from external memory directly with no
caching. So the kernel(cog) currently accessing external memory holds up all
the other kernels until the access is done. Result being that everything
proceeds at a snails pace.
Those of us who try to run large C programs on the Prop 1 are used to that, surely?

Next up up put a cache in HUB, or even one per kernel, still all the kernels
are fighting over external memory when they need their caches updating. Plus
you have lost all your HUB space.

This is a thousand time worse than cogs waiting for their HUB slots to access
Not exactly - the nature of caching means that performance of 1x8k cache is not going to be significantly different than the performance of 8x1k caches.

...

At this point you are better off running your code on some other MCU
that has the address space for large programs and interrupts to schedule
tasks/threads,
Well, I can't disagree with that one :(


...

Migrating code around like this is not so simple.

I beg to differ - it is not actually code you are migrating, it is a thread of control. Catalina can already do this between cogs. Doing it between chips is not much more difficult (assuming all the chips have the same code loaded). This is on my list.

This is exactly the problem addressed by the old Transputer chip from the 1980's and today the chip from the company that shall remain nameless here.

I did say there were no usable languages, not that there were no languages.

Ross.

Dr_Acula
11-23-2011, 09:25 AM
I must respectfully disagree with heater :)

Let's see. Say you take a C program running in a cog kernel and say it has 8k of hub ram available as a cache. This is what we have already. Now Ross has said this runs extremely fast because almost all the time it is reading from cached hub ram, not from XMM ram. I did not quite believe this so I wrote my own test code and ran it. Ross is correct. It runs almost as if the XMM is not being accessed, and I suspect because it is a cache, the XMM memory is not being accessed much.

That means that the XMM memory speed is rather irrelevant. It also means that if two kernels are trying to access XMM memory, this will only happen infrequently and it is actually very unlikely that both want to access XMM at the same time.

I very much suspect that the two kernels will run just as fast as one kernel. Indeed, because they are separate, they will be running twice as fast overall. Net result - maybe you lose 10% of speed due to external ram access, but you gain 2x speed due to two kernels. I suspect this means faster code overall, not slower code.

WRT inter kernal comms, let's say we had 5 physical propeller chips all talking via Tim Moore's 4 serial object. And let's say that the way they all talked was via a common circular buffer in hub of 128 bytes. That enables intercompatability with existing code. Now let's say you put all this into one propeller. You could do the same thing by creating 5x128 byte buffers in hub memory. Not difficult. Each buffer might contain data packets of various sizes, with say a start byte (02), number of bytes, source, destination, data packet, and finish byte (03). Any program can search for packets destined for itself.

There are other protocols that are possible, but you don't need much to enable a comms system. With the above protocol, you might define a data packet to say "read x bytes at hub location y" and then you can transfer arrays between kernels.

You could even define a super simple interkernal comms system using one or two longs. Flag to say data is present. Read i bytes at hub location j to location k. Reset flag when you have read this. That might only be two longs and it enables whole hub memory to be transferred.

In some ways it may not matter what protocol you choose. That can be defined in your C program. All you really need is for a C program to be able to read and write longs (only one or two) to fixed locations in hub memory.

Where this could lead is something really cool. You could have two (or more) C programs, hundreds of kilobytes in size, running in parallel. How they interact is up to the programmer. Maybe they don't even interact at all (each has its own external comms ports for instance and interacts with the real world but not with each other). If there are race conditions, well it is up to the programmer to handle how those work.


I beg to differ - it is not actually code you are migrating, it is a thread of control. Catalina can already do this between cogs.

This is what I am thinking - Catalina already does this. Much of the propeller runs in parallel anyway. Hub for each kernel are going to be separate so there is no thread problem there. Each thread will have its own cogs so no problem there (eg each thread might have its own serial comms port cog for instance). The main one that seems complicated to me would be two kernels wanting access to XMM at once, and two kernels wanting access to an SD card at once. But that ought to be just two locks?

David Betz
11-23-2011, 11:30 AM
Thanks, David - but the problem is definitely serial comms related. I use the curses library (which means the terminal emulation code is only a few lines) and everything works fine under Windows. Under Linux everything works functionally, but the output keeps pausing as if the I/O was being buffered somewhere. Tried non-buffered I/O and flushing etc - it appears it is being buffered within the virtual USB ports used when running Linux under Windows.

Ross.
I wasn't aware that curses (or is it ncurses?) had a terminal emulator function. Does using curses mean that you get full VT100 or ANSI terminal emulation? That should be handy. My terminal mode is much simpler than that. I put it in originally for debugging the loader and people found it useful so it's become a permanent feature.

RossH
11-23-2011, 09:12 PM
I wasn't aware that curses (or is it ncurses?) had a terminal emulator function. Does using curses mean that you get full VT100 or ANSI terminal emulation? That should be handy. My terminal mode is much simpler than that. I put it in originally for debugging the loader and people found it useful so it's become a permanent feature.

Hi David,

No, curses does not have a built-in terminal emulator (although it does simplify the code if you want to do fancy things like screen manipulation in your own code). Mainly, it just avoids the need to do all the low level i/o configuration and "select" calls on a set of file descriptors just to be able to do multiple stream character I/O. I hate all that crazy BSD stuff - it's such a bizarre and non-portable way to have to do things.

Ross.

David Betz
11-23-2011, 10:50 PM
Does curses exist on all of your target plaforms? I imagine it exists on Mac OS X and Linux. Is it available for Windows?

RossH
11-24-2011, 12:38 AM
Does curses exist on all of your target plaforms? I imagine it exists on Mac OS X and Linux. Is it available for Windows?

Yes - check out pdcurses (http://pdcurses.sourceforge.net/%20)

Ross.

David Betz
11-24-2011, 01:23 AM
Yes - check out pdcurses (http://pdcurses.sourceforge.net/%20)

Ross.
Thanks for the link.

RossH
11-25-2011, 12:00 PM
All,

Regarding the problem I was having on Linux with the new version of Payload - i.e. ...

... everything works fine under Windows. Under Linux everything works functionally, but the output keeps pausing as if the I/O was being buffered somewhere. Tried non-buffered I/O and flushing etc - it appears it is being buffered within the virtual USB ports used when running Linux under Windows.
Ross.

I've finally managed to test the new Payload on a native Linux installation (thanks to those that offered theirs) and confirmed that this is indeed a problem related to using a virtual serial port when running Linux under VirtualBox. VirtualBox seems to have quite a few problems with USB devices and serial ports.

On a native Linux installation everything works fine.

However, I probably won't bother releasing a Linux binary until Catalina 3.5 is ready for release - but if someone really wants it sooner, let me know.

Ross.

Dr_Acula
12-12-2011, 04:11 AM
Hi Ross,

I've been distracted from Catalina while I searched for the perfect display. I think I now have an answer and it is a tower of Gadget Gangster boards with TV, VGA and a 320x240 full color display. Why not have them all, I say! See this thread for some photos http://forums.parallax.com/showthread.php?110134-2.4-quot-320x240-TFT-Prop-based-display-module/page2

I think Spin is going to run out of memory for such a display so it is back to XMM C.

These displays come with a huge library of C code but I don't think this is going to work as it is not fast enough. Filling an entire screen with 320x240x2 bytes using Spin takes ten seconds. C is faster but ideally I'd like this to be 100x faster and take 1/10th of a second, which is a data rate of around 1.5 megabytes per second.

For things like font libraries, the display has a mode where you send it an "address" which is 4 bytes, x1,y1,x2,y2 and then you stream bytes and the display fills up a block defined by those four values. If x1=x2 or y1=y2 it draws a line. Or you fill a square or a rectangle.

This is perfect for tile drivers and for icons, and for drawing fonts on the screen and is a lot faster than sending pixels one at a time (though if x1=x2=y1=y2 it does just draw a pixel with the next two bytes).

However, the more pixels and the better the resolution, the more data is needed. I am not sure if an SD card is fast enough. It probably is but I need to do some real tests with refreshing text by drawing fonts one at a time.

To get the speed up I am trying to use parallel data as much as possible. So data goes from an SD card into external memory (it could go into hub, but at 153k for a screen, this is too much for hub, or for a cache for that matter). Access to the sram is via a pasm program and I'm hoping I can write some pasm primitives to move blocks of data directly from sram out to the display one byte at a time. Maybe 30 pasm instructions to move one byte??

One catch is that the display shares the same propeller pins as the XMM C code. So one needs to pause C processing while a block of memory is moved out to the display. I already have this working with other graphics drivers.

I have some ideas for how this pasm code will look and maybe once I write it I might also have some ideas that could be useful for the huge intercog communication standard thread!

Hopefully we can get some sort of GUI working on this display using C :)

RossH
12-12-2011, 06:28 AM
Hi Ross,

I've been distracted from Catalina while I searched for the perfect display. I think I now have an answer and it is a tower of Gadget Gangster boards with TV, VGA and a 320x240 full color display. Why not have them all, I say! See this thread for some photos http://forums.parallax.com/showthread.php?110134-2.4-quot-320x240-TFT-Prop-based-display-module/page2

...
Hopefully we can get some sort of GUI working on this display using C :)

Hi Dr_A,

I've been meaning to buy a GG module, so I will go ahead and buy one of these as well. We'll see what we can come up with.

Ross.

Dr_Acula
12-12-2011, 10:19 AM
I have one or two of those displays available plus a spare adapter board that plugs into a standard GG USB board. So you could test this out if you wanted and see if something is possible in C. Even a dual color 40 column text display would be very useful on this display.

I've come up against a silly little problem with the cache command - I think it is paired with something else. This is my program:


#include <stdio.h>
int main ()
{
printf("Hello, World!\n");
while (1); // Prop reboots on exit from main()!
return 0;
}


and if I compile with LMM it works fine.

If I compile with external memory and a cache using this line it works fine



catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA -D CACHED_8K NEW.C


but if I compile with the XMM on but cached off using this line


catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA NEW.C


I get a blank screen with just a cursor flashing.

What is the correct syntax for no cache?

RossH
12-12-2011, 09:52 PM
I have one or two of those displays available plus a spare adapter board that plugs into a standard GG USB board. So you could test this out if you wanted and see if something is possible in C. Even a dual color 40 column text display would be very useful on this display.

I've come up against a silly little problem with the cache command - I think it is paired with something else. This is my program:


#include <stdio.h>
int main ()
{
printf("Hello, World!\n");
while (1); // Prop reboots on exit from main()!
return 0;
}


and if I compile with LMM it works fine.

If I compile with external memory and a cache using this line it works fine



catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_VGA -D CACHED_8K NEW.C


but if I compile with the XMM on but cached off using this line


catalina -lcx -D LARGE -D DRACBLADE -D HIRES_VGA NEW.C


I get a blank screen with just a cursor flashing.

What is the correct syntax for no cache?

Hi Dr_A,

I think we've been down this road before. I can't remember the exact answer (I'll figure it out again tonight) but just try removing all those unnecessary options from your compile command.

I'll try it out tonight, but in the meantime you could try:


catalina -lcx -D LARGE -D DRACBLADE -D HIRES_VGA NEW.C

Ross.

Dr_Acula
12-12-2011, 10:52 PM
Thanks Ross - much appreciated.

RossH
12-13-2011, 02:20 AM
Thanks Ross - much appreciated.

Do you mean that got it working?

Ross.

Dr_Acula
12-13-2011, 02:31 AM
No sorry, won't have a chance to test till later tonight.

I tried reading the document you have that describes all the settings but SHARED_XMM does not seem to be on the list, so I'm sort of guessing and randomly removing settings but not quite knowing what they all do.

I have some C code that loads up cog 7 with a plugin and it works with LMM mode but not with XMM mode and caching, and I suspect the cache is using the last free cog. So I had the idea of removing the cache command and leaving it in XMM mode but then it wouldn't print "Hello World" any more.

Freeing up a cog is the first step in getting a 320x240 touchscreen working...

RossH
12-13-2011, 02:44 AM
No sorry, won't have a chance to test till later tonight.

I tried reading the document you have that describes all the settings but SHARED_XMM does not seem to be on the list, so I'm sort of guessing and randomly removing settings but not quite knowing what they all do.

SHARED_XMM is now an internal flag - it should only be set on certain hardware, and (if required) it is now set in the *_CFG.inc file (e.g. DracBlade_CFG.inc).

Ross

RossH
12-13-2011, 02:48 AM
SHARED_XMM is now an internal flag - it should only be set on certain hardware, and (if required) it is now set in the *_CFG.inc file (e.g. DracBlade_CFG.inc).

Ross

Dr_A, I just did a quick search, and here is the previous thread on exactly the same issue (http://forums.parallax.com/showthread.php?135039-Catalina-3.3&p=1044630&viewfull=1#post1044630).

Ross.

Dr_Acula
12-13-2011, 02:54 AM
Thanks Ross.

Yes, it looks like I fixed that in code::blocks. Now I need to do the same thing on my IDE.

code::blocks is nice but it doesn't quite have the flexibility of a custom IDE. Debugging plugins is hard and I need a way of including inline pasm code so that changes can be made in the C code and the pasm code at the same time. Once I get a driver working I'll be able to go back to code::blocks but meantime, thanks for your patience while I bring my IDE up to the version 3 standard :)

Another option is to leave in the caching and remove some other cog. Maybe the mouse cog, since that won't be needed for a touchscreen...

Dr_Acula
12-14-2011, 10:00 AM
Hi Ross,

Sorry to trouble you again but I made those changes and I'm still having problems. I know this is v 3.3, not 3.4, but hopefully that is ok.

My program:


#include <stdio.h>
int main ()
{
printf("Hello, World!\n");
while (1); // Prop reboots on exit from main()!
return 0;
}




This works



catalina -lcx -D LARGE -M 512k -D DRACBLADE -D LORES_VGA -D CACHED_8K NEW.C


and this does not



catalina -lcx -D LARGE -M 512k -D DRACBLADE -D LORES_VGA NEW.C


The only change here is that when the cache is deleted it does not work.

I have tried with vga hi res, vga lo res, tv hi res and tv lo res and it is the same problem - with no cache there is just a flashing cursor and no "Hello World".

Below is the full printout of the compilation. Any help would be most appreciated.

Addit: having said all this, what I really want to do is free up a cog so maybe there is another way. Will removing the mouse free up a cog and if so, what command do I add?


Works with a cache:


===================
SETTING UP CATALINA
===================


CATALINA_DEFINE = [default]
CATALINA_INCLUDE = [default]
CATALINA_LIBRARY = [default]
CATALINA_TARGET = [default]
CATALINA_LCCOPT = [default]
CATALINA_TEMPDIR = [default]
LCCDIR = "C:\Program Files\Catalina"
catalina -lcx -D LARGE -M 512k -D DRACBLADE -D LORES_VGA -D CACHED_8K NEW.C
Catalina Compiler 3.3
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\xmm_default.spin
parsing C:\Program Files\Catalina\target\Catalina_Common.spin
parsing C:\Program Files\Catalina\target\Cache.spin
parsing C:\Program Files\Catalina\target\Catalina_SPI_Cache.spin
parsing C:\Program Files\Catalina\target\Command_Line.spin
parsing C:\Program Files\Catalina\target\Catalina_CogStore.spin
parsing C:\Program Files\Catalina\target\Floating_Point.spin
parsing C:\Program Files\Catalina\target\Catalina_Float32_A_Plugin.sp in
parsing C:\Program Files\Catalina\target\SD_Card.spin
parsing C:\Program Files\Catalina\target\Catalina_SD_Plugin.spin
parsing C:\Program Files\Catalina\target\Clock.spin
parsing C:\Program Files\Catalina\target\HMI.spin
parsing C:\Program Files\Catalina\target\Catalina_HMI_Plugin_LoRes_Vg a.spin
parsing C:\Program Files\Catalina\target\Catalina_CogCount.spin
parsing C:\Program Files\Catalina\target\Catalina_comboKeyboard.spin
parsing C:\Program Files\Catalina\target\Catalina_VGA_Text.spin
parsing C:\Program Files\Catalina\target\vga.spin
parsing C:\Program Files\Catalina\target\Graphics.spin
parsing C:\Program Files\Catalina\target\Proxy_IO.spin
parsing C:\Program Files\Catalina\target\Extras.spin
parsing C:\Program Files\Catalina\target\Catalina_XMM.spin
parsing C:\Program Files\Catalina\target\Catalina_HUB_XMM_Loader.spin
compiling xmm_default.spin
compiling Cache.spin
compiling Catalina_SPI_Cache.spin
compiling Command_Line.spin
compiling Catalina_CogStore.spin
compiling Floating_Point.spin
compiling Catalina_Float32_A_Plugin.spin
compiling SD_Card.spin
compiling Catalina_SD_Plugin.spin
compiling Clock.spin
compiling HMI.spin
compiling Catalina_HMI_Plugin_LoRes_Vga.spin
compiling Catalina_CogCount.spin
compiling Catalina_comboKeyboard.spin
compiling Catalina_VGA_Text.spin
compiling vga.spin
compiling Graphics.spin
compiling Proxy_IO.spin
compiling Extras.spin
compiling Catalina_XMM.spin
compiling Catalina_HUB_XMM_Loader.spin
compiling Catalina_Common.spin
writing 32768 bytes to C:\Program Files\Catalina\target\xmm_default.eeprom
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\Catalina.spin
compiling Catalina.spin
writing 69724 bytes to NEW.binary
renaming output file from NEW.binary to NEW_temp.binary
combining target and program to NEW.binary

code = 35620 bytes
cnst = 468 bytes
init = 176 bytes
data = 652 bytes
file = 70236 bytes
Payload XMM NEW
Using Propeller (version 1) on port COM1 for first download
Using Secondary Loader on port COM1 for subsequent download
Press any key to continue . . .


and not working when the cache is removed:



===================
SETTING UP CATALINA
===================


CATALINA_DEFINE = [default]
CATALINA_INCLUDE = [default]
CATALINA_LIBRARY = [default]
CATALINA_TARGET = [default]
CATALINA_LCCOPT = [default]
CATALINA_TEMPDIR = [default]
LCCDIR = "C:\Program Files\Catalina"
catalina -lcx -D LARGE -M 512k -D DRACBLADE -D LORES_VGA NEW.C
Catalina Compiler 3.3
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\xmm_default.spin
parsing C:\Program Files\Catalina\target\Catalina_Common.spin
parsing C:\Program Files\Catalina\target\Cache.spin
parsing C:\Program Files\Catalina\target\Command_Line.spin
parsing C:\Program Files\Catalina\target\Catalina_CogStore.spin
parsing C:\Program Files\Catalina\target\Floating_Point.spin
parsing C:\Program Files\Catalina\target\Catalina_Float32_A_Plugin.sp in
parsing C:\Program Files\Catalina\target\SD_Card.spin
parsing C:\Program Files\Catalina\target\Catalina_SD_Plugin.spin
parsing C:\Program Files\Catalina\target\Clock.spin
parsing C:\Program Files\Catalina\target\HMI.spin
parsing C:\Program Files\Catalina\target\Catalina_HMI_Plugin_LoRes_Vg a.spin
parsing C:\Program Files\Catalina\target\Catalina_CogCount.spin
parsing C:\Program Files\Catalina\target\Catalina_comboKeyboard.spin
parsing C:\Program Files\Catalina\target\Catalina_VGA_Text.spin
parsing C:\Program Files\Catalina\target\vga.spin
parsing C:\Program Files\Catalina\target\Graphics.spin
parsing C:\Program Files\Catalina\target\Proxy_IO.spin
parsing C:\Program Files\Catalina\target\Extras.spin
parsing C:\Program Files\Catalina\target\Catalina_XMM.spin
parsing C:\Program Files\Catalina\target\Catalina_HUB_XMM_Loader.spin
compiling xmm_default.spin
compiling Cache.spin
compiling Command_Line.spin
compiling Catalina_CogStore.spin
compiling Floating_Point.spin
compiling Catalina_Float32_A_Plugin.spin
compiling SD_Card.spin
compiling Catalina_SD_Plugin.spin
compiling Clock.spin
compiling HMI.spin
compiling Catalina_HMI_Plugin_LoRes_Vga.spin
compiling Catalina_CogCount.spin
compiling Catalina_comboKeyboard.spin
compiling Catalina_VGA_Text.spin
compiling vga.spin
compiling Graphics.spin
compiling Proxy_IO.spin
compiling Extras.spin
compiling Catalina_XMM.spin
compiling Catalina_HUB_XMM_Loader.spin
compiling Catalina_Common.spin
writing 32768 bytes to C:\Program Files\Catalina\target\xmm_default.eeprom
Homespun Spin Compiler 0.30
parsing C:\Program Files\Catalina\target\Catalina.spin
compiling Catalina.spin
writing 69724 bytes to NEW.binary
renaming output file from NEW.binary to NEW_temp.binary
combining target and program to NEW.binary

code = 35620 bytes
cnst = 468 bytes
init = 176 bytes
data = 652 bytes
file = 70236 bytes
Payload XMM NEW
Using Propeller (version 1) on port COM1 for first download
Using Secondary Loader on port COM1 for subsequent download
Press any key to continue . . .

RossH
12-14-2011, 08:47 PM
Hi Ross,

Sorry to trouble you again but I made those changes and I'm still having problems. I know this is v 3.3, not 3.4, but hopefully that is ok.



I can't see why this wouldn't work - everything looks ok. I will re-install 3.3 and try this tonight. I do vaguely remember making some changes in the VGA support of the DracBlade, but I can't remember which version that was in, so I'll have to wait till I get home to investigate further.

If you get time before then, try using -D SMALL (instead of -D LARGE), and also try using -D HIRES_VGA (instead of -D LORES_VGA).

Ross.

RossH
12-15-2011, 06:11 AM
Hi Dr_A.

Works for me under Catalina 3.3 or 3.4 (or 3.5), using any combination of library, memory model and HMI options.

I'd say your problem is that when you removed the cache option from your program, you did not also rebuild the utilities. The XMM loader and the program to be loaded have to be compiled with the same cache options (or with no cache options).

Try the following (from the main Catalina directory):



cd utilities
build_all DRACBLADE
then try it again.

Also, make sure you don't have an old copy of XMM.binary in your local directory - if you do, delete it - Catalina will use the one in the Catalina bin directory.

Ross.

Dr_Acula
12-15-2011, 06:57 AM
Ah, that could explain it. Thanks Ross.

Maybe I could add "build_all" to the batch file?

Then again, the cache is so nifty, I'll have to find a free cog some other place. Touchscreens won't need either a mouse or a keyboard so that could save cog(s)? I found the NO_MOUSE etc commands - I think they free up a cog, right?

Also, a general question, if you have a registry, is there a function you can use in a program to query the registry and see what cogs are loaded with what? I know there is a command that tells you which cog catalina is running in (my program says it is cog #2) but can you find out about the other cogs?

If so, that could justify that entire inter-cog communication thread you are running :)

RossH
12-15-2011, 07:54 AM
Ah, that could explain it. Thanks Ross.

Maybe I could add "build_all" to the batch file?
A better option would be to build the utillities twice - once with the cache and once without, renaming the cached version of XMM.binary to XMM_cache.binary (or something else appropriate).

Then again, the cache is so nifty, I'll have to find a free cog some other place. Touchscreens won't need either a mouse or a keyboard so that could save cog(s)? I found the NO_MOUSE etc commands - I think they free up a cog, right?
Not on the DRACBLADE - I think NO_MOUSE is the default. Anyway, I may implement a touchpad driver that is mouse-driver compatible.

Also, a general question, if you have a registry, is there a function you can use in a program to query the registry and see what cogs are loaded with what? I know there is a command that tells you which cog catalina is running in (my program says it is cog #2) but can you find out about the other cogs?
Yes, there is a demo program in the demos directory called test_plugin_names.c

If so, that could justify that entire inter-cog communication thread you are running :)

Yes, I will get back to that thread later this week - I now have a complete service-oriented model for cog-to-cog communications that I intend to adopt in Catalina - Mike and Eric's suggestions of implementing a service-based registry actually fixes a long-standing problem with Catalina. I knew about the problem, but had held off fixing it because my own solution took too much code to justify - but Mike's idea works a treat!

Ross.

sicoloco55
12-31-2011, 05:06 AM
Im new to Catalina and I was wondering if there's some manual or any examples about simple programs.
Im programming in SPIN but I like more C.

Thanks :D

RossH
01-08-2012, 10:53 AM
Im new to Catalina and I was wondering if there's some manual or any examples about simple programs.
Im programming in SPIN but I like more C.

Thanks :D

Hi sicoloco55

Sorry to take so long to answer. I've been out of internet range for the last couple of weeks.

Catalina C is 100% pure ANSI C. So the best book I can refer you to is the The C Programming Language (http://en.wikipedia.org/wiki/The_C_Programming_Language) - anything you find in there should compile and run. If you are at all interested in C you will want to buy, beg or steal a copy of this book (make sure you get the second edition - the first edition describes the C language prior to the ANSI standard). This book is probably the best book on progamming ever written, and still the bible for C programmers.

In the meantime, any book on ANSI C will do, and there are several online - e.g. The C Book (http://publications.gbdirect.co.uk/c_book/the_c_book.pdf),

Also, if you just download and install Catalina and look in the Catalina\demos directory, you'll find there's plenty of examples - and there is a reference guide and tutorial document in the main Catalina directory.

Ross.

richaj45
01-20-2012, 07:56 AM
Hello:

I am wondering if the Prop GCC development is undermining the Catalina tool?

Also why would Parallax move to support a GCC port when the Catalina is available and from what i read is being continuously improving?

Thanks for the BW

Rich

Heater.
01-20-2012, 08:53 AM
Parallax would like to make more Propeller sales, naturally, and hence they are addressing the huge world of commercial embedded systems developers.
There is a perception that such "professional" developers demand the C language and will not look at Spin or assembler solutions. Further that they expect GCC as it is in use for pretty much every other micro-controller.
Requiring GCC may not make much sense but I suspect that is the case generally.
Hence the GCC for Propeller effort.
I hope both propgcc and Catalina have success and long lives.

Cluso99
01-20-2012, 08:58 AM
righaj45: You may well ask ;)
I have no idea except that some believe they need GCC for the professional market. Frankly, Catalina is pretty damn good and has lots of environments. And best of all, its pretty stable.

Fernand
01-20-2012, 09:13 AM
Just got a QuickStart board a couple of days ago and have been getting my
feet wet with the Prop. SPIN works ;-)

Since the QuickStart is not on the list of environments, and I'm having trouble
setting options (redefinition of PROPTERM etc), is there a ready-made project
I can load up and have it compile, load into RAM (or EEPROM), that will have
printf() working with the Parallax Terminal on a USB Com port? In other words
something to get started from the IDE with a known working set of options?
Thanks!

RossH
01-20-2012, 09:25 AM
Hello:

I am wondering if the Prop GCC development is undermining the Catalina tool?

Also why would Parallax move to support a GCC port when the Catalina is available and from what i read is being continuously improving?

Thanks for the BW

Rich

Hi Rich,

GCC does not really undermine Catalina, and nor does Catalina really undermine GCC. GCC support for the Propeller is a useful addition to the toolset of professional C/C++ developers who already use GCC and don't want to have to learn anything else.

Catalina is a simpler compiler (i.e. ANSI C only, no C++) which is likely to be appealing to existing Propeller users, and also likely to be easier for hobbyists who already know Spin but want to learn C without having to deal with the additional complexity that comes with the GCC tool chain (which is a Linux-based toolchain which requires additional support - such as MinGW or Cygwin - to work under Windows).

Also, Catalina will continue to move in the direction of better Spin integration. I don't think GCC will ever support Spin.

So - two different compilers for two different markets. If the Prop 2 takes off I wouldn't be surprised to see other compilers emerge. I'm sure someone somewhere is already working on an LLVM backend for the Propeller. In some ways, LLVM might be a better fit for the Propeller architecture than GCC anyway.

Ross.

RossH
01-20-2012, 10:58 AM
Just got a QuickStart board a couple of days ago and have been getting my
feet wet with the Prop. SPIN works ;-)

Since the QuickStart is not on the list of environments, and I'm having trouble
setting options (redefinition of PROPTERM etc), is there a ready-made project
I can load up and have it compile, load into RAM (or EEPROM), that will have
printf() working with the Parallax Terminal on a USB Com port? In other words
something to get started from the IDE with a known working set of options?
Thanks!

I don't have a QuickStart board, but it isn't difficult to support. I suppose I really should add it as a standard platform since a few people seem to have them these days - I'll post a set of Catalina configuration files that adds specific support for it over the weekend

In the meantime, it will work if you just specify the DEMO board (to set the correct clockspeed) and limit yourself to the PC (or PROPTERM) HMI options - e.g:


cd demos
catalina hello_world.c -lc -D DEMO -D PC
payload -i hello_world


Note that you need the new version of payload (i.e. 3.5.1) that supports the interactive terminal option (i.e. -i). See the second post in this thread.

Ross.

ersmith
01-20-2012, 11:58 AM
I don't think GCC will ever support Spin.

Why would you say that? There's already a Spin to C++ converter. Granted it isn't part of the official propgcc release, but I would not be surprised to see some kind of Spin compilation strategy become part of propgcc.

Anyway, I'll add to the chorus here that says that Catalina and GCC can certainly co-exist (and to some degree complement each other). Catalina is somewhat more hobbyist focused, and GCC somewhat more professionally focused, but both are useful for all kinds of projects. All the other "serious" platforms (x86, amd64, arm, powerpc, etc.) have multiple C compilers available, I don't see why the Propeller should be any different :-).

Eric

RossH
01-20-2012, 09:43 PM
Why would you say that? There's already a Spin to C++ converter. Eric

Yes, I know about and applaud your efforts to convert Spin to C++ - but the resulting program is not a Spin program. There were some stats somewhere about Spin program code sizes vs C program code sizes. I think it showed that C programs were around 4 times larger than the equivalent Spin programs, Unfortunately this negates one of the key advantages of Spin - i.e. it's compact code size.

This means that on the Prop 1, many Spin programs converted to C++ won't be able to run - they would simply end up too large. However, your Spin to C++ converter would be a good solution for people who currently use a Prop 1 and want to use a Spin-like language on the Prop 2, since the Prop 2 has enough RAM to run Prop 1 Spin programs converted to C++.

Have Parallax confirmed whether there is going to be an "official" Spin compiler/interpreter for the Prop 2?

Ross.