I've been following this thread for the past couple of weeks, and it doesn't seem to be any closer to a Gold Standard process than when it started. I really don't understand Prof_Braino's posts. They just seem to overcomplicate the issue. Is this thread trying to circumvent the process that is already in place on the parallaxsemiconductor.com site? It seems that the process that Parallax has already posted is fine. They've posted the requirements for a Gold Standard object, and a list of objects that they've like to see. Anybody can earn $50 credit for each Gold Standard object just by guilding an existing object that's on the list and submitting it to Parallax for approval. I don't understand the problem that's trying to be solved in this thread
That thread talks about a "gold standard obex", and I'm guessing the intent is to be in addition to the "Gold Standard Objects" mentioned on the parallaxsemiconductor.com site.
I was looking at it this way:
1) The "Gold Standard Objects" on the parallaxsemiconductor.com site are objects commisioned by Parallax and intended to act as "soft peripherals" to be used in place of the hard wired peripherals on most other mcu's.
2) The "Gold Standard Obex" would be an improvement on the current obex; a user would be able to have more confidence in the quality of the objects posted there.
I haven't seen it specifically stated as a step, but it seems part of the gold standard process is to throw rocks at the couple of people that are actually trying to put together an example of what they are talking about.
I've been following this thread for the past couple of weeks, and it doesn't seem to be any closer to a Gold Standard process than when it started. I really don't understand Prof_Braino's posts. They just seem to overcomplicate the issue. Is this thread trying to circumvent the process that is already in place on the parallaxsemiconductor.com site? It seems that the process that Parallax has already posted is fine. They've posted the requirements for a Gold Standard object, and a list of objects that they've like to see. Anybody can earn $50 credit for each Gold Standard object just by guilding an existing object that's on the list and submitting it to Parallax for approval. I don't understand the problem that's trying to be solved in this thread
The problem that Prof Braino is trying to solve with process is that the current Gold Standard documents simply specify what an piece of code looks like, without guaranteeing it's function (italics for keywords, not shouting...).
My guess for the long discussion is two different perspectives on what the Gold Standard should be:
a) A collection of objects that are "well documented" and follow a consistent API
OR
b) First and foremost, a collection of objects that have proof that they actually work completely, along with a).
My attempt at an analogy: scientific papers.
a) The papers must look the same: an abstract, some research sections, and a conclusion. No references required. Must be in two column format, with 14 point headings.
b) all of a), but you must cite your sources so that future researchers can replicate and check your results.
ps to all who read this thread: I would email Parallax before working on one of those $50 objects. I think we have moved beyond those standards listed there.
I've been following this thread for the past couple of weeks, and it doesn't seem to be any closer to a Gold Standard process than when it started. I really don't understand Prof_Braino's posts. They just seem to overcomplicate the issue.
These steps, when completed, will CLARIFY. The net effect will be significantly less complicated than the current "undefined". (Or not, you can decide when the time comes).
Is this thread trying to circumvent the process that is already in place on the parallaxsemiconductor.com site? .... I don't understand the problem that's trying to be solved in this thread
The issue with the OBEX was and is that most of the code is unreliable, we often can't get it to work and we don't really know what its supposed to be doing. The Gold Standard Specification adds to the definition of "good code" by addressing code formatting. But the same issue that exists in the OBEX still is still problematic: How do we define "good" beyond formatting? We can find MANY examples of properly formatted code that just plain don't work. This process is an attempt to address the issues beyond formatting. Please suspend judgement till we have results.
Doug, sorry if my questions came across as judgement. I'm just trying to understand what you're trying to accomplish since Parallax already has a Gold Standard process. Maybe my bias toward less control and more freedom was obvious in my questions. I like the OBEX the way it is. I think if we apply a "process" to submitting objects it will inhibit people from contributing.
I don't think (I hope it's not) intended as a process to submit things. I see it as a process to elevate submitted objects to the Gold Standard. The message should be feel free to submit and share and through your own nomination or through a crowd sourced nomination, Objects begin to percolate to the top as Gold Standard objects. The author would update, modify and be coached and mentored as needed to package their object as a Gold Standard Object.
The other side of this is having Parallax specify a basic set of Gold Standard objects to either create internally or commission for creation.
The message should be feel free to submit and share and through your own nomination or through a crowd sourced nomination, Objects begin to percolate to the top as Gold Standard objects. The author would update, modify and be coached and mentored as needed to package their object as a Gold Standard Object.
This is my idea. Gerrit, which I set up, is very good for coaching/mentoring, which is why I picked it out and set it up for this purpose. I was hoping, in creating this thread, that I'd get a couple of submissions, and people helping to mentor the authors until they did reach such a standard.
0) Establish Gold Standard API and coding standards for languages in the Gold Standard libraries
0a) identify needed Gold Standard objects on Parallax's product roadmaps
1) does the code under submission perform a needed Gold Standard function (is there a better candidate out there?) (has the function already been added to the Gold Standard collection?) (is it something that shoudl be a Gold Standard item?)
2) Has it been written to Gold standard coding and API standards?
3) Does it have supporting documentation (internal documentation to code source PLUS an app note)
4) peer review and requirements checklist, mentoring, coaching, debating (lather, rinse, repeat)
5) update standards documents if needed (need to keep backward compatibility if at all possible)
6) Publish as Gold Standard with all documentation
7) identify next most needed object in Parallax's product roadmap
8) return to 1
Nice list RIck. Thanks for taking the time to codify it.
AFAIK regarding the current situation with respect to your list ....
There is a parallax SPIN/PASM standard document already ... do we get to ratify it? At the moment we go with what has been written.
Presumably we need an initial list and volunteers. Also a set of objects from the Parallax demos would be modified for standard compliance, or other important modules. There are also candidates that work better than some parallax modules for example. One issue that comes up is that there may be better modules/objects for doing a job, but another choice may be easier to use - how does someone deal with that. I don't think anyone should exclude seemingly redundant code. All it has to do is meet the requirements.
Do we need a full app-note for all objects? A good demo is important for sure, but a fully developed app-note?
Need to have initial requirements listed and ratified before attempting a serious review of a project even as a test. Your item 0 says that SPIN/PASM is the only candidate since that's all we got. There needs to be a methodology in place to change requirements if necessary after the initial cut (item 5?). Is SPIN sufficient for self-documenting? Seems like that doc effort from Phil would need to be included.
The idea of different certification levels as someone mentioned before appeals to me.
0) Wood - very malleable, does not conduct very well, may not last very long if neglected, but has promise
1) Bronze - good attempt, but some things are missing
2) Silver - almost perfect
3) Gold - perfectly acceptable
Part of the problem is direction. Most of the suggestions are good, but are out of sequence. Some of the suggestions are still valid, but contradict this experiment.
Again, if you don't want to try this, please don't actively try to derail it. This is only an experiment and will have no impact on you if it doesn't work.
If it does work, you still don't have to do anything different.
Advanced engineers tend to get resentful of any improvements or changes that may affect they the the work. This experiment is not for you, and will not affect you.
The question remains open: what is a reference that tells us how serial is supposed to work?
Fair enough, I'll just sit back and watch the process unfold (not that I was trying to derail it).
We'll go discuss the API in jazzed's thread and the C/C++ standards document someplace else so when the process is ready, it can be wrapped around the other standards. (unless that's not how it works)
Instead of sitting back, please share you favorite reference for serial.
I realize this is a very simple function and everybody already knows it by heart, but some of us have not written a serial driver before, and can't tell what about circuitsoft's driver is working and what is not working, because we can't tell exactly what its supposed to do.
The first rule of thumb (in this process) is "If you can't say what you want, you won't get it". In this case, we need a reference to compare to, that we all agree is sufficient.
Would it be suffient to reference the UART documentation of a PIC or AVR with a hardware UART, at least for now.
I was thinking one prop should talk to another prop, or one cog should talk another cog. This would be simpler, and allow anyone with a prop to run the test, and not require the additional expense of new hardware.
I was thinking that the serial we want is before the UART, the PIC or AVR might be limited to the hardware. This is what made me think the wiki article would be more appropriate, but usually wiki is not what we want to reference.
Either way would be ok, as long as we agree that it is what we can measure to.
I was thinking one prop should talk to another prop, or one cog should talk another cog. This would be simpler, and allow anyone with a prop to run the test, and not require the additional expense of new hardware.
I was thinking that the serial we want is before the UART, the PIC or AVR might be limited to the hardware. This is what made me think the wiki article would be more appropriate, but usually wiki is not what we want to reference.
Either way would be ok, as long as we agree that it is what we can measure to.
The issue with the prop talking to itself is it only proves we have a protocol that can talk to itself and not necessarily the standard to be implemented.
Communicating with the FTDI chip which is on most prop dev boards would be nice because it lets you use the PST for simple testing, you could also communicate using the prop plug.
The issue with the prop talking to itself is it only proves we have a protocol that can talk to itself and not necessarily the standard to be implemented.
Communicating with the FTDI chip which is on most prop dev boards would be nice because it lets you use the PST for simple testing, you could also communicate using the prop plug.
This is a good illustration of why we want to start with a simple function for this experiment.
Now we are starting to see that "serial" is not just serial communication, but also might include specific hardware (and additional protocol).
Can we assume that props these days include the FTDI chip? I do have equipment for com1 serial port, but these days UI seem to favor quick start or protoboard with plug plug.
Also, when I do anything serial, I test with termaterm on the PC talking to the prop (pin 30 & 31), and then have the prop talking on another pair of pins to something else.
Do you guys do the same, or do you re-use 30 & 31 for serial testing after loading code?
Can we plan to test (whatever we come up with) using pin 30 and 31 to talk from the PC to the prop [via FTDI chip], and use another set of pins to talk to some other serial device?
The RS232 standard was maintained by the EIA but they disbanded in 2011. The standard has a new custodian in some other outfit. They seem to want you to pay to read the thing.
Anyway it matters not as any serial object for the Prop is probably not implementing that standard as such. So if you want to cite a reference for bit sequences,timing etc wikipedia is probably as good as any.
.
You guys are bouncing around between 40,000 foot and detailed development levels. This cause scope creep and a moving target. If we go down this path and standardize serial testing, what's next? I2C, SPI, DHCP...
The developer is responsible for verifying the code works. This is usually done with a demo or unit test results. If code is submitted of Gold and it does not have a demo and cannot be proven to work then it should not be considered. IMO, this experiment already failed because we're messing with code that the submitter admits does not work!
Keep in mind "Gold" needs to mean something, if we just want "Gold" to be something where everyone gets a trophy then there isn't much point to doing it.
You can write perfectly formatted code that incorrectly implements a protocol.
For example we could write an async serial receiver that samples data very late in the bit frame, it would work most of the time, but would likely fail on occasion.
Ideally for things like an async serial receiver the sampling method and timing would be well described and the timing verified.
Mainly that we are not anywhere near looking at code yet.
We are trying to refine the statement that "this will do serial" down to a bunch of things that we can test.
In order to test something, we first have to say, for our purposes"serial" means "as defined by "X".
Even if the code were "complete", we need to state what it does (conforms to EIT 232 or what ever) and how we are going to test it.
In the course of establishing those, the author would undoubtedly find items that weren't covered but are going to be tested, and make the necessary changes. Circuitsoft's code is in the same position. It's "Not working" because we haven't defined "working" yet, regardless of the state of any code.
This isn't even a statement of what this code does. This is a statement of what we want/expect this code to do.
The process as I understand it now (I'm really trying to be good and positive and tolerant and accepting)
Someone starts here:
We need an <insert language here> object to do this function according to this specification, data sheet or other set of requirements.
Here is the coding standard for <insert language here>
{...writing code is left as an exercise for someone...}
Author completess the code and enters as "Wood" in OBEX
Cdde is either crowd-source nominated to be Goldified or self-nominated
Here is the code in <insert language here> that should perform this function according to this specification. Test and demo wrappers are provided.
//SQE Questions and review process - what we are discussing in this thread, I believe
Bless this object for it is GOLDEN or iterate process with author and reviewers until it is golden, or hobbyist author loses interest in project or finds something more fun and distracting
Golden Object author is satisfied and basking in success moves on to the next object
If so, are you referring to my enumerated list just above in post #147 or my original list way back in post #119 ?
I'm really just trying to understand this and follow along with P_Braino's lead - I just need to rephrase and/or clarify things and consolidate multiple posts to try and keep myself straight.
I don't want to dictate, lead or document this process, I'm just trying to understand like everyone else.
It look slike the AVR is a particular implementation, and is limited at 9600 baud, the microUart data sheet contains a lot implementation specific material that might be beyond the scope of the serial driver itself. Do we need to include this and/or limit to including the hardware uart or specifying a particular uart?
I'm not the expert, and circuitsoft is doing the work; does any of these cover all of what we need without going beyond? Which of these (or which combination) covers what we need, with a lot of extra?
Remember, we want to avoid making implementation decisions at this point; we want to define the "what" and not touch the "how" till later, as much as possible.
Comments
I think this thread was a result of this one:
http://forums.parallax.com/showthread.php/144536-Whatever-happened-to-the-quot-Gold-Standard-quot?highlight=gold+standard
That thread talks about a "gold standard obex", and I'm guessing the intent is to be in addition to the "Gold Standard Objects" mentioned on the parallaxsemiconductor.com site.
I was looking at it this way:
1) The "Gold Standard Objects" on the parallaxsemiconductor.com site are objects commisioned by Parallax and intended to act as "soft peripherals" to be used in place of the hard wired peripherals on most other mcu's.
2) The "Gold Standard Obex" would be an improvement on the current obex; a user would be able to have more confidence in the quality of the objects posted there.
C.W.
I can easily add a step if you like!
It doesn't seem to be so much of a step in and of itself, rather something that can be done before during and after each step.
C.W.
The problem that Prof Braino is trying to solve with process is that the current Gold Standard documents simply specify what an piece of code looks like, without guaranteeing it's function (italics for keywords, not shouting...).
My guess for the long discussion is two different perspectives on what the Gold Standard should be:
a) A collection of objects that are "well documented" and follow a consistent API
OR
b) First and foremost, a collection of objects that have proof that they actually work completely, along with a).
My attempt at an analogy: scientific papers.
a) The papers must look the same: an abstract, some research sections, and a conclusion. No references required. Must be in two column format, with 14 point headings.
b) all of a), but you must cite your sources so that future researchers can replicate and check your results.
ps to all who read this thread: I would email Parallax before working on one of those $50 objects. I think we have moved beyond those standards listed there.
These steps, when completed, will CLARIFY. The net effect will be significantly less complicated than the current "undefined". (Or not, you can decide when the time comes).
The issue with the OBEX was and is that most of the code is unreliable, we often can't get it to work and we don't really know what its supposed to be doing. The Gold Standard Specification adds to the definition of "good code" by addressing code formatting. But the same issue that exists in the OBEX still is still problematic: How do we define "good" beyond formatting? We can find MANY examples of properly formatted code that just plain don't work. This process is an attempt to address the issues beyond formatting. Please suspend judgement till we have results.
The other side of this is having Parallax specify a basic set of Gold Standard objects to either create internally or commission for creation.
Don't anyone stop submitting and sharing!
Nice list RIck. Thanks for taking the time to codify it.
AFAIK regarding the current situation with respect to your list ....
There is a parallax SPIN/PASM standard document already ... do we get to ratify it? At the moment we go with what has been written.
Presumably we need an initial list and volunteers. Also a set of objects from the Parallax demos would be modified for standard compliance, or other important modules. There are also candidates that work better than some parallax modules for example. One issue that comes up is that there may be better modules/objects for doing a job, but another choice may be easier to use - how does someone deal with that. I don't think anyone should exclude seemingly redundant code. All it has to do is meet the requirements.
Do we need a full app-note for all objects? A good demo is important for sure, but a fully developed app-note?
Need to have initial requirements listed and ratified before attempting a serious review of a project even as a test. Your item 0 says that SPIN/PASM is the only candidate since that's all we got. There needs to be a methodology in place to change requirements if necessary after the initial cut (item 5?). Is SPIN sufficient for self-documenting? Seems like that doc effort from Phil would need to be included.
The idea of different certification levels as someone mentioned before appeals to me.
1) Bronze - good attempt, but some things are missing
2) Silver - almost perfect
3) Gold - perfectly acceptable
My item 0 would better read as:
Establish Gold Standard API and coding standards for EACH language to be supported with Gold Standard libraries (spin/PASM/C/C++)
Maybe not a full app note but enough to use and point out any quirks (yes, even Gold Standards will probably have quirks)
Yes, step #5 is your spot to take "key learnings" away from the latest effort and plow them back into the standard if need be.
I think Spin needs help for self documenting. Phil's solution is a good approach.
I own many,many wooden pieces of code...wood and other things that float!! :0)
Again, if you don't want to try this, please don't actively try to derail it. This is only an experiment and will have no impact on you if it doesn't work.
If it does work, you still don't have to do anything different.
Advanced engineers tend to get resentful of any improvements or changes that may affect they the the work. This experiment is not for you, and will not affect you.
The question remains open: what is a reference that tells us how serial is supposed to work?
We'll go discuss the API in jazzed's thread and the C/C++ standards document someplace else so when the process is ready, it can be wrapped around the other standards. (unless that's not how it works)
I realize this is a very simple function and everybody already knows it by heart, but some of us have not written a serial driver before, and can't tell what about circuitsoft's driver is working and what is not working, because we can't tell exactly what its supposed to do.
The first rule of thumb (in this process) is "If you can't say what you want, you won't get it". In this case, we need a reference to compare to, that we all agree is sufficient.
We could make the test be communcation with the PIC or AVR used in the docs.
I was hoping the FTDI site might have something but didn't find anything.
C.W.
I was thinking one prop should talk to another prop, or one cog should talk another cog. This would be simpler, and allow anyone with a prop to run the test, and not require the additional expense of new hardware.
I was thinking that the serial we want is before the UART, the PIC or AVR might be limited to the hardware. This is what made me think the wiki article would be more appropriate, but usually wiki is not what we want to reference.
Either way would be ok, as long as we agree that it is what we can measure to.
The issue with the prop talking to itself is it only proves we have a protocol that can talk to itself and not necessarily the standard to be implemented.
Communicating with the FTDI chip which is on most prop dev boards would be nice because it lets you use the PST for simple testing, you could also communicate using the prop plug.
C.W.
This is a good illustration of why we want to start with a simple function for this experiment.
Now we are starting to see that "serial" is not just serial communication, but also might include specific hardware (and additional protocol).
Can we assume that props these days include the FTDI chip? I do have equipment for com1 serial port, but these days UI seem to favor quick start or protoboard with plug plug.
Also, when I do anything serial, I test with termaterm on the PC talking to the prop (pin 30 & 31), and then have the prop talking on another pair of pins to something else.
Do you guys do the same, or do you re-use 30 & 31 for serial testing after loading code?
Can we plan to test (whatever we come up with) using pin 30 and 31 to talk from the PC to the prop [via FTDI chip], and use another set of pins to talk to some other serial device?
Anyway it matters not as any serial object for the Prop is probably not implementing that standard as such. So if you want to cite a reference for bit sequences,timing etc wikipedia is probably as good as any.
.
The developer is responsible for verifying the code works. This is usually done with a demo or unit test results. If code is submitted of Gold and it does not have a demo and cannot be proven to work then it should not be considered. IMO, this experiment already failed because we're messing with code that the submitter admits does not work!
What the heck am I missing?
Some feel there is a pot of gold at the end of the rainbow.
I'm not so sure.
[8^)
Jonathan
You can write perfectly formatted code that incorrectly implements a protocol.
For example we could write an async serial receiver that samples data very late in the bit frame, it would work most of the time, but would likely fail on occasion.
Ideally for things like an async serial receiver the sampling method and timing would be well described and the timing verified.
C.W.
http://www.atmel.com/Images/AVR274.pdf
http://micromouse.sdsu.edu/uart/microUart.pdf
Mainly that we are not anywhere near looking at code yet.
We are trying to refine the statement that "this will do serial" down to a bunch of things that we can test.
In order to test something, we first have to say, for our purposes"serial" means "as defined by "X".
Even if the code were "complete", we need to state what it does (conforms to EIT 232 or what ever) and how we are going to test it.
In the course of establishing those, the author would undoubtedly find items that weren't covered but are going to be tested, and make the necessary changes. Circuitsoft's code is in the same position. It's "Not working" because we haven't defined "working" yet, regardless of the state of any code.
The process as I understand it now (I'm really trying to be good and positive and tolerant and accepting)
Someone starts here:
Golden Object author is satisfied and basking in success moves on to the next object
If so, are you referring to my enumerated list just above in post #147 or my original list way back in post #119 ?
I'm really just trying to understand this and follow along with P_Braino's lead - I just need to rephrase and/or clarify things and consolidate multiple posts to try and keep myself straight.
I don't want to dictate, lead or document this process, I'm just trying to understand like everyone else.
I like this one, says it used in RS-232 which is ONE KIND of start-stop transmission, but does not require RS-232 per se.
It looks like
http://en.wikipedia.org/wiki/Asynchronous_serial_communication#Asynchronous_start.2Fstop_operation
tells us most of what our target is.
It look slike the AVR is a particular implementation, and is limited at 9600 baud, the microUart data sheet contains a lot implementation specific material that might be beyond the scope of the serial driver itself. Do we need to include this and/or limit to including the hardware uart or specifying a particular uart?
I'm not the expert, and circuitsoft is doing the work; does any of these cover all of what we need without going beyond? Which of these (or which combination) covers what we need, with a lot of extra?
Remember, we want to avoid making implementation decisions at this point; we want to define the "what" and not touch the "how" till later, as much as possible.