Yes, Catalina has a very rich set, and more get added regularly. But the point is not the C wrapper, as much as making the PASM component common to any language (not just Spin and C). That way, the Spin version can stay in the OBEX, and all high level languages can make use of any of them - they don't have to (as we both do now) create and maintain our own slightly modified copies.
With the inclusion of a simple preprocessor in Spin (courtesy of openspin), this should now be even easier.
Ross.
I suppose it ought to be possible to use the Catalina wrappers in PropGCC as well. I guess I should try it. We could benefit from your work in porting OBEX objects.
I suppose it ought to be possible to use the Catalina wrappers in PropGCC as well. I guess I should try it. We could benefit from your work in porting OBEX objects.
I don't think this is feasible, since the Catalina wrappers usually involve the registry (which you don't have). Even if the actual communication technique is a simple shared memory buffer, in Catalina the address of that buffer is found by interrogating the registry (usually only once, on package initialization). Once you have that address, the C code to actually use it can be a fairly trivial line-by-line translation of the Spin methods to C functions.
I don't know what mechanism propGCC uses to do the same job - do you have fixed memory map somewhere? Does this have to be updated every time you add a new device?
I don't think this is feasible, since the Catalina wrappers usually involve the registry (which you don't have). Even if the actual communication technique is a simple shared memory buffer, in Catalina the address of that buffer is found by interrogating the registry (usually only once, on package initialization). Once you have that address, the C code to actually use it can be a fairly trivial line-by-line translation of the Spin methods to C functions.
I don't know what mechanism propGCC uses to do the same job - do you have fixed memory map somewhere? Does this have to be updated every time you add a new device?
Ross.
I guess the difference is that you load the COG PASM drivers before you start the C code. Is that correct? We typically just load the COG drivers as part of the initialization of the C wrappers. This is the way the Spin code typically works as well. Given that we don't need a registry. I knew you used the registry for HMI drivers but I guess I didn't know you used it for every driver.
I guess the difference is that you load the COG PASM drivers before you start the C code. Is that correct? We typically just load the COG drivers as part of the initialization of the C wrappers. This is the way the Spin code typically works as well. Given that we don't need a registry. I knew you used the registry for HMI drivers but I guess I didn't know you used it for every driver.
I use the registry for every cog - driver, library or kernel, and whether I load them from Spin during run time initialization or later from C.
I use the registry for every cog - driver, library or kernel, and whether I load them from Spin during run time initialization or later from C.
Ross.
I guess consistency is good. So are you saying you have to modify OBEX code to include code to maintain the registry before you can use it with Catalina?
So are you saying you have to modify OBEX code to include code to maintain the registry before you can use it with Catalina?
Not necessarily. If the PASM code is already "well behaved" (according to Catalina's definition) and uses a well-specified mechanism to communicate (e.e. via a buffer that is passed to it on initialization of the PASM) then Catalina can usually do all the necessary registry stuff itself, without changing the PASM - essentially, just by discarding the existing Spin initialization code and methods and replacing them with either new Spin code or equivalent C code (this depends on whether I need to make the plugin dynamically reloadable or not).
However, many OBEX objects are not "well-behaved" (e.g they start another cog, or expect to be able to write to fixed locations in Hub RAM, or Spin VAR or DAT segments). This is not the fault of the original author, of course - in most cases they had no idea that anyone would eventually want to use them from anything but Spin! Such objects would generally require some minor modifications.
Or you can do what we currently do, which is maintain multiple versions of essentially the same object - one in the OBEX, the others outside it.
Not necessarily. If the PASM code is already "well behaved" (according to Catalina's definition) and uses a well-specified mechanism to communicate (e.e. via a buffer that is passed to it on initialization of the PASM) then Catalina can usually do all the necessary registry stuff itself, without changing the PASM - essentially, just by discarding the existing Spin initialization code and methods and replacing them with either new Spin code or equivalent C code (this depends on whether I need to make the plugin dynamically reloadable or not).
However, many OBEX objects are not "well-behaved" (e.g they start another cog, or expect to be able to write to fixed locations in Hub RAM, or Spin VAR or DAT segments). This is not the fault of the original author, of course - in most cases they had no idea that anyone would eventually want to use them from anything but Spin! Such objects would generally require some minor modifications.
Or you can do what we currently do, which is maintain multiple versions of essentially the same object - one in the OBEX, the others outside it.
Ross.
So I guess it's this registry idea that is the main difference between the Catalina runtime environment and what we've setup for PropGCC. I guess that makes it difficult to share much of anything without adding a bunch of ifdefs to the code.
So I guess it's this registry idea that is the main difference between the Catalina runtime environment and what we've setup for PropGCC. I guess that makes it difficult to share much of anything without adding a bunch of ifdefs to the code.
Or PropGCC could adopt Catalina's registry!
Just think how simple that would make everyone's life!
You don't - but the original author of this thread does. As do many other people. Isn't that the point?
Ross.
You can already use "well behaved" OBEX objects with PropGCC. What we're lacking is decent documention about how to do that. To be honest, I was hoping that Parallax would help with that. They're known for their great documentation. I guess they're too busy creating the SimpleIDE/SimpleLibrary educational material though.
You can already use "well behaved" OBEX objects with PropGCC. What we're lacking is decent documention about how to do that. To be honest, I was hoping that Parallax would help with that. They're known for their great documentation. I guess they're too busy creating the SimpleIDE/SimpleLibrary educational material though.
So can Catalina. So the answer to the original poster is that the world is all good provided the only OBEX objects he wants to use are "well behaved" (by somebody's definition). And if it is not, then tough luck.
We are just going round in circles now, and as usual we come to the conclusion that the users who keep raising these annoying questions don't actually matter enough to provide them even the hope of an eventual answer.
We are just going round in circles now, and as usual we come to the conclusion that the users who keep raising these annoying questions don't actually matter enough to provide them even the hope of an eventual answer.
*sigh*
I don't believe that users needs don't matter. I'm just tired of putting a lot of effort into things people think they want but then when get them they still aren't satisfied. I guess I need to concentrate on making things that I want and not worry about whether anyone else cares or not.
I don't believe that users needs don't matter. I'm just tired of putting a lot of effort into things people think they want but then when get them they still aren't satisfied. I guess I need to concentrate on making things that I want and not worry about whether anyone else cares or not.
If Parallax is going to rely solely for their offical dev software on unpaid labor, I guess that's the best we can hope for!
-Phil
I think we're now seeing why other companies charge for their dev tools. It's expensive to develop them. Parallax has not entirely relied on unpaid labor though. I believe they have invested a fair amount of money on PropGCC and I've been paid for a little of the work I've done. It isn't fair to say they've entirely relied on unpaid labor. It's just that developing a toolchain is a big job. Ross has done an amazing job over the years developing Catalina. I hope a lot of people have donated money in support of it!
Ross has done an amazing job over the years developing Catalina. I hope a lot of people have donated money in support of it!
Thanks.
You can't charge for LCC-derived compilers under the terms of their "open source" license (they have another commercial license, that I believe ImageCraft may have purchased).
I used to charge for the Catalina Optimizer, but in the end that became more trouble than it was worth, so I stopped. It made me enough money to buy more Propeller boards, but that's about it ... so in the end I guess Parallax made a profit from that, not me!
You can't charge for LCC-derived compilers under the terms of their "open source" license (they have another commercial license, that I believe ImageCraft may have purchased)..
That's interesting. I didn't know that ImageCraft had used LCC as the basis for their product.
Comments
I don't think this is feasible, since the Catalina wrappers usually involve the registry (which you don't have). Even if the actual communication technique is a simple shared memory buffer, in Catalina the address of that buffer is found by interrogating the registry (usually only once, on package initialization). Once you have that address, the C code to actually use it can be a fairly trivial line-by-line translation of the Spin methods to C functions.
I don't know what mechanism propGCC uses to do the same job - do you have fixed memory map somewhere? Does this have to be updated every time you add a new device?
Ross.
I use the registry for every cog - driver, library or kernel, and whether I load them from Spin during run time initialization or later from C.
Ross.
Not necessarily. If the PASM code is already "well behaved" (according to Catalina's definition) and uses a well-specified mechanism to communicate (e.e. via a buffer that is passed to it on initialization of the PASM) then Catalina can usually do all the necessary registry stuff itself, without changing the PASM - essentially, just by discarding the existing Spin initialization code and methods and replacing them with either new Spin code or equivalent C code (this depends on whether I need to make the plugin dynamically reloadable or not).
However, many OBEX objects are not "well-behaved" (e.g they start another cog, or expect to be able to write to fixed locations in Hub RAM, or Spin VAR or DAT segments). This is not the fault of the original author, of course - in most cases they had no idea that anyone would eventually want to use them from anything but Spin! Such objects would generally require some minor modifications.
Or you can do what we currently do, which is maintain multiple versions of essentially the same object - one in the OBEX, the others outside it.
Ross.
Or PropGCC could adopt Catalina's registry!
Just think how simple that would make everyone's life!
Ross.
You don't - but the original author of this thread does. As do many other people. Isn't that the point?
Ross.
Very funny.
If you are feeling the lack, try contributing something to the discussion yourself.
So can Catalina. So the answer to the original poster is that the world is all good provided the only OBEX objects he wants to use are "well behaved" (by somebody's definition). And if it is not, then tough luck.
We are just going round in circles now, and as usual we come to the conclusion that the users who keep raising these annoying questions don't actually matter enough to provide them even the hope of an eventual answer.
*sigh*
Amen to that.
-Phil
-Phil
Thanks.
You can't charge for LCC-derived compilers under the terms of their "open source" license (they have another commercial license, that I believe ImageCraft may have purchased).
I used to charge for the Catalina Optimizer, but in the end that became more trouble than it was worth, so I stopped. It made me enough money to buy more Propeller boards, but that's about it ... so in the end I guess Parallax made a profit from that, not me!
Hmmm ... I wonder if I am the only unpaid labour in the "getting C onto the Propeller" effort!
Ross.
And don't forget Zog:)