Interface and Software - Max-i Fieldbus

Title
Go to content
Interface and Software
Evaluation and Interface Boards
Until the final IC solution is available, Innovatic can offer an evaluation board - EB1, which simulates a Max-i IC by means of an FPGA and other standard components. This solution may be very interesting for vendors, who want to take the step into the future and have a possibility to influence the standard before the IC is made. It may also be interesting for semiconductor companies, who may be looking for a new product family and/or can see the enormous potential in one fieldbus for virtually all low to medium speed applications from the most price sensitive ones to the most demanding.

EB1 simulates an 8-pin IC solution by means of an FPGA (Field Programmable Gate Array) and other standard components. Although there are only 8 connections to the electronics, the board is provided with a heavy duty, 20 A, 26-position clamp row, which is able to accept flexible conductors with ferrules with plastic sleeve up to 2.5 mm2 and rigid conductors up to 4 mm2. The many poles makes it very easy to make experiments as it is usually not necessary to connect more conductors in the same clamp. The module can be connected directly to for example LED's, opto couplers and solid-state relays and even to most RS-232 ports (with a triggering level of approximately 1.5 V above ground). You can also screw NPN and N-channel TO-220 and TO-218 power transistors and protected low-side switches directly into the clamp row and in this way drive loads up to 10 A, and there is an extra output clamp (OxA) for the collector or drain connection to the load so that not even in this case, you need more conductors in the same clamp. The module also has a programming connector, which can be connected to a USB port by means of a Microchip (previously Actel and later Microsemi) FlashPro3 programmer. This makes it simple and cheap to download new firmware versions as they become available on this page.

Because EB1 was designed for a previous version of the specification, it is not using 20 V, but only 12 V, and it has only 2 inputs and 3 outputs, but it can still be used for evaluation purpose and a new 20-V board with 8 inputs and 8 outputs, which comply with version 11 of the specification and can also be used for products (not just evaluation), is under development and expected to be released in Q2 2020.

Communication to Computers
Like for example DMX512 and LIN, Max-i uses asynchronous UART communication with "Break" to separate telegrams. This is the most efficient way for Max-i, which uses synchronous binary communication on the bus where all byte values from 0 to 255 are possible (no code left for separation). To be able to hold back the communication when the bus is busy, it uses automatic flow control based on CTS. Although this kind of communication is an over 40 years old de-facto standard, it is unfortunately still not supported very well in the PC-world.

First of all, the transmitter FIFO in the standard UART 16550 of the PC world has always been full of errors and flaws. In the first version, the FIFO didn't work at all although the circuit was brought to market! In the next version (16550AFN), the FIFO almost worked, but a byte written while the last byte was transmitted, was not always recognized so that you could lose bytes. In the following versions, this bug was fixed, but except for Texas Instruments, the designers still did not realize that a transmitter FIFO without automatic flow control is useless in practice, and although there are plenty of newer and better designs like 16C650, 16C750, 16C850 and 16C950, most chip sets in the PC-world still use the buggy one.

The receiver FIFO in 16550 is cleverer as it is 11 bit wide to enable 100 % synchronization between the received bytes and the three error and status flags - Break, Framing Error and Parity error, but with a little help from Microsoft that feature is efficiently destroyed! Microsoft takes 11 bits from the FIFO, use the three status bits to fire some events, which may be executed much later, and then throws them away, before the result is stored in a 16-bit stream, which could easily have contained all 11 bits. This makes it impossible to use any of the modern communication methods like 9th bit communication and telegram separation by means of Break because the vital synchronization between bytes and flags are lost and cannot be regained. This also means that in case of an error, all received bytes in the receiver FIFO and any following buffers must be thrown away because it is impossible to tell to which telegram an error belongs!

To make it complete, Microsoft has only two flow control options - None and CTS, but it is not possible to specify whether CTS shall be handled in hardware or in software, which may be too slow. Besides, they do not fire an event when the transmitter serial register becomes empty (if this is possible) so it may be necessary to listen to one's own communication to control the modem signals in a reliable manner, and they pass all signals through at least one level of task switching so that it for example is impossible to generate Break conditions shorter than 11-16 mS unless it can be done in hardware.

USB-Serial Converters
Today, most PC's do not have an RS-232 or RS-485 port and may not even have space for an extension board, so it is very common to use USB-serial converters, but some precautions are necessary depending on the manufacturer:

Devices from Future Technology Devices International Ltd. (FTDI) like the FT232(x) series:

These devices are not recommended.

  • Although the data sheet claims that the devices support Break detection, this support is so limited that it is useless in practice. The receiver FIFO is only 8 bit wide and every time a special event occurs, this is reported in the first byte of a USB transfer. Unfortunately, "Break" is not an "event character" so in case of more telegrams immediately after each other, it is impossible to separate the various telegrams and even if it were, the very short telegrams of Max-i would course so many USB transfers that the maximum speed would be rather limited.
  • When used together with SerialPort of Microsoft .Net, more break events are sometimes reported than actually transmitted, and the state of CTS is not reported correct except just after initialization of the driver.
  • Although the data sheet claims that there is automatic flow control, this is only partly true. When CTS goes low, the devices may continue to transmit up to 3 bytes more, which is too much for the Max-i controller, which only has a 3-byte FIFO where one byte is the UART shift register. In practice, all telegrams course overflow except for a poll of a value with a short identifier! Note that most microprocessors with build-in UART have an even shorter FIFO than Max-i - usually only a single register, so the FTDI devices are as useless for communication with these kind of devices as they are for communication with Max-i.

Devices from MaxLinear (previous EXAR) like the XR21V141x, XR21B1411 USB-UART family:

The MaxLinear family has a 384 x 11-bit receiver FIFO and a 128 x 9-bit transmitter FIFO. They also have a Wide-mode i hardware where the devices transfer two bytes for every byte received - one with data and one with status. In this way, it is possible to work around the Microsoft limitation and use advanced communication methods, but unfortunately the two bytes are not marked as status and data so it is possible for the communication to get out of synchronization. The devices are also able to force a USB transfer if a period corresponding to 3 bytes has elapsed without any reception and it can generate a timed Break, which, after all, is better than a software controlled Break, but there are still some problems:

  • If a timer value is written to the TX_BREAK register, a Break with the specified time is generated as soon as the serial register (TSR) gets empty and no matter the state of CTS! This means that if there are any data in the FIFO, the Break will be generated before the last byte has been transmitted, which will destroy the message, and since Break does not take CTS into account, it may even cause an overflow in the Max-i controller! This is certainly not very clever.
  • Break is not specified as a number of subsequently 0-bits, which would be the ony appropriate thing to do, but in milliseconds (ms). Since the minimum value is 1 ms, which will cause the time to be between 1 and 2 ms, a Break will usually take longer time than the message itself at all speeds above 76.8 kbit/s. This limits the maximum number of telegrams a factor 30 - 60 at the highest UART speed (4 Mbit/s) where a 5-byte message itself only takes approximately 32 µS!
  • There is no way to tell when the serial register (TSR) is empty. It is only possible to tell when the FIFO is empty, but this does not guarantee that it is safe to send a Break when CTS is asserted because more data could be loaded in the FIFO in the meantime. If the test for FIFO empty and CTS is only done once, it fairly frequent happens that Break is activated while CTS is de-asserted, which causes an overflow in the Max-i controller. In practice, it is necessary to do the tests 3 times after each other before Break is activated to get a sufficient reliable communication for uncritical applications.
  • It is not possible to use an external (x4, x8 or x16) clock for the UART so the Max-i controller needs to have a very accurate (external) clock and every time a speed is changed, it is not enough just to set it in the Max-i controllers, which is easily done by means of two common network telegrams - one to set the new speed and one to confirm it and store it permanently.
  • The driver seems to be a standard Microsoft driver, which does not support any of the advanced settings in the circuits. For example, it is only possible to set the FIFO sizes up to 16 bytes corresponding to a standard 16C550 UART and it is not possible to select the wide mode.
  • The driver does not fire the .Net SerialPort PinChanged event for Break characters, which makes it useless for Max-i unless the circuit is put into Wide mode. The PinChanged event works all right for DSR and CTS.
  • The driver or the circuit generates numerous Break's (00 bytes) when the driver settings are changed such as port name (COMx) or flow control.
  • There is no way to set the properties of the USB part like the number of 64-byte blocks for each transfer (for Max-i, this number should be 1). You can only hope that the default settings are what you want.

It is easy to utilize the wide mode by means of for example native C or C++ programming, but nowadays most Windows programmers use .Net and managed code and "of course" there is no direct way to communicate with the driver that way. SerialPort of .Net has no method to return the handle of an opened port and many types are private. The only way to get the handle is by means of a reflection hack, which gets it from the generated code. By means of this handle and a little unmanaged code it is then possible to put the MaxLinear circuits in wide mode and utilize the Break generation. It is not very pretty, but it works - at least for uncritical purposes. The combination of the block oriented USB, which does not fit very well with short messages, and the horrible Microsoft implementation of Serial Port is a very bad combination, which is not recommended for any critical purpose.

In practice, there are at least three solutions to the communication problem:

  • Use a microprocessor with a good UART and an Ethernet port to interface the Max-i controller to a LAN port by means of UDP/IP. This is properly the best solution and it has the advantage that it is inherent galvanic separated by the magnetics. Besides, it enables WiFi communication to mobile devices if rare errors due to reduced speed and/or interference can be accepted. Since Max-i and other fieldbus systems cannot guarantee that all data always come through and all commands are always executed - the necessary power or pressure may for example be missing, there is no reason to use TCP and 10 Mbit/s may therefore be enough. A fieldbus system should instead check the status of the process regulary and after each command.
  • Use for example a 16C950 UART from PLX Technology (previous Oxford Semiconductor) and write a driver that uses 16-bit buffers and preserves the synchronization between bytes and flags. This is also a good solution, but it will usually require an extension board, which may not be available or possible to mount.
  • Use the MaxLinear XR21V141x, XR21B1411 or any newer family of USB-serial converters in Wide mode as shown in the test program. This is good enough for debugging and user interface, but not good enough for example for industrial automation.

Test program
We have a small test program written in Microsoft VB.NET for framework 2.0, which is the only tested .Net version, where you can live with the bugs. It throws an unhanded exception if you remove the USB plug, but otherwise it works. All newer versions up to at least 3.5 SP1 are completely useless. Microsoft tried to dig down in the "hornet's nest" to fix the bug, but didn't succeed and instead destroyed everything! You can download the entire source code as zip file here: www.max-i.org/MaxiTesterExar.zip or just the executable: www.max-i.org/MaxiTesterExar.exe . When the zip-archive is unzipped, open the folder MaxiTesterExar. You can then choose to open the VB program by clicking on MaxiTesterExar.sln or you can navigate to the exe file in MaxiTesterExar/bin/Release/MaxiTesterExar.exe. The test program will be updated from time to time as new features are added, but the version should be at least V10.0 to be usable with specification 10.x and 11.x (check the name in the upper left corner of the form).

The test program is default in UART mode for use with everything else than a MaxLinear USB-serial converter. In this mode, a transfer is triggered when the Break event fires. Because Microsoft doesn't preserve the synchronization between data and flags, our test program cannot always recognize telegram boundaries in this mode. At low telegram rates it works quite well, but at higher rates, it is not able to separate the various telegrams. Note that if you try to use the program in this mode together with a MaxLinear USB-serial converter, you will not receive anything as these circuits do not fire the PinChanged event when a Break occurs.

If you have a MaxLinear USB-serial converter, you can put the program in Wide mode (remember to choose the right circuit type). In this mode, all telegrams are separated correct except for a very slight probability of misplaced Breaks, which destroys the messages as described above. Note that for the moment, the program is only tested with XR21B1411. It therefore may not work for newer types or with XR21V141x, which uses different register addresses.

When you start the test program, you must first select the UART type, then select the COM port in the ComboBox and then usually "CTS handshake" except for a few 16C950 UART drivers, where the handshake must be set to None in the program and to CTS handshake in the driver by means of Windows device manager (program setting not transferred to driver). At any time it is possible to change the COM port selection and the Baud rate.

The Transmitter TextBox accept any mix of ASCII characters embedded in quotation marks and hexadecimal numbers with an even number of digits like for example """Test""" 78 90 "UU" FF76. A Carriage Return (CR or Enter) is specified as its hexadecimal value 0D and a Line Feed (LF) as 0A. Note that to transmit " in an ASCII string, it is necessary to write "" - exactly as in Visual Basic. In hexadecimal mode, all spaces, CR's and LF's are ignored. In case of hexadecimal numbers with four or more digits, the numbers are transmitted with the big-endian model, that is, with the most significant part first. The Send button transmits the content of the Transmitter TextBox and the Break button generates a Break condition. The receiver TextBox always writes hexadecimal characters. Note that because both the transmitter and the receiver regard all numbers as hexadecimal, no hex specifier is used! 63 means 63 hex (99 decimal) - not 63 decimal! There is no decimal to hex conversion in the program.

The maximum telegram length is limited to 2048 bytes, but it is very easy to change if longer telegrams are needed.

This page is created with WebSite X5 and updated April 16th 2020

Back to content