1) As one of the Propeller's USPs is software peripherals then the GSL ought to contain objects that simulate those peripherals that are normally present in other chips; objects that exploit unique features of the Prop (eg VGA); objects that interface to common external hardware (eg PS2 keyboards) and nothing else.
2) If it's possible to make, for instance, a 4-channel UART then there's no point in having a single channel UART as long as resource usage is the same.
3) Every object in the GSL ought to conform to a common API.
4) Every part of the API ought to conform to a common naming convention with similar function 'bits' in identical positions, eg the enable bit for a UART ought to be called UART_EN and be in, for example, bit 31. The enable bit for an I2C peripheral ought to be called I2C_EN and also be in bit 31. Likewise 'control registers' ought to have a common naming convention.
What we need is a "project management" system. I've looked at Trac before, but there's many out there. There are three main components to a good system:
- revision control (for source)
- bug tracking
- wiki (documentation)
Many project management systems are open source, so you can host the server on your own hardware. Then you don't have to give complete control to Google or anybody else. And I agree that there should be different levels of users: a distinction must be made between who can commit and who cannot, but everybody should be able to post bugs and improvements for review.
I'd be willing to contribute and help out on maintaining such a system.
SRLM, we agree, I was merely suggesting Google Code to get GSL out in a timely fashion and figure out exactly what needs to go into a future version of OBEX that can serve this purpose.
One of the problems we have to be careful of is allowing many to apply updates.
IMHO a Gold Standard is a group of smaller and approved objects that should be...
Stable and works as described
Well documented as far as usage goes (not necessarily with detailed beginners comments as to how the instructions work)
So, for FullDuplexSerial, the mods to fix the timing issues, add buffer length definition in CON, single port. I would like to see IN & OUT methods call RX & TX methods so that it can be easily substitued by/with a VGA or TV or LCD module and Keyboard module, and that the only change to user calling code would be with the START method.
I would also like to see the same methods in a Gold Standard 4 port serial object, text only VGA, TV and LCD object, and for a Keyboard (and perhaps mouse???) object. Also I would like to see a Gold Standard fsrw (SD card driver) - this is going to take some discussions as there are a few things that need consensus and this is not going to be easy as we all have differing requirements. I am all for a simple basic fast pasm driver (that tristates pins when required - for sharing the SPI pins).
I don't think any of these should be on Google etc, but should be on a Parallax Gold Obex site.
However, perhaps before most objects (some critical ones named above perhaps should bypass this procedure and just be discussed on the forum first) become Gold Standard candidates, they could spend a few months on Google to get to a stable object.
At the same time leave Obex as is. It is actually quite simple to use, and if everyone who fixed or minorly modified an object kept the base name and added and "_xxxxxx) extension to it, then it would appear in obex underneath the original.
Some new objects could be placed on Google or other (I cannot help here because I mainly do not use these) and a posting on the forum so we know where it is and can offer / fix / add to it.
One of the problems of virtually allowing a "free-for-all" update is you may compile for a particular version, and then it changes and you recompiled code breaks. This I guess is a reason the Obex works so well, because any changes are there because they are an improvement, but they do not usually affect the original posting.
This is manageable within the context of Google Code and can be ported to a Parallax hosted framework in the future.
Since I have raised my hand, I would be willing to be one of the project leaders to see this forward. I would want to see at least 2 other community members be part of the leader group. Off the top of my head, I could nominate a few others for project leaders and a handful more as lieutenants.
You're hired. I've got a post in the works to start this in a new thread. By this afternoon we should be able to proceed.
The only difference I see right now is the extent to which we use Google Code. I'd like to see it become a one-stop for more of our code base than GSL (AppNotes, etc.). We can figure out how all of this plays together based on what the leaders find appropriate (you, and a few others), as well as the order of improvement.
You're hired. I've got a post in the works to start this in a new thread. By this afternoon we should be able to proceed.
The only difference I see right now is the extent to which we use Google Code. I'd like to see it become a one-stop for more of our code base than GSL (AppNotes, etc.). We can figure out how all of this plays together based on what the leaders find appropriate (you, and a few others), as well as the order of improvement.
Thank you very much -
Ken Gracey
This sounds like a great plan! I'm looking forward to a whole lot of gold standard objects! Maybe I'll even try writing one myself. :-)
Comments
2) If it's possible to make, for instance, a 4-channel UART then there's no point in having a single channel UART as long as resource usage is the same.
3) Every object in the GSL ought to conform to a common API.
4) Every part of the API ought to conform to a common naming convention with similar function 'bits' in identical positions, eg the enable bit for a UART ought to be called UART_EN and be in, for example, bit 31. The enable bit for an I2C peripheral ought to be called I2C_EN and also be in bit 31. Likewise 'control registers' ought to have a common naming convention.
- revision control (for source)
- bug tracking
- wiki (documentation)
Many project management systems are open source, so you can host the server on your own hardware. Then you don't have to give complete control to Google or anybody else. And I agree that there should be different levels of users: a distinction must be made between who can commit and who cannot, but everybody should be able to post bugs and improvements for review.
I'd be willing to contribute and help out on maintaining such a system.
IMHO a Gold Standard is a group of smaller and approved objects that should be...
- Stable and works as described
- Well documented as far as usage goes (not necessarily with detailed beginners comments as to how the instructions work)
So, for FullDuplexSerial, the mods to fix the timing issues, add buffer length definition in CON, single port. I would like to see IN & OUT methods call RX & TX methods so that it can be easily substitued by/with a VGA or TV or LCD module and Keyboard module, and that the only change to user calling code would be with the START method.I would also like to see the same methods in a Gold Standard 4 port serial object, text only VGA, TV and LCD object, and for a Keyboard (and perhaps mouse???) object. Also I would like to see a Gold Standard fsrw (SD card driver) - this is going to take some discussions as there are a few things that need consensus and this is not going to be easy as we all have differing requirements. I am all for a simple basic fast pasm driver (that tristates pins when required - for sharing the SPI pins).
I don't think any of these should be on Google etc, but should be on a Parallax Gold Obex site.
However, perhaps before most objects (some critical ones named above perhaps should bypass this procedure and just be discussed on the forum first) become Gold Standard candidates, they could spend a few months on Google to get to a stable object.
At the same time leave Obex as is. It is actually quite simple to use, and if everyone who fixed or minorly modified an object kept the base name and added and "_xxxxxx) extension to it, then it would appear in obex underneath the original.
Some new objects could be placed on Google or other (I cannot help here because I mainly do not use these) and a posting on the forum so we know where it is and can offer / fix / add to it.
One of the problems of virtually allowing a "free-for-all" update is you may compile for a particular version, and then it changes and you recompiled code breaks. This I guess is a reason the Obex works so well, because any changes are there because they are an improvement, but they do not usually affect the original posting.
Just my 2c
You're hired. I've got a post in the works to start this in a new thread. By this afternoon we should be able to proceed.
The only difference I see right now is the extent to which we use Google Code. I'd like to see it become a one-stop for more of our code base than GSL (AppNotes, etc.). We can figure out how all of this plays together based on what the leaders find appropriate (you, and a few others), as well as the order of improvement.
Thank you very much -
Ken Gracey
SVN and TRAC are really easy to install on any server (not just linux also windows). And Parallax has the control and not google.
Please KEN look at TRAC (link at SLRMs Post)
Enjoy!
Mike