How to transmit data from an analog multiplexer to an RS232 COM port on a PC

analogmicrocontrollermultiplexerrs232serial

I am having trouble understanding how to design a circuit that will transmit multiple analog data signals to a computer through one RS232 COM port.

The analog data is a simple voltage reading from 12 different LEDs. The LEDs are triggered by relays that are controlled with software from the same computer that I will use to monitor the LEDs. Other software will be developed to read which LEDs have been triggered and if they are operating within a specified voltage range. For now I am just trying to understand the hardware aspect of transferring 12 analog signals through a single COM port.

My understanding is that an analog multiplexer can be used to combine the voltage signals and transmit them to the computer's com port through a voltage converter/serial interface like the MAX232. Is this possible without using a microcontroller chip? If not, what chip should I use to perform this task? I am trying to avoid using a microprocessor in the interest of keeping things as simple as possible.

Ultimately, I am looking for the simplest way to transmit multiple analog signals through a single COM port on a PC. Thanks in advance.

Best Answer

My understanding is that an analog multiplexer can be used to combine the voltage signals and transmit them to the computer's com port

An analog multiplexer is just the electronic equivalent a multi-pole rotary switch - it simply steers one of the inputs to the output. The output is still analog, not suitable for transmitting via RS232 (which is a +-12V digital signal).

To create the serial signal you need an ADC (Analog to Digital Converter) to convert the analog voltages into digital numbers, and a UART (Universal Asynchronous Receiver Transmitter) to serialize the data bits with the correct baud rate and format.

You could make such a circuit using separate analog MUX, ADC and UART (with a few logic gates to 'glue' them together) or just use a small microcontroller which has all these features built in.

An MCU might seem more complex because it needs software, but the hardware can be much simpler. You will be sending 12 readings to the PC continuously and it needs to know which one is which, so your transmission protocol must include more than just the raw data. You will find it much easier to develop this protocol in software, rather than having to add even more chips to a complex digital control circuit.

Related Solutions

Sending Via PIC18F97J60 EUSART

One annoying misfeature of the UART on every PIC I've worked with is that a data overrun error will shut down the receiver until code disables and re-enables it. It is thus imperative to have code that will periodically check the overrun-error flag and, if it is set, disable and re-enable the UART receive function. Otherwise if the receive buffer overruns, you won't just lose a received byte--you'll lose all data forevermore.

I'm not really sure why Microchip designed their UARTs this way. My guess would be that in early PICs a receive overrun would cause the receive state machine to lose frame sync, and that disabling the receiver was considered preferable to receiving randomly-framed data (I might agree with them on that point, though I would consider dropping whole bytes while maintaining sync to be better still); later PICs maintained the behavior for compatibility, despite substantial redesigns of the UART subsystem.

In any case, the PIC's UART implementation is what it is. Check to ensure that the UART receiver is enabled and the receive-overflow isn't tripped. If not, disable the UART receive function and re-enable it. Note, btw, that on some PICs the master disable for the UART function will not disable the receiver; you need to clear and re-set the receiver enable.

Electronic – How to Efficiently Decode Non-Standard Serial Signal

Another answer: Stop using interrupts.

People jump to use interrupts too easily. Personally, I rarely use them because they actually waste a lot of time, as you are discovering.

It's often possible to write a main loop which polls everything so rapidly that's it's latency is within spec, and very little time is wasted.

loop
{
    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (serial_byte_ready)
    {
        // decode serial data
    }

    if (enough_serial_bytes_available)
    {
        // more decoding
    }        

    if (usb_queue_not_empty)
    {
        // handle USB data
    }        
}

There might be some things in the loop which happen far more often than others. Perhaps the incoming bits for example, in which case, add more of those tests, so that more of the processor is dedicated to that task.

loop
{
    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (serial_byte_ready)
    {
        // decode serial data
    }

    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (enough_serial_bytes_available)
    {
        // more decoding
    }        

    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (usb_queue_not_empty)
    {
        // handle USB data
    }        
}

There might be some events for which the latency of this approach is too high. For example, you might need a very accurately timed event. In which case, have that event on interrupt, and have everything else in the loop.

Best Answer

Related Solutions

Sending Via PIC18F97J60 EUSART

Electronic – How to Efficiently Decode Non-Standard Serial Signal

Related Topic