Can you please try the attached catbind.exe (unzip it into your Catalina bin directory) and see if it solves your "cannot open temporary files" problem?
All I have done is make catalina use the same directory lcc uses for temporary files. You can override the default by setting the CATALINA_TEMPDIR environment variable.
I'll bundle up a patch release for Windows 7/Vista users - I'll just wait a day or two to see if Michael Park can find an answer for the wierd homespun problem.
Ross, I'm toying with the idea of adaption Catalina for my Rampage memory module with SQI flash and 4-bit wide SRAM on the same bus...
I was poking around your source code and I think all the memory code is in XMM.inc, is that right?
One problem I think I see is that your code works at the byte level, whereas my SRAM memory pretty much works in longs only. I.e., to write just a byte, I'd have to read it's long, change the byte, then write the byte back...
How much of an issue do you see that being?
PS: I think I see now that the way you might make money with this is with the "code optimizer". Is this something you sell now?
Ross, I'm toying with the idea of adaption Catalina for my Rampage memory module with SQI flash and 4-bit wide SRAM on the same bus...
I was poking around your source code and I think all the memory code is in XMM.inc, is that right?
One problem I think I see is that your code works at the byte level, whereas my SRAM memory pretty much works in longs only. I.e., to write just a byte, I'd have to read it's long, change the byte, then write the byte back...
How much of an issue do you see that being?
PS: I think I see now that the way you might make money with this is with the "code optimizer". Is this something you sell now?
Hi Rayman,
Working at the long level rather than the byte level is not a problem if you use the caching version of the XMM driver. It accesses XMM RAM only at the long level, but allows users to access the RAM at the byteword,or long level - e.g. if you read a byte, the caching driver reads the whole long from XMM RAM (and caches it) but then just returns you the relevant byte of the long. If you write a byte, it is written to the appropriate byte of the cached long, and then sometime later that long will be written back to XMM RAM.
So just implement your XMM RAM using the caching driver and see how you go. See the file target/Catalina_SPI_Cache.spin (ignore the "SPI" reference - the cache was originally intended to support only SPI-based XMM RAM, but is now also used for all types of XMM RAM). From memory, on non-Flash platforms, this driver only requires four XMM routines (implemented in target/XMM.inc):
XMM_Activate - activate XMM bus
XMM_TriState - deactivate XMM bus
XMM_ReadPage - read a page of data from XMM RAM
XMM_WritePage - write a page of data to XMM RAM
Although nominally the XMM_ReadPage and XMM_WritePage deal in bytes, when used from the caching XMM driver they will only ever be asked to read/write a whole number of longs, and could be implemented that way.
Ross.
P.S. Yes, I do sell the Optimizer - at a nominal cost of $US25 - but I certainly don't make much money out of it!
Thinking out loud here, if I write a program like the GUI in XMM C using a 512k ram chip, this code ought to be portable to other XMM solutions, like Rayman's design.
Catalina C is leaping ahead here. Spin doesn't even have an external memory solution, and now Catalina has a number of solutions. I love being able to start a program that fits in the propeller memory, then when it runs out of room, change one parameter on the compile command line and then just keep coding with the code fitting into external memory.
Internal vs external vs caching vs non caching - the user doesn't really have to worry about that. Just write the C code and run it.
I am wondering if we need to think about some sort of code repository? I'm posting things on the forum but they can easily get lost over time. Some things are not really 'objects' as such, so don't really fit in the obex, though maybe this is the best place?
Or maybe send code to Ross and include it in the demo folder along with all the other demo code?
Thinking out loud here, if I write a program like the GUI in XMM C using a 512k ram chip, this code ought to be portable to other XMM solutions, like Rayman's design.
...
Internal vs external vs caching vs non caching - the user doesn't really have to worry about that. Just write the C code and run it.
Naturally - what made you think this might not be the case? Everything you write in Catalina should be portable to all other platforms supported by Catalina, provided that platform has enough RAM (but of course, the performance between platforms may vary widely).
I am wondering if we need to think about some sort of code repository? I'm posting things on the forum but they can easily get lost over time. Some things are not really 'objects' as such, so don't really fit in the obex, though maybe this is the best place?
Or maybe send code to Ross and include it in the demo folder along with all the other demo code?
I'll give this some thought. I don't want to become a bottleneck on the process - perhaps another sourceforge repository might be the answer?
Naturally - what made you think this might not be the case?
Nah, more that I couldn't resist the free plug for Catalina!
Thinking about performance, in the GUI there are some things that work fast enough in C, like drawing a solid box, and there are some that are very close to being fast enough, like redrawing the mouse, and there are some that are too slow, like drawing fonts. But everything that is too slow can be moved over to a cog. The mouse would be a perfect example - just take an existing mouse obex that works in spin and C, and then add the code to draw and redraw the pixels for the pointer. So then any caching or SPI serial ram solution that ends up being too slow may not matter because the time critical things can always be moved into cogs.
And with the ability to load and reload cogs from XMM arrays, it is possible to break out of the 8 cog limitation.
Ross, I was reading through your very nice documentation and just had a minor comment:
I think the standard notation for byte is a capital B and bit is lower case b. I think you are using only the lower case b. I was a little confused at first...
One more technical question... I think I see how to use Flash and how to use SRAM. But, what do you do when you want to use both within the same program? I think you said in a PM that this was possible, but I don't see what to do to invoke that option...
Ross, I was reading through your very nice documentation and just had a minor comment:
I think the standard notation for byte is a capital B and bit is lower case b. I think you are using only the lower case b. I was a little confused at first...
One more technical question... I think I see how to use Flash and how to use SRAM. But, what do you do when you want to use both within the same program? I think you said in a PM that this was possible, but I don't see what to do to invoke that option...
Hi Rayman,
I'll check my documentation on the next release - thanks.
To use Flash and SRAM together required two new memory layouts. You will see these referred to internally as layouts 3 and 4 (on the command line, you can still invoke them using using -x3 and -x4, but now you would do it more intuitively as -D FLASH -D LARGE or -D FLASH -D SMALL, respectivey). The main difference is that when these layouts are used, Catalina knows to separate the read/write segments from the read/only segments. There are a couple of definitions in Catalina_Common.spin that tell Catalina where to locate these segments in the global memory map of the target platform. For example, for the C3 you will see:
SPI_RW_BASE_ADDRESS = $0000_8000 ' SPI Read-Write Base address
SPI_RO_BASE_ADDRESS = $0001_8000 ' SPI Read-Only Base address
This means that Catalina will compile the segments so that read/write segments start at $8000 and read/only segments start at $180000. Of course, the underlying XMM access code has to then map all XMM addresses into the appropriate SRAM or FLASH chip by decoding the address and then selecting the appropriate SPI device - so the first step in the process is to decide on your global memory map and allocate the memory space to your devices (so that this is easy to do given any XMM address).
Ross, thanks for the info. One other question....
It appears that flash is completely erased ever time the loader is used.
But, I was thinking about implementing a basic file system in flash...
How hard do you see it to have a loader create a new flash file and then execute it?
Ross, thanks for the info. One other question....
It appears that flash is completely erased ever time the loader is used.
But, I was thinking about implementing a basic file system in flash...
How hard do you see it to have a loader create a new flash file and then execute it?
Hi Rayman,
You can do that - just don't tell Catalina to use the Flash as XMM. For instance, on the C3 if you compiled with -x5 (or -D LARGE) then Catalina will use the SRAM as XMM RAM but not use the FLASH at all. Then you can write a plugin of your own that uses the FLASH independently of Catalina (just be aware that if it shares control lines with the SRAM then you can only use the Flash when Catalina actually requests to do so).
Even better - if you made the interface to your plugin compatible with the one implemented in Catalina_SD_Plugin.spin (which implements very simple sector based read/write services), then you get FAT32/FAT16 file system support for your Flash RAM for free! The only thing you would need outside this is something like a "format" utility that wrote an "image" to the FLASH that makes it look like a (blank) formatted SD card of the appropriate size.
@Ross, I have a functional JCACHE-like interface for byte wide QuadSPI Flash working now. It provides C3-like flash features. The programming object is a separate driver. I'll be testing this with Catalina later. It already works with XBASIC in preliminary tests.
@Rayman, having a wear-leveled QuadSPI flash file-system would be a nice asset
Then you can write a plugin of your own that uses the FLASH independently of Catalina (just be aware that if it shares control lines with the SRAM then you can only use the Flash when Catalina actually requests to do so).
If the pins are different then the code is quite easy.
If the pins are shared, I've just finished writing that sort of code (see some earlier posts) and there is code to put catalina to sleep while a cog takes over shared pins, and then wakes up catalina when it is finished.
This might seem a bit of a dumb question, but can Catalina do inline pasm code in XMM mode?
If so, what does this end up looking like? Do you just add pasm instructions in the middle of C code?
I'm thinking of instances where short fragments of pasm are going to be quicker to run inline from XMM than they are to be run by loading up a cog, running it and then unloading the cog.
This might seem a bit of a dumb question, but can Catalina do inline pasm code in XMM mode?
If so, what does this end up looking like? Do you just add pasm instructions in the middle of C code?
I'm thinking of instances where short fragments of pasm are going to be quicker to run inline from XMM than they are to be run by loading up a cog, running it and then unloading the cog.
Hello, Dr_A
The short answer is "yes". But I do it in a slightly devious way (would you expect anything else with Catalina?)...
I have resisted adding the asm keyword (or function) to Catalina because it is non-ANSI, compiler-dependent, makes the program confusing and harder to maintain, and immediately makes your entire program non-portable.
Instead, I support assembly language functions that can be called from C. For example, to invoke the PASM cogid instruction with another compiler, you might use an asm function to just poke the instruction into the middle of your C code. But for the reasons I mentioned above, I regard this as bad practice.
Instead, to invoke cogid, I provide a _cogid() function that you can call from C like any other function. Here is the actual code for the function:
' Catalina Code
DAT ' code segment
' Catalina Export _cogid
long ' align long
C__cogid
cogid r0 <----- this is the instuction we would like to execute.
jmp #RETN
' end
You can do the same. Just use the above as a template for "wrapping" the instruction you want to execute (change the name of the function, of course!). Any parameters you pass will be passed in register r2, and any value you want to return should be returned in register r0.
"Aha!" (I hear you say) "this is very inefficient! I now have the overhead of a function call and a return statement just to get my cogid! At least three instructions (more in fact) instead of just one!"
But ... (and here's the clever bit!) ... if you use the Catalina Optimizer, any calls to this function will be automatically inlined. The procedure call and function return overheads will be optimized away, and the instruction will be inserted in your code and executed exactly as if you had used an asm statement - without littering your lovely C program with ugly and non-portable constructs!
This is in fact the main reason I wrote the Optimizer in the first place.
If you need help, just let me know what instruction you want to use, and I will write you a suitable function you can call from C.
This sounds brilliant! I *knew* you would have a solution.
Just pass a parameter list and off it goes. I can see this being very useful for testing out cog code. I suppose like LMM there is no 496 long limit either?
Re possible differences to cog code, how do "wrlong" and "rdlong" work? In cog code that moves data to and from hub ram to cog ram but where does it end up using this inline code?
I'd like to use this to do some faster bitmap rendering of the fonts on the GUI. After lots of testing, I found the mouse works faster than I expected but the bitmap rendering is slower. The GUI project is going quite well - soon I can see a time when it should be possible to design a screen on a PC with buttons etc, then click a button and the IDE will write the C code to put all those buttons on the propeller screen.
As an aside, there is a huge thread running on another part of the forum talking about using GCC for the prop II. I don't want to post a dumb question on that thread but I can't help thinking 'why don't they just use Catalina?'
This is probably an obvious question but if I'm compiling Catalina C code for the C3 using one of the flash memory layouts will the "const" keyword in a data declaration cause the data to be placed in flash?
Just pass a parameter list and off it goes. I can see this being very useful for testing out cog code. I suppose like LMM there is no 496 long limit either?
You can easily pass up to 4 parameters provided they are all longs (or pointers, ints, shorts or chars). They are passed in registers r5,r4,r3,r2 with r2 as the rightmost parameter - so if you had a function called my_func that accepted 4 parameters, and you called my_func(a,b,c,d) then inside your function you would see:
Re possible differences to cog code, how do "wrlong" and "rdlong" work? In cog code that moves data to and from hub ram to cog ram but where does it end up using this inline code?
Well, it gets complex - in some modes a simple RDLONG (or WRLONG) makes no sense because your value is not even in Hub RAM - it may be in XMM RAM. But the following code shows how you can do a RDLONG from a specific data address (in this case the address labelled "my_address") that copes with either case:
jmp #LODA <---- load the address ...
long @my_address <---- ... into RI using a kernel primitive
#ifdef LARGE
jmp #RLNG <---- in LARGE mode we must use a kernel primitive ...
mov RI,BC <---- ... and manually move the result to RI
#else
rdlong RI, RI <---- in other modes, we can use a RDLONG
#endif
Whatever is loaded from "my_address" ends up in register RI. If you wanted to return this value from your function, you would simply move it to R0 before retrning. The code to do a WRLONG would look almost identical.
I'd like to use this to do some faster bitmap rendering of the fonts on the GUI. After lots of testing, I found the mouse works faster than I expected but the bitmap rendering is slower. The GUI project is going quite well - soon I can see a time when it should be possible to design a screen on a PC with buttons etc, then click a button and the IDE will write the C code to put all those buttons on the propeller screen.
As an aside, there is a huge thread running on another part of the forum talking about using GCC for the prop II. I don't want to post a dumb question on that thread but I can't help thinking 'why don't they just use Catalina?'
Well, some people think they need to be able to program the Propeller in C++, Objective-C, Fortran, Java and Ada. While I agree this would be nice (especially the Ada part!) it simply isn't practical.
But why should we deprive them of the fun of finding this out for themselves?
This is probably an obvious question but if I'm compiling Catalina C code for the C3 using one of the flash memory layouts will the "const" keyword in a data declaration cause the data to be placed in flash?
For example:
const int foo[] = { 1, 2, 3, 4 };
Will "foo" be placed in flash?
Hi David,
No, it is not a dumb question - and the answer may surprise you. The C const qualifier when applied to an object just means it is illegal to attempt to write to it. The compiler will check and generate a compilation error if it detects such an attempt - but there are cases where it will not be able to tell that this is the consequences of what you are doing (e.g. if you use a pointer). In such cases, the behaviour of the program is undefined. It does not mean foo will go into the const section - there is no requiredment that a C compiler even have a const section.
However it is a reasonable expectation (and would often be true) that if a platform has read-only RAM, that is where const variables would end up - I will think about whether I should make this true on plaforms (such as the C3) that have some kind of read-only RAM. It would be easy to do.
Thanks Ross. I think it would be very useful to put const data in flash on platforms that support flash like the C3. I believe the PIC C compiler does this and it helps a lot on processors where there is lots of flash space but hardly any RAM.
Well, some people think they need to be able to program the Propeller in C++, Objective-C, Fortran, Java and Ada. While I agree this would be nice (especially the Ada part!) it simply isn't practical.
But why should we deprive them of the fun of finding this out for themselves?
Ah good to hear. I feel more confident now talking about this - maybe I'll keep these comments to this thread rather than the GCC thread.
On the Parallax Semiconductor forum is a very interesting thread/application note regarding writing a GUI. In that document is a graphic that talks about the low level graphics and the higher level part of your program.
Now - I think that this is entirely possible to do with Catalina and to do without needing to go to object oriented languages.
Consider the actual code of the GUI driver I have written. It is already quite a large program, but no matter as catalina is having no trouble compiling it and the compilation is all but instant.
But for a new user wanting to print 'hello world', this code might be a bit daunting. I'm thinking of a little demo program that I think we could get working fairly soon. In the IDE you have a screen that replicates the propeller screen. You drag and drop a button and a textbox to that screen. Double click on the button and it opens up a C function called textbox1_click(). In that function you write a line of code - in pseudocode something like strcpy(textbox1_text[],"Hello"); (sorry that is probably not correct c syntax but you get the idea).
From that, I think the IDE has enough information to write C code and combine it with the GUI code to produce a single C program.
I'm still thinking through some of the fundamental concepts, but I think things like buttons become arrays of data and code. The array defines things like the text, position, active area for a mouseclick. Then there are events which are things like a button click.
If we wrote this in an "object oriented" language it might be button1.click() but I think with a very simple change to replace the . with an underscore, we can get the same functionality with button1_click().
And that means the code becomes C89 code which compiles with catalina.
So maybe there is no need for a C++/visual C compiler?
And as for the way you design the code - dragging buttons onto a screen and double clicking them to bring up code windows, does the design chain being talked about in the other thread have the flexibility to be able to do this?
My conclusion is that we can do cool things right now with Catalina, an open source IDE and the Prop I. And easily port it to the Prop II in the future.
I note your comment a few days ago about the catalina development taking several years. We have the tools so let's start doing cool things now!
Ah good to hear. I feel more confident now talking about this - maybe I'll keep these comments to this thread rather than the GCC thread.
I'm sure your comments would be welcome there. As a significant user of the only "C-like" language that can be used for building non-trivial applications on the Propeller, your comments should be more relevant there than many other people's.
Consider the actual code of the GUI driver I have written. It is already quite a large program, but no matter as catalina is having no trouble compiling it and the compilation is all but instant.
...
So maybe there is no need for a C++/visual C compiler?
You may be surprised to hear it, buy I disagree with this.
There is no doubt that for GUI programmming, an object orient language is absolutely perfect - in fact, this kind of problem was one of the key drivers for their development, and it is therefore no surprise that it is one of the things they are very, very good at.
A subset of C++ would enable you to get nearly all the benefits of OO programming - but the full-blown C++ language is not necessary. Or (as has been pointed out) even desirable for most hobbyist users - who will never need to use some of the more advanced features of the language they use.
My conclusion is that we can do cool things right now with Catalina, an open source IDE and the Prop I. And easily port it to the Prop II in the future.
Yes, I agree with this. My own view on this (which perhaps does not always come across well, because it is not simple to explain) is that C is necessary for the success of the Propeller, even though it is not a very good fit. C++, on the other hand, might be nice - but it will be an even worse fit, and it is also notnecessary for the success of the Propeller.
Over on the GCC thread there is a post from ctwardell
Memory Models:
1) Straight PASM in a COG, I know there isn't much space, but the ability to do driver level type programming in C would be nice.
This has got me thinking - could you write cog code in C?
I know 2k isn't much space, but then again, there is picaxe code in Basic that has to fit into 256 bytes, and there probably are arduino examples squeezing small programs into tiny code space. Consider
unsigned long a = 0;
unsigned long i;
for (i=0;i<10;i++)
{
a++;
}
That could almost translate 1:1 into pasm. The declarations end up at the end of the code instead of the beginning. You have a conditional jump in a loop, and an increment.
Even with an ultra tiny subset of C, ie the instructions that are very easy to translate to Pasm, one could do a lot.
Over on the GCC thread there is a post from ctwardell
This has got me thinking - could you write cog code in C?
...
Even with an ultra tiny subset of C, ie the instructions that are very easy to translate to Pasm, one could do a lot.
Is this a totally crazy idea?
No, it's not a crazy idea - converting something like the Tiny C Compiler (the original version of this compiler was only a few hundred lines long, and was capable of compiling a small subset of C) would be quite feasible.
Sounds good Ross. I'll ponder this some more. I'm thinking that rather than think about trying to translate C into Pasm, instead think of of Pasm instructions and how to translate into C. For instance, bit shifts in pasm, and their C equivalents. Add/subtract in pasm, inc, etc all translate nicely into C.
There are many solutions too. eg multiply - so easy to type * in C, but if you want speed, C rewards you by being a 'close to the metal' language. Just now I needed to multiply a number by 20 and to do it quickly. Replace that multiply with a bitshift 4 to the left added to a bitshift 2 to the left (n*20 = n*16+n*4) This takes things a step closer to a pasm solution in a similar number of lines of code to C.
Maybe some pasm instructions don't port over eg rdlong, but perhaps you put those in 'asm' blocks?
I shall ponder this some more.
Meanwhile, I was wondering if all the C experts would be able to kindly help me out with a big picture solution to a problem?
In designing the GUI I need objects like text boxes and radio boxes and buttons. Some have states that are relatively easy to describe, eg a button might have x,y width, height, text, status (pushed/not pushed). Others are a little more complex eg a richtext box with scroll bars, wrap/no wrap, font and the text itself.
It is this last part that has me a little stuck because the text might be 10 bytes, or it might be 50k. Do you reserve the most you might ever need, even though it might never be used? Or do you have a dynamic array that can be resized? (Can Catalina arrays be resized on the fly within code?).
I'm also pondering how the data is stored. Get inside vb.net and all the objects are stored as text files "width = x" etc. But if you want a fast search to see if a mouse click has occurred on a particular object, it makes more sense to store the width as a number rather than as a string. Many objects need both - numerical values and string values.
I'm not sure of the best sort of array structure to store this sort of information. A multidimensional array? A number of single dimensional arrays - some numerical with fixed size, some string with variable size, and link these together somehow.
I've even pondered a slightly crazy idea of a giant single array that describes everything on the screen - buttons, textboxes, etc. Objects in any order. A list at the beginning that lists where in the array each object is. Then at the beginning of each object, another list of the internal parts of the object. Searches would be fairly fast. Maybe set the text part to a default of 80 bytes and then if it gets bigger than this, go up in discrete intervals eg 256 bytes, which would minimise the number of times the bytes above that need to be shuffled up to make room.
In some ways a single array does simplify things. It becomes a state machine of sorts, eg the user clicks somewhere on the screen. Get the x,y, then search the list of objects, search each object to find if one has been clicked, then change the state of that object to 'clicked'. Maybe 3 binary decisions?
It might make things easier to pass data around within a huge C program as the only thing ever passed to each function is this giant object array.
In a way I can see why object oriented programming was invented, to hide this sort of stuff from the user. I'm sure it can be done in C89. I just need to work out what really is going on within memory when someone uses myobject.text = "massive string".
I'm putting together some Gadget Gangster boards and as mentioned in another thread, I'm looking at a way of doing fast downloads. I think all the hardware is going to be possible. Use two USB cables, one to program the propeller and one to go to the SD/USB adaptor board. You reset the propeller, send a tiny spin program that sets a latch pin high which changes the sd card from being connected to the propeller to being connected to the PC, via a second USB cable. The software downloads the new program (which will be only a few seconds), then resets the prop with another tiny spin program to set the sd back to being connected to the propeller. I'm hoping this will be under 10secs for any arbitrary length program.
My question is - how do I then run that program?
I know there is the catalyst program to move data from the serial port into external ram. In this situation though, the program is now a huge binary sitting on the sd card.
What I am thinking is that when a program is compiled, two files are created - myprog.c and myprog.bin The myprog.c is the huge file and this is on the sd card. The .bin program is a small spin program that you can run from Kyedos.
myprog.bin is a spin program and it uses Kye's FAT driver which I believe is faster than the catalina SD driver. It loads myprog.c from the sd card into external memory.
The question is - if I have a compiled XMM program loaded up into external memory and ready to go, what would I run to run this?
Comments
I've sent an email to mpark (author of homespun) asking if he has any suggestions. I'll update you when I get a response.
Ross.
Can you please try the attached catbind.exe (unzip it into your Catalina bin directory) and see if it solves your "cannot open temporary files" problem?
All I have done is make catalina use the same directory lcc uses for temporary files. You can override the default by setting the CATALINA_TEMPDIR environment variable.
Thanks,
Ross.
C:\Users\Public\storage\catalina\demos>catalina -lc hello_world.c Catalina Compiler 3.0 1 個のファイルを移動しました。 Homespun Spin Compiler 0.30 parsing C:\Users\Public\storage\catalina\target\lmm_default.spin parsing C:\Users\Public\storage\catalina\target\Catalina_Common.spin parsing C:\Users\Public\storage\catalina\target\Catalina.spin parsing C:\Users\Public\storage\catalina\target\Catalina_LMM.spin parsing C:\Users\Public\storage\catalina\target\Catalina_HMI_Plugin_HiRes_Tv.spin parsing C:\Users\Public\storage\catalina\target\Catalina_comboKeyboard.spin parsing C:\Users\Public\storage\catalina\target\Catalina_comboMouse.spin parsing C:\Users\Public\storage\catalina\target\Catalina_mouse.spin parsing C:\Users\Public\storage\catalina\target\Catalina_HiRes_TV_Text.spin parsing C:\Users\Public\storage\catalina\target\TV_Half_Height.spin parsing C:\Users\Public\storage\catalina\target\Catalina_CogCount.spin parsing C:\Users\Public\storage\catalina\target\Catalina_CogStore.spin compiling lmm_default.spin compiling Catalina.spin compiling Catalina_LMM.spin compiling Catalina_HMI_Plugin_HiRes_Tv.spin compiling Catalina_comboKeyboard.spin compiling Catalina_comboMouse.spin compiling Catalina_mouse.spin compiling Catalina_HiRes_TV_Text.spin compiling TV_Half_Height.spin compiling Catalina_CogCount.spin compiling Catalina_CogStore.spin compiling Catalina_Common.spin writing 24244 bytes to hello_world.binary code = 14132 bytes cnst = 232 bytes init = 156 bytes data = 172 bytes file = 24244 bytes C:\Users\Public\storage\catalina\demos>Very nice!I'll bundle up a patch release for Windows 7/Vista users - I'll just wait a day or two to see if Michael Park can find an answer for the wierd homespun problem.
Ross.
I was poking around your source code and I think all the memory code is in XMM.inc, is that right?
One problem I think I see is that your code works at the byte level, whereas my SRAM memory pretty much works in longs only. I.e., to write just a byte, I'd have to read it's long, change the byte, then write the byte back...
How much of an issue do you see that being?
PS: I think I see now that the way you might make money with this is with the "code optimizer". Is this something you sell now?
Hi Rayman,
Working at the long level rather than the byte level is not a problem if you use the caching version of the XMM driver. It accesses XMM RAM only at the long level, but allows users to access the RAM at the byte word,or long level - e.g. if you read a byte, the caching driver reads the whole long from XMM RAM (and caches it) but then just returns you the relevant byte of the long. If you write a byte, it is written to the appropriate byte of the cached long, and then sometime later that long will be written back to XMM RAM.
So just implement your XMM RAM using the caching driver and see how you go. See the file target/Catalina_SPI_Cache.spin (ignore the "SPI" reference - the cache was originally intended to support only SPI-based XMM RAM, but is now also used for all types of XMM RAM). From memory, on non-Flash platforms, this driver only requires four XMM routines (implemented in target/XMM.inc):
- XMM_Activate - activate XMM bus
- XMM_TriState - deactivate XMM bus
- XMM_ReadPage - read a page of data from XMM RAM
- XMM_WritePage - write a page of data to XMM RAM
Although nominally the XMM_ReadPage and XMM_WritePage deal in bytes, when used from the caching XMM driver they will only ever be asked to read/write a whole number of longs, and could be implemented that way.Ross.
P.S. Yes, I do sell the Optimizer - at a nominal cost of $US25 - but I certainly don't make much money out of it!
I seem to be running out of good reasons not to give this a try now...
Catalina C is leaping ahead here. Spin doesn't even have an external memory solution, and now Catalina has a number of solutions. I love being able to start a program that fits in the propeller memory, then when it runs out of room, change one parameter on the compile command line and then just keep coding with the code fitting into external memory.
Internal vs external vs caching vs non caching - the user doesn't really have to worry about that. Just write the C code and run it.
I am wondering if we need to think about some sort of code repository? I'm posting things on the forum but they can easily get lost over time. Some things are not really 'objects' as such, so don't really fit in the obex, though maybe this is the best place?
Or maybe send code to Ross and include it in the demo folder along with all the other demo code?
Naturally - what made you think this might not be the case? Everything you write in Catalina should be portable to all other platforms supported by Catalina, provided that platform has enough RAM (but of course, the performance between platforms may vary widely).
I'll give this some thought. I don't want to become a bottleneck on the process - perhaps another sourceforge repository might be the answer?
Ross.
P.S. Rayman:
Nah, more that I couldn't resist the free plug for Catalina!
Thinking about performance, in the GUI there are some things that work fast enough in C, like drawing a solid box, and there are some that are very close to being fast enough, like redrawing the mouse, and there are some that are too slow, like drawing fonts. But everything that is too slow can be moved over to a cog. The mouse would be a perfect example - just take an existing mouse obex that works in spin and C, and then add the code to draw and redraw the pixels for the pointer. So then any caching or SPI serial ram solution that ends up being too slow may not matter because the time critical things can always be moved into cogs.
And with the ability to load and reload cogs from XMM arrays, it is possible to break out of the 8 cog limitation.
I think the standard notation for byte is a capital B and bit is lower case b. I think you are using only the lower case b. I was a little confused at first...
One more technical question... I think I see how to use Flash and how to use SRAM. But, what do you do when you want to use both within the same program? I think you said in a PM that this was possible, but I don't see what to do to invoke that option...
Hi Rayman,
I'll check my documentation on the next release - thanks.
To use Flash and SRAM together required two new memory layouts. You will see these referred to internally as layouts 3 and 4 (on the command line, you can still invoke them using using -x3 and -x4, but now you would do it more intuitively as -D FLASH -D LARGE or -D FLASH -D SMALL, respectivey). The main difference is that when these layouts are used, Catalina knows to separate the read/write segments from the read/only segments. There are a couple of definitions in Catalina_Common.spin that tell Catalina where to locate these segments in the global memory map of the target platform. For example, for the C3 you will see:
This means that Catalina will compile the segments so that read/write segments start at $8000 and read/only segments start at $180000. Of course, the underlying XMM access code has to then map all XMM addresses into the appropriate SRAM or FLASH chip by decoding the address and then selecting the appropriate SPI device - so the first step in the process is to decide on your global memory map and allocate the memory space to your devices (so that this is easy to do given any XMM address).
Ross.
It appears that flash is completely erased ever time the loader is used.
But, I was thinking about implementing a basic file system in flash...
How hard do you see it to have a loader create a new flash file and then execute it?
Hi Rayman,
You can do that - just don't tell Catalina to use the Flash as XMM. For instance, on the C3 if you compiled with -x5 (or -D LARGE) then Catalina will use the SRAM as XMM RAM but not use the FLASH at all. Then you can write a plugin of your own that uses the FLASH independently of Catalina (just be aware that if it shares control lines with the SRAM then you can only use the Flash when Catalina actually requests to do so).
Even better - if you made the interface to your plugin compatible with the one implemented in Catalina_SD_Plugin.spin (which implements very simple sector based read/write services), then you get FAT32/FAT16 file system support for your Flash RAM for free! The only thing you would need outside this is something like a "format" utility that wrote an "image" to the FLASH that makes it look like a (blank) formatted SD card of the appropriate size.
Ross.
@Rayman, having a wear-leveled QuadSPI flash file-system would be a nice asset
If the pins are different then the code is quite easy.
If the pins are shared, I've just finished writing that sort of code (see some earlier posts) and there is code to put catalina to sleep while a cog takes over shared pins, and then wakes up catalina when it is finished.
This might seem a bit of a dumb question, but can Catalina do inline pasm code in XMM mode?
If so, what does this end up looking like? Do you just add pasm instructions in the middle of C code?
I'm thinking of instances where short fragments of pasm are going to be quicker to run inline from XMM than they are to be run by loading up a cog, running it and then unloading the cog.
Hello, Dr_A
The short answer is "yes". But I do it in a slightly devious way (would you expect anything else with Catalina?)...
I have resisted adding the asm keyword (or function) to Catalina because it is non-ANSI, compiler-dependent, makes the program confusing and harder to maintain, and immediately makes your entire program non-portable.
Instead, I support assembly language functions that can be called from C. For example, to invoke the PASM cogid instruction with another compiler, you might use an asm function to just poke the instruction into the middle of your C code. But for the reasons I mentioned above, I regard this as bad practice.
Instead, to invoke cogid, I provide a _cogid() function that you can call from C like any other function. Here is the actual code for the function: You can do the same. Just use the above as a template for "wrapping" the instruction you want to execute (change the name of the function, of course!). Any parameters you pass will be passed in register r2, and any value you want to return should be returned in register r0.
"Aha!" (I hear you say) "this is very inefficient! I now have the overhead of a function call and a return statement just to get my cogid! At least three instructions (more in fact) instead of just one!"
But ... (and here's the clever bit!) ... if you use the Catalina Optimizer, any calls to this function will be automatically inlined. The procedure call and function return overheads will be optimized away, and the instruction will be inserted in your code and executed exactly as if you had used an asm statement - without littering your lovely C program with ugly and non-portable constructs!
This is in fact the main reason I wrote the Optimizer in the first place.
If you need help, just let me know what instruction you want to use, and I will write you a suitable function you can call from C.
Ross.
Just pass a parameter list and off it goes. I can see this being very useful for testing out cog code. I suppose like LMM there is no 496 long limit either?
Re possible differences to cog code, how do "wrlong" and "rdlong" work? In cog code that moves data to and from hub ram to cog ram but where does it end up using this inline code?
I'd like to use this to do some faster bitmap rendering of the fonts on the GUI. After lots of testing, I found the mouse works faster than I expected but the bitmap rendering is slower. The GUI project is going quite well - soon I can see a time when it should be possible to design a screen on a PC with buttons etc, then click a button and the IDE will write the C code to put all those buttons on the propeller screen.
As an aside, there is a huge thread running on another part of the forum talking about using GCC for the prop II. I don't want to post a dumb question on that thread but I can't help thinking 'why don't they just use Catalina?'
I don't think it's a dumb question at all.
For example:
const int foo[] = { 1, 2, 3, 4 };Will "foo" be placed in flash?
c in r3
b in r4
a in r5
Well, it gets complex - in some modes a simple RDLONG (or WRLONG) makes no sense because your value is not even in Hub RAM - it may be in XMM RAM. But the following code shows how you can do a RDLONG from a specific data address (in this case the address labelled "my_address") that copes with either case:
Whatever is loaded from "my_address" ends up in register RI. If you wanted to return this value from your function, you would simply move it to R0 before retrning. The code to do a WRLONG would look almost identical.
I look forward to it!
Well, some people think they need to be able to program the Propeller in C++, Objective-C, Fortran, Java and Ada. While I agree this would be nice (especially the Ada part!) it simply isn't practical.
But why should we deprive them of the fun of finding this out for themselves?
Ross.
Hi David,
No, it is not a dumb question - and the answer may surprise you. The C const qualifier when applied to an object just means it is illegal to attempt to write to it. The compiler will check and generate a compilation error if it detects such an attempt - but there are cases where it will not be able to tell that this is the consequences of what you are doing (e.g. if you use a pointer). In such cases, the behaviour of the program is undefined. It does not mean foo will go into the const section - there is no requiredment that a C compiler even have a const section.
However it is a reasonable expectation (and would often be true) that if a platform has read-only RAM, that is where const variables would end up - I will think about whether I should make this true on plaforms (such as the C3) that have some kind of read-only RAM. It would be easy to do.
Ross.
Ah good to hear. I feel more confident now talking about this - maybe I'll keep these comments to this thread rather than the GCC thread.
On the Parallax Semiconductor forum is a very interesting thread/application note regarding writing a GUI. In that document is a graphic that talks about the low level graphics and the higher level part of your program.
Now - I think that this is entirely possible to do with Catalina and to do without needing to go to object oriented languages.
Consider the actual code of the GUI driver I have written. It is already quite a large program, but no matter as catalina is having no trouble compiling it and the compilation is all but instant.
But for a new user wanting to print 'hello world', this code might be a bit daunting. I'm thinking of a little demo program that I think we could get working fairly soon. In the IDE you have a screen that replicates the propeller screen. You drag and drop a button and a textbox to that screen. Double click on the button and it opens up a C function called textbox1_click(). In that function you write a line of code - in pseudocode something like strcpy(textbox1_text[],"Hello"); (sorry that is probably not correct c syntax but you get the idea).
From that, I think the IDE has enough information to write C code and combine it with the GUI code to produce a single C program.
I'm still thinking through some of the fundamental concepts, but I think things like buttons become arrays of data and code. The array defines things like the text, position, active area for a mouseclick. Then there are events which are things like a button click.
If we wrote this in an "object oriented" language it might be button1.click() but I think with a very simple change to replace the . with an underscore, we can get the same functionality with button1_click().
And that means the code becomes C89 code which compiles with catalina.
So maybe there is no need for a C++/visual C compiler?
And as for the way you design the code - dragging buttons onto a screen and double clicking them to bring up code windows, does the design chain being talked about in the other thread have the flexibility to be able to do this?
My conclusion is that we can do cool things right now with Catalina, an open source IDE and the Prop I. And easily port it to the Prop II in the future.
I note your comment a few days ago about the catalina development taking several years. We have the tools so let's start doing cool things now!
There is no doubt that for GUI programmming, an object orient language is absolutely perfect - in fact, this kind of problem was one of the key drivers for their development, and it is therefore no surprise that it is one of the things they are very, very good at.
A subset of C++ would enable you to get nearly all the benefits of OO programming - but the full-blown C++ language is not necessary. Or (as has been pointed out) even desirable for most hobbyist users - who will never need to use some of the more advanced features of the language they use.
This is the lesson of the Arduino.
Yes, I agree with this. My own view on this (which perhaps does not always come across well, because it is not simple to explain) is that C is necessary for the success of the Propeller, even though it is not a very good fit. C++, on the other hand, might be nice - but it will be an even worse fit, and it is also not necessary for the success of the Propeller.
Ross.
This has got me thinking - could you write cog code in C?
I know 2k isn't much space, but then again, there is picaxe code in Basic that has to fit into 256 bytes, and there probably are arduino examples squeezing small programs into tiny code space. Consider
unsigned long a = 0; unsigned long i; for (i=0;i<10;i++) { a++; }That could almost translate 1:1 into pasm. The declarations end up at the end of the code instead of the beginning. You have a conditional jump in a loop, and an increment.
Even with an ultra tiny subset of C, ie the instructions that are very easy to translate to Pasm, one could do a lot.
Is this a totally crazy idea?
No, it's not a crazy idea - converting something like the Tiny C Compiler (the original version of this compiler was only a few hundred lines long, and was capable of compiling a small subset of C) would be quite feasible.
Ross.
There are many solutions too. eg multiply - so easy to type * in C, but if you want speed, C rewards you by being a 'close to the metal' language. Just now I needed to multiply a number by 20 and to do it quickly. Replace that multiply with a bitshift 4 to the left added to a bitshift 2 to the left (n*20 = n*16+n*4) This takes things a step closer to a pasm solution in a similar number of lines of code to C.
Maybe some pasm instructions don't port over eg rdlong, but perhaps you put those in 'asm' blocks?
I shall ponder this some more.
Meanwhile, I was wondering if all the C experts would be able to kindly help me out with a big picture solution to a problem?
In designing the GUI I need objects like text boxes and radio boxes and buttons. Some have states that are relatively easy to describe, eg a button might have x,y width, height, text, status (pushed/not pushed). Others are a little more complex eg a richtext box with scroll bars, wrap/no wrap, font and the text itself.
It is this last part that has me a little stuck because the text might be 10 bytes, or it might be 50k. Do you reserve the most you might ever need, even though it might never be used? Or do you have a dynamic array that can be resized? (Can Catalina arrays be resized on the fly within code?).
I'm also pondering how the data is stored. Get inside vb.net and all the objects are stored as text files "width = x" etc. But if you want a fast search to see if a mouse click has occurred on a particular object, it makes more sense to store the width as a number rather than as a string. Many objects need both - numerical values and string values.
I'm not sure of the best sort of array structure to store this sort of information. A multidimensional array? A number of single dimensional arrays - some numerical with fixed size, some string with variable size, and link these together somehow.
I've even pondered a slightly crazy idea of a giant single array that describes everything on the screen - buttons, textboxes, etc. Objects in any order. A list at the beginning that lists where in the array each object is. Then at the beginning of each object, another list of the internal parts of the object. Searches would be fairly fast. Maybe set the text part to a default of 80 bytes and then if it gets bigger than this, go up in discrete intervals eg 256 bytes, which would minimise the number of times the bytes above that need to be shuffled up to make room.
In some ways a single array does simplify things. It becomes a state machine of sorts, eg the user clicks somewhere on the screen. Get the x,y, then search the list of objects, search each object to find if one has been clicked, then change the state of that object to 'clicked'. Maybe 3 binary decisions?
It might make things easier to pass data around within a huge C program as the only thing ever passed to each function is this giant object array.
In a way I can see why object oriented programming was invented, to hide this sort of stuff from the user. I'm sure it can be done in C89. I just need to work out what really is going on within memory when someone uses myobject.text = "massive string".
I'm putting together some Gadget Gangster boards and as mentioned in another thread, I'm looking at a way of doing fast downloads. I think all the hardware is going to be possible. Use two USB cables, one to program the propeller and one to go to the SD/USB adaptor board. You reset the propeller, send a tiny spin program that sets a latch pin high which changes the sd card from being connected to the propeller to being connected to the PC, via a second USB cable. The software downloads the new program (which will be only a few seconds), then resets the prop with another tiny spin program to set the sd back to being connected to the propeller. I'm hoping this will be under 10secs for any arbitrary length program.
My question is - how do I then run that program?
I know there is the catalyst program to move data from the serial port into external ram. In this situation though, the program is now a huge binary sitting on the sd card.
What I am thinking is that when a program is compiled, two files are created - myprog.c and myprog.bin The myprog.c is the huge file and this is on the sd card. The .bin program is a small spin program that you can run from Kyedos.
myprog.bin is a spin program and it uses Kye's FAT driver which I believe is faster than the catalina SD driver. It loads myprog.c from the sd card into external memory.
The question is - if I have a compiled XMM program loaded up into external memory and ready to go, what would I run to run this?