3 serials topology on Pro Mini

Projects Programming
1

Hello guys,

i would like to make a unit, based on Pro Mini 5V 16Mhz, that has 3 serial channels.

Channel #1 is used to read / write data to and from a RC turbine engine ECU. at fixed 9600 baud.
Channel #2 is used to talk to Sbus2 Futaba Receiver at 100K baud (has to be HW serial i guess). this channel needs minimum latency to both read and write, so will be out of the state machine in the code and run every main loop.
Channel #3 is used to transfer parsed data from Channel #1 to a BT module (can configure to any baud rate i like).
And lastly, Channel #4 will be I2C to print the data on LCD.

would like to get your recommendations as far as baud rates and serial libraries (hw.serial, sw.serial and alt.sw.serial and so on).

i did read the tips on the AltSWSerial github page:
http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html

Here is the relevant quote:
"Using Both SoftwareSerial and AltSoftSerial
It is possible to use both SoftwareSerial and AltSoftSerial, and of course HardwareSerial, to have 3 serial ports! However, the baud rates must be chosen carefully!
Because SoftwareSerial creates 10 bit times of latency for other libraries, it should be used for a device needing high baud rate. SoftwareSerial should NOT be used at slow baud rates, because it will interfere with the other ports. SoftwareSerial can not simultaenously transmit and receive, so it should be used with a device that never sends in both directions at once.

HardwareSerial can tolerate up to 20 bit times latency for receive, or 10 bit times for non-stop transmit. To maintain full transmit speed, HardwareSerial's baud rate should be no greater than SoftwareSerial's. If continuous transmit is not needed, HardwareSerial can use a baud rate almost twice as fast as SoftwareSerial and still reliably receive. But more than twice SoftwareSerial's baud will not be able to receive reliably.

AltSoftSerial can tolerate almost 1 bit time latency, so its baud rate must be at least 10 times less than the baud rate used for SoftwareSerial.

If the baud rates are chosen wisely, all 3 can work together reliably! "

So i thought about doing the following:
HW serial for Sbus2 100k baud
SW Serial 57600 for BT module
alt SW Serial 9600 for ECU

im not entirely sure all of this can be managed reliabely.
any tips would be welcome.
thanks.

2

You REALLY need a board that has 3 or more hardware serial ports to achieve the results you seem to be looking for. The Teensy 3+ boards have 3 hardware serial ports and are, well, teensy.

http://pjrc.com/teensy/index.html

3

The main disadvantage of the Teensy is price. the cheaperst Teensy 3+ board i could find is about 30$, whild the Pro Mini is 1.3$, so Teensy is about 25 times more than pro mini, making it completely out of range as far as cost for this project.

any cheaper alternatives with more serials?
or yet go back to the (obviously far from perfect) SW solution?

Perhaps one of these?

4

If size is not an issue, mega or due or clone of those.
Possibly more expensive though.

5

sterretje:
If size is not an issue, mega or due or clone of those.
Possibly more expensive though.

im afraid size / weight is critical so cant use any of these.
are there any Mega or Due on small boards (pro mini size or a bit more)?

6

Like this one I offer?
http://www.crossroadsfencing.com/Bobuinorev17/
See card at the top of the page. (having network issues, can't get to the page myself at the moment)

7

having network issues, can't get to the page myself at the moment

Your site appears to be down.

are there any Mega or Due on small boards (pro mini size or a bit more)?

Yeah. There called Teensys.

8

Any other options, better priced / sized?
Do you guys feel the sw solution is out of question?

9

If you're controlling a turbine engine worth several thousand dollars then I wouldn't hesitate spending $19 on a Teensy V3.2 with four hardware serial ports. The capabilities of the later Teensies, 3.2 and 3.6, are a far better choice than a 16MHz AVR. The T3.2 is not much larger than a Pro Mini.

10

If you're controlling a turbine engine worth several thousand dollars then I wouldn't hesitate spending $19 on a Teensy V3.2 with four hardware serial ports.

I doubt that OP's RC turbine engine cost anywhere near that. But, if you wouldn't hesitate to buy the Teensy, I'm sure OP would appreciate that.

11

I have friends at the RC field that use these engines and have been told that they are in the $2K region. They're actual turbines spinning at near 100K RPM and burn jet fuel they buy from the airport.

Jet Engines

12

I had no idea that they were so pricey.

13

The technology used in these engines is astounding. Until a saw one fly a few years ago in a 2m wing span copy of the German ME163, I would not have believed they existed. They usually start on propane then switch over to jet A. The medium sized engines have a thrust of more than 20 lbs and sound just like the real thing. Do a YouTube search for some interesting videos.

14

The price of the jet engine is completely irrelevant to the project.
please, can we keep the discussion on subject?

15

It is probably not possible to do, because you have two ports that RX and three ports that TX.

The two ports that RX have to be a HardwareSerial and another software serial port. You can't use the built-in SoftwareSerial because it blocks interrupts for long periods of time, interfering with everything else.

You should use AltSoftSerial; it only works on pins 8 & 9. It can simultaneously RX and TX, and it does not block for either operation. It uses TIMER1, and it is the most efficient software serial choice.

So far, HardwareSerial and AltSoftSerial can work together. Adding the 3rd serial port TX is the problem, because all other software serial libraries block on transmit. This will interfere with the HardwareSerial and the AltSoftSerial operations.

If you could "share" two of the TX lines, you could make this work. For example, if Channel #1 (RC ECU) and Channel #3 (BT) have different command sets, you could wire them both to the AltSoftSerial TX pin. They would both receive the same characters, but if the ECU commands will be ignored by the BT (and vice versa), each device will ignore half the data it receives.

If the BT just echoes everything, it would also echo the ECU commands. Maybe that won't work for you... unless you define your own BT packets. If the app receiving the BT data ignores the ECU commands, that could work, too.

Another possibility is to use external logic gates to "switch" the AltSoftSerial TX pin to either the ECU or the BT device. Just use a digital pin to switch. You could have different baud rates for the ECU and the BT if you like.

Cheers,
/dev

16

/dev:
It is probably not possible to do, because you have two ports that RX and three ports that TX.

The two ports that RX have to be a HardwareSerial and another software serial port. You can't use the built-in SoftwareSerial because it blocks interrupts for long periods of time, interfering with everything else.

You should use AltSoftSerial; it only works on pins 8 & 9. It can simultaneously RX and TX, and it does not block for either operation. It uses TIMER1, and it is the most efficient software serial choice.

So far, HardwareSerial and AltSoftSerial can work together. Adding the 3rd serial port TX is the problem, because all other software serial libraries block on transmit. This will interfere with the HardwareSerial and the AltSoftSerial operations.

If you could "share" two of the TX lines, you could make this work. For example, if Channel #1 (RC ECU) and Channel #3 (BT) have different command sets, you could wire them both to the AltSoftSerial TX pin. They would both receive the same characters, but if the ECU commands will be ignored by the BT (and vice versa), each device will ignore half the data it receives.

If the BT just echoes everything, it would also echo the ECU commands. Maybe that won't work for you... unless you define your own BT packets. If the app receiving the BT data ignores the ECU commands, that could work, too.

Another possibility is to use external logic gates to "switch" the AltSoftSerial TX pin to either the ECU or the BT device. Just use a digital pin to switch. You could have different baud rates for the ECU and the BT if you like.

Cheers,
/dev

that is a great answer, thank you!
sharing one port sounds interesting, for example my Ardu can recieve ECU data that starts with XX YY header from ECU to ALTSWserial port (8.9), and then transmit a different header message to BT (i.e AA BB header).
this makes 2 concerns:

  1. how the ECU (which is not used to incoming "garbage" data will react - i suspect this is a non issue.
  2. how will i time the messages from Ardu to BT, as ECU is sending its message in a 5hz rate or so, and aru would have to Tx only when ECU is off the Tx line.

any ideas?

17
  1. how the ECU (which is not used to incoming "garbage" data will react - i suspect this is a non issue.

You'll have to look at the spec to answer that. If an ECU command has header and checksum bytes, it will probably ignore other data sent to the BT on the shared wire.

  1. how will i time the messages from Ardu to BT, as ECU is sending its message in a 5hz rate or so, and aru would have to Tx only when ECU is off the Tx line.

I did not mean the Arduino TX pin would ever be connected to the ECU TX pin. When I said "share a TX" line, I meant two listeners for one sender: Connect the Arduino TX pin to the ECU RX pin and the BT RX pin. One sender, two listeners.

The only "timing" is that the Arduino can only send to one of the listeners at a time. If the line is shared (not switched), the Arduino could send them consecutively (e.g., ECU command immediately after BT data), not simultaneously. If the line is switched, you have to wait for the ECU command to go out (using flush() or availableForWrite()), then switch (and change baud rate?), then send the BT data.

When you print to HardwareSerial or AltSoftSerial, they queue the characters first, then start sending them in the background (with interrupts). Your code won't be blocked while all the characters go out (unless you call flush()). This means your code is free to read characters from those ports while that's happening.

Cheers,
/dev

18

thank you again.
i was able to get everything running today in the way i described in my first post, with BT receiving only.
next is BT transmit, i reckon its gonna be OK :slight_smile:

19

as i mentioned earlier, all 3 channels work together.
one problem im having is timing with sending messages to the ECU.

im using SWserial to read the a BT message, which functionally is a string that needs to go to ECU.

ECU sends data frames for 100ms on and off. i.e 100ms of data, 100ms of quiet - and uses only one data line to comminicate half duplex, so i have to time my messages.

in my code, when i want to transmit to ECU, i wait 6ms after the 50th byte (ECU data strings are 50 bytes long) and then i transmit.

i noticed i had come collisions on the line so measure on the arduino Tx/Rx pins with a LOGIC analyser and this is what i got:

can anyone help debug why this is happening? the small data strings are supposed to be 6ms after the big ones.

thanks.

LOGIC image.png
LOGIC image.png1920×1036 73.1 KB

20

If you want to keep the cost down, and use an AVR, go to a MEGA on your own PCB.
Lightweight, small and plenty of resources to play with.