Help understanding combining serial communications over ONE wire.

Hi Ron @zander (& @Inq),

  Classic UART chips were 8250 (used in 'original' IBM PC), soon replaced by 16550 (+ other variants). These are 1 UART for a physically large chip ...

Now, adding the UART capability to a microcontroller only increases the internal silicon chip size by a 'pin prick', and all of the connectivity to the processor is also achieved, so the market for separate UART chips is near zero. In addition, other serial interfaces like USB, I2C, SPI, Ethernet all offer advantages over traditional asynchronous serial, so the need for serial ports has generally shrunk. So whilst clones of the legacy chips are still listed on AliExpress, they would be extremely clumsy for Inq's application.

Of course, that also means the maximum number of UARTs readily available is limited by the microcontroller designer's decisions. Inq wants to use ESP8266s, and they have only 1 full UART.

It is possible utilise a GPIO port as a serial input or output, using software, but for the input in particular, it is somewhat onerous, maybe requiring an interrupt call for each incoming bit, which must always be serviced before the next bit arrives.

I have never seen it done, but it might be possible to dedicate an ESP8266 (or other controller) to being a multiport serial handler, maybe using a round robin approach of continually checking each of the data pins, on the basis it has nothing else to do?

Though, it might be a bit brain-bending if they all use different baud rates, etc... 🤨 

If it was for a commercial product, I would probably consider an FPGA approach, but that is a whole new world, and may be relatively expensive.

Best wishes,

Dave

@davee Time for a random out-of-the-box idea. What other bus could be used?

Hi Ron @zander,

  Hobson's choice ... @Inq wants to connect to FlySky radio control equipment, plus an unidentified GPS, so the choice of bus is dictated by the external equipment, including its largely undocumented protocols.

Dave

Posted by: @zander

↑

@inq It's probably not an answer you want to hear, but Adafruit has a USB GPS I think. There also is this, a serial mux, sorry, just googling for a friend. MUX  A higher level description is at Sparkfun even though they don't carry it anymore HERE

Actually, that sounds interesting.  I hadn't even considered a Mux.  Might have to experiment with that to see if I can sample at sufficient rates.

Posted by: @davee

↑

Sadly, adding a third source of incoming data is not going to make it any easier.

Sounds like you need some kind of serial character 'marshalling' solution ... each incoming serial line will need its own "UART" ... well "UAR" for Receive at least .. T for transmission is another story. Maybe an ESP8266 could spend its entire career being a semi-soft "multi-UAR"? Other possibilities are also plausible!

I've been a little slow on this project with lots of family issues and events.  Might be another couple of weeks before I can dive into this stuff again.

But, I've also been giving some thought to joining device via SPI or I2C.  I wrote a duplex SPI library some time ago.  I think I got it to the proof of concept level, but, I need to brush it off and see if it is serviceable.  I was thinking of using the ESP32.

Posted by: @zander

↑

I hate to see Dennis get stuck, his projects are always so interesting and educational so I want to see him succeed.

You mean... the 10% that actually get done and work? 🤣 

@inq 10% is better than 9%.

Posted by: @inst-tech

↑

@inq  I think I may have an idea of what your asking..In the industrial process control world, we used Token ring topology, and ethernet to do what your trying to do.. see link https://www.techtarget.com/searchnetworking/definition/Token-Ring

I could have gone the rest of my life and not here that word uttered and be quite happy with it! 🤣 

It's even worse than ArcNet architectures. 

Posted by: @davee

↑

Inq wants to use ESP8266s, and they have only 1 full UART.

Yes, I'm being held back by my own library.  BUT... in the past I have been resistant to trying port my library to the ESP32 (or any other micro).  I had never seen a need for more than one or two sensors for 99% of the IoT scenarios I was purporting to cover.  Even with a robot controlling two steppers and four or five I2C sensors, was no big deal.  Needing three hardware serials... which I think the ESP32 has.  The literature I read so far isn't real clear about them being hardware or software serial.

Posted by: @davee

↑

It is possible utilise a GPIO port as a serial input or output, using software, but for the input in particular, it is somewhat onerous, maybe requiring an interrupt call for each incoming bit, which must always be serviced before the next bit arrives.

If I'm understanding this correctly, it's a little like bit-banging.  I already tried using the one hardware serial port and a second software serial port.  It kind of worked until I started adding the servos that also require critical PWM hardware timers and there is only one of those to go around... IOW the Serial bit-banging and PWM servo bit-banging were banging their heads against each other and nobody was happy. 😆 

Hi @inq,

it's a little like bit-banging

Although this is not the first time of seeing it, sorry, but I don't know the precise definition of this expression is, although it has the right kind of 'feel'. So I'll try to describe my view of what could be considered:

For serial input, I am thinking of continually checking on the input state of GPIO port, and waiting for a change of state ... then once a 'start bit' is spotted, starting the clock to check for the rest of the bits of the word at appropriate times, assuming the baud rate is known, and building up the 8 (say) bits to make a word. Of course there are also sorts of refinements that can be suggested, such as sampling several times per bit and taking an average to reduce noise errors, checking parity, and so on.

Serial Output is a bit simpler, as it amounts to setting the GPIO pin output state according to each of the bits of the word. Once again, the total exercise includes start, stop, parity bits, etc.

I can completely sympathise with the view that once a processor gets tangled in dealing with a serial port a bit at a time, it has little chance of doing anything else.

My suggestion, only if you particularly want to stick to 8266s, is that it might be possible to use one (8266) to have just 1 goal in life ... to act as multiple serial port handler. e.g. it might listen to three serial streams, and turn them into words that it 'somehow' passes to another processor (e.g. another 8266) to make sense of.

The idea being that as it doesn't do anything else, so it could be a 'simple' round robin schedule of the three ports, deciding whether a new bit had arrived, etc., assuming it could do all of the processing needed for the extra bit, before it was necessary to deal with the next port. In other words it wouldn't do much more than emulating the receive part of 3 UARTs. Of course, if the ports are all different Baud rates, etc., it could get very messy.

I haven't the faintest idea how credible the suggestion is, but assuming the incoming baud rates are low, I wondered if it was worth your while doing a back of the envelope feasibility "guesstimate".

-------

Of course, if you are thinking of looking at another processor, which I think is probably a good idea, given the 8266 is getting rather long in the tooth, then that is different story.

Best wishes, Dave

@inq Is this of any help? https://www.parallax.com/multiple-serial-port-16-object/

@davee @inq Maybe it's assumed or I misread, but this is definitely a case where you want to NOT poll and use pin interrupts instead. I am assuming the time between 'bits' is far shorter than between 'words/chars/bytes'. If you are monitoring 2 or more pins, you can not risk doing any more than setting a flag in the ISR then in the main loop adding the last char to a buffer when the flag is detected as set. I know I am not telling you anything you probably haven't heard, or done before, but in this case, you may have more than one pin to react to and there is no way to slow the data down so each interrupt must be dealt with ASAP.

Might be time to learn to use the register, inline, asm features of Arduino C++ and change the compiler options at least locally (#pragma) to optimize for time rather than space as is the default. Apologies if obvious.

Hi Ron @zander,

   You may be right ... and I did consider an approach similar to yours. Had I viewed the overall processing as having a main 'task', occasionally punctuated by incoming data arrivals, then I would have suggested such an approach.

However, in my usual spirit of looking at things from a different angle, I thought this may be one of those occasions for a different approach. One that treats the ESP8266 more in the spirit of a specialised logic chip that continually repeats a sequence of operations, than a computer.

---------

Essentially dividing time into slots, each slot being of the same short  duration of a time. I would expect the length of time to be related to a bit time of the incoming data. It might be equal to a bit time, or perhaps a convenient fraction (e.g. one quarter) of a bit time.

Each time slot would be responsible for performing the necessary servicing of all of the serial channels. That is there would be a list of very short tasks to be performed, possibly finishing with an effective halt of processing work until the start time of the next period, whereupon the list would be rerun.

------

The reasons for suggesting this include:

A/ Digitising the incoming data is based on sampling the incoming ports on a timed basis.

Contrast this with a 'conventional' serial input using a UART, which would typically have a FIFO, that can be "comfortably" serviced by an interrupt when a new word or group of words have been received and assembled by the UART.

This situation is the largely the other way round ... once the first transition of the start bit has occurred, sampling to recover and assemble the bits into a word is all time driven. Each of the serial inputs could start to transmit a new word whilst the other inputs are transmitting a word, so using interrupts tends to complicate the situation.

B/ Servicing an interrupt involves not only running the explicit interrupt service code, but also a sequence of operations performed automatically by the processor to save the present context of the task being interrupted, jumping to the interrupt service routine, and the complementary operations to restore the context and jump back to the main task.

These operations normally assume that interrupts only occupy a small fraction of the processing time. However in this case,  the incoming GPIO transitions are likely to occur at a high rate, and hence the interrupts could become an onerous overhead, even if the interrupt service code is kept to a minimum.

C/ When two or more bits have the same data value, there is no transition, and hence no obvious interrupt source.

D/ The data sampling must follow a rather strict timing protocol .. interrupts make timing predictions rather difficult.

---------------

I emphasise, these are only a few 'first impressions', and my suggestion may be completely impractical. It was only an 'unusual' idea for consideration.

In particular, simultaneously handling different baud rates could become tricky ... two rates like 300 and 600 with a simple 1:2 ratio might be reasonable, but 110 and 600 could be more difficult.

---------

I hope that makes sense.

Best wishes, Dave

@davee I am at the hospital with just my phone so can’t read all of the post. I just wanted to say I used to read all the stock and money market lines in North America, I don’t remember the number but dozens and only one way. All were done the way I said, that is the only way you can do that

Hi Ron @zander,

  As always, I am only making a suggestion, and as usual, it is unusual. 😉 😉 😉 

  But the most important thing at the moment for you is to take care of yourself in hospital. I hope it all goes well for you.

Take care my friend, I shall be thinking of you.

Best wishes, Dave