A customizable TP-UART interface
Here is the place for design notes, howtos, errata, ideas for further improvement - everything that is not documented in the PDF documents or the release package. Items will be added as they cross our mind or otherwise come to our attention...
The Wayback Machine has a copy of the schematic of the TP-UART interface developed at FH Deggendorf (Reference 3 in our paper). The corresponding paper by Stocker and Grzemba (Reference 8) does not contain information about the interface hardware.
GerbMerge looks like a convenient tool for merging (panelizing) Gerber files (especially from EAGLE).
A (hopefully) helpful note: On ACTIface, UART levels are straightforward. For both sides of the MSP430, logic "1" (i.e., Mark/Idle, RS-232 -10V) corresponds to a high (Vcc) voltage level.
Design notes:
Measurements:
The "typical application circuit" in the TP-UART datasheet uses SMD components. Since we wanted to use THT components wherever possible, we had to find equivalent types. Our thoughts concerning the diodes (U2, D1) were:
Instead of the SMAJ43CA (TVS diode), Christian Troger uses the Fairchild P6KE51CA in his interface board. We followed this decision, since the P6KE51CA has identical or better characteristics than the reference part:
Although the HER158G works perfectly for us, we cannot exclude that there may be an impact on the AC characteristics of the circuitry. To be sure, voltage traces at the cathodes of the two different types would have to be compared.
"Depending on the PC configuration, this is often propagated to the application as 0x00" (paper, p. 15): The 0x00 character comes from TP-UART TXD changing from high (which is the idle level, causing the PC side of the interface to transmit a space state) to low - provided the PC processes the UART character despite the framing error that is caused by the missing stop bit.
On power-up and when the TP-UART receives a U_Reset.request service, D6 prevents the TP-UART RESn signal from resetting the MSP430 via RST, ensuring that the TP-UART-Reset.indication can be properly passed on to the PC. However, if the reset button is pressed (or RTS is connected as a reset signal and activated), the MSP430 will start up too late and miss the Reset.indication service.
It would be possible to work around this by letting the MSP430 send a TP-UART-Reset.indication on its own after startup in case it receives no such indication from the TP-UART. However, to ensure consistent behaviour under all circumstances (it may be that the MSP430 was reset, but the TP-UART was not), the MSP430 should actively reset the TP-UART by sending a U_Reset.request in this case.
Simultaneous traces of EIB+, TP-UART VCC, SAVE, nRESET and TXD on bus power-up and power-down (with the buffer capacitors from the "typical application circuit") would be interesting.
Showing the end-of-packet condition as a break signal is elegant, since it is "out of band". However, if a serial port implementation can handle BREAK states, it is likely to translate them into an escape sequence anyway (asynchronous signals are another possibility, but would be inconvenient for our purpose). Glibc (at least on Linux) can either use SIGINT or an escape sequence: "If neither BRKINT nor IGNBRK are set, a break condition is passed to the application as a single '\0' character if PARMRK is not set, or otherwise as a three-character sequence '\377', '\0', '\0'." (man 3 termios). Therefore, it is probably more useful to use an escape sequence from the start.
Firmware for testing the hardware: Turn on all LEDs for 3 seconds, then map the state of each switch and button to one LED (just copy byte from input to output port for this). Echo back all characters received via RS-232.
Firmware for testing the U_AckInformation time frame (cf. page 10, par. 2 in the paper): When a frame appears on the medium (created with an arbitrary KNX/EIB device) , the MSP430 waits for the maximum possible time as described in the paper (the expected frame length would be set via the DIP switches or via RS-232) and then sends a U_AckInformation service. Any bus monitor can be used to check if the TP-UART actually sent a L2-ACK.
Firmware for generating faulty frames in analog mode (cf. page 14 in the paper).
A PC test/demo program that uses termios to access the serial port and can be compiled without changes on both Linux and Windows/Cygwin (only using free tools):
Design based on work by Matthew J Taylor, Free CSS Templates, Custom Web Design and styleshout - Project hosting by