View previous topic :: View next topic |
Author |
Message |
lightydo
Joined: 15 Jun 2014 Posts: 8
|
Protothreads on CCS |
Posted: Tue Jun 17, 2014 2:12 am |
|
|
Has anyone successfully ported Protothreads to CCS?
http://dunkels.com/adam/pt/
I am always getting : Error#51 A numeric expression must appear here
on PT_WAIT_UNTIL(pt, ..); _________________ Daniel. |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Wed Jun 18, 2014 4:48 am |
|
|
An interesting concept to create threads in processors with little memory.
I didn't know this library and only had a very quick look but I already spotted one problem: the use of short integers. In CCS a short is defined as 1 bit while the programmers of this library assumed it to be 8 bit or larger.
This can be fixed by replacing all 'short' types by standard 'int' or use the #type directive to change the size of 'short' in the CCS compiler.
Another big risk is how this compiler depends on the C preprocessor. Lets put it nicely, but the preprocessor in the CCS compiler is not exactly following the standards... |
|
|
lightydo
Joined: 15 Jun 2014 Posts: 8
|
|
Posted: Wed Jun 18, 2014 6:24 am |
|
|
ckielstra wrote: | In CCS a short is defined as 1 bit while the programmers of this library assumed it to be 8 bit or larger.
This can be fixed by replacing all 'short' types by standard 'int' or use the #type directive to change the size of 'short' in the CCS compiler.
|
Right.
ckielstra wrote: |
Another big risk is how this compiler depends on the C preprocessor. Lets put it nicely, but the preprocessor in the CCS compiler is not exactly following the standards... |
That was my guess as well...I like it that saves me some of the work but compliance is not it's strong suit.. _________________ Daniel. |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1345
|
|
Posted: Fri Jun 20, 2014 7:26 am |
|
|
I found the protothreads site pretty interesting. One thing I noted while perusing the actual code is that in addition to the switch statement implementation (I don't know how well CCS conforms to this "clever" use of legal C), they had an additional label address based version for the GCC compiler.
CCS has a compiler specific label address functionality as well, and at quick glance it looks like it could be an option (see label_address and goto_address in the manual).
I only bring this up because the switch statement implementation has a specific downside of not being able to use "exiting" calls in switch statements since the case it generates would be added to that switch statement instead of the protothread's switch statement. An addressing method would work around that requirement, but it may (haven't put any time into this to check) take more ROM than the switch method. Also, the label address method would make the protothread variable int32 size on some of the later chips (the label_address entry in the manual discusses this).
Just some things to consider. I really enjoyed the explanation the site gave on how the switch statement method worked...very clever. |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1345
|
|
Posted: Fri Feb 20, 2015 1:48 pm |
|
|
This is a bit of a necro, but wanted to provide an update.
I've played around with protothreads for a while and have determined that the CCS compiler doesn't correctly implement the standard switch() local continuations used by the default protothreads implementation. The error the OP got comes from the "case blah:" line expanded out from the PT_WAIT_UNTIL(pt, ..) macro under certain situations (just inside simple for loop). I am using v5.025.
That said, the goto_address() and label_address() methods do provide a working alternative method. You'll need to update the LC_ macros to use these methods instead.
I have what I believe is a working port (with some modifications), but I haven't had time to test it. The general gist:
1. changed variable types to conform to CCS types
2. used goto_addresss and lable_address methods in the LC_ macros
3. remove do{ /*stuff*/}while(0) entries due to warnings
In addition to that, I changed:
1. ability to use reference parameters vs pointers (by way of #define). Each method can give small code coverage depending on your style. By reference is the default since it tends to produce small code for threads (you don't typically call the same thread function multiple times...but if you do, you can swap to pointers).
2. I changed how PT_END() and PT_EXIT() work slightly. In the provided form, they reset the thread to the beginning. I prefer to have the thread not reset, so I changed some lines to make that functionality.
3. I removed PT_THREAD() and replaced it with a return type pt_ret_t instead. I don't know why, but I found it abrasive.
I have 100% tested it yet, but once I feel comfy, I'll post it in the code forums.
EDIT: Tested it enough to feel comfy with it. Posted it in the Code Library forum. Search for "protothreads" |
|
|
|