RS 232 Serial Communication Routing

Projects General Guidance
1

Project Task:
I have a project where I need to route RS 232 serial communication to two (2) different devises from a single source.

The source of the data is a fuel injection control computer (ECU) in an Off-Road car. The ECU will communicate with any outside devise through a, RS232 interface at 112k Baud using 8 bit data one stop bit and no parity. When the ECU is polled, it returns a serial string of 212 (8 bit) bytes of data. The ECU can respond to polls as fast as 15 times a second. One of the complicating issues it that the ECU does not incorporate any flow control systems ( hardware or software). The ECU's RS232 serial interface is converted to Blue tooth with the ECU being the slave.

I have a dash panel that collects data from the ECU via the ECU's serial port. The dash polls the ECU about once a second. The dash uses a Mega 2560 to collect and display the data. The Mega processor is currently loaded and I basically cannot get it to do much more than it already is doing.

I also can poll the ECU using a tablet for data logging purposes at around 10 polls per second. The polling rate is programmable.

Problem:
Since the ECU only has one (1) serial port, I can poll the ECU from one or the other but not both. I do not think the blue tooth converter can connect to multiple devises at the same time so that means I need to use two blue tooth converters.

Since both devises are completely separate devises and do not know each other exists, I need a router to allow both devises to collect data they need when they want it without collisions.

Concept:
My thoughts are to incorporate a Mega 2560 as a router since it has 3 available (hardware) serial ports. I would connect the Mega directly to the ECU via RS232 and attach two (2) Blue tooth converters (setup as slaves) to communicate with the dash board computer and the tablet.

This seems to me to be a bit overkill but maybe not.

What Are your thoughts??

Ken

2

What Are your thoughts??

You know that this "router" has to know exactly the protocol that is "spoken" on that RS-232 interface?

The two polling devices must have a mechanism to let them wait for a certain amount of time. Let's say the dash panel has just polled and is waiting for the data to arrive. At this time the tablet starts to poll for logging purposes. Your "router" has store that poll request, wait for the panel to finish it's request and then send the tablet's request. During this time the table has to wait. If the tablet is polling 10 times a second the panel has to find a slot where it's able to do it's poll. All of that has to be handled in that "router"'s code.

Depending on the above requirements being fulfilled by your equipment your project might be realizable.

3

First, Thanks you for the response.

With respect to the Dash boards processor (a Mega), I wrote the code. The way the dash computer works is that the Mega sends a request for data and then waits for data to show up in the serial port buffer. There is a time out so it won't wait forever. See Below:

      while (Serial1.available() <= 0){
           Serial1.print("A");   // send a capital A and wait for a return
             delay(50);
             b = b+1;
          if (Serial1.available() >= 1) break;
          if (b >= 3){ b = 0; break; }
      } 
      while (Serial1.available() >= 1) { // Load ECU Database with incoming stream from ECU
            incomingByte1 = Serial1.read();
            RawECUData[a] = incomingByte1;   
            a = a +1;
            ScreenData6[2] = a;
            if (a == 213) break;
          }

As far as how the tablet works, I have no idea. The tablet runs on the android system and I have no experience with that. The data logging software that I am using it is a pre-programed package.
I suspect that I could ask how it works. The owner of the software may tell me how it works at least how the communication system works.

Is there another processor that might be smaller that would work?? A Mega is significantly over kill.

Thanks again for your input

Ken

4

KenK:

delay(50);

If you want a responsive system you do NOT want ANY delay()s in the program.

If the ECU s sending data in 212 byte packets there is almost certainly an interval between packets that is significantly longer than the interval between bytes and which can be used to identify the end of a packet and the beginning of the next one.

I agree with @pylon about the complexity if you try to use two devices that each try to control access to the ECU.

I think you would need to write the Mega program so that it handles requests from the Tablet and decides when to pass them on to the ECU. Presumably there will be times when a single reply from the ECU can satisfy both the Tablet and the Mega's own requirement.

...R

5

It sounds like we have a consensus in that I need some kind of router to control access to the ECU. Allowing the two devises to have direct access simply will not work.

It also looks like using a devoted Mega as a router is possible and it also sounds like the Mega may be a good choice.

I am quite familiar with the Mega and it does have the necessary hardware to do the job.

Thanks to both of you for your input on the issue

Ken

6

Why do they both have to poll? Just have one send requests and listen. The second device just listens. It will eventually see the data it wants. No router required at all.

7

MorganS:
Why do they both have to poll? Just have one send requests and listen. The second device just listens. It will eventually see the data it wants. No router required at all.

That sounds sensible. However I have the impression that the OP has some pre-existing software for his tablet which happens to poll. And he also wants to be able to get data with the Mega when the tablet is not active which means that the Mega also needs to poll.

Hopefully the OP will clarify.

KenK:
It also looks like using a devoted Mega as a router is possible and it also sounds like the Mega may be a good choice.

If you already have a Mega collecting and displaying data why can't that also do the routing?

...R

8

RS232 is normally used point-to-point. RS485 is normally used in multidrop situations. Here is an article that describes them;
http://www.electronicdesign.com/what-s-difference-between/what-s-difference-between-rs-232-and-rs-485-serial-interfaces

Having said that you could hang two devices onto the RS232 evesdropping onto what the ECU sends. Rather than the ECU being polled could it not broadcast the data?

If the ECU does have to be polled then the suggestion that the Mega sends all the requests to the ECU then passes some replies back to the tablet sounds like it is worth exploring.

The fact that there is no handshaking at all on the ECU should not be a problem providing;

  • Polls are only sent to the ECU when it is able to receive them
  • The device polling the ECU only polls when it is able to handle the reply without losing characters.
9

All of the above comments are great. It sounds like I need to present a little more detail on what is going on with the entire project.

The existing Mega:
The existing mega is at this point pretty well loaded. It is currently responsible for the following tasks:

It polls the ECU once every second;
It scans, tracks and displays data from several analog inputs;
It scans, and responds to about 15 digital inputs;
It is running a GPS card and polls it every ten (10) second;
The Mega tracks mileage, speed, GPS location and several way points;;
It is running two (2) ST7565 GLCD displays updating the displays once a second;
The Mega is capable of displaying some ten (10) different displays on each of the two (2) displays;
It is running and storing some data on a SD chip;
It stores some data on the on board EEPROM;

The current program running in the Mega consumes about 53k of program space and about 5k of RAM. All of the labels for the displays are kept in ProgMem to conserve on RAM. I do have a Rapid Circuits 512k RAM board for the Mega and it is running on my prototype board but it is not incorporated into the running board system.

As for polling frequency, the existing Mega is doing about it can do to poll the ECU and update the screens once a second.

The ECU:
The ECU does not have a broadcast mode. It only responds when polled. It can be polled for data as fast as 15 times per second.

Once polled, the ECU must be allowed to respond to the current poll before being polled again. This could be critical.

There are about 15 different polling commands that can be issued to the ECU. I am using only one of them (Real Time Data). The Tablet on the other hand is using a large number of them.

The ECU does support CRC checking. I am not using it in the mode I am using for the dash it is not critical. If the data gets corrupted, I just wait for the next polling to update the screens.

There are some 110 different data points that can be polled. The data is transmitted in a string of 212 bytes. Some of the data points consist of one (1) byte others use two (2) and some use three (3).

Tuning of the engine program is performed through the serial port. Once a tuning mode or table is entered, You have to be very careful to insure that the table or tune mode is handled and exited properly before issuing some other type of command. If this is not executed correctly, you could very easily corrupt the existing tune program within the ECU.

The dash board Mega does none of that it only polls for real time data.

The Tablet Software:
The Tablet software package is a third party package.

It can perform the following tasks:
Poll and store data from the ECU at a rate of 15 time second;
Display the data on strip charts and graphs; and
The Tablet software also has the ability to tune or change anything within the ECU.

System Operational Considerations:
1), The Dash is always there and only polls for data once a second.

2), The Tablet may or may not be there.

3), The tablet may be polling for real time data or it could be in some programming mode.

4), The Tablet’s polling frequency is way to fast for the Dash’s Mega to handle.

5), Because of the possibility that the Tablet might be in some kind of programming mode, the router is going to have to monitor what commands are being passed to the ECU. If the ECU is placed in one of the programming modes, the Dash will have to be looked out until it is safe for it to access the ECU.

At this time, I don’t know exactly how the Tablet software works and it does not look like I am going to get any support from the Tablet software’s provider. The ECU on the other hand is an open architecture package and I have documentation on what the commands are how they work.

Moving Forward From Here:
My plans at this point are to setup a system such that I can monitor and store the Tablet’s communications to and from the ECU by the Tablet.

To get this done, I think I am going to use two serial ports on a Mega to monitor the ECU communication. One serial port to monitor the communications to the ECU and the other to monitor communications from the ECU. I will use a third Mega serial port setup to retransmit data going to and from the ECU with an identifying label so I can log and record the data on a separate computer to allow me to study the transactions at a later time.

Once I have a functioning transaction monitoring system to monitor both the Tablet and the ECU’s transmissions, I will run the Tablet through most if not all of its functions and record the transactions. After I collecting the data, I intend to study the data and try to understand what is going on. I don’t need to know everything about what is going on I just need to know how to recognize the entry and exit commands to the programming modes.

Once I understand how the Tablet works with the EDU, I will setup the router such that it locks the Dash out when the Tablet is in some kind of a critical mode.

I sorry this turned into a rather long dissertation but it is turning out to be a rather complex project.

Thanks for all of your thoughts. Any thoughts any of you may have will be greatly appreciated. Although I have been playing with Arduino’s for about a year now, I am no programmer and I am still trying to learn the language. It has been a learning experience to say the least.

10

KenK:
Tuning of the engine program is performed through the serial port. Once a tuning mode or table is entered, You have to be very careful to insure that the table or tune mode is handled and exited properly before issuing some other type of command. If this is not executed correctly, you could very easily corrupt the existing tune program within the ECU.

I get the impression that tuning is the primary role for the Tablet. And in view of what you say about possibly corrupting the ECU I wonder is it wise even to attempt to operate the Mega at the same time as the Tablet. Why not simply disconnect the Mega when you want to do the tuning?

From what you have said it seems to me there is great scope for things going wrong - perhaps due to a failure to respect some niggly detail and I could easily see several months of time being consumed in trying to get everything perfect. And that assumes that you are lucky and don't screw up the ECU in the process of learning.

Is the value of having the Mega working in parallel with the Tablet really worth all that effort?

...R

11

The primary reason for the Tablet is really to log data. The Tablet can make tuning changes and I some times do that but generally, I just use it for data logging. When I get to a place where I can spend some time (in doors) so I can read the Tablet and review the data, I may make changes to the tune program itself.

Currently, I allow the ECU Blue Tooth converter to log onto one or the other but it cannot do both. The problem here is that I have no dash data when the Tablet is logging data and that could be dangerous if something were to go wrong. Without the Dash, I would not know about it until something either broke or went bang.

One thing I could do with the Mega router would be to block all calls that could modify the ECU programming. This would protect the ECU from accidental program changes. That might be a good idea, especially during program development.

If the ECU program were to become corrupted, I can download a saved version of the program from either my laptop or the Tablet in a few seconds.

As for time, I have been working on the Dash for almost a year now and there is more to come. I am currently nearing completion of a function that will allow the display of topo maps with a location tracking system that shows me where I am on the map. This function has taken me months to develop.

Thanks for your comments

Ken

12

Could you log the data to an SD Card with your Mega?

...R

13

I could use the SD as there is plenty of room but speed and Dash processor time is an issue.

The current Dash processor load is such that I am doing good to get a 1 second up date.

In working with the SD reading 192k map files from the SD my experience tells me that takes about a second to upload the file. Writing to the SD is a lot slower. If I remember correctly, there are functions that would allow me to append data to a file and that might be faster but still relatively slow. Another problem is that I would have to write a program that would format the data such that the Tablet program could read the files. The Tablet software does a real nice job of plotting the data in strip charts. I could load the files into Excel but that is more work and not available on my Android Tablet,

Speed is the real problem here. Remember that the Tablet can poll and store the data as fast as 15 times a second or once every 66 milliseconds.

I think I'll try to set up a second Mega such that it polls the ECU, stores the data in RAM and sends the data to the Dash Mega when polled. The second Mega could then format the data and send it to a second SD chip. Since the second Mega would only have to do the polling and storage, it might be able to keep up. If that worked, I could up load the data to the Tablet from the second Mega via Blue Tooth. That would be simple enough.

I'll do some speed tests on simulated data files and see how that goes. I'll let you know in the next day or two.

It's worth a try

Thanks again for your thoughts

Ken

14

KenK:
I think I'll try to set up a second Mega such that it polls the ECU, stores the data in RAM and sends the data to the Dash Mega when polled. The second Mega could then format the data and send it to a second SD chip. Since the second Mega would only have to do the polling and storage, it might be able to keep up. If that worked, I could up load the data to the Tablet from the second Mega via Blue Tooth. That would be simple enough.

You have not posted your Mega program so we cannot know what is using up all its CPU time. (And it may be a long program and I may be too lazy to study a long program :slight_smile: )

From what you have said so far my guess is that the only heavy computational load on the existing Mega is updating the display. If that is the case (and if the display part of the program is as well written as it can be) then maybe a good strategy would be to use one Arduino just to manage the display based on data sent to it from the "main" Arduino. That way all the interaction with the ECU could be managed in one place and the display could be handled separately.

...R

15

Well, I have an update for you.

With respect to the Dash Mega, managing the Displays is very time consuming. And I am running two (2) of them.

The program in the Dash Mega is pretty big (about 1700 lines). You might be interested in looking at that but that will take you a while to get through. A lot of the program involves loading data into constants used by the screens (Way points, ect. , Lat and Long). This is done with the use of switches.

The screen updates are by far the slowest. Also the GPS down loads are slow as there very verbose and run at 9600 baud. The GPS data also has to be parsed to get the info I want. I am using ADA's library for that.

Now I did some testing today.

I wrote a program that would take data from a 210 point array, send it out Serial port 1, Receive it on Serial port 2 and write that onto the SD.

By making the Mega run through this 24 times, I was able to get a pretty good idea how long the cycle takes. There is one issue that caused me some grief and that was the time it takes for the Mega recognize that there is data in the Serial Port 2 buffer. I found that I had to put in a 10ms delay between writing to Serial Port 2 and reading Serial Port 2. If I didn't, data got lost and the Mega would crash.

The total time for the transaction with the 10 ms delay is about 50ms. Not bad.

Side note: I have increase the size of the UART buffer from 64 bytes to 220 bytes.

I have not tried to format the file placed on the SD but at least I know that the Mega can do that. The data file expected by the Tablet is a CSV file. Not to hard to generate. I don't think I need to sort the data just load it into a CVS file and assign a file name based on a real time clock. Also not a deal breaker.

It is starting to look like I could have the Polling Mega poll the ECU, write the data to the SD chip and service the Dash Mega at a rate of once a second.

Now to get the data off the polling Mega, I think I can setup a function that would send the data to the Tablet via blue tooth. That would be done when polling the ECU was not being done. At this time I don't know how I would receive the data file with the Tablet but that is a ways down the road.

The next step is to figure out how the Tablet communicates with the ECU. I suspect that there is a CRC involved.

Thanks for your ear. I got to go.

Ken

16

An update on the router project.

I did get the router working. The architecture has changed a bit but it works for my needs.

Architecture:
First, the Arduino Mega is connected to the ECU via a hard wired RS 232 connection running at 115,200 baud. The tablet is connected to the HC-05 Blue tooth (BT) converter running at 115,200 baud. The Dash is connected to the Mega through a separated RS 232- BT converter running at 115,200 baud.

The transmit (Tx) line from the ECU is connected directly to the HC-05 BT converter and the Mega’s UART #2. The ECU’s receive (Rx) line is connected the Tablet and the Mega’s Tx lines through two (2) channels of a 74HCT125 buffer. The buffer has tri-state outputs. By default, the Tablet has access to the ECU’s Rx line. If the Tablet is present, it will poll the ECU about 15 times per second (about every 66 ms).

When data is available from the ECU, the Mega will store the data received in a 225 point byte array.

A watchdog timer is setup that monitors the data received from the ECU. If data from the ECU is received at least once every 300 ms, control of the ECU remains with the Tablet. If data is not received by the Mega within the 300 ms window, the state of the two 74HCT125 buffers are reversed and the Dash is allowed to poll the ECU.

The Dash collects its data from the data array within the Mega every 700ms.

Several Arduino problems were encountered when it came to sending and receiving long data strings using the Mega.

1), If the I tried to transmit data strings longer than 64 bytes, the Mega cut the transmission off at 64 bytes. To get around this problem, I had to go into the Arduino “HardwareSerial.h” file and change the transmit buffer size to 220 bytes. This fixed the problem although it does consume a lot of RAM. 220 bytes per open serial port. Three open serial ports equals 660 bytes of RAM.

2), If the I tried to receive long data strings the data received was corrupted. To get around this problem, I had to go into the Arduino “HardwareSerial.h” file and change the receive buffer size to 220 bytes. Again, this conumes a lot of RAM.

3), When I tried to receive and store the 219 byte data string repeatedly, the data stored in the array would become concatenated or corrupted. To get around this problem, I had to put in delay between “if (Serial2.available() >= 1) {“ and “while (Serial2.available() >= 1) {“. You will notice that the 18 ms is about the time required to send the 219 bytes of data at 115,200 baud. I can’t say that I understand the issue but the delay fixed the problem.

See code below:

byte a, InByte ,WatchDog;
unsigned long previousMills;

 if (Serial2.available() >= 1) { 
    delay(18);// Needs this to allow time to receive the 219 bytes of data
    while (Serial2.available() >= 1) { 
           InByte = Serial2.read();
           ECU_RT_Data[a] = InByte;
           a = a +1;
          }
    previousMills = millis();
    PrntData(); // Development function to allow me to see the data as received and stored
    WatchDog =0; // Watchdog timer
   }

For now, the router works although I know there will be some issues that come up and refinements made.

I just thought I would enter this post for those who have and will see this series of post in the future.