I think the main issue (and advantage) here is that your realtime requirements are really very soft. A delay of a few milliseconds or two won't make any difference whatsoever to the perceived immediacy.

My recommendation would be a multidrop fieldbus with RS485, with a single master handling a bus, and that connecting via USB to the PC. For a 20m x 40m stage you could easily run at 1Mbps. You would have a CPU per mat, each with a 75176 RS485 driver. The CPUs could be any tiny MSP430 with hardware support for a UART, just bang out a score packet with the latest step count, and a sequence number for an ack. And have CRCs on the packets. Meanwhile keep adding the scores per mat in a totals variable to ensure at least the final score is exact.. Basically you would only need to design a protocol that has two commands (clear and get score) and an ack. Not even an ack if you are willing to do some processing on the master side.

Have the master poll, and have as many distinct masters and busses as you need to ensure any given bus meets your timing constraints. Given that a packet (request + reply) would be (HDR/ADR/CMD+CRC)+(VAL2+CRC), you should be able to get a message turned around in about 100 microseconds, therefore about 10,000 messages per second (in terms of raw bandwidth). 300 mats gives you about 30 messages per mat per second.

One downside is that the mat CPUs need power, but an upside is that there is only a single wire per bus. I should mention that RS485 has limitations on the number of devices allowed on a bus, between 32 and 128 depending on the driver.

Dear Llerena,

I too suggest the same idea given by Kinghan. Fieldbus is a better choice for your application. Instead of creating your own protocol (MAC layer (HDR/ADR/CMD+CRC)+(VAL2+CRC) as given by him), you can use an existing protocol such as CAN, Ethernet, etc. You can find lot of worked out examples (software + hardware schematics) for existing networks.

Arun - yes, you are quite right about the ease of implementation of just dropping in an existing MAC provider, and that is often the way to go. However, it sounded a bit like there might be a cost consideration, given he was wanting to scan raw wires. If he goes Ethernet, that basically means an MCU capable of implementing UDP at least, not to mention the physical MAC and PHY cost (because there aren't any really inexpensive MCUs with those built in). CAN might be better, but even there, you have to go a step up in MCU. A USART is pretty much always the next silicon you get in a range, after the timers and I2C/SPI. MSP430G devices with USART start around $0.60, with enough flash and RAM to handle a simple protocol.

Dear Sean,

I agree with your argument. It is a cost effective method to use a system that is already in possession. If new equipment is to be purchased, you can invest.

I think it has to be master-slave approach. A single master with multiple slaves. The slaves count the steps on the mats. The master gets the number of steps from the slaves periodically (as such in TT protocol, Token pass). There must be an acknowledgement for every data transfer.

If there are multiple masters in the network, there will be a situation in which two or more masters are transmitting data/commands at the same instant of time. In that case, these masters must be programmed to listen before transmit (like CSMA/CD). If there is a collision, retransmission of data should be done.

That's why I gave the suggestion to implement an existing network. Further these networks are now available with add-on devices. For example a CAN network can be implemented if the microcontroller is having SPI. MCP2515 is a SPI to CAN controller which costs around $1.52 to $2.01. If you think it is costly, then USART is the better choice. Similarly, SPI to Ethernet devices are available. Even you can get RF modules with SPI support such as CC2500, nRF2401+, etc.

In my opinion if you want to handle multiple I/Os in real time and have communications at the same time I suggest to use XMOS microprocessor.

It is not an interrupt routine microprocessor, it is a different concept based on transputers technology. Briefly, all code can be written in C/C++, only the way that you start the tasks is in XC. But there are a lot of examples and the documentation provides is pretty good.

Regarding communications, you can implement pretty much any type of protocol. The I/Os can go up to 100MHz. All this can be done in a concurrent or parallel way with all the mechanism available to coordinate the tasks between them and still have the real time constraints at I/Os level.

Instead of having the 15 USB Links I would connect these 15 links to another XMOS board that would be responsible to get all the data and then send it over USB (FTDI can go up to 3 Mbits) to a computer. All in real time.

Dear Lorenz,

I2C is limited to short range communication only. Since it follows synchronous mode of data transfer method, it is not suitable for remote communication.

Dear Martins,

The objective is to read 600 switches each separated by 3ft (my guess). Please tell us whether the I/O pins of the XMOS processor can be used. If yes, How?

Dear Llerena,

Please tell us whether this discussion is going on the right path. Does the information given by us is useful to you?

Dear Arun,

Correct me if I am wrong but I think the problem is not on the amount of I/Os that XMOS or any other microprocessor can handle. The real time needed to read all I/OS + communication protocol are the issues here.

The first solution that Llerena mention required 50 I/Os to be read in real time. The MSP430F5529 has 63 I/Os but it can't handle I/O reading + debounce in real time. That is why I suggested XMOS.

I believe XMOS can handle these I/Os issues.

Regarding handling 50 I/Os:

- The XMOS starter kit (XK-1A) has 24 I/Os. By using a digital multiplexer (e.g. Texas Instruments CD74HC4067 16-Channel multiplexer) it is possible to use 5 I/O to read 16.

- So with one XK-1A and 4 (24 I/Os / 5 pins = 4.8) 16-Channel multiplexers it is possible to read up to 64 I/Os (4 * 16)

- Here it is an example using an arduino (http://bildr.org/2011/02/cd74hc4067-arduino/)

- This approach is valid with any microprocessor. However by using XMOS not only it saves time programming (don't need to deal with interrupt routines to manage I/Os) but also it guarantees real time.

Another solution can go from using an FPGA, for example ZTEK USB FPGA module.

This particular board can handle 90 I/Os. I/Os readings are going to be done in parallel with no delays!

Hope it helps

An example of an application with a lot of I/Os and using XMOS

http://www.xcore.com/projects/swarm-light-awesome-led-cubes-using-xmos-processors

I forgot to mention that you can always stack 3 of XK-1A boards and then you have 72 I/Os with real time.

Or you can design your own board and use the L-Series family. The XS1-L8A-64 device can handle 64 I/Os and it is a TQFP48 package (not to hard solder by hand)

I was once involved in a project, where we produced multipoint pressure sensing mat for sensing patient pressure on bed surface. It was part of decubitus preventing system. We developed 8 channel pressure sensor in single package. Each sensor was connected with tiny plastic tube to small pillow, which were arranged in a matrix placed on a bed. The whole system consists of 720 pressure sensors and scanned via LPT port with about 1 sample per 5sec. The conventional 4056 muxes were integrated within 8 channel sensor and outputs were muxed further on a board containing 15 eight-channel modules. It is not directly related to your question, but if you ever think about measuring not just only ON/OFF presence on a fitness mat, but also the force, I can provide you a solution.

Regarding your question: you could use multiple n-bit bus latches (e.g. 30 pcs. of 20 bit 74ALVCH16841 for 600 switches). Switches are connected to data inputs, you trigger all inputs with latch enable and then read the state sequentially with individual output enable signals. The OE signals can be connected to one 5 to 32 demux (two 74HC154). The address 00000 is idle, 000001 is connected to latch enable and all remaining to OE of each 74ALVCH16841. Then you simply count the address from 0 to 31 and read 20 GPIO pins with each address from 2 to 31. Pin count for this solution is 20 + 5.

You could put a small, cheap microprocessor with a UART in each mat to debounce and count each switch and insert its data into a circulating message in a data insertion ring. Character format could be 1 start bit + 7 data bits + 1 parity bit + 1 stop bit. Message length would be: 1 character start, 1 character command (Reset or Insert Current Count), 2 chars data position (1..300), 1200 chars count data (4 chars per mat = 2 chars (14 bits) for each switch count). Configuration is: master controller Tx ==> mat 1 Rx; mat 1 Tx ==> mat 2 Rx; ...mat 300 Tx ==> master controller Rx. Each mat also introduces 1 char time delay while waiting for the start character, so total messaging delay would be 1504 or 15,040 bits. At the standard 115.2Kbps signaling rate you should be able to achieve at the short distance and simple point-to-point connections between mats, the master controller (which could be any old PC with a serial port) would receive updates on all counts more than 7 times a second - plenty fast for real-time display.

Dear Martins,

Now I agree with your idea. Now it is for the questioner to decide.

Regards,

Arun

P.S. (http://www.xcore.com/projects/swarm-light-awesome-led-cubes-using-xmos-processors) Really amazing to see the video of example project.

Dear Jorge, the problem you have could be solved with minimal pain using first an of-the-shelf product liken Altium Nanoboard3000, see http://www.altium.com/en/products. After you develop your solution and you're happy with the results you can build your custom board dedicated to your product, using the project you already tested with the development board.

This board will give you immediately access to any possible software/hardware gizmo, ready to be hooked-up to you array of switches and to any available PC, network, or wireless interface. You can on-the-fly configure, load, and use multiple micro-controllers inside the provided FPGA and add any hardware interface between them to you mat. It is trivially simple to process even 400 switches in under 20ns in parallel after you build your custom board. With multiplexing techniques you can process millions of switches in real time. Also, you can configure inside the FPGA at least a few thousands hardware debouncers if you wish, with no time penalty.

Also, you get right to your fingertips all the embedded solutions you could possibly think of. You can use hardware schematic-like design for your project, HDL languages, C and C++ code; whatever you're more comfortable with. Even more, you can mix in your project all these designing tools if you wish. And the cherry on the cake: Altium is even a PCB design platform! After you finish your design and build your PCB you get real time access to a plethora of "Instruments" in a "Rack" allowing you to dynamically interact with any piece of your design on the final custom board product. You also get to make live real time software changes and instantly see the result on the running product.

With priority based interrupt control and, todays modem based communication system, it is not needed to put 600 push button control, all instrumentation, protection and control can be interlinked easily with priority for more information refer my 25 years back paper, " Protection operation and loading .....using microprocessor/PC online"!!!!!!!!!!!!!!!!!!!!.

6 min is very long for 600 buttons. Your task may be solved for 1ms if you use assembler and SPI buttons controller like MC33993. Your microcontroller is good, but possible use more simple controller and RS485 (as virtual COM port through USB)