PropBus, Single wire multi-propeller comm link
MikeChristle
Posts: 31
I just uploaded version 2.00 of the PropBus to OBEX. It has the same title as this thread.
The purpose of the Prop Bus is to provide a communications link
between two or more Propeller chips. This interface is very
loosely based on the MIL-STD-1553 interface. One chip becomes the
Bus Controller (BC) and all others are Remote Terminals (RT).
The interface uses a single wire, bi-directional bus. The data
is transferred using Manchester encoding at a 1MBit data rate.
All data consist of 16 bit words.
Enjoy
Mike
The purpose of the Prop Bus is to provide a communications link
between two or more Propeller chips. This interface is very
loosely based on the MIL-STD-1553 interface. One chip becomes the
Bus Controller (BC) and all others are Remote Terminals (RT).
The interface uses a single wire, bi-directional bus. The data
is transferred using Manchester encoding at a 1MBit data rate.
All data consist of 16 bit words.
Enjoy
Mike
Comments
1st question: have you looked at some the objects that handle 'SD chips'?
like http://forums.parallax.com/showthread.php/128553-Better-than-sliced-bread!-SD3.01-FAT16-32-Driver-Updated!
the reason I ask is perhaps the BC in your object could pass program code to a RT that it could boot on?
2nd question: does this code (not familiar with the MIL std you gave) compensate for the distance the prop (RT) is from the BC?
3rd question: any chance the physical medium could be changed to 'blue tooth' or ir-leds?
Thanx for posting your own thread on this subject. Nice work for a guy who has less than 10 post's
... Tim
The cool thing about Manchester encoding is that it encodes the clock with the data. Distance is not a problem. MIL-STD-1553 was designed for communications in aircraft. With a differential driver the RTs can be 100 feet apart.
http://www.aim-online.com/pdf/OVW1553.PDF
I'm not sure about blue tooth, but IR-leds should work great. I may be new to the Propeller (what a great chip), but I have been working with embedded controllers for 30+ years.
Mike
Nice project.
Any chance you would share your original C files? I'm interested in Manchester encoding for another communications project.
Welcome to the forum BTW. Happy 4th.
--Steve
I grabbed the PDF, will read it this weekend.
I'll keep an eye on this thread
No problem. See attachment.
The extension on this file should be .pc but that would not upload, so I changed it to .c.
Mike
Love your coding style!
PUB Start(Pin, Freq, BCount) {{ Starts the BC and starts cycling. This should be delayed until all the RTs have had time to setup their buffers. }}another question: "Do all the RT's have to be up and running before the BC start method is called?"
and, I don't know if this would fit with the protocol, could you have each RT hold the line low while setting up. Then release (open collector) the line when started so the BC could be sure it is safe to start cycling.
... Tim
In another thread, Cluso99 mentioned the Hijack project (indirectly).
The point of Hijack is to allow communications (and powering) a phone and a device connected via the audio jack.
Two Hijack communication methods are used: 1) 300baud FSK modem, and/or 2) Manchester encoding.
Seeing your project makes me believe it may be possible to program a (separately powered) Propeller using simple circuits for TX/RX.
I don't want to "Hijack" this thread by having some long discussion here (as usually happens), so I'll start another thread.
Would you be interested in contributing to such a project?
Yes. I have added a two cycle delay in the BC from when it starts until it starts cycling. If this is not sufficient, I have also added a method that allows you to take complete control of the buffer cycling, SendCmnd. The easiest option is to hold off starting the BC until all the RTs are ready.
This bus does NOT use open-collector. Do not drive the line LO. The problem with open-collector is that it has a very slow rise time. I could never get to 1 Mbit without using a very small value pull-up resistor. That would waste a lot of current and create a lot of electrical noise.
Mike
Possibly. Where is this new thread, I would like to hear more.
Mike
Oops .... I meant no offense here,
But what relevance does this have to my question? I was speaking about prior to the BC COG being started. So, there would be no communication at that point, true? My thought was, the last RT to 'setup shop' would let go of the line, and the BC could safely begin. That was the vision I had in my mind.
... Tim
To answer your original question, my code comment said 'should' not 'must'. The RT should start before the BC. Unfortunately, with the current version, this condition will cause the bus to lock-up. I am currently testing a fix for this so the bus will never lock-up. This involves adjusting delays and timeouts so errors are handled gracefully.
The problem with pulling the line low is that an active RT will see that as the start of a command and go into a timeout/retry loop. A safer solution would be to let all devices start as soon as the chip resets. If an RT is late, the BC will handle the timeout and keep running. You can tell that the RT is running when its buffer starts getting fresh data.
Hope this helps.
Mike
Trying to assemble a 3 prop version on the bench using your objects. One w/BC controller, another with a RT & BC (for a sub-bus) and the third w/RT only.
I think it should work as is! But, was curious about the extra delay from 'down stream' RT's and if any delay would affect the main bus ... perhaps that's not an issue? I'll know shortly.
... Tim
PS - this object is a real 'Gem'
I just uploaded Version 2.1. This version has been running on my bench for 2+ days now without dropping a word or locking up. Good luck.
Mike
The CAN bus Transceivers can run an 'or' wired bus at up to 2MBd on the newer faster ones.
They have much higher ESD and common mode tolerance than a direct controller pin, and lower RFI.
Some have fault timers, to prevent a hung node locking the bus.
You do not have to use CAN data-encode, but a device with a fault timer would need to idle in a known recessive state
Some examples
http://www.ti.com/product/SN65HVD266/compare
Support for such 'hardened' interface devices could be nice to add as an option ?
But, I think you miss the point of this object.
w/o any hardware .. you can couple several props together on the same PCB using one pin.
Suddenly, instead of 32 I.O pins I have over a hundred!
... Tim
Exactly, so why limit this object to same PCB ? - there are many cases where multiple PCBs make more sense, and many designs where there is ESD/RFI/Distance/Ground Noise to consider, as well as 'just connecting'.
I hope everyone had a safe holiday weekend. I'm still a little groggy.
The current version of PropBus provides a single wire interface suitable for designs where the chips are very close together. The only required external hardware is a pull-up resistor.
Now that this interface is running stable I plan to create a three wire interface version, RX, TX, OE. This version will control an external driver, like the CAN transceiver.
Opinions please:
Some drivers have an active HI output enable, some active LO. Should I program one, then assume the user can modify the code for the other? Or should I provide a programmatic method for the user to select output enable polarity?
Mike
- 1) It will mean that you as the creator do more of the handling and writing; saving a range of user error
- 2) You can make it clear and obvious on how to do it in the code (i.e. take care of newbies...)
- 3) It thereby makes more awesomeness more easy for more people.
Love it, btw.
CAN does not need OE, it uses an 'or' style BUS drive. ( so RX follows TX, which can be used to show contentions)
RS485 does have OE, and TI have some new interesting MSOP10 parts with separate RS422/RS485 options.
Std 8 pin RS485 (eg SN65HVD21A) seem to have both DE and /RE, so you can join DE to /RE and then join R to D in the Half duplex applications - which would reduce your pin count to 2.
A 3 wire connection would allow Duplex, but that is probably a new OBEX.
One detail to watch is when no device at all is driving RS485, you are relying on RxHyst to avoid idle noise effects.
CAN has a more deliberate offset threshold.
Software half duplex can ignore RX pins outside known valid echo times to mitigate this effect.
You can also wire a RS485/RS422 device to be 'CAN-like' if you pre-bias the BUS, and drive TXD->DE with D set to drive the BUS the other way.
I am currently testing the three wire interface with a pair of 65176 differential bus transceivers wire as a RS-485 bus, more details to follow. I looked at the CAN chip and decided that if I was to use a CAN driver I might as well follow the CAN bus protocol. Surely someone has already written a CAN bus object.
Mike
Basically, I'll replace the regular circuit board inside a servo with a Prop board.
If we stay with the original cable, there's only one data wire. Usually that goes directly to a Prop pin.
Sounds like this object could allow for bi-directional communication.
Might be nice so the servo can report status...
Any chance this would work if one of the Props is running in RCfast mode (20 MHz) ?
I think you are referring to the J1708? I have this built-in as an option on some of my RS485 products so that the 485 chip drives the bus in an OR fashion. As for protocols I prefer to use a form of asynch between Props, even 9-bit serial as used in some MCUs. In the simplest form there is no 485 chip, just a single I/O and a series resistor driving the bus. The simplest protocol just sends out an address byte and waits for it to be echoed for acknowledgement after which the units (any units) can communicate as if they were point-to-point but with a limited talk time. After they are done they can send a FIN byte and the bus is free for any other device to use. Some address bytes are reserved for broadcasts or group/class broadcasts.
I'd agree the semantics can appear confusing, but you do not have to use CAN on a CAN driver, as a CAN driver is really just a hardware variant, with an offset RX slicing level, and usually a monostable for bus-lock.
It also has an ability to sense bus-contention that could be useful.
Also some CAN drivers have higher BUS error tolerances. (eg +40v,-27v), which can be appealing in Motor apps.
As such, it is well suited to a shared bus that needs something more rugged than Pin-Pin connects.
A Software version that does 2 pin CAN driver, should also work through an Opto-isolated link, like 2 x H11L1.
I'm curious. What sort of bit rates can you get with this arrangement?
Mike
Yes. Although you might need to use a slower bit rate because of the 20 MHz clock, but that is a trivial issue. Once I do the math, I'll add some comments on the relation ship between clock rate and bit rate.
Mike
Sounds good. - and some comments on Clock-range tolerance ?
The circuit given above has 4k7 and 2n2, so it will not be fast, but if you have a lower-impedance pre-bias (& no C), the psuedo open drain design can go >> 1MBd.
Even on a conventional RS485 setup, some pre-bias can help noise immunity if you expect no-drive-from-anyone for significant times.
Today I am testing PrpBus with two QuickStrt boards, one in RCFast mode. Is there a way to do tis without using two computers. The Prpeller Tool doesn't seem to support two USB links.
Mike
Actually, I hope I can be helpful on this. I have been working on a multi-prop project and use the propeller tool for multiple boards. To do this you have to go into the preferences in "File & Folders" and UN-check off that "associated files launch into a single editor". Now you can open two editors for two different boards. You do this by opening the main file for each, and that project goes to that Propeller Tool.
Then you go to Preferences, then into "Operations" and manage Serial Port for that USB connection --> no longer AUTO, but the one for the board you are using.
Then you can switch between them with your keyboard, and keep a USB hooked up to each, and work on them at the same time. It has been very handy for me.
Looking forward to using your object !!