3 propeller board
Sariel
Posts: 182
Hey all!
I have been looking around for some elegant solutions to connecting 3 propeller chips together with an XBee radio using some kind of serial bus. There are a few suggestions out there, but none that I can see does what I am looking for.
What I envision is 3 propellers and an XBee module on the same bus. The XBee would work as a transparent bus monitor with the ability to issue commands from a serial terminal or other microcontroller, just like if it were another microcontroller in the chain. The basic theory of operation would be to hold a busy line high, output the destination prop ID number, then the data, then drop the busy line low to signal EOT. Seems pretty straightforward, but from what I can tell, no FullDuplexSerial object would work because mixing the TX and RX lines from 4 devices wont work for obvious reasons. This breaks compatibility with the Xbee.
I looked into 1 wire serial objects, and nothing is really catching my eye as an end-all solution. Can anyone suggest a starting point for me, or is this even possible?
I have been looking around for some elegant solutions to connecting 3 propeller chips together with an XBee radio using some kind of serial bus. There are a few suggestions out there, but none that I can see does what I am looking for.
What I envision is 3 propellers and an XBee module on the same bus. The XBee would work as a transparent bus monitor with the ability to issue commands from a serial terminal or other microcontroller, just like if it were another microcontroller in the chain. The basic theory of operation would be to hold a busy line high, output the destination prop ID number, then the data, then drop the busy line low to signal EOT. Seems pretty straightforward, but from what I can tell, no FullDuplexSerial object would work because mixing the TX and RX lines from 4 devices wont work for obvious reasons. This breaks compatibility with the Xbee.
I looked into 1 wire serial objects, and nothing is really catching my eye as an end-all solution. Can anyone suggest a starting point for me, or is this even possible?
Comments
Yes, all things are possible, and sometimes they are very simple to implement. I would just have my own serial receive that also responded to address bytes to enable or disable passing data. Say $F0 disables all, $F1,$F2,$F3 selects any device, $FF is global. The transmit routine simply leaves the line floating with a pullup so that any one can respond on the common transmit. The command interpreter is Forth itself of course so you have complete control over each Prop and even reprogram it in this manner over the Xbee. This is a simple scheme I used many many years ago in POS terminals (not Xbee but) and it worked very well. In the case of Tachyon Forth the receive routine actually has this option that can be put back in and then the transmit would simply float the line when it's done as it also has the option. No need for any FDS objects etc. I could easily give you the code that works except it would be in Forth of course!
Wouldn't that be cog hungry to have that many serial objects? At that cost, I could just use 2 props, the XBee, and FDS and save myself some code. I am finding that my latest project is cog hungry, and I want to conserve as many I/O's as possible. Ideally, I want to do something that makes use of one cog and 3 I/O's per Prop. With this idea, wouldn't I use 4 I/O's and 2 cogs per prop, plus the XBee requirements? Using nearly half of my resources just to connect the props together seems like a waste.
Peter Jakacki:
This is interesting. My original idea was to have all of the Props cascading with a common serial bus. It sounded good in my head, and I even started building the board. It wasn't until I started actually writing test code when I realized tying all Tx to Tx and all Rx to all Rx would result in nothing short of a train wreck. (need to stop having my brilliant ideas at 2 in the morning) This is when I started thinking about 1 wire serial options since I have a board now that has 3 pins from all the props connected anyhow. Can you go into a little bit more depth in your explanation of this? I'm having a hard time visualizing what you mean. Maybe a quick schematic or block diagram? you say "floating pins", and I think "No Connections"
What is it with Forth? Jeez guys! Isn't Spin and PASM good enough? *wicked grin* I hear nothing but good, but think "Man I don't want to learn a new language.
Hardware wise there is nothing to it, you just join the 3 Prop's rx pins together and the same with the Tx pins too although it wouldn't hurt to have a small value resistor (220R) in each transmit line just in case. Since any Prop needs to pulldown the transmit line (active) then that means that none of them should be trying to drive it high so in this case when a Prop isn't selected it must float it's transmit line by releasing the corresponding DIR bit (same as an input). But if there are no Props selected the transmit line is just floating with no set voltage on it so we just add a pullup resistor of around 10K to this to prevent false signals from being received at the Xbee end. This is how simple the hardware is:
Now if you want your software to be just as simple with a built-in "command interpreter" and OTA reprogramming capability then I would recommend Tachyon Forth. But if you want to do it the hard way.....
Lol I suppose I could take a peek. I know nothing about forth, But I'll give it a go if it really is that simple. Mind including that code you spoke of? I'll download tachyon later this eve if I have a chance.
I'll do better, I will test it out on the bench and post the code, but not right now, best not start something new at 2:30 in the morning
It will be surprisingly simple, I will just revector my KEY input to handle the control codes and float the transmit if it's not selected. At reset the unit will be deselected and once it receives its address code it will unblock the input stream and enable the transmit output. If all units are selected via a global address then it will unblock the input stream but leave the transmit disabled, this is for when you want all units to act in unison to a command or even for reprogramming. Anyway with this arrangement you can hook up a terminal emulator on the control side and converse with any Prop and debug it live. For convenience in this case we can use regular control characters for addressing the Props, such as ^U ^V ^W etc rather than binary $Fx.
-Edit
Now that I think about it, don't worry about control chars. I would prefer hex . In the end application, the other end of the XBee will be connected to a remote control with another prop, 4x20 NewHaven LCD display, a few buttons, and some other controller-like features. The addition of a ps2 keyboard port will be only be for rare times.
You would need the FDS cog and 4 I/O lines. I don't see how that equates to half the Prop's resources. It's just worked well for me since every project I've design required the FDS cog for something or other but there were always at least 2 transceivers unused that I could spend for this purpose. And the XBee requirements would only involve the first Prop in the chain.
Thanks, Marcus