Standardised Objects
Brian Fairchild
Posts: 549
I've been playing with the Prop for a few months to decide if I could use it in commercial projects. During that time I've tried out many of the objects in the OBEX and spoken to colleagues about the chip. One of their first questions is often something along the lines of 'How many UARTs does it have' or similar. Yesterday, since my programming language of choice is 'C', I sat down to convert vga_hires_text into a C-friendly object and opened a can of worms.
All of these separate strands has led me to the question - 'Surely there must be a better way to write and use objects?'
Let me explain...it appears that here are three sorts of object in the exchange
1) Sample Code - an example of using a specific peripheral or sensor or algorithm
2) External Peripherals - code which interfaces the prop to things like keyboards, mice and SD cards
3) Integrated Peripherals - code which simulates the hardware based peripherals found in other micros, USART, SPI, I2C etc
There is also a huge range of interfaces to those type of object - point PAR to a parameter block which is copied into COGRAM and used, point PAR to a parameter block in HUBRAM and use it there, implant parameters into 'variables' before launching the COG, embed parameters directly into the COG code before launch, etc etc etc.
Then there is how you interface the objects to different application-level languages.
It occurs to me that to make a universal object we need two things...
1) A generic interface between the object and the application
2) A way to use the same object, maybe as a binary, with different languages.
All of these separate strands has led me to the question - 'Surely there must be a better way to write and use objects?'
Let me explain...it appears that here are three sorts of object in the exchange
1) Sample Code - an example of using a specific peripheral or sensor or algorithm
2) External Peripherals - code which interfaces the prop to things like keyboards, mice and SD cards
3) Integrated Peripherals - code which simulates the hardware based peripherals found in other micros, USART, SPI, I2C etc
There is also a huge range of interfaces to those type of object - point PAR to a parameter block which is copied into COGRAM and used, point PAR to a parameter block in HUBRAM and use it there, implant parameters into 'variables' before launching the COG, embed parameters directly into the COG code before launch, etc etc etc.
Then there is how you interface the objects to different application-level languages.
It occurs to me that to make a universal object we need two things...
1) A generic interface between the object and the application
2) A way to use the same object, maybe as a binary, with different languages.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I too also agree with your analysis of the situation, but there are many objects in the exchange written by people with varying understanding of the Propeller.
I think the major issue is, each person has their own way they view the code to work, and it is hard to get the general public to all think in the same fashion. This results in different interface types, and methods. Because of the universal freedom the propeller provides with programming, just about any object could be written at least 5 different ways.
Maybe some basic education about code interfacing should be covered in a Webinar by Parallax. The topic is difficult, for some do not care to conform to any specific rule, they share their code, and you may use it if you wish. If you do not like it's interface, rewrite the code to suit yourself.
I believe standardization is very helpful with respects to some of the larger, everyday use code (TV object, keyboard object,etc.). Some of the other smaller objects, not so much.
But some basic rules of interfacing would be a good topic to have as a sticky, and should be discussed.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Maybe I'm different, but every proposal for some form of standardised calling convention or interface convention has just led to some form of bloat or unneeded complexity.
Personally I use the OBEX as a great pool of sample code, and fantastic ideas for algorithmic implementation, but I don't think I've _ever_ used anything from there unmodified. You just can't please all the people all the time and trying to is a sure path to failure.
From a learning standpoint, it's nice to be able to plug modules together and have the chip do something, but if you are seriously using code, somewhere along the line you will need to modify or re-write something for size or speed.
I have another bugbear with regard to using code (or lawn mowers, washing machines, cars or anything else with any individual components - but that's just me), which is not understanding it .
I'm working on a _unique_ project with the propeller (read as "possibly stupid, likely to cost a lot in smoked semiconductors as I'm not very clever, and potentially dangerous") which I'll talk about later if I can make it work without blowing too much stuff up.. but I digress.. it needs a stable PWM and I had no idea how to make a _fast_ high resolution, multi-channel PWM with the propeller. I grabbed PhilPi's code from the OBEX and had a look. After having a lightbulb moment when looking at it's complete elegance, I said "Why didn't I think of that". I thought.. it's not what I need, but it's very close. So I re-wrote it to do what I needed it to do, the way I needed it to do it. In my application, it's faster, smaller and far less flexible.. but without Phil's code in the OBEX I'd probably still be using a PIC with a dedicated PWM module..
I guess what I'm trying to say is the code is there to be learned from. If you make it so completely plug'n'play that there is zero thought required to put it all together it becomes a set of wooden building blocks. (Some) People won't take the time to explore the power because they don't have to. They can just buy the device, plug other peoples code together and have it work 90% of the time (the other 10% they will get a product to market, it will explode and they will blame someone else's code). That's not learning. That is what kids are growing up with these days and it's breeding a consumer-society generation of people who are not interested in how things work, how to fix them or how to build them. (That is my real fear. A complete consumer society where people just throw it away and buy a new one, or don't know how to build something they see a need for).
The Propeller is an incredibly powerful tool.. let's not dumb it down to the point you don't need to have any understanding to use it. Make people learn, just a little.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
On the other hand, I also use the OBEX and the objects that come with the Propeller Tool as the basis for my own customizations. I may look at what someone else has done before and decide that I can do a better job, at least for my own purposes. It's like finally designing and building your own lab / workshop, made out of bought pieces and built pieces, based on experience in using things and building other things.
The Prop "community" and resources are reaching a point maybe where some "standards" should be discussed. I don't think we're at the point where they're ready to be declared as "standards". There's a common experience with the development and use of "standards" ... across industries. If they're done too early, people will ignore them because they're not based enough on experience and "best practices" found through that experience. If the industry waits too long to define standards, they'll be created by default and not necessarily well. Usually the biggest player in the business gets to do this and often these default "standards" are awful.
Personally, I think some general documentation "rules" should be agreed upon, things like:
1) An object should have comments at the beginning that describes the purpose of the object, generally how it's used, any general limitations or advantages over other, similar, objects. It should describe in general terms how the object does its thing. This is where the format / layout of any control blocks or other shared / global information should be described. This is where any restrictions or conditions should be described.
2) Each public method should have comments, probably where the method is declared, that describe the purpose of the method in general terms, describe each of the parameters and the return value, how the method is used, any restrictions on the parameters. If the method ABORTs, how and why should be described, at least in general terms.
When I say "agreed upon", I don't mean that someone should make up a set of rules and post it. I'm really referring to people posting or linking to examples taken from existing code and, if someone likes another format or style, they should try rewriting what was posted and use their style instead and post that for people to compare and comment upon.
I think the vast majority of objects would stay as they are written. I'd be fairly certain that, just as with just about everything else, objects follow the 90:10 (or 80:20) rule - that is to say 10% of the objects will be used 90% of the time. The 'Sample Code' objects would never be rewritten; they are what they are. However, I see great merit in a core of objects to replicate 'traditional' microcontroller peripherals. I'd put money on 99% of people who want a serial port object using it at standard baud rates simply because what they connect to at the other end of the wire runs at those standard rates. Making it easy for people to start a project is what this is about. Where the prop scores over traditional micros is that it is possible to craft more intelligent peripherals, eg buffered UARTS which looks after their own handshaking for instance or objects that look after large parts of interfacing to SD cards.
@BradC
I completely agree with everything you wrote. However, I see little point in re-inventing the wheel every time. A core of high performance objects, probably numbering in the dozens rather than hundreds would open up the prop to a much wider market. Do you really want to hack around a USART every time you want one? Wouldn't it be much easier if there was one really good one there for you to use?
@virtuPIC - I missed that thread - I'll go take a read.
TV.out("A")
FDX.TX("A")
It would be nice to be able to substitue, just by changing the initial call. I did just that in one of the codes I was playing with.
Unfortunately, it wasn't thought of at the time of writing and we all move on to something else.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
In the ICCPROP universe it is important to try to have tight libraries ... .c modules should only have minimally relevant functions for the task per module. Having 15 functions in a module will cause code bloat. This is why macros are available instead of functions for some common Propeller things. If you want functions for macros that will be used often and you don't care much for performance, the macros will show you a way to do it.
I have been lazy about keeping C modules small and tight since the OBEX to me is really just a place to learn. A revenue project may have variations or derivatives of things in the OBEX or a complete re-write to satisfy some need. It is after all your intellectual property that you are responsible for creating and maintaining ... if you don't "own it" you might be disappointed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
That is not to say that I would like to have better interfaces, datasheets and code samples, but you get what you get when you use other peoples code. That also does not mean that we should not try to make things better.
Question, of all the OBEX objects, which would you consider are the "best" examples?
Chuck, that is like playing with a loaded gun.
I really feel, functionality wise Mike G. has some great objects for SPI, I2C, and SD interface. But (sorry Mike), his command structure sometimes looses me. I just recently was working with some of the functionality for the I2C object from "BoeBot Basic" and couldn't figure out how to structure the command correctly.
His object is documented pretty well, but he wrote it to his understanding. That is not a criticism, just the way I see it. It is hard to write documentation for something you understand, for someone who doesn't. But in his defense, he is always around to slap me in the head for me to see the light. Also, the object was not really written to be used as a stand alone I2C driver, so I am to blame in that respect.
This is another issue I have with the OBEX. There is a lot of functionality there, embedded in other objects. Those objects work well together, but are not always easily understood alone, although they do work alone.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
One thing CPAN does not have, though, is a bunch of rules regarding method naming or calling. Part of the reason is that Perl's module interface is structured enough as part of the language. Establishing a standard for the OBEX would be a mistake, I think, mainly because the Propeller's resources are thin by comparison to a PC's and anything a person can do to optimize the use of those resources is fair game.
What CPAN does have, and which I would definitely encourage for the OBEX and the IDE, are registered namespaces. This is basically a subdirectory structure imposed on the library so that modules can be organized by type. This is a feature that is way overdue for Spin, IMO; and the longer Parallax waits to implement it the more disorganized the Spin library will become.
I guess the thrust of my comments is, "Don't reinvent the wheel." Look at the successes other community-supported program archives have had and derive a model from that. That CPAN has been around since the '80s and is still active is testament to it organization and makes it deserving of a look for the OBEX.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 4/28/2009 6:08:13 PM GMT