no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | livebox:xap_bridge [2011/10/10 15:10] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== xAP Bridge ====== | ||
+ | <box red> | ||
+ | **DEPRECATED**\\ \\ | ||
+ | Build 279 was the last build to have this module\\ | ||
+ | Using [[xap_serial]] you can achieve much the same thing | ||
+ | </ | ||
+ | |||
+ | See also [[xap_serial]] for an even simpler serial interface. | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | //xAP is, so far is as practicable, | ||
+ | |||
+ | In some cases, the bridge may provide a configuration interface to allow traffic in one or both directions to be restricted. | ||
+ | |||
+ | A proposal has been made to permit messages to be flagged " | ||
+ | |||
+ | Messages passed over the bridge always have the xAP-header hop count increased. A bridge may be configured to discard messages with hop-count > n to prevent looping/ | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | The xap-bridge will allow xAP compliant hardware to extend the functionality of the [[HAH]] [[livebox]] implementation. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Using a USB hub and a set of RS232/USB adapters, such as the ubiquitous //Prolific USB-to-serial dongle//, a large number of external hardware devices can be supported. | ||
+ | |||
+ | This configuration of xap-hub/ | ||
+ | |||
+ | The bridge not only acts as a Ethernet/ | ||
+ | |||
+ | The xAP serial devices must wrap their xAP message in a [[http:// | ||
+ | ===== Implementation ===== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | The xAP bridge uses two threads separated by a FIFO (First in First Out) buffer to hold packets generated on fast networks for transmission to the slow networks, typically for the Ethernet to serial flow, but also high speed serial to low speed serial. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | The **Rx Thread** processes all serial data through the state machine above, the state is preserved for each serial port and as the data stream is read the machine continues to process the bytes until a valid xAP packet is produced. | ||
+ | |||
+ | The xAP bridge will use the common ''/ | ||
+ | |||
+ | <code ini> | ||
+ | [bridge] | ||
+ | enable=1 | ||
+ | hopCount=5 | ||
+ | forwardHeartbeats=0 | ||
+ | s1=/ | ||
+ | s2=#/ | ||
+ | s3=/ | ||
+ | </ | ||
+ | |||
+ | * **enable** default 0. This attribute is examined by the / | ||
+ | * **hop-count** default 5. As a packet passes through the bridge its hop count will be incremented packets can be dropped if they exceed a certain number of hops. | ||
+ | * **forwardHeartbeats** default 0 (off). | ||
+ | * **s< | ||
+ | |||
+ | < | ||
+ | |||
+ | < | ||
+ | |||
+ | The < | ||
+ | * TX - The bridge will send data to the serial port but never read anything from it. | ||
+ | * RX - the most common scenario, the micro controller will generate data for the bridge to receive but does not accept data for processing. | ||
+ | * TX RX - a full duplex conversation. | ||
+ | |||
+ | If you not specify at least one TX or RX option you'll effectively disable the port. The xmit directive helps reduce the workload on the bridge when prior knowledge about the traffic on the serial interface is known, if you don't know supply TX RX. | ||
+ | |||
+ | A serial port on a bridge may supply data to a serial port running yet another bridge. In this way serial cables can be used to extend the reach of your xAP network increasing the hop count at each bridge. | ||
+ | |||
+ | Browse source http:// | ||
+ | |||
+ | Linux executable R29 {{xap-bridge-linux-i386.tar.gz}} | ||
+ | |||
+ | ==== Input Modes ==== | ||
+ | |||
+ | Values of the c_iflag field describe the basic terminal input control, and are composed of following masks: | ||
+ | < | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | </ | ||
+ | |||
+ | ==== Output Modes ==== | ||
+ | |||
+ | Values of the c_oflag field describe the basic terminal output control, and are composed of the following masks: | ||
+ | < | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | </ | ||
+ | |||
+ | ==== Control Modes ==== | ||
+ | |||
+ | Values of the c_cflag field describe the basic terminal hardware control, and are composed of the following masks. | ||
+ | < | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | </ | ||
+ | |||
+ | ==== Local Modes ==== | ||
+ | |||
+ | Values of the c_lflag field describe the control of various functions, and are composed of the following masks. | ||
+ | < | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | </ | ||
+ | |||
+ | ==== Speed ==== | ||
+ | |||
+ | The input baud rate is assumed to be the same as the output baud rate and must be one of these constants. | ||
+ | < | ||
+ | B0 | ||
+ | B50 | ||
+ | B75 | ||
+ | B110 | ||
+ | B134 | ||
+ | B150 | ||
+ | B200 | ||
+ | B300 | ||
+ | B600 | ||
+ | B1200 | ||
+ | B1800 | ||
+ | B2400 | ||
+ | B4800 | ||
+ | B9600 | ||
+ | B19200 | ||
+ | B38400 | ||
+ | B57600 | ||
+ | B115200 | ||
+ | B230400 | ||
+ | </ | ||
+ | |||
+ | ====== Bridge tester ====== | ||
+ | |||
+ | A simplistic xAP message generator for the [[: | ||
+ | |||
+ | Configuration for our bridge: | ||
+ | <code ini> | ||
+ | [bridge] | ||
+ | s1=/ | ||
+ | </ | ||
+ | |||
+ | MEGA-8 source code to generate an xAP message every 3 seconds. | ||
+ | <code vb> | ||
+ | ' | ||
+ | '* xAP message generator | ||
+ | '* Language: | ||
+ | '* | ||
+ | ' | ||
+ | ' Compile for the AVR-SDK board | ||
+ | $regfile = " | ||
+ | |||
+ | $crystal = 4000000 | ||
+ | $baud = 9600 | ||
+ | |||
+ | Dim I As Bit | ||
+ | |||
+ | Config Pinc.0 = Input ' | ||
+ | Config Pind.7 = Output | ||
+ | |||
+ | Set Portd.7 | ||
+ | Do | ||
+ | Print " | ||
+ | Print " | ||
+ | Print " | ||
+ | Print " | ||
+ | Print " | ||
+ | Print " | ||
+ | Print " | ||
+ | Print " | ||
+ | Print " | ||
+ | I = Not Pinc.0 | ||
+ | Print " | ||
+ | Print " | ||
+ | Print "state = " ; I | ||
+ | Print " | ||
+ | Print " | ||
+ | Wait 3 | ||
+ | Toggle Portd.7 | ||
+ | Loop | ||
+ | </ | ||
+ | ====== Bridge aware hardware - an RF Receiver ====== | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | The Livebox PCB has a built in RF Transmitter. However, there is no ' | ||
+ | |||
+ | A Nokia phone USB cable will connect the microcontroller UART to the Livebox. | ||
+ | |||
+ | The USB phone cables that we purchased have three conductors. Wire colours are as follows (if you buy your own cable, the colours may well be different) : | ||
+ | |||
+ | Pin 8 - Orange - Ground \\ | ||
+ | Pin 7 - Red - Phone Tx \\ | ||
+ | Pin 6 - Blue - Phone Rx \\ | ||
+ | |||
+ | The first physical device that we will look to support is an RF PIR unit. | ||
+ | |||
+ | This PIR has a ten way dip switch to allow the 'house code' to be set. Hooking the output of this up to a 'scope gives us the following waveforms [[http:// | ||
+ | |||
+ | As you can see, there are 41 ' | ||
+ | |||
+ | A test rig was assembled to hookup the Rx socket to the AVR micro. The 'data out' line is hooked directly to the Int1 line on the AVR. By default (when no RF signal is being received), the data out pin seems to change state to ' | ||
+ | |||
+ | So, our code must cope with this behaviour. The initial design is as follows: | ||
+ | |||
+ | Configure an interrupt to occur whenever a falling edge is detected on the Int1 pin - easy to do this in Bascom. When we get the interrupt, start a timer then wait for the next rising edge of the stream. Since the time for a valid pulse is so very much shorter for that of an invalid one, the time difference will be easily noticed. | ||
+ | |||
+ | In order to build up a ' | ||
+ | |||
+ | Running the prototype gives solid results with reliable reception. The next job will be to design a PCB to hold the micro. | ||
+ | |||
+ | |||
+ | |||
+ | {{tag> |