I've been playing with Arduino for some time now and I've come across a project that requires me to interface with two serial devices. Obvious problem here: the handy serial interface on the Arduino is a solitary creature.
I was thinking of multiplexing the two devices but then I realised I may need to access them concurrently and that could get messy I think...
So, I thought: "RS232, it's not really that complex a protocol. Surely I could build my own implementation!". I suspect I'm being naive - what I need from you guys is an indication of how naive. Is it as straightforward as I hope or am I opening a can of worms? :-?
At the moment, I use the Arduino Serial library and the dedicated 7/8 Rx/Tx pins. RS232 defines a lot more pins (RTS, DLR etc) but these all seem optional. In fact, from a hardware perspective, all I need to do is take two pins, double their voltages (enter a MAX232) and my hardware implementation is .. done?
Then there's the software. I'm hoping that I can redefine and overload the Serial.Begin() function to pass it the pins it should use for Rx and Tx. Then, I run two instances of the Serial object concurrently. My plan here is that all the yukky stuff of frame composition, start/stop bits/ synchronisation and buffering will all be handled in software.
Bingo, I have a variable number of RS232 interfaces, limited only by my pins.
Is it like that or have I missed something big? I guess other people have done this before?
On the Arduino, is there anything special about the 7/8 pins' hardware (other than their exaggerated voltages)?
Can I run concurrent Serial objects safely?
Mods: Not sure if this is a hardware of software query (yet) - please move if appropriate!
Yes the something big is that the serial drivers rely on the hardware attached to those two pins inside the processor. If you change these pins to something else, there is no serial hardware behind other pins and so it will not work.
AlphaBeta - thanks for the heads-up! Looks like some peeps have encountered a very similar issue before Strictlyy speaking, it's not exactly what I want (concurrent access to two devices at high baud), but this makes me think what I want isn't possible. I may be able to redo my logic to allow sequential serial access, which wold make this lib very applicable!
Grumpy_Mike - Indeed, but I'm wondering what hardware is behind them. There must be at least a MAX232-esque interface to manage the voltages, but from what AlphaBeta suggests, I think this may be all? And if it is, I can make up for it externally quite easily. Is there other hardware I've missed perhaps? Some kind of logic, or even perhaps a hardware buffer?
That said, I understand that many serial devices are quite happy to work with a 0-5v range, so maybe I can get away without even a MAX232!
There is no voltage conversion circuits inside the chip. It works on TTL only. Any voltage conversion has to be an extra chip.
Yes, the voltmeter says you're right. Looks like most PCs and phone are happy with TTL as well, so I never noticed..
It is inside the chip. It is a UART, you can't move it, you need one UART per serial port.
Ah, this is what I was wondering. So yeah, that puts a spanner in the works. I may try some bit-banging for the second port (which would be read only) - I think this is what AlphaBeta's suggestion helps with..
Well, it's certainly a good idea to use proper RS-232 voltages, but all the PCs I've used over the last couple of decades have tolerated inverted TTL, as long as the cables are short and you make sure the two pieces of gear have a good common ground. The near-universal use of MAX232-type driver/receivers have made most equipment less fussy.
But it's a good rule to follow, because even though you can get away with cheating much of the time, sooner or later you're bound to encounter a situation where you need that extra voltage swing to make the connection reliable. And that huge volume of MAX232s also makes it cheap and easy to do the job right.
but all the PCs I've used over the last couple of decades have tolerated inverted TTL,
Sorry being a Mac user I didn't realize how bad PC hardware actually is. If it recognizes 0V as a mark state then it is working way outside the serial spec and will be subject to interference and all sorts of noise.
And the equipment you connect the PC output to? :o
The hardware inside the AVR serial port is essentially a shift register plus a bunch of logic to detect beginning and end of characters, plus a clock-rate generator to clock the shift register at the appropriate speed. (well, double all that since it has to receive and transmit at the same time If you look up older computer hobbyist literature, you can sometimes find "clever" circuits designed to connect to your ASR33 using only TTL logic chips. I couldn't find anything that looks brilliant, but here are a couple links that might be interesting.
You can also find SPI and I2C interfaced uart chips, but they seem to mostly be overpriced solutions for the truly desperate; you might as well use two ATmega8s... (http://parts.digikey.com/1/parts-kws/spi-uart)
but all the PCs I've used over the last couple of decades have tolerated inverted TTL,
being a Mac user I didn't realize how bad PC hardware actually is. If it recognizes 0V as a mark state then it is working way outside the serial spec and will be subject to interference and all sorts of noise.
It's not PCs, it's the rs232 receiver chips. All the ones I've used (1489, 14506, max232/etc) will treat 0V pretty much the same as -12V or whatever, and the granddaddy of them all, the venerable MC1489 receiver, doesn't even have a negative supply voltage to implement a reference below zero.
What do you EXPECT it to do? It's not like a modern comm controller where there's a separate "signal good" indication; the output has to be either high or low regardless of what the input voltage is. At least this way you get to cheat easily (fond memories of connecting the "-12V" supply of the 1488 transmitter to Gnd, "+12V" to 5V, and having my SDK86 talk to my CPM machine "just fine.")
Now, a PC that doesn't TRANSMIT lower than -3V for mark is indeed broken. ("Be conservative in what you send, and liberal in what you accept!")
(And I bet you're not really sorry that you're a Mac user, either! ;D)
So the guy who relies on a fluke in the design of RS-422 receivers is sneering at the promiscuity of MAX232s?
I've lost count of the things I've connected to PCs in the last 25+ years. Everything from PICs to 8051s to Arduinos to custom test equipment to chip programmers. Even Macs, on occasion
The equipment design depends on whether I'm "hacking" or "engineering": if it's supposed to work for someone other than just me, or in an environment more demanding than my workbench, I make sure it has a proper driver/receiver. But I'm using a P4 (which is just a cheesy CMOS inverter) to connect the PC to my TTL-only Arduinos for programming. But I've bought a couple of MAX3232s (nice because they also work at 3.3V) to make similar adapters for any Arduinos that get connected to RS-232 interfaces for "deployment".
Want to see a real RS-232 to TTL hack? Check out how the Picaxe PC based IDE wires from a PC's RS-232 port to it's 5vdc logic level PIC chip using just two resistors.
page 37 of:
I got it running without the DTR and CTS pins...I left those open and the only thing i had to do is to ground arduino reset that correspons to arduino DTR...
Strictlyy speaking, it's not exactly what I want (concurrent access to two devices at high baud), but this makes me think what I want isn't possible. I may be able to redo my logic to allow sequential serial access, which wold make this lib very applicable!