Modular subsystems
gtmize
Posts: 9
Rather than building one off subsystems I’ve decided to construct modules which I can use on different robots or other projects.
·
For example ·for infrared Sensors, Sonic Sensors, or RF communications I’d like build them once and use them on multiple projects.
·
Although some modules like this are sold, the selection appears to be limited, and non-standard.
·
So, if I want to “roll my own” for a wide range· of components I need to develop standards around things like, a common bus or serial protocol and power.
·
Has anyone attempted to do this?
·
For example ·for infrared Sensors, Sonic Sensors, or RF communications I’d like build them once and use them on multiple projects.
·
Although some modules like this are sold, the selection appears to be limited, and non-standard.
·
So, if I want to “roll my own” for a wide range· of components I need to develop standards around things like, a common bus or serial protocol and power.
·
Has anyone attempted to do this?
Comments
Question - Should I just assume the best way to network multiple sub-modules is via say a 2 wire protocol?
Question - I'm also guessing that the master BS2 would soon be overwhelmed as the number of sub-modules requiring attention grows, so I'd also have to add subordinate processors ( BS2s? ) ..
Question - Physically, I'd like to plug-in each submodule into some bus arrangement .. any suggestions here?
THanks.
Sure, they didn't reinvent the wheel....but so long as you have, usually, +5volts/gnd/serial control (SPI/RS232/RS485/etc...) then you can move their modules from one application to the other!!
Say, you're Sonic sensor is RS485 and yet you're controller is only RS232....you can buy an IC that will translate for you....maybe in creating your 'boards/modules' you'll leave a switch option to choose between the different communication protocols.... But now the question...which protocols? All of them? That can turn in to a lot of ICs to translate for you....hence more $$. Of course, you could build the boards so that you'd only need to solder in the ICs you'd need for a given application....but now this isn't all that "one-off" or universal/generic of a module (you can't just lift from one and take to any)!.
Current Loop (I2C is it??) is a way to transmit, over copper lines, for ~3km distances. You can hook things up in a giant token-like ring and address each one.
Only problem with this one is that it's a ring....in series....so one item goes down, it takes down the rest of the ring!
TTY (Teletype) systems would insert a 'jumper' when their machines were suspected of taking down the ring/network.
what distances are you looking at? I'd stick with rs232, as this would allow you to directly plug it in to your PC to debug/troubleshoot!
I think it's been discussed on here that 1wire can be a PITA....in regards to the DAllas 1 wire comms.
The simplest to impliment is rs232 in my opinion!!
AS far as hardware....you should investigate the SX (not the BS2SX)...but the SX/B chips that parallax retails! They do all taht the stamp does....but are much cheaper...OH, and faster!
I keep hoping to get a kit....but maybe for christmas (I keep ordering more gear and stockpiling it for SOMETHING! haha).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
Your thoughts and efforts to develop a "standard bus" or common access method, while laudable, is highly impractical in the world of microcontrollers which are based on the MicroChip PIC processor. These are NOT bus oriented devices (in the true sense of the general definition), although a common communications pathway could easily be established. There are many aspects of real bus oriiented systems which either can't be done practically, even if they could be done, or aren't worth the effort. It's always best to play into the STRENGTHS and not the weakensess of any processor.
Before you get too far along in your thinking, just remember that ALL of the more advanced Stamp processors permit 8 (or more) separate banks of program code. By viewing these banks as the modular sections which you seem to want to exploit, there is ONLY need for INTERNAL communications between the banks, since they exist on the same underlying processor. The biggest development challenge here would be the design of a common communications area, not unlike the COMMON facility (which see) in many other languages (FORTRAN is one example). Just because the COMMON facility doesn't exist per se in the PBASIC Language, doesn't mean that it can't be simulated. If properly designed, you wouldn't even have to use the same bank for the same function in every program. It could very easily be table driven, within the Slot 0 (aka MAIN) module.
On to the questions you posed:
Question 1 - Should I just assume the best way to network multiple sub-modules is via say a 2 wire protocol?
Answer 1 - It all depends on what the module is doing, and what you mean by "network". Think about what I said above, using the separate program banks, and everything which exists on one processor is essentially "self-networked" through this COMMON technique I was suggesting. If the need arises to communicate between different PROCESSORs (multiple Stamps, PICs, etc), there are really only two choices in my mind; synchrounous or asynchronous serial communications.
With synchronous serial you would be using either SHIFTIN / SHIFTOUT or the I2C commands on the more advanced Stamps. The potential downside here is that the Stamp can only act as a Master if you implement the actual I2C (or similar) protocol. This is both restricting, and not truly network-like, although bi-directional communication is certainly possible, using your own communication scheme. My thought here is why try to re-invent the wheel if it isn't necessary to do so?
With asynchronous serial communication you would be using SERIN / SEROUT as the communication link. Ordinarily, the protocol used with PBASIC Stamp communications is the RS-232 protocol, however, for your perceived needs you might want to investigate the use of RS-485 which permits MASTER and SLAVE relationships with ADDRESSABLE NODES! That latter aspect may give you exactly what I suspect you're looking for. For more information about implementing RS-485 in a multi-drop network, please download Jon William's excellent "Nuts and Volts" magazine articles numbered 55 and 56 from here:
http://www.parallax.com/html_pages/downloads/nvcolumns/Nuts_Volts_Downloads_V2.asp
Question 2 - I'm also guessing that the master BS2 would soon be overwhelmed as the number of sub-modules requiring attention grows, so I'd also have to add subordinate processors ( BS2s? )
Answer 2 - By the very nature of a "master", the master can never be truly overwhelmed. The master has complete control of all the subordinate slave units, and tells them what to do, and when to do it. That being said, it IS possible for a master to spend more time than is appropriate, practical, or efficient, in tasking the slaves, or however it must service them from time to time. In this case, you need an interim communications processor which acts as a common "commutator" or hub for the entire system. Classically it will be a faster processor than any of the others. Tasking will usually be asynchronous to the master's requests. Thus, timing and dispatch control become critical elements in the design of such a system. A formal software protocol will be required to assign TASKID's, PRIORITIES, BUSY-READY SIGNALLING, TASK DEPENDENCIES, and be also able to pair task requests with the subsequent task complete responses. This is probably more than you want to get into, but well within the capabilities of an inter-networked microprocessor system.
Question 3 - Physically, I'd like to plug-in each submodule into some bus arrangement .. any suggestions here?
Answer 3 - As noted above, the only bus you may need will be 2-3 wires, based on the particular communications methodology you choose to use. It might be worth noting that RS-485 is a differential mode link, so longer physical links (read: wires) are possible than with most any other form of simple serial communications.
I hope that gives you some ideas to think about.
Regards,
Bruce Bates
BEFORE REINVENTING THE WHEEL, MIGHT I SUGGEST A THOROUGH REVIEW OF THE SITE http://www.hth.com/snap/ .
IF YOU DON'T USE IT. IT MIGHT JUST GIVE YOU SOME POINTERS THAT WOULD BE INVALUABLE.
73
SPENCE
K4KEP
To clarify all submodules would be local not remote.
Many threads get hijacked or just plain change topic, regardless of the subject heading!
So knowing the search function is handy....although I still have a hard time finding threads I've read previously!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
- True peer to peer networking. No master is necessary to coordinate bus activities
- A number of built in error detection and recovery features
- 2-wire bus at speeds up to 1 Mbit/sec
- Message priorities
Parallax sells a CAN controller (#30011) for the BASIC Stamp. The Stamp communicates via serin/serout and has full control over the CAN controller.
You may also find the following articles useful:
http://www.sensorsmag.com/articles/0805/29/main.shtml
http://machinebus.com/documents/whitePapers/canOverview/canTechnologyOverview.pdf
Hope this helps,
Dan Mannisto
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Steve
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."