Prop I - Gold Standard Obex ?

koehler

Per the thread "Your opinion about Propeller's future", any idea if there is going to be Gold Standard object for the Prop I? Speaking as a new user, when I browse the current OBEX, while its nice to have a User Rating, I don't know how useful/relevent that really is.
I realize Parallax' resources are limited. Is there any chance Parallax might consider starting some sort of Peer Review board with senior/expert forum members? Such a board might be interested in and have the time to be able to review OBEX entries for quality, correctness, etc.
At least for specific OBEX code that needs to be Gold Standard. I would think there might be at least a couple of forum members who'd be interested in this. Maybe leverage some member's free time with a Prop or two, gift cards, etc. Maybe access to some sort of Prop II Beta???

On a function/form perspective, it would be great if the OBEX Object Overview were restricted to a few words, such as what is currently bolded. The extended description should be shown when a link is clicked. I would prefer to see more 'slim' entries per page, versus multiple pages with oddly stuffed/tall columns.



Edit/ O/T- I really think the name OBEX should be reconsidered for the Parallax Semi ramp up.
While there is an OBEX (http://en.wikipedia.org/wiki/OBEX), I get the impression the Prop OBEX is just a contraction for Object Exchange. Doesn't help that I also get a vague Egyptian Obelisk image for some odd reason. Aside from my personal mental problems, I think Parallax would be doing itself a favor if it tried to conform to industry standard language wherever possible. Granted there isn't a lot in industry that would conform to many of the Prop's unique attributes. But, please get a better handle for how you are going to sell the programmable core/peripherals. I still think shaders, as in peripheral shaders or something is viable and more importantly, easily discernable to the average engineer.
The OBEX is a library, maybe Propeller Shader Library? Not everything needs a catchy name. I sort of like how Cypress explains their reconfigurable logic http://www.cypress.com/?id=1353&rID=37442

PPS- I know Chip has said the process the Prop1/2 use is not useful for flash, etc. Just curious why Cypress can do it, and not Parallax. How much would it really cost to move to a process that would allow that, and to be frank, is it possible that not having to add an external EEPROM might tip the scales for the average engineer? I know, I know, this has all probably been discussed before.

groggory

Sounds good to me. There are definitely better objects than others. Additionally, there are many objects that have little to no documentation, which is a real detriment.

It's almost as if each object deserves its own development space like sourceforge so other people can come in and update the object with updated schematics, bug fixes, etc when the author has no motivation to update it.

koehler

Or, have an In-Progress OBEX, and a Standards Complaint one. The latter should have basic document templates so that authors can simply fill out the spaces and have a significantly higher chance or passing the review board. More efficient, less wasted time for everyone, sort of like Change Management process in IT. Every 6 months a mod might even push non-worked on In-Progress OBEX entries to an Orphaned OBEX.

groggory wrote: »

Sounds good to me. There are definitely better objects than others. Additionally, there are many objects that have little to no documentation, which is a real detriment.

It's almost as if each object deserves its own development space like sourceforge so other people can come in and update the object with updated schematics, bug fixes, etc when the author has no motivation to update it.

Heater.

Koehler,

"shaders". What?!

Leon

I've never heard of the term, either. It's a lot less meaningful than those shields and sketches used by Arduino afficionados.

David Betz

Heater. wrote: »

Koehler,

"shaders". What?!

Aren't shaders the little programs that people write to run in the cores of a GPU? Not sure why they would apply to the Propeller though.

Leon

Gouraud shading comes to mind:

http://en.wikipedia.org/wiki/Gouraud_shading

Nothing to do with the Propeller, unless it's doing graphics.

Cluso99

Nothing wrong with "OBEX" for me.
O.T. The company Parallax uses to make the chips (the die) cannot do the flash process. But, the PropII can boot from other chips too, including SD which is really much more attractive.

Bobb Fwed

I've thought about something similar to the "board" idea. Some system to be able to determine which objects are most suited for your application. There would have to be ratings for things like functionality (fitness for a particular purpose), program size (many people have hard memory constraints), power usage (for the power conscious like me: minimum operating frequency, cogs used, etc.), ease of use, documentation, active development, and I'm sure there are other areas that are important to people that didn't pop into my mind right away.

prof_braino

koehler wrote: »

... Is there any chance Parallax might consider starting some sort of Peer Review board with senior/expert forum members? ...

There has been some discussion of organizing Peer Review recently (most recently by me).
Parallax does not appear to have sufficient resources to conduct formal peer reviews; but there should be a pool of interested forum members proportional to the interest in the object in question.
Unfortunately, the majority of most prolific posters on this forum are very skilled, independent individuals, and do not perceive benefit from an organized review process. That is, unfortunate for the rest of us that are not so highly skilled.

I am still working on a process for peer review process that is somewhat more rigorous that posting code snippets but less cumbersome than those typically found in business.

Please PM me if you are interest in collaborating on such an experiment.

rod1963

I think a gold standard of core objects would be a grand dea, especially when the Prop II is unveiled. As for the later it's doubly important, that prospective new users of the Prop II from industry will have a set of high quality routines with documentation at their disposal when they evaluate Parallax's latest product. Objects for ADC, DAC, video, etc.

Another thing is that Parallax ought to define is some minimum documentation standards for object put in Obex because some of the objects are evidently coded by people who have no idea what documentation is or why it's important. They just upload a object and let others figure out how to use them.

potatohead

Let's talk about that for a minute.

Say some code gets written, and it does some stuff that many people would consider valuable. And it's MIT license, meaning if it's present, it's there for the taking. And there are skills, people, needs, etc...

Some of the people can pick up the object and build on it. Their skill match is favorable. Other people can't do it, or lack the time to do it because their skill match isn't as favorable.

Documentation varies from essentially none, but what is embodied in the code through some comments, variable names, etc... through to very complete.

When the documentation is essentially the code, or "poor" for purposes of this discussion, is it better to simply not have the code available?

What about very well documented, kind of poor code?

Code that has some documents, but not all the ones potentially desirable?

Some people are great programmers, or have done professional work, while others are just learning stuff, contributing where they can. That's a pretty broad range of potential matches, or mis-matches in terms of contributions and people able to use them.

For me personally, I want the code. If it's got great docs, I'm happy! If it's got a little demo / test program, I'm really happy! But, then again, it might just be some code with a description, and whatever is in the comments too. Anybody who put something in the OBEX did so gratis, with MIT licensing to boot! That's a good thing generally, even if it is frustrating at times, from where I stand.

Not having the code to pick through is worse! In that scenario, one has to re-code, or ask people stuff, or just avoid the problem, etc... Sometimes using code that doesn't have good comments takes more time than it would have to just write the code. That's fair, but then again, not everybody will have that experience.

I like the idea of promoting objects. That's only a value add, and it's good for everybody, with almost no downsides that I can see. Barring code contributions, is both a value add and a potential loss, not good for everybody.

There is always the possibility for others to document the code, and frankly, I would make that possible ASAP, but do so in a way that doesn't devalue the original contributor.

Maybe they didn't have time for a comment? Perhaps they don't know how to document well? Maybe they thought the comment was adequate? Who knows?

At the end of the day, like it or not, the code is self-documenting to a high degree, and that's a skill everybody should be working on, right?

I guess I'm saying that I completely agree with the need to improve documentation and ease of use in general. Not sure that's ever a bad idea, but I think doing it in a add value only way is important, or we risk losses that we won't know the cost of.

Some experience to share. As a fairly rank amateur, I contributed some open code to Source Forge. Was my first real C project, and it had a lot of gaffes in it. Thought this over and damn near didn't contribute it, because I knew it wasn't where it could be. Then I thought people might use it.

Well, I think I made the right decision. The following things have happened over the years:

1. A very nice comp-sci prof took a coupla hours and commented my code for me to learn from, including lecture material, references to source examples and texts I could use to improve, and sent me the following brief note:

"On one hand, posting this up will not reflect well on your skill, on the other hand, this is useful and people will use it, so post it!" We exchanged some e-mails, and I worked through a lot of his material. Was a great experience, and the next rev or two cleaned up nicely.

That code, which views STL files, has had a lot of downloads from all over the world, and got ported (by me) to windows, IRIX, linux.

For a good few years, I received many patches, some fixing bugs, others adding features, all thanking me for the effort, and some honoring my request for info on how the code was used and where. I asked that because the whole thing was a experiment to give back for all the OSS software I used at the time, and to understand something of the culture and overall dynamics surrounding these things.

A company in Germany incorporated that code into a proprietary software package. They had somebody working there that didn't get it. Their replacement sent me a note: "oops! Let's talk" I asked them to submit patches, and put my name on the box, and the FSF advised me on that license agreement, all parties happy, code gets better. (a lot better actually)

Just last year, I got a thank you from somebody doing some home brew STL related work, who enjoyed the program.

So, what if it were not contributed at all? Is that a gain or a loss? The OBEX works the same way, but it lacks the elements needed to properly build the value of what people put in there. Why not address that the best we can, leaving people free to do what they can and they will?

koehler

Potatohead- I don't think anyone suggested not accepting objects. The suggestion was to try and implement a system by which Objects, a foundation of the Prop/II, could be realistically ranked for quality, correctness, and perhaps importantly, extensibility.
This is not only for the benefit of the enthusiast, but equally if not more so, the professionals considering investing/justifying time in the study of Prop development from a commercial perspective. You OSS story was interesting, and sounds like it was rewarding. However I think you got on the wrong track. I don't see any reason why Parallax would not allow people to commit what they wanted, how they wanted. I do think the average engineer, who is probably unfamiliar with the Prop, interruptless, and now has to wrap his head around soft-hardware, has too figure out what software to use to run this or that peripheral. And if there is a problem, is it his design, or some of the software he pulled from the OBEX.... I'm not a professional, and I even have concerns about that.
Having a Gold standard would I think give most reasonable people that warm, fuzzy feeling sort of like a Parallax Certified Pre-Owned Object. "We've take only the best, and subject it to rigorous testing, so you don't have too".
Someone could write the best black box function ever seen, but everyone wants something just a little different, a tweak for this or that. I would think something considered Gold would be just that, complete in all the major categories. If an object isn't decently commented, then that means its much harder for the average person to use or tweak/extend. Once Parallax goes ahead with their new commercial venture there is going to be a slim window for making or breaking any sort of reputation. Not having a solid suite of objects that are reliable, efficient, understandable, etc, etc, is not going to encourage anyone. What works for the OSS crowd is unique. I don't think any engineer worth his salt is going to want to load what are basically 'apps' into his Props without a good idea of exactly what they are doing. In fact, considering the limited programming courses and interest which even most new graduates have, not having well documented code could be a much bigger disadvantage than whats been seen among the more enthusiast geared community.
Nothing says the OBEX couldn't have a Gold section or award field that was searchable on either.

potatohead

I saw parts of the conversation leaning that way, which is part of why I wrote that. The other part is the implication that contributions need documentation to be valuable. I think MORE valuable is a good thing, just so long as the value baseline is given consideration, that's all.

Was speaking to this:

Another thing is that Parallax ought to define is some minimum documentation standards for object put in Obex because some of the objects are evidently coded by people who have no idea what documentation is or why it's important. They just upload a object and let others figure out how to use them.

(and I'm only providing a counter point, no negative statements about the author implied, nor intended )

IMHO, promoting objects is good. Adding options where people can add to objects is good, and that can be documentation, a revision, fork, whatever. The license allows it.

My only position is that contributed code is also good. It can be better, but the baseline for contributed code should be, "thanks", and where value is possible, it's realized and people build from there.

Mike Green

There are a couple of levels to a "Gold Standard". The code itself should be correct (as much as any good code is). It should be documented internally so that someone familiar with the language and the problem area, but not necessarily familiar with the particular algorithms or techniques used should be able to understand what it does and mostly why.

The interface should be well documented so that users familiar with the problem area can understand how to use it.

So far, the documentation doesn't deal with teaching the techniques used or teaching the problem area. That's the next level and it often takes skill in technical writing that many programmers don't have. For many of the "Gold Standard" objects, this level of writing should also be done, but maybe later and by another person than the one who originally did the work.

I see a real need for a demonstrated standard of documentation, perhaps applied to some of Chip's commonly used objects as examples. They should be documented by Parallax's staff and there should be "meta-documentation" included that discusses how to do this, what formats to use, explains several acceptable variations in style and/or content, then demonstrates the use of these styles with the actual code. These can be the first "Gold Standard" objects and be the models for others.

koehler

Whoops, disregard all that about shaders, etc. I've only been popping in and out of this and a few other forums lately, and just did some re-reading of the prop docs.

jazzed

The "gold standard" is whatever Parallax includes in the Propeller Tool.
Parallax projects it's software standard there. Go use that if you need "gold."

Expecting anything else from the myriad of varying opinions is "fools gold."

RossH

This is a very interesting thread. I agree about the need for better documentation - in fact, I would go further, and say that each 'gold' entity should come with a comprehensive technical application note (if it is small and simple) or even a full-blown reference guide (if it is large and complex).

I also have a few other suggestions:

• Don't call the gold repository an OBEX, and don't call the things in it objects. Two main reasons for this:

1. They aren't objects in the sense that most software engineers use the term. Using such terminology makes it look like Spin is pretending to be an object-oriented language - which leads to much confusion for newcomers (and not a little exasperation, once they realize this is not the case).
2. This is software-oriented terminology, but by far the majority of objects are hardware-oriented - Video, Keyboard and Mouse drivers, SPI/I2C interfaces, servo and motor controllers, signal generators, ADCs etc etc. As has been pointed out in other threads, for most users these take the place of the hardware peripherals intergrated into other microcontrollers - so call them something that conveys this! How about soft peripheral? (I'd suggest plugin, but this term is already used by Catalina - and for exactly this reason - i.e. they form the Hardware Abstraction Layer necessary to insulate the programs from the peripherals)

• A soft peripheral can be submitted by anyone, but to achieve the 'gold' standard, they must be tested, certified and supported by Parallax - no exceptions! Of course, Parallax is free to farm test and support work out to anyone it likes, including (but not limited to) the original author - but commercial users must be absolutely certain that if they have a problem with a soft peripheral, they can go straight to Parallax to get an answer. They should not have to rely on the whim of a casual contributor, or the presence of suitable expertise in the forums (after all, we forum members continually come and go, and OBEX entries can end up orphaned until someone picks them up again).

• All soft peripherals must interoperate. Any combination of them should be able to be made to work together (until you run out of cogs, or memory, or pins for them - and their requirements for all such resources should be uniformly documented up front). All interfaces to all soft peripherals should be standardized as much as possible - at the very least all soft peripherals of the same type (e.g. SPI drivers, Video drivers) should use the same interface so that they can be swapped in or out. Parallax actually seems to do this quite well in their own objects - but the OBEX is a bit less stringent.

• All soft peripherals must be usable from all languages promoted by Parallax - so far these are Spin, PASM, Basic and C (i.e. the language options currently allowed in the OBEX).

Ross.

Heater.

RossH,

Yes, "OBEX" is an unfortunate name. It's already the name of an object exchange protocol for mobile phones etc.

Yes, "objects" is all wrong. Objects don't exist until they are instantiated. Those files in OBEX are "classes".

Oh, that's not what you meant.:)

Now, the Prop has "soft peripherals" in the same way that an FPGA does. You have a blank slate of logic hardware, COGs for the Prop, logic blocks for the FPGA.

In the ever so professional world of FPGA's they refer to the "objects" that you can pick and choose to fill up your device as "IP Blocks".

Perhaps a Prop aimed at professional users should adopt the same. With the same drag and drop wizards in the Prop Tool to install them into your apps and configure them. Without ever having to look at the source code.

Heater.

RossH,

All soft peripherals must be usable from all languages promoted by Parallax

Absolutely yes.

jazzed

RossH wrote: »

A soft peripheral can be submitted by anyone, but to achieve the 'gold' standard, they must be tested, certified and supported by Parallax - no exceptions!

I agree with this the most. I agree with everything you said actually except some claim of exclusivity to the word "plugin". I "plugin" my radio, my mouse, my ipod, etc... My girlfriend used to "plugin" ... um well, better not to say that in public. :P

RossH

jazzed wrote: »

I agree with this the most. I agree with everything you said actually except some claim of exclusivity to the word "plugin". I "plugin" my radio, my mouse, my ipod, etc... My girlfriend used to "plugin" ... um well, better not to say that in public. :P

Err...ah..(cough)...hmmm...very interesting, jazzed ... reminds me of an old girlfriend who had a trick she liked to call "the propeller" ... but to get back to the subject ...

I wasn't claiming exclusivity - Parallax is welcome to adopt the term - I just didn't want to appear to be pushing Catalina's specific plugins.

Ross.

potatohead

Are all the gold objects peripherials?

prof_braino

>>>...levels of..."Gold Standard". The code itself should be correct as much as any good code is...documented internally so that someone familiar...

This is true, but is not yet clear enough. I don't want to tell anybody their own business, but I have some experience with standards and process. The definition of "correct" must be clarified so that is it objective (does something specific, yes or no) rather than subjective (I got it to work so it looks "good" to me).

The key concept here is "conformance to requirements". Does it say what it does and do what it says? For example, a driver for a specific part does not have to implement every feature of the part to be correct. It simply has to state the feature set that it addresses, and demonstrate that it does exactly that and nothing more. The useful measure here is "degree of conformance to stated requirements". Of course, prerequisite to this is "testable requirements", but that concept is pretty easy if we agree to choose this path.

>>> The "gold standard" is whatever Parallax includes in the Propeller Tool. Parallax projects it's software standard there. Go use that if you need "gold." Expecting anything else from the myriad of varying opinions is "fools gold."

I find the first part suspect. It could be a big mistake to assume that Parallax is infalable and that a hardware manaufacturer has somehow perfected software process when the rest of the world is still discovering it. You are exactly right that everyone has a different opinion and these can be contradictory, the key is to separate out the "subjective" and stick to the "objective" (can a given question be answered "yes" or "no" and everybody gets that same answer?)

[This is not to say that parallax software is not generally very good; quite the contrary, it usually does what it says. But sometimes it does not, even Chip makes mistakes (I'm guessing).]

We must be able to evaluate whether an item is gold, and be able demonstrate it when required. This is actually quite easy.

"Degree of Conformance to Stated Requirements": If we establish a definition for "testable requirements" we can use "degree of conformance to requirements" as the measure, and thereby determine if a given item is "Gold" or not.

jazzed

The point is not about whether Parallax is infallible - they're just different sometimes which can trouble.

The point is that Parallax sells Propellers and provides solutions to that end. It is their business to mess up or succeed in however they like. They pay attention to customer input, but it is their choice to act or not to act.

Parallax has control over the libraries and examples that are packaged with the Propeller tool. Putting onerous burdens on OBEX contributors will stymie creativity of people who wish to share there. The gold standard is what Parallax chooses it to be.

RossH

potatohead wrote: »

Are all the gold objects peripherials?

Hi potatohead,

The vast majority of the OBEX entries are intended to interface either directly with the outside world, or with external hardware.

You could argue that some OBEX entries - such as the various floating point packages - are simply software - but I would say that even many of these are intended to replace hardware found on other processors (i.e. in this case a floating point processor and supporting instructions).

The number of pure software OBEX entries - i.e. entries that implement functions that would be implemented in software on any processor - such as BS2 libraries and hash algorithms - makes up only a very small fraction of OBEX entries.

But the main reason I suggested the term soft peripherals is that it also counters a common criticism of the Propeller - i.e. that it is missing many of the built-in (or "hard") peripherals embedded in many other microcontrollers. In the Prop, this lack is intentional - and is more than made up for by a wealth of soft peripherals avaliable. This also means there need only be "one" Propeller chip, rather than the multitudes of chips with various hardware options offered by other manufacturers.

Ross.

RossH

jazzed wrote: »

Putting onerous burdens on OBEX contributors will stymie creativity of people who wish to share there. The gold standard is what Parallax chooses it to be.

Hi jazzed,

I don't think having a gold repository would place additional burdens on normal OBEX users. My suggestions are that Parallax should consider shouldering some of the responsibility for testing, certifying and supporting OBEX entries that they deem suitable for inclusion in the gold repository.

The gold repository will not replace the OBEX. The OBEX would continue much as it does now - i.e. a grab bag of interesting and useful objects that you use at your own risk, and which is supported by the forums rather than by Parallax.

In fact, I see this as benefitting OBEX contributors, since in some cases Parallax may choose to pay the original author to do some (or all) of the work required to elevate an OBEX entry to the gold repository.

Ross.

Cluso99

RossH: I love your "soft peripherals" concept.

Could someone start a wiki page in the prop section, so we can all edit a definition and description? The purpose would be for us as acommunity to create a writeup (available widely) to expose the propeller to the outside world, and for Parallax Semi to use in their marketing.

I see this as one of the biggest opportunities to advance the prop

potatohead

I like it too. Like it a lot Ross. Just asked the question to see what people would say. It just kind of popped in there, so I wrote it.

I'm in favor of any and all things that promote objects, encourage discussion, forking, aggregating, and documenting / revising objects in a structured way. Let the "gold" rise to the top! I'm also in favor of Parallax doing some work to ship the "gold" with the standard software distribution. I think some compensation to see some objects get realized to their full potential is a good idea too.

As long as there is a open door for anybody wanting to contribute to the OBEX, and said contribution is easy, then I'm happy. Others can pick up that code, or the author can and improve on it at a later date. Life is good.

Edit: It's gonna be hard to quit saying "objects"!

jazzed

Well if it has to be work, then so be it. Nothing has to be committed to OBEX or whatever to be useful.

potatohead

As long as general contributions can be made, it won't be any more work than it is right now. That's my concern too. Raising that bar means less overall contributions, and IMHO, that's a generally bad thing.