Ross: I mentioned my version because I have found Catalina cannot take the data from the buffer quick enough with only 16bytes of buffering.
Here is FDX_rr004 with 256 byte buffers (only a single change to set the size in the CON section - 256 is the max size!). Just noticed I did this in AUg 2009. Attachment not found.
Cluso,
Catalina 3.6 doesn't yet include your amended Full Duplex Serial driver. I plan to post a new version of the Full Duplex Serial plugin (which can be simply copied over the existing one) for those that want to use your version - I just have to find the time to do so!
Ross: Here is the Catalina_FullDuplexSerial_rr004.spin
It has been set for 256byte buffers (change in CON) and should be copied into the subdirectory "target" and replaces Catalina_FullDplexSerial.spin
I have not yet tested, but as you can see, the changes are minimal. There are 3 changes in spin to use BUFMSK and 3 changes in pasm to use BUFSIZ & BUFMSK plus the CON changes. Catalina_FullDuplexSerial_rr004.spin
Ross: Here is the Catalina_FullDuplexSerial_rr004.spin
It has been set for 256byte buffers (change in CON) and should be copied into the subdirectory "target" and replaces Catalina_FullDplexSerial.spin
I have not yet tested, but as you can see, the changes are minimal. There are 3 changes in spin to use BUFMSK and 3 changes in pasm to use BUFSIZ & BUFMSK plus the CON changes. Catalina_FullDuplexSerial_rr004.spin
Thanks, Cluso. I'll do some testing on the weekend.
I just posted an update to one of the Catalina demo programs (small_lisp.c) - to fix a bug I introduced by messing about with the original. See the second post in this thread for more details.
The 32 and 64 bit Unix packages for Catalina 3.6 originally uploaded to SourceForge were missing some files. I have corrected this and uploaded them again. If you have downloaded and installed them over an existing version of Catalina then everything may appear to work correctly, but in fact you will have a mix of old and new files - I recommend you download and install again.
If you are not sure, check the size of the files you downloaded - the incorrect ones are about 15Mb, whereas the correct ones are about 40Mb.
This does not affect Windows users - The Windows "one touch" installer version contains all the correct files.
I have just emailed all purchasers of the Catalina Optimizer a copy of version 3.6. The previous version of the Optimizer (3.1) will not work with the latest version of Catalina due to changes in the way C programs are compiled (i.e. in the user's current working directory, and no longer in the Catalina target directory).
If you have paid for a copy of the Catalina Optimizer but have not yet received version 3.6 (some of the email addresses I have appear to be no longer valid) then please send me an email or post here.
Ray Rodrick released a modified version of "Full Duplex Serial" driver that uses 256 byte buffers (the original used 16, and these were too small for some applications).
Attached is a small package that adds this driver as a new Catalina plugin. It provides a neat self-contained example of how to turn an OBEX driver into a plugin that can then be used from both Catalina and Spin.
i'v been running catalina on ubuntu 10.04. I have been experimenting with ubuntu 12.04, but I can't get payload to upload.
(bst works, though i'm having trouble with its terminal) Here is what payload -d says
payload -d button
Catalina Payload 3.6
diagnostic level 1
arg: button
executable name = payload
Loading Propeller binary button.binary
File size = 6052
baudrate = 115200
timeout = 250
sync timeout = 100
reset delay = 0
interfile delay = 100
Trying /dev/ttyS0 ... unable to read portsettings : Input/output error
error 1 opening port 0Trying /dev/ttyS15 ... unable to read portsettings : Input/output error
error 1 opening port 15
.....
Trying /dev/ttyUSB0 ... opened port 16
Error: lfsr data incorrect at 250 - received 0 (expected 254)
Error: lfsr data incorrect at 251 - received 0 (expected 255)
Error: lfsr data incorrect at 252 - received 0 (expected 254)
Error: lfsr data incorrect at 253 - received 0 (expected 254)
Error: lfsr data incorrect at 255 - received 255 (expected 254)
Error: lfsr data incorrect at 256 - received 254 (expected 255)
...
actually, if i pull the usb and start afresh, this is what i get at the end of payload
Trying /dev/ttyS14 ... unable to read portsettings : Input/output error
error 1 opening port 14
Trying /dev/ttyS15 ... unable to read portsettings : Input/output error
error 1 opening port 15
Trying /dev/ttyUSB0 ... opened port 16
Using Propeller (version 1) on port /dev/ttyUSB0 for download
Downloading normal binary file button
Error: No response received
actually, if i pull the usb and start afresh, this is what i get at the end of payload
Hi manitou,
I have had it working on Ubuntu, but I don't recall what version - I'll check when I get home. However, on all versions of Linux the problems are usually timing related. Two things to try immediately:
increase the general payload read timeout (using -t)
use the Linux "nice" command to increase the priiority of payload.
For example, to do both of these in one command, try:
Ross:
Firstly, thanks for all your help offline with the plugins. (for others - I am not a C programmer, so often I just have to try things without understanding why).
This latest release has a much improved and simplifiedPLUGIN use. Some of my problems have also been that I used the CLOCK plugin as a base when really it was not what I needed after all, particularly as Ross has added the EXTRAS file. Anyway, I thought I would ask this question publicly because I thought others might be interested in the answer. Once I have everything simplified and understood properly, I will document the plugin use here (basically for my app although I cannot publish the actual code).
Currently I have the catalina spin code performing the xxx.start method (xxx.spin being my plugin code) and have the block allocation (I need a block of hub ram to be allocated for passing parameters and buffers between C and my pasm routines) being done in this routine first. The documents recommend this be done in the xxx.setup method. However, I couldn't work out how to get this xxx.setup method to be called - Ross told me how (forget atm)
But thinking further...
Is there any reason that I cannot allocate the BUFFER (block of hub ram) in the xxx.start method just prior to loading the pasm code with cognew?
What I would do (simplified) is this...
In SPIN xxx.START method...
Allocate a BUFFER of 16 longs (needs to be 64 in bytes for catalina - trap!) - could be any size >= 2 longs
Clear the BUFFER (using LONGFILL)
Perform COGNEW with PAR = BUFFER_POINTER (address i.e. a pointer)
COG+1 is returned if successful from the COGNEW command
REGISTER the COG (required by Catalina) with the REGISTRY entry set to (TYPE << 24 | BUFFER_POINTER)
Now what we have is a simple PASM driver that has in PAR just the BUFFER_POINTER (address in hub).
Catalina can still perform any standard short or long REQUESTS but it will now use the first 2 longs of the hub BUFFER for this instead of the usual REQUEST buffer (2 longs that catalina reserves for each cog/registry entry).
Catalina will not know the difference because it gets the REQUEST address from the REGISTRY lower 24 bits.
PASM is happy because it now does not need to perform any registration (saves space and complexity and allows simpler objects and perhaps standard objects as far as pasm is concerned). It just has a buffer, of which the first 2 longs can be used if catalina needs to perform requests of the pasm. If not, then these are free for other use.
Catalina can easily find the BUFFER address by locating the REQUEST block address, and then use this in any way the user requires.
Ross, does this make sense? Is there any problems you see with this way? Seems to me to be a simpler way, and we have the best of both worlds.
Currently I have the catalina spin code performing the xxx.start method (xxx.spin being my plugin code) and have the block allocation (I need a block of hub ram to be allocated for passing parameters and buffers between C and my pasm routines) being done in this routine first. The documents recommend this be done in the xxx.setup method. However, I couldn't work out how to get this xxx.setup method to be called - Ross told me how (forget atm)
It was because you based your new plugin on the existing CLOCK plugin. I frigged around with the CLOCK plugin several times in various versions of Catalina and it has ended up being slightly non-standard. For instance - there was no Setup method called during the initialization of that particular plugin.
Adding new plugins to the Extras.spin file is the right way to go.
Is there any reason that I cannot allocate the BUFFER (block of hub ram) in the xxx.start method just prior to loading the pasm code with cognew?
No. I had originally tried to standardize this so that all plugin setup (such as buffer allocation) happens in the Setup method, then each plugin is started in the Start method - but I break this rule myself regularly
In SPIN xxx.START method...
Allocate a BUFFER of 16 longs (needs to be 64 in bytes for catalina - trap!) - could be any size >= 2 longs
Clear the BUFFER (using LONGFILL)
Perform COGNEW with PAR = BUFFER_POINTER (address i.e. a pointer)
COG+1 is returned if successful from the COGNEW command
REGISTER the COG (required by Catalina) with the REGISTRY entry set to (TYPE << 24 | BUFFER_POINTER)
Now what we have is a simple PASM driver that has in PAR just the BUFFER_POINTER (address in hub).
Catalina can still perform any standard short or long REQUESTS but it will now use the first 2 longs of the hub BUFFER for this instead of the usual REQUEST buffer (2 longs that catalina reserves for each cog/registry entry).
Catalina will not know the difference because it gets the REQUEST address from the REGISTRY lower 24 bits.
PASM is happy because it now does not need to perform any registration (saves space and complexity and allows simpler objects and perhaps standard objects as far as pasm is concerned). It just has a buffer, of which the first 2 longs can be used if catalina needs to perform requests of the pasm. If not, then these are free for other use.
Catalina can easily find the BUFFER address by locating the REQUEST block address, and then use this in any way the user requires.
Ross, does this make sense? Is there any problems you see with this way? Seems to me to be a simpler way, and we have the best of both worlds.
Yes, you can do this. A lot of plugins (especially those based on existing OBEX objects) don't know about the registry at all, and instead use a preallocated block of Hub RAM like this. Catalina's cog housekeeping functions assume you will "register" such plugins (e.g. this will prevent Catalina reusing the cog because it thinks it is currently unused), but other than that Catalina won't care. You don't need to reserve the first two longs if the plugin is not intended to respond to plugin requests, and you don't need to record the memory block in the registry. In fact, in general it better if you don't, since if you want to add dynamic memory management over the top of this scheme (which means you may re-use that memory block) you will have to remember to replace this memory block with a new 2-long one in case this cog is later used for another plugin. Of course, if your plugin will never be dynamically loaded or unloaded, this does not matter.
In hindsight, I perhaps should have reserved a bit or two in the registry to indicate these things - i.e. whether the plugin responds to requests, whether it can be unloaded and reloaded, and whether it has messed with the original memory block allocation. I'll have a think about some of these for a future version.
Thanks Ross.
Yes, I understand if catalina is not using requests then the first 2 longs are not required to be reserved. I will record the memory block in the registry because it makes it easy to use the standard catalina library to get to the buffer. And I will register the object in spin. This object is not dynamically loadable.
Reloadable plugins are a problem when it comes to buffers because it may not be possible to return the block to the heap, so to speak, because we are not using chaining. So, it would be just lost to the ether. This is a problem we are just going to have to wear as I don't see a dynamic heapas being a requirement. At least for the time being anyway.
In hindsight, I perhaps should have reserved a bit or two in the registry to indicate these things - i.e. whether the plugin responds to requests, whether it can be unloaded and reloaded, and whether it has messed with the original memory block allocation. I'll have a think about some of these for a future version.
IMHO I think this would be too much overhead for a small micro.
I am still of the opinion that the registry and request block should be 4 longs (x8), permanently allocated. This would waste 8 longs by this would be recovered by simplifying the access to the request block (saves the instructions to calculate where it is from the request base). This would not impact my case above because the lower 24 bits of the registry would only be used if a block were allocated, zero otherwise. And catalina would always use the next 2 longs for requests, with a third optional long available. In fact, it could simplify the whole request structure by using registry+1 (32bits, normally using only the lower 8/9) for the request code, registry+2 (32bits) for parameter (no short or long requests needed any more) and response code, registry+3 (32bits) for optional 2nd parameter and 2nd response code. Could even use registry+1 extra bits for something.
Of course, the plugin could use these 3 longs for a different purpose if requests were not implemented.
I am still of the opinion that the registry and request block should be 4 longs (x8), permanently allocated. This would waste 8 longs by this would be recovered by simplifying the access to the request block (saves the instructions to calculate where it is from the request base). This would not impact my case above because the lower 24 bits of the registry would only be used if a block were allocated, zero otherwise. And catalina would always use the next 2 longs for requests, with a third optional long available. In fact, it could simplify the whole request structure by using registry+1 (32bits, normally using only the lower 8/9) for the request code, registry+2 (32bits) for parameter (no short or long requests needed any more) and response code, registry+3 (32bits) for optional 2nd parameter and 2nd response code. Could even use registry+1 extra bits for something.
Of course, the plugin could use these 3 longs for a different purpose if requests were not implemented.
Hi Cluso,
As you know, Catalina's current solution allows for any size comms block, but Catalina always pre-allocates a comms block of 2 longs for each plugin. I did this because this is the most commonly required size. Some plugins need less than this, but none currently needs more - so any extra longs allowed in your scheme would never get used anyway. Also, a plugin is free to completely ignore the pre-allocated comms block if it doesn't need it, and it is also free to allocate a larger one if it needs that instead.
In hindsight, perhaps I shouldn't have pre-allocated any default comms blocks, and simply had each plugin allocate whatever it needed for itself during initialization. A bit of code duplication, but such things are typically done in the Spin plugin initialization code - which is deleted before the C code begins executing anyway. So the overhead would be effectively nil.
I am really happy the way it is. Plugins are way easier in 3.6 and existing objects are easier to interface with too.
Don't get rid of the request blocks. It is only 8*2*4 = 64 bytes. I am sure they will be required for some things anyway, and the allocation of them would consume something anyway.
Comments
Cluso,
Catalina 3.6 doesn't yet include your amended Full Duplex Serial driver. I plan to post a new version of the Full Duplex Serial plugin (which can be simply copied over the existing one) for those that want to use your version - I just have to find the time to do so!
Ross.
It has been set for 256byte buffers (change in CON) and should be copied into the subdirectory "target" and replaces Catalina_FullDplexSerial.spin
I have not yet tested, but as you can see, the changes are minimal. There are 3 changes in spin to use BUFMSK and 3 changes in pasm to use BUFSIZ & BUFMSK plus the CON changes.
Catalina_FullDuplexSerial_rr004.spin
Thanks, Cluso. I'll do some testing on the weekend.
Ross.
I just posted an update to one of the Catalina demo programs (small_lisp.c) - to fix a bug I introduced by messing about with the original. See the second post in this thread for more details.
Ross.
The 32 and 64 bit Unix packages for Catalina 3.6 originally uploaded to SourceForge were missing some files. I have corrected this and uploaded them again. If you have downloaded and installed them over an existing version of Catalina then everything may appear to work correctly, but in fact you will have a mix of old and new files - I recommend you download and install again.
If you are not sure, check the size of the files you downloaded - the incorrect ones are about 15Mb, whereas the correct ones are about 40Mb.
This does not affect Windows users - The Windows "one touch" installer version contains all the correct files.
Ross.
I have just emailed all purchasers of the Catalina Optimizer a copy of version 3.6. The previous version of the Optimizer (3.1) will not work with the latest version of Catalina due to changes in the way C programs are compiled (i.e. in the user's current working directory, and no longer in the Catalina target directory).
If you have paid for a copy of the Catalina Optimizer but have not yet received version 3.6 (some of the email addresses I have appear to be no longer valid) then please send me an email or post here.
Thanks,
Ross.
Ray Rodrick released a modified version of "Full Duplex Serial" driver that uses 256 byte buffers (the original used 16, and these were too small for some applications).
Attached is a small package that adds this driver as a new Catalina plugin. It provides a neat self-contained example of how to turn an OBEX driver into a plugin that can then be used from both Catalina and Spin.
Here is the package: tty256.zip
To use it, do the following
See the README.tty256 file for more details.
Ross.
Thanks, manitou
I'll include it in the demo folder of the next release of Catalina.
Ross.
(bst works, though i'm having trouble with its terminal) Here is what payload -d says
what should i try ??
Hi manitou,
I have had it working on Ubuntu, but I don't recall what version - I'll check when I get home. However, on all versions of Linux the problems are usually timing related. Two things to try immediately:
- increase the general payload read timeout (using -t)
- use the Linux "nice" command to increase the priiority of payload.
For example, to do both of these in one command, try:Note that you may need to be root to use "nice".
Ross.
OK, -t 1000 seemed to solve things (didn't need nice)
thanks
Firstly, thanks for all your help offline with the plugins. (for others - I am not a C programmer, so often I just have to try things without understanding why).
This latest release has a much improved and simplifiedPLUGIN use. Some of my problems have also been that I used the CLOCK plugin as a base when really it was not what I needed after all, particularly as Ross has added the EXTRAS file. Anyway, I thought I would ask this question publicly because I thought others might be interested in the answer. Once I have everything simplified and understood properly, I will document the plugin use here (basically for my app although I cannot publish the actual code).
Currently I have the catalina spin code performing the xxx.start method (xxx.spin being my plugin code) and have the block allocation (I need a block of hub ram to be allocated for passing parameters and buffers between C and my pasm routines) being done in this routine first. The documents recommend this be done in the xxx.setup method. However, I couldn't work out how to get this xxx.setup method to be called - Ross told me how (forget atm)
But thinking further...
Is there any reason that I cannot allocate the BUFFER (block of hub ram) in the xxx.start method just prior to loading the pasm code with cognew?
What I would do (simplified) is this...
In SPIN xxx.START method... Allocate a BUFFER of 16 longs (needs to be 64 in bytes for catalina - trap!) - could be any size >= 2 longs Clear the BUFFER (using LONGFILL) Perform COGNEW with PAR = BUFFER_POINTER (address i.e. a pointer) COG+1 is returned if successful from the COGNEW command REGISTER the COG (required by Catalina) with the REGISTRY entry set to (TYPE << 24 | BUFFER_POINTER)Now what we have is a simple PASM driver that has in PAR just the BUFFER_POINTER (address in hub).
Catalina can still perform any standard short or long REQUESTS but it will now use the first 2 longs of the hub BUFFER for this instead of the usual REQUEST buffer (2 longs that catalina reserves for each cog/registry entry).
Catalina will not know the difference because it gets the REQUEST address from the REGISTRY lower 24 bits.
PASM is happy because it now does not need to perform any registration (saves space and complexity and allows simpler objects and perhaps standard objects as far as pasm is concerned). It just has a buffer, of which the first 2 longs can be used if catalina needs to perform requests of the pasm. If not, then these are free for other use.
Catalina can easily find the BUFFER address by locating the REQUEST block address, and then use this in any way the user requires.
Ross, does this make sense? Is there any problems you see with this way? Seems to me to be a simpler way, and we have the best of both worlds.
Adding new plugins to the Extras.spin file is the right way to go. No. I had originally tried to standardize this so that all plugin setup (such as buffer allocation) happens in the Setup method, then each plugin is started in the Start method - but I break this rule myself regularly
Yes, you can do this. A lot of plugins (especially those based on existing OBEX objects) don't know about the registry at all, and instead use a preallocated block of Hub RAM like this. Catalina's cog housekeeping functions assume you will "register" such plugins (e.g. this will prevent Catalina reusing the cog because it thinks it is currently unused), but other than that Catalina won't care. You don't need to reserve the first two longs if the plugin is not intended to respond to plugin requests, and you don't need to record the memory block in the registry. In fact, in general it better if you don't, since if you want to add dynamic memory management over the top of this scheme (which means you may re-use that memory block) you will have to remember to replace this memory block with a new 2-long one in case this cog is later used for another plugin. Of course, if your plugin will never be dynamically loaded or unloaded, this does not matter.
In hindsight, I perhaps should have reserved a bit or two in the registry to indicate these things - i.e. whether the plugin responds to requests, whether it can be unloaded and reloaded, and whether it has messed with the original memory block allocation. I'll have a think about some of these for a future version.
Ross.
Yes, I understand if catalina is not using requests then the first 2 longs are not required to be reserved. I will record the memory block in the registry because it makes it easy to use the standard catalina library to get to the buffer. And I will register the object in spin. This object is not dynamically loadable.
Reloadable plugins are a problem when it comes to buffers because it may not be possible to return the block to the heap, so to speak, because we are not using chaining. So, it would be just lost to the ether. This is a problem we are just going to have to wear as I don't see a dynamic heapas being a requirement. At least for the time being anyway.
IMHO I think this would be too much overhead for a small micro.
I am still of the opinion that the registry and request block should be 4 longs (x8), permanently allocated. This would waste 8 longs by this would be recovered by simplifying the access to the request block (saves the instructions to calculate where it is from the request base). This would not impact my case above because the lower 24 bits of the registry would only be used if a block were allocated, zero otherwise. And catalina would always use the next 2 longs for requests, with a third optional long available. In fact, it could simplify the whole request structure by using registry+1 (32bits, normally using only the lower 8/9) for the request code, registry+2 (32bits) for parameter (no short or long requests needed any more) and response code, registry+3 (32bits) for optional 2nd parameter and 2nd response code. Could even use registry+1 extra bits for something.
Of course, the plugin could use these 3 longs for a different purpose if requests were not implemented.
Hi Cluso,
As you know, Catalina's current solution allows for any size comms block, but Catalina always pre-allocates a comms block of 2 longs for each plugin. I did this because this is the most commonly required size. Some plugins need less than this, but none currently needs more - so any extra longs allowed in your scheme would never get used anyway. Also, a plugin is free to completely ignore the pre-allocated comms block if it doesn't need it, and it is also free to allocate a larger one if it needs that instead.
In hindsight, perhaps I shouldn't have pre-allocated any default comms blocks, and simply had each plugin allocate whatever it needed for itself during initialization. A bit of code duplication, but such things are typically done in the Spin plugin initialization code - which is deleted before the C code begins executing anyway. So the overhead would be effectively nil.
Anyone else have an opinion one way or the other?
Ross.
Don't get rid of the request blocks. It is only 8*2*4 = 64 bytes. I am sure they will be required for some things anyway, and the allocation of them would consume something anyway.