Obex compatibility suggestion/request
EmptyBit
Posts: 72
This may sound like a no brainer to the initiated prop user or well seasoned spinner, but I have run into a bit of frustration with objects in the OBEX or in stickies. Between the Demo Board and the Proto Board eeprom configuration, some I2C objects are incompatible with various Parallax stock products for various reasons.
Like when I tried Kye's I2CEngine and found it was made for use with pull-ups, but the demo board had only one. Regroup, find another obex offering and learn to work within its methods. The Propeller Eeprom.spin was created for the 256k eeprom. Fine for the demo board.
Now I find after getting Propeller Eeprom functioning on the demo board and transferring my work to another stock product to package the final product on a protoboard, I find my R&D coding time and learning curve begin anew. The protoboard has both pull-ups and a 512k eeprom, which does not seem directly compatible with Propeller Eeprom.spin. At my current knowledge level, I don't see anything in it that can be changed to make it work with a protoboard. I could not find a thread that explained why it is not compatible or how it could be made so.
Part of this frustration was the potential for needing 2 versions of my work to use one in development stage and something quite different for the projects in the field. I'll guess, I need to create a proto-demo-board.
I will now be working with the Basic I2C next to get back to saving some settings with the smallest footprint. Just as I thought I was done with debugging and reprogramming this project.
The OBEX has listings for Category, Author, Attributes, Version, downloads and update. It would be really beneficial to have another listing section for base and/or cross platform as to what the object was written for use with. Be that Stock or custom boards and circuit specific details. Some do include details in the header or documentation. I've really had to seek out many of the finer details elsewhere in or out of the forums.
Yes, I know they are a free offering......sorry, I did not mean this to sound like a rant. Just wishful thinking for others considering this path.
$0
Like when I tried Kye's I2CEngine and found it was made for use with pull-ups, but the demo board had only one. Regroup, find another obex offering and learn to work within its methods. The Propeller Eeprom.spin was created for the 256k eeprom. Fine for the demo board.
Now I find after getting Propeller Eeprom functioning on the demo board and transferring my work to another stock product to package the final product on a protoboard, I find my R&D coding time and learning curve begin anew. The protoboard has both pull-ups and a 512k eeprom, which does not seem directly compatible with Propeller Eeprom.spin. At my current knowledge level, I don't see anything in it that can be changed to make it work with a protoboard. I could not find a thread that explained why it is not compatible or how it could be made so.
Part of this frustration was the potential for needing 2 versions of my work to use one in development stage and something quite different for the projects in the field. I'll guess, I need to create a proto-demo-board.
I will now be working with the Basic I2C next to get back to saving some settings with the smallest footprint. Just as I thought I was done with debugging and reprogramming this project.
The OBEX has listings for Category, Author, Attributes, Version, downloads and update. It would be really beneficial to have another listing section for base and/or cross platform as to what the object was written for use with. Be that Stock or custom boards and circuit specific details. Some do include details in the header or documentation. I've really had to seek out many of the finer details elsewhere in or out of the forums.
Yes, I know they are a free offering......sorry, I did not mean this to sound like a rant. Just wishful thinking for others considering this path.
$0
Comments
Yes, most of us have felt your pain at one point or another. The OBEX is something like the wild, wild west around here - opportunities and pitfalls galore. Forum members have made suggestions and complaints, have yearned openly for standards and required documentation of some sort, but it continues to remain mostly a free for all, both a blessing and sometimes a curse. On the other hand, it makes for an active forum - I'm always on here begging for help. :-) Yeee haw!
-Phil
Pretty much as I gathered, without accidently raising ire of the brilliant object writers…..if there were a field to insert this helpful documentation I think it would fall in place as a natural element in the mix.
You are among many of my favorite reads here. I know there will be a treasure of information within your responses to the discussion subjects held here. Some contributors just have a knack for cohesive inquiry on any subject matter bringing out the finer points I only hope to gain. Despite my noob tone, I am absorbing little pieces of this wonderful world of the propeller so many are willing to share.
My purpose here is somewhat of a hobby/occupational related Holy Grail. A goal in developing adaptive technology for the Blind and Deaf Blind in some industrial manufacturing fashion or another. Although I must admit there is a mutual benefit here as well. I get to retain my hard fought electronics education along with my fascination of controlling/interfacing devices in the real world. Double reward for the challenge so to speak?
I do try to be resourceful within the realm of what is available here, but realize my endeavors are not a common application. Fitting what I do find into my application is quite a joy. Only when I have exhausted the history of the forum and web, I post for some SOS alert where I am lost. I'd rather comprehend a concept for my goal on my own than ask inane question that annoys those that have answered the same verifiable question with a simple search of the archives.
I let this frustration set for a few days before posting something ihair-triggered or self loathing
Even so, I’ve learned a ton in this R&D process with fewer regrets than I have a right to. It is still a worthwhile set of projects from the in-house feedback so far.
$0
I don't. I lean on this forum like a drunk on a keg of beer. I can't seem to live without it. When it comes to electronics, I stagger around in darkness almost all the time, but the good people on here always somehow pull my rear out of the gutter and get me back on my feet. So moral of the story is: feel free to ask questions. Projects like yours are what keep the gurus like Phil, et al, from getting bored.
Please don't take this thread wrong. My noob ignorance is not posted to shame anyone here. Can we relate this to playing Mahjong with someone else funding? LOL!
No fault to either designer. More along the line of documentational collaboration of loose ends is all. I am a firm believer in common sense, provided one has exposure to what is common to the subject at hand. As a beginner does not know enough to discern the difference or intentions of either offering. Let alone these pitfalls to avoid mating the unknowns prior to the ah s&&t moment. Obviously there may be no covering for all custom combination conditions of course.
Contributors in the OBEX know what peripheral they are directing their work for. Listing if it was written for stock or custom environments could simply be essential time savers. Not everyone is at a level to mod boards or objects to suit or re-mod due to exchange to another stock prop board product with subtle difference in its get along.
After all, this is just a follow on the legacy of Basic Stamp and SX version compatibility.
$0
There is no difference between using the 256K and 512K provided you only use the lower 256K (32KB). Normally, only the lower 32KB is used. You have to use specialised code to access above the 32KB limit.
Should you require the pullup on SCL, it should be quite simple to add one.
I feel your frustration about documentation. But you can't get around it. I2C objects are only half the battle. If you can't find an object or example that is written for the specific device you want to use, then you have to dig into the data sheet for the device in question to see how it specifically has implemented the I2C protocol. Sometimes, that really means dig and read between the lines, and experiment. Often these devices have what may seem at first like a multitude of internal registers that have to be set up before you can feel joy. Or, there are variations. For example, different manufacturers have different schemes for addressing eeprom memory above 64kbytes.
Don't hesitate to ask questions about specific devices. Usually problems are not so much the specific development board or I2C object, as they are the device itself.
My working version of I2C store and restore on the Demo Board using Propeller Eeprom.spin does not seem to get along on the ProtoBoard.
The protoboard does boot with my project and everything else works as expected. SD card and audio voicing, TV display and color selection, Hall effect sensor for count pulses. It just won't save my settings with a button press so they persist through a power outage as did the Demo Board.
Maybe I am jumping the gun here, but nothing else in my method or the objects has changed. I'll go back and look again and run it back on the demo board. I have verified the program flow does get to the I2C write method.
Here is a pic of what my suggestion for a compatibility field would look like. Naturally, in the case of non-stock board the user will need the experience to mod the object into submission. In the case of stock boards, or with minor tweaks to make an object cross compatible.
PDB= Prop development Board
DB= Demo Board
Pstk= Prop Stick
C/st= Custom, non-stock
Take it for what its worth.
$0
I guess I best humbly eat crow or pull a steel toed redwing out of my mouth.
I did jump the gun on this one out of frustration. The Propeller Eeprom.spin has proven to be working with my protoboard after some changes to my program that were trouncing on the settings array after restoring. That made it appear nothing was getting to the eeprom via save. I still do not know why my program worked with the demoboard as it was left while I built up I/O and power holdup circuits on the protoboard.
Not really worth going backward to find out the transition failure now that it is behind me and the demoboard stripped of parts on its breadboard. Part of this challenge is in proving ones conclusion right or wrong, as long as we learn from the experience converting frustration into success.
All is well again going forward, although my suggestion above could still be handy for a minor addition to the obex attributes list. True enough, it wouldn't have helped me in this circumstance.
$0
I have seen one device though that needed the "initialize" function in Mike Green's code.
Perhaps that's related to not having a pull-up on SCL...
The only surpise is that I figured out the problem was my code not the boards differences that can cause incompatability with objects due to the lack of pullups. I am still puzzled by my code that ran without a bug on the demo verses what I found on the proto and it had nothing to do with I2C. The bug ended up being my restore timing at boot and passing variables to the TV object. When that bug was introduced must remain a self inflicted mystery.
As I understand it, the I2C initialize prefered practice is due to setting the chip in a ready known state subsequent methods expect for reliable access.
Could well be related to the potential for SCL left floating without a pullup or simply rectifying the unknowns experienced by finding unexpected states.
I find in reverse engineering others methods and objects to learn the concepts the author used, eventually leads me to their logical purpose. The obvious doesn't sink in until I have that Eurika-Aha! moment. Trying to use those concept in my own application is about like hearding wild cats. Taming them first helps!
The bad news is that it is hard to search the OBEX for the right object (so ask someone to recommend the good ones).
A whole different issue is how one learns today's electronics. When I started out, there was not digital and only the occasional transistor. Much has changed, but good education texts on theory and practice of electronics haven't kept up with the rather fast pace of development.
So sometimes you just have to pick up information bit-by-bit; like the concepts behind pull-up resistors. The OBEX was really intended to provide code, not complete build data. If you want to learn that, "What's a Micontroller" is a good Parallax book available in download. Or try the Propeller Educational Kit.