From what I can tell, there are at least 15 different serial drivers in the OBEX. And this doesn't include variants that are specific to LCD displays or some other serial peripheral. Will the "Gold Standard" serial driver meet the needs of all 15 serial drivers plus the peripheral-specific variants? It would be nice to only have one serial driver that meets all our needs.
I figured a total of three. ffds1 (high speed, 1-channel, 1 cog), ffds4 (medium speed, 4-channel, 1 cog), hds (low-speed, half-duplex, blocking, no extra cog).
I figured a total of three. ffds1 (high speed, 1-channel, 1 cog), ffds4 (medium speed, 4-channel, 1 cog), hds (low-speed, half-duplex, blocking, no extra cog).
3 is better than 15. Will they be cog-safe? That is, will they allow multiple cogs to write to the same serial port without causing problems? Cog-safeness is usually implemented using a lock.
How about multiple-object access? FDS has a feature/restriction that it can only be used by the object that started it. Will the Gold serial drivers have this same feature/restriction?
EDIT: Oh, and how about buffer sizes? Will the Gold serial driver have fixed buffer sizes, or can we define the size of the buffers when we open the serial port?
So far I've only worked on one. At the moment it's fixed, but I don't see why it can't be variable. But, again, that needs to be specified and tested. Maybe leave it fixed for a v1.0, then update it with variable buffers later?
I initially set up Gerrit because, in my experience, it has made following process easy and fun, but some process needs to be defined. I think we're going through the most painful part of this right now. Once we have something decided on, we can get back to coding, and the reviewing shouldn't be any harder.
I don't think Jobs and Wozniak would have ever created the Apple if they went about it this way. The same goes for Ford and his Model T.
And that is why committees don't work. Someone needs to make the final decision. Too many people have way too many ideas on what should be a "Gold Standard".
My opinion is that you should have a Bronze standard, a Silver standard, and then a Gold Standard.
So a Bronze Standard would be an object that works correctly. The Silver standard would have the correct documentation. And the Gold Standard would be standardised method calls, usage etc etc.
But in the end who is going to review each of the objects in the OBEX and tag them with the correct standard???
...This Gold Standard is supposed to be a professional thing. Everyone's expectations are different.
Part of this process is to define exactly what the expectation are for this function. We will define what will be supported, and can state what will not be supported. Then everyone can have the same expectation and decide "this does what I want" or "This isn't intended to do what I want".
That's the "professional" part, we don't have to guess and figure it out on our own by repeating all the work that went into developing it in the first place. .
I don't think Jobs and Wozniak would have ever created the Apple if they went about it this way. The same goes for Ford and his Model T.
Of course not. They would have ignored the engineers in favor of where they thought they could find the most money from non engineer consumers. But in this case, the engineers are the target.
Even when I spent time doing IT for AF flight test programs, I didn't see this level of complexity among coders. They wrote, tested and documented the code. Yes, the programmers actually documented their own code! There were no "process" people involved unless they were managers, who wisely kept their noses out of the day to day work of their programmers.
This is why we have such heavy regulation in aviation (and medical) today. When management applies pressure to release on a ridiculous deadline (based on arbitrary dates rather than the time needed to perform a given volume of work), things get missed. In aviation, people can die as a result. This is why so much effort was spent figuring out exactly what needs to be done and what needs to be skipped. We get the benefit of all the effort for free (if we chose to accept it).
In the case of aviation, FAA (and even military these days) require tons of paper work, since the pressure is so great to cut corners. In our case, we can skip the paper work, but is still a good idea to do all the steps that we need to do. This is how we arrive at the list of steps we need to do. We only have to figure this out once, after that the process is very quick, as we have a list to read, rather than a list to create and write.
If you are wiring up your Prop to robots and gadgets, if you are writing propeller code to drive it all, then you are a "Propeller Engineer". Never mind if this is a hobby activity. You are as much an engineer as James Watt was when he was tinkering around with his prototype "toy" steam engines.
Engineers? I though this was a community endeavor. I am thoroughly lost.
Sorry I am equating prop users with software and/or hardware engineers. To me, any folks using a microcontroler are in the role of engineer, some are very skilled and experienced, the others have zero experience, most are in between these extremes.
Unfortunately its quite common for the "experts" to belittle the novice.
The expert may have climbed the learning curve faster, or may simply have spent more time practicing. But everybody has to start from zero.
Until we make it through this process successfully at least once, we are all beginners.
Doug, I don't think anybody was trying to belittle the novice. However, I think the opposite is true. It takes years of education and/or experience for someone to become a professional engineer. When you say that everyone that programs the prop is an engineer you're discounting the value of the education and experience that it took to become an engineer. That's like saying that all people that work in the medical field are doctors.
I've been programming things and hooking up electronic thingies for 38 years, I have been paid (and paid well) to work in the computer/IT industry since I was 18. I have been schooled in both technical and business related areas. At no time would I consider myself an engineer or accept that title were it bestowed upon me. While I share some knowledge and ability with engineers, it is not my trained or practiced discipline and I know that my knowledge base lacks items that are fundamental to what I expect an engineer to possess.
If nominated I will not run.
If elected I will not serve.
If labeled Engineer, I will not accept.
However, I think the opposite is true. It takes years of education and/or experience for someone to become a professional engineer.
You're focusing on being a certified engineer at the end; I am talking about becoming an engineer by gaining experience. This is the same thing through different ends of the telescope.
I originally created this thread to announce my attempt to apply some light process to reviewing of golden IP blocks. 200 posts later...
Got it. Now that we have some sense of requirements, perhaps we can proceed?
One requirement is that a coding standard must be followed.
Since we have a Parallax standard for Spin (and no other language) we should be doing Spin.
If I may add a single data point, here was the informal process I just followed:
* 1 - Problem Statement *
I needed a full-duplex serial object. I needed speeds above 115.2 kbps, faster = better. I only had 1 cog free. I needed a large RX buffer in case my other code had to leave it for a while.
* 2 - Survey Existing Solutions *
I checked out the objects bundled with the prop tool. I searched the OBEX for serial, found a bunch, none quite what I was looking for, though Kye's came closest. (Note: searching the OBEX seems to require more intellect or luck than I have available.)
* 3 - Design *
I sat down and thought about mechanisms I could use to satisfy my requirements, hit on some I thought might work.
* 4 - Programming *
I printed off the Gold Standard code requirements. They mostly have to do with what I think of as formatting, but also include a few requirements like demo code (could be considered a 1st pass test harness). So, I kept those in mind, and also I kept in mind that I hoped people would look at the code, so I took care to favor clarity over tiny hacks, and to document what I was doing.
* 5 - Internal Testing *
I tested it via the on-chip methods, using 2 cogs and connecting via unused pins. I also tested on the serial terminals (bst and the Propeller Tool one). Then I did some testing with a serial app on the PC streaming data to the prop.
* 6 - External Testing / Request for Feedback *
This was me posting it on the forums. Bugs were found, kuroneko swooped in to the rescue.
* 7 - Publish as Object *
Not done yet...was going to just exile it to the OBEX.
================
Observations:
1 & 2 will be done by end users, not the Gold Standard Commission Body [8^)
3 is totally dependent on the initial programmer and the problem...I think this is out of scope for the GSCB.
4 was really nice to have guidelines and generic requirements...perfect for the GSCB
5 is very problem specific. It is a good idea to require tests, IMO, but useless to over-constrain. Maybe specify 2 levels: on-chip diagnostics to catch what can be caught w/o hardware, and "works with intended hardware" tests.
6 this forum community is great... knowledgeable people who will help. Because of this, I think once an object passes some initial screening (goes Bronze?) getting as many "eyes on" as possible is a good thing. Maybe highlight new projects or projects that still need feedback?
7 If all objects are listed, searchable, and ranked (Bronze Silver Gold) in one place, I would be happy. Even just the addition of the rankings to the OBEX would work...if you screen Any / Bronze or above / etc.
Sorry for the longish post. I definitely believe this effort is worthwhile. I really think the level of input from the GSCB should be as minimal as possible. Basically the current code standards in the Gold Standard document, a few definitions of test frameworks, and a simple system for voting on the objects. After that we'll probably need to select a smallish group of people who are qualified to vote on an object's status, and there will be some web development required. I personally would rather get something minimal started within a month than wait for the perfect incarnation to arrive with the Propeller III. [8^)
thanks for your time,
Jonathan
P.S. "GSCB" is not intended to be an actual name suggestion, I was merely attempting to be a bit silly.
P.P.S. Regarding what requirements the GSCB enacts, a good rule of thumb might be: if this requirement could not be satisfied by an object bundled with the Propeller Tool, it might be too strict. I don't mean things like "needs more documentation", I mean "a beginner should understand the code" will never work with the VGA or TV drivers.
You're focusing on being a certified engineer at the end; I am talking about becoming an engineer by gaining experience. This is the same thing through different ends of the telescope.
That explains everything. Now I understand everything you've posted on the forum. You're looking through the wrong end of the telescope.
Lonesock,
I think the biggest problem with the Parallax Coding Standard, is that most engineers that aren't already familiar with the propeller will scoff at anything other than C. That's why my initial posting was C-oriented, but I have added a SPIN library as well.
The main point of what I created was to integrate what you list as step 6 and 7.
I've been around for a while, at least long enough to see this kind of "process stuff" discussed and implemented every which way. I can't tell ya how many times in my work life I get dinged for not filing someone's idea of proper paperwork. I could probably be successful if the paperwork pushers would stop changing the rules.
Alas, paperwork has become a necessary time suck and apparently a critical business function. I work with folks who's job it is to monitor paperwork and processes. And man do they get upset when paperwork is messed up. But ya know, there is not a single group, where I work anyway, that monitors code health. I find that interesting and a little similar to this discussion.
Comments
How about multiple-object access? FDS has a feature/restriction that it can only be used by the object that started it. Will the Gold serial drivers have this same feature/restriction?
EDIT: Oh, and how about buffer sizes? Will the Gold serial driver have fixed buffer sizes, or can we define the size of the buffers when we open the serial port?
We just need a decent set of spec and test docs to see exactly what prof_braino is suggesting.
I see some good suggestions for the "ideal universal serial driver (tm)", maybe a thread should be started for that discussion.
C.W.
And that is why committees don't work. Someone needs to make the final decision. Too many people have way too many ideas on what should be a "Gold Standard".
My opinion is that you should have a Bronze standard, a Silver standard, and then a Gold Standard.
So a Bronze Standard would be an object that works correctly. The Silver standard would have the correct documentation. And the Gold Standard would be standardised method calls, usage etc etc.
But in the end who is going to review each of the objects in the OBEX and tag them with the correct standard???
Part of this process is to define exactly what the expectation are for this function. We will define what will be supported, and can state what will not be supported. Then everyone can have the same expectation and decide "this does what I want" or "This isn't intended to do what I want".
That's the "professional" part, we don't have to guess and figure it out on our own by repeating all the work that went into developing it in the first place. .
Of course not. They would have ignored the engineers in favor of where they thought they could find the most money from non engineer consumers. But in this case, the engineers are the target.
This is why we have such heavy regulation in aviation (and medical) today. When management applies pressure to release on a ridiculous deadline (based on arbitrary dates rather than the time needed to perform a given volume of work), things get missed. In aviation, people can die as a result. This is why so much effort was spent figuring out exactly what needs to be done and what needs to be skipped. We get the benefit of all the effort for free (if we chose to accept it).
In the case of aviation, FAA (and even military these days) require tons of paper work, since the pressure is so great to cut corners. In our case, we can skip the paper work, but is still a good idea to do all the steps that we need to do. This is how we arrive at the list of steps we need to do. We only have to figure this out once, after that the process is very quick, as we have a list to read, rather than a list to create and write.
Sorry I am equating prop users with software and/or hardware engineers. To me, any folks using a microcontroler are in the role of engineer, some are very skilled and experienced, the others have zero experience, most are in between these extremes.
You are probably correct. Committees could never be used with any success. We need only cite the US Congress and British Parliament as examples.
But in our case we may have fewer lawyers, so we may have a different result.
Used in a sentence: "Parallax patronizes Propeller Prengineers."
The expert may have climbed the learning curve faster, or may simply have spent more time practicing. But everybody has to start from zero.
Until we make it through this process successfully at least once, we are all beginners.
"Prengineer" sounds A LOT BETTER than "Engineller"
of course, that leads to the question if someone using the Basic Stamp is a "BSengineer"?
You are suggesting I am belittling the novice? Where did you read that?
Silly me, I thought you meant the contraction PR(opeller)ENGINEER, which Parallax should patronize over the Arduingineer, of course!
I originally created this thread to announce my attempt to apply some light process to reviewing of golden IP blocks. 200 posts later...
If nominated I will not run.
If elected I will not serve.
If labeled Engineer, I will not accept.
You're focusing on being a certified engineer at the end; I am talking about becoming an engineer by gaining experience. This is the same thing through different ends of the telescope.
Got it. Now that we have some sense of requirements, perhaps we can proceed?
One requirement is that a coding standard must be followed.
Since we have a Parallax standard for Spin (and no other language) we should be doing Spin.
Up for that?
* 1 - Problem Statement *
I needed a full-duplex serial object. I needed speeds above 115.2 kbps, faster = better. I only had 1 cog free. I needed a large RX buffer in case my other code had to leave it for a while.
* 2 - Survey Existing Solutions *
I checked out the objects bundled with the prop tool. I searched the OBEX for serial, found a bunch, none quite what I was looking for, though Kye's came closest. (Note: searching the OBEX seems to require more intellect or luck than I have available.)
* 3 - Design *
I sat down and thought about mechanisms I could use to satisfy my requirements, hit on some I thought might work.
* 4 - Programming *
I printed off the Gold Standard code requirements. They mostly have to do with what I think of as formatting, but also include a few requirements like demo code (could be considered a 1st pass test harness). So, I kept those in mind, and also I kept in mind that I hoped people would look at the code, so I took care to favor clarity over tiny hacks, and to document what I was doing.
* 5 - Internal Testing *
I tested it via the on-chip methods, using 2 cogs and connecting via unused pins. I also tested on the serial terminals (bst and the Propeller Tool one). Then I did some testing with a serial app on the PC streaming data to the prop.
* 6 - External Testing / Request for Feedback *
This was me posting it on the forums. Bugs were found, kuroneko swooped in to the rescue.
* 7 - Publish as Object *
Not done yet...was going to just exile it to the OBEX.
================
Observations:
Sorry for the longish post. I definitely believe this effort is worthwhile. I really think the level of input from the GSCB should be as minimal as possible. Basically the current code standards in the Gold Standard document, a few definitions of test frameworks, and a simple system for voting on the objects. After that we'll probably need to select a smallish group of people who are qualified to vote on an object's status, and there will be some web development required. I personally would rather get something minimal started within a month than wait for the perfect incarnation to arrive with the Propeller III. [8^)
thanks for your time,
Jonathan
P.S. "GSCB" is not intended to be an actual name suggestion, I was merely attempting to be a bit silly.
P.P.S. Regarding what requirements the GSCB enacts, a good rule of thumb might be: if this requirement could not be satisfied by an object bundled with the Propeller Tool, it might be too strict. I don't mean things like "needs more documentation", I mean "a beginner should understand the code" will never work with the VGA or TV drivers.
I think the biggest problem with the Parallax Coding Standard, is that most engineers that aren't already familiar with the propeller will scoff at anything other than C. That's why my initial posting was C-oriented, but I have added a SPIN library as well.
The main point of what I created was to integrate what you list as step 6 and 7.
Alas, paperwork has become a necessary time suck and apparently a critical business function. I work with folks who's job it is to monitor paperwork and processes. And man do they get upset when paperwork is messed up. But ya know, there is not a single group, where I work anyway, that monitors code health. I find that interesting and a little similar to this discussion.
I don't see it yet.