1
\$\begingroup\$

I am totally new to just about all of this, first off.

I have two boards that I want to be able to communicate. Both are using half-duplex serial connection, but one is fixed at 4800bps, and the other is at 57600bps.

I've dug in, and to the best of my understanding, I'll need something with 2 UARTs to more or less convert the signal from one to the other. That is about where my understanding has hit a wall. I'm unsure what chip would work, how to setup the chip, or if there are other, simpler options. I just need a bit of direction from someone with some experience!

\$\endgroup\$

closed as too broad by Andy aka, pipe, Marcus Müller, laptop2d, Finbarr Jun 5 '18 at 15:31

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ It is unlikely that the slower device will be able to keep up with the faster device unless transmissions are very sporadic. \$\endgroup\$ – Ignacio Vazquez-Abrams Jun 3 '18 at 17:28
  • 3
    \$\begingroup\$ A better quality question would be "how do I get two units to communicate when they have fixed but different baud rates" and ask for preferred solutions (if any) and don't ask for "a bit of direction". This is a Q&A site and specific, direct questions are encouraged whereas questions that solicit opinions are not. \$\endgroup\$ – Andy aka Jun 3 '18 at 17:39
  • 1
    \$\begingroup\$ Before we go forward, are you sure that the baud rates cannot be changed? Usually there is some way to select different baud rates. \$\endgroup\$ – mkeith Jun 3 '18 at 18:19
  • \$\begingroup\$ Do you know if there is any active "flow control" services available to the slower device. If so, that could help. \$\endgroup\$ – jonk Jun 4 '18 at 5:58
  • \$\begingroup\$ Baud rates are hard coded in both devices. They also run Half-Duplex, and the slower device "always responds when a frame is received." so it shouldn't be an issue as far as keeping up. So far what I've been able to come up with is using a 2 uart microcontroller to take commands from the fast device, and slow it down, then speed up the response from the slow device. \$\endgroup\$ – AmpMunkey Jun 4 '18 at 19:42
3
\$\begingroup\$

As @IgnacioVazquez-Abrams noted, the difference in speed is potentially a real problem. Data transfer requirements can take a variety of forms. For your purposes, let's look at a few possibilities:

1 - A bunch of small, intermittent, packets in both directions

In this case, any small device with 2 UARTs and enough RAM to buffer the largest typical transfer will be sufficient.

2 - Large amounts of data coming from the slower device with acknowledgements or other small packets being returned by the faster device

In this case as well, any small device with 2 UARTs and enough RAM to buffer the largest typical transfer from the faster device will be sufficient.

3 - Large amounts of data coming from the faster device with acknowledgements of other small packets being returned by the slower deive

In this case, I recommend researching to find a different solution. While it is possible to create ever-larger RAM buffers for serial data, eventually, inevitably, there will be a problem.

Note that I use the term "packets" here very loosely. The data does not need to conform to anything like Ethernet network packets or similar highly-structured data. But most data transfers, in my experience, beyond keyboard input, fit one of these 3 models.

There is an additional factor - handshaking. Either device, or both, may be able to handle incoming data at the full defined speed. But one or both may require handshaking to be implemented in order to function reliably. That handshaking may be hardware (CTS, RTS or other pins) or software (e.g., XON/XOFF). If you can't configure the bit rates then you are unlikely to be able to configure the handshaking and should support whatever each device needs. Again, a small device with 2 UARTs can handle different handshaking methods as well, but needs to be configured properly to do so.

I am also a little surprised that you would have 2 devices that BOTH have fixed bit rates. Most devices I have worked with for the past 30 years have had configurable bit rates. Even if one device is fixed due to other constraints (e.g., you are capturing data that is already being sent to another system), that typically doesn't apply to BOTH parts of a project.

\$\endgroup\$
  • \$\begingroup\$ I've done some more research, and so far I think the 2 UART device will work for me. The slower device "always responds when given it receives a frame" and frames are very short, a couple bytes at most. \$\endgroup\$ – AmpMunkey Jun 4 '18 at 19:47
  • \$\begingroup\$ @AmpMunkey If the frames are short enough - and not too frequent - then that should work OK. Basically you need to calculate the estimated total data traffic from the 57.6k to the 4.8k. If it works out to < 4.8k, or preferably < ~ 75% of 4.8k = 3.6k, then buffering using a small 2-UART device should work fine. What should that device be? Any computer will do, but to save time/space/$ a microcontroller with at least 2 built-in UARTs and enough RAM & ROM (or Flash or whatever) to "do it all" is the way to go. \$\endgroup\$ – manassehkatz Jun 4 '18 at 19:57
  • \$\begingroup\$ It's for use in an RC aircraft, so I don't think a pc would suffice! I've found the ATmega164, which I think is my best option from my research so far. Now I'm trying to learn what I would have to do to use said microcontroller and set it all up. Lots of learning to do, but I'm piecing it together. Thanks you for your help so far! \$\endgroup\$ – AmpMunkey Jun 4 '18 at 22:35
  • \$\begingroup\$ @AmpMunkey Just curious - since this seems a little unusual, can I ask what types of devices are involved? \$\endgroup\$ – manassehkatz Jun 4 '18 at 23:42
  • \$\begingroup\$ @manassahkatz, a FrSky Receiver and a SmartAudio capable VTX. FrSky SmartPort runs at 57600, and SmartAudio runs at 4800. Normally, the RX connects to a flight controller, which is connected to the SmartAudio VTX. Each have their own UART on the flight controller. However, planes are usually built without a flight controller, so I want create something to bridge that gap. \$\endgroup\$ – AmpMunkey Jun 6 '18 at 13:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.