RS232 to Ethernet

This is my first Arduino project. It's been probably 20yrs since I last programmed in C++ and I've read that the Uno performs best with this. I am slowly re-learning this language with tons of reading.

My goal is to communicate with a Serial device (RS232 signal is 5v, the baud rate, bits, and parity are also known) via Ethernet. After researching the vastness of the internet, I think I need an RS232 to TTL Converter, Ethernet Shield, and ATmega 2560. I chose the 256k because I don't know how big the code will be to make this work. I felt 32k would be like putting a refrigerator in a microwave box. I'd rather have too much than not enough.

My guidance question is: Will the equipment I've listed above make the connection I need (other than the obvious cabling)? Will the Ethernet Shield need any additional programming to convert TTL to packets, is this built in, or does the ATmega do the conversion and pass this info back to the Ethernet Shield for transmission? My concern is overloading the Uno with too many tasks.

You may be wondering why I didn't just simply buy an RS232 to Ethernet convertor and write a program to send/receive data from the PC. That answer I can say is that I wanted something to challenge me and create myself that has a web interface. It's quite boring being forced to sit at home all day.

So yeah, I'm at square 1. Baby steps, right?

I think I need an RS232 to TTL Converter

If the signal is 5V (TTL) serial, there is no need for a RS232 to TTL converter. Real RS232 that uses ±12V signals would require conversion. You can connect 5V (TTL) directly to one of the extra hardware serial ports of the Mega.

RS232 signal is 5v

I think I need an RS232 to TTL Converter

These two statements are contradictory. If the signal is 5V, either you don't need the latter device, or you haven't explained your need properly.

Edit- you have to answer fast around here... :slight_smile:

Will the Ethernet Shield need any additional programming to convert TTL to packets, is this built in, or does the ATmega do the conversion and pass this info back to the Ethernet Shield for transmission? My concern is overloading the Uno with too many tasks.

Yes, you will have to write the code for that. The Uno can probably do that without breaking a sweat. If not, you can transfer the shield to a Mega.

You need to be more precise with your terminology, TTL is a logic level (hardware) description, and packets are a software thing. I'm assuming you meant, "serial".

The advantage to a Mega (aside from the extra memory) is the extra hardware serial ports. You can use a software serial port on the Uno in order to preserve the hardware serial for program upload,debug and monitoring program flow and variable values, but those software ports will not support baud rates faster than 38400.

And the term "TTL" is an annoying misnomer. We do not use TTL levels at all, these devices are CMOS.

First question is if you can plug the Ethernet cable into the computer, connect to your device and get the results you want?

Then put the Ethernet shield on the Mega, and send the same signals. Bob's your Uncle.

The Ethernet shield connects to the thing you have and handles all the interconnection, voltages, etc
The Mega controls the Ethernet shield and tells it what signals to send.

The is all dependent on your thing, being Ethernet compatible.

groundFungus:
If the signal is 5V (TTL) serial, there is no need for a RS232 to TTL converter. Real RS232 that uses ±12V signals would require conversion. You can connect 5V (TTL) directly to one of the extra hardware serial ports of the Mega.

Yeah, it's real RS232 and definitely not a digital (TTL) signal.

groundFungus:
The advantage to a Mega (aside from the extra memory) is the extra hardware serial ports. You can use a software serial port on the Uno in order to preserve the hardware serial for program upload,debug and monitoring program flow and variable values, but those software ports will not support baud rates faster than 38400.

This is a BEAUTIFUL little piece of information. Thank you!! The device I’m controlling is limited to 19200, so this would work for me.

dave-in-nj:
First question is if you can plug the Ethernet cable into the computer, connect to your device and get the results you want?

Then put the Ethernet shield on the Mega, and send the same signals. Bob's your Uncle.

The Ethernet shield connects to the thing you have and handles all the interconnection, voltages, etc
The Mega controls the Ethernet shield and tells it what signals to send.

The is all dependent on your thing, being Ethernet compatible.

The device I'm controlling isn't Ethernet friendly. I wish it was, life would be so much simpler. :slight_smile:

RS-232 includes various control signals such as RTS and CTS. Does your device use such control signals?

Paul

It would greatly behoove you to reveal this mystery device that you are interfacing.

Paul_KD7HB:
RS-232 includes various control signals such as RTS and CTS. Does your device use such control signals?

Paul

No RTS or CTS signal requirement from the device. It just need 3 wires from the device, RxD, TxD, and a ground to communicate.

aarg:
It would greatly behoove you to reveal this mystery device that you are interfacing.

I didn't want to reveal the device too much so I didn't get the "I got an app for that!" or "I've written so much code for that" or "Oh, you're one of THOSE guys" responses. LOL I'm doing what several people I know have done, but I wanted to put my own tweak on it sorta say. I'm trying to build an interface between my slot machine and PC based on a protocol standard. I chose the Arduino way first to see if I can make it a self-contained unit that doesn't need an outside source to operate. After success, I would then take, what I feel is, the easy path of just getting an RS232-Ethernet adapter and coding a program to talk to it.

I'm a retired Electronics Tech, so I'm a "hands on" kind of person. I gotta know "how" and "why" it operates instead of plug-n-play. I still haven't decided if I want to code in C# or Python (an alternative I heard that worked). I understand Python is larger, but that's another reason why I picked the 2560, just in case.

peasoup:
No RTS or CTS signal requirement from the device. It just need 3 wires from the device, RxD, TxD, and a ground to communicate.

Now the real problem you have to address is: does your device send complete blocks of data as a complete message or does it dribble out character by character? The reason I ask is the ethernet is message based and if the device just sends bytes and not actual complete messages, you need to make a determination of how to make the conversion.

Paul

Paul_KD7HB:
Now the real problem you have to address is: does your device send complete blocks of data as a complete message or does it dribble out character by character? The reason I ask is the ethernet is message based and if the device just sends bytes and not actual complete messages, you need to make a determination of how to make the conversion.

Paul

Responses from the machine are complete blocks, some add a 16-bit CRC to the end (I'm assuming for validation purposes). I've been told I need to make sure there's a wake-up bit, this I'm still researching.

So far, so good!

By having a CRC in each message, then your machine may expect an ACK response for a valid message or a NAK for a bad message and will resend the last message. Explain?

Paul

Paul_KD7HB:
So far, so good!

By having a CRC in each message, then your machine may expect an ACK response for a valid message or a NAK for a bad message and will resend the last message. Explain?

Paul

The protocol utilizes an implied ACK or NACK only on the "server" side.

The machine side IS though, required to send an ACK or NACK only on certain types of commands received. If the "server" does not receive either response after a requiring command is sent, it resends the command until some type of acknowledgement is received on those commands requiring this. After 3 non-responses, the "server" gives up and continues.

It does appear that every message received by the "server", that isn't an ACK or NACK, will have a CRC-16 attached to it.

Researching the past couple of hours I've noticed I'm going to have to include some type of CRC-16 algorithm to validate the data received on the "server" side. Not sure at the moment of the outcome if the CRC-16 is bad.

Steve

There should be lots of hits on an Arduino search for CRC-16 or Google can help. Too many decades have gone by for me to be of any help. But one of the message check algorithms returned zero if the bytes of the CRC were included in the test. The helped when using assembly on an 8-bit machine.

I am sure I have the code, but it is on Apple floppy disks!

Paul