I'm using a Mega 2650 as a hub for 4 serial communications networks, all local to the house and shop. Max wire length is about 300'. One of the networks will be connected via the TX/RX pins, which also feed the USB chip. That network is contemplated to be TTL at 5V.
My question is, if there is no signal on the USB connector, can the TX/RX pins be safely toggled at 5V, eg, is the input/output of the USB chip wire-OR'ed to the serial pins? Further, if the RX pin has an external pullup resistor to 5V, say 2K ohms, will that prevent the USB chip from driving the serial pins when and if I need to do an in-circuit upload via the USB?
BTW, I have a random question about Processing, which is running on my laptop that is connected to the Mega via USB. I understand the reset of the Mega when I open Processing, but I don't understand why it resets when I close Processing.
Dr_Quark:
My question is, if there is no signal on the USB connector, can the TX/RX pins be safely toggled at 5V, eg, is the input/output of the USB chip wire-OR'ed to the serial pins?
Yes you can use Tx and Rx when there is no USB connection.
If you want the precise details of the hardware look at the schematic for the board.
Further, if the RX pin has an external pullup resistor to 5V, say 2K ohms, will that prevent the USB chip from driving the serial pins when and if I need to do an in-circuit upload via the USB?
When you want to upload a program it is essential that the USB side can drive the serial pins. The usual problem is that whatever external device is connected to Rx and Tx prevents that from happening and needs to be disconnected, or isolated to allow a program to be uploaded.
If you want the precise details of the hardware look at the schematic for the board.
Usually true, but not always. For example, the 16U2 drives the Tx/Rx pins using its port D pins. From my reading of the Atmel data sheet for the 16U2, para. 2.2.6
As inputs, Port D pins that are externally pulled low will source current if the pull-up resistors are activated. The Port D pins are tri-stated when a reset condition becomes active, even if the clock is not running.
I gather that these pins are actively driven, both on the high side and low side. This means that the 16U2 would have to be in a "reset"(floating) state in order for a direct input to Rx to work, except that the 1K resistor between Port-D on the 16U2 and pin PE0 on the Mega provides some isolation.
The bottom line is, we know a direct input to Rx works, but I'm assuming that the 16U2 is not in a tri-state condition during normal operation of the Mega, so the input impedance is going to be approximately 1K against a +5 pullup (the output of the 16U2 to the Rx pin is most assuredly held high when there is no serial input to the USB port).
This is a non-trivial piece of info when you're attempting to drive the Rx pin with up to 15 wire-OR'ed external microcontrollers.
BTW, there appears to be a small error on my version of the Mega schematic. In the ground circuit of the USB connector, there is a solder pad bridge near the lower left of the 16U2 that is shown to be unshorted. Physical inspection of the bottom of the pcb shows it to be shorted, similar to the reset enable pads. If it was as depicted in the schematic, there would be no way to power the board from the USB connector.
Why not use one of the other Hardware Serial ports on the Mega?
I can re-analize the networks and maybe reduce from 4 to 3. On the other hand, that 1K input impedance provides a lot of noise immunity, so it's not a bad thing unless the wire-OR'd network has problems pulling the pin down to something like 0.5V to meet TTL switching levels.
When Rx is pulled low, the voltage across the 1K resistor should be approximately 4V. So it takes a 4 ma sink to hold the pin low. This is well within the capability of an Arduino Tx pin, which can sink a max of 20 ma. So I don't think there's an issue due to the connection to the 16U2 port-D.
However, when wire-OR'ing a bunch of Tx pins together, you need to isolate them with a small signal diode at each pin. These can have a forward voltage of as much as 0.7 V. The Tx pin itself will have a typical low threshold of about 0.2 V (Fig 32-27), so the voltage seen at the Rx pin will be ~1V. The 2650 electrical spec for input pins shows reliable "0" detection at 2.1V. This leaves about 1V noise immunity for the Rx pin.
Computing the induced noise in the serial signal line that is buried in parallel with the 300' power wire to the shop is a bit above my expertise. I guess I'll just have to cycle the table saw a few times and sit through a few thunderstorms to see how many spurious start bits are seen by the Rx pin(s).
Why not use something like RS485 which is designed for multiple drops. Or maybe CANBUS?
Darn, good idea. I have some RS485 boards I was using for a long-haul line (1000'), but hadn't thought of using it for multiple drops. Thanks.
The project is for my "green" house. There are 4 networks--HVAC (7 controllers), Radiant Heat (15 controllers), Lights (9 controllers), and Miscellaneous (7 controllers). 95% of all the messages for each network remain on that network, but there are a few that need to be shared, eg, time, total water used, temperatures, day/night, security, and a few others.
Once you make your systems computer based and low voltage controlled, the opportunity for fooling around grows exponentially. For example, if you turn on the light in the shower, the bathroom exhaust fan turns on one minute later and remains on for 5 minutes after you turn the light off. The bath fans all go through the HRV, so there's really no appreciable heat loss when the air is exchanged.
You really don't want the details. The user manual is approaching 200 pages (includes all the software files and pcb layouts).
If the word "controller" means "microprocessor" I wonder why a single microprocessor could not deal with each group of functions, or maybe even all 31 functions.
If the word "controller" means "microprocessor" I wonder why a single microprocessor could not deal with each group of functions, or maybe even all 31 functions.
From a processing power, no problem. But there are displays in many of the rooms, so driving a display needs a local processor. In some cases there are redundant processors in order to prevent things like water spills, etc. And in other cases the network was built up piecemeal so processors were added to the new areas using a cooperative network design--units could be added or subtracted without changes to the remainder of the network.
Hey, an Arduino processor is inexpensive and in many cases there were "prototypes" running a year before we moved in, to gather data and just check out nominal operating conditions. So far there have been zero failures.
Dr_Quark:
Hey, an Arduino processor is inexpensive
True. But there is no such thing as a free lunch. And in your case the "cost" seems to arise when you try to connect everything together. Probably unavoidable now - we must start from where we are.
Yes, there is some cost, but a large part of designing and building this "green" house was the payback of being able to experiment with the systems. All of them have the capability to fall back to very simple operation. For example, the house is perfectly happy to operate on just two processors, which run the heat. It just requires some manual adjustments now and then. But it also means there is a total loss of data collection. And it also allowed me to start simple and add complexity as I had the time. All in all, it has been successful and rewarding. The next significant addition will be remote reporting and control of the temperatures in the paint/kayak building room (part of the shop), so I can monitor the resin curing cycle from the house. And on and on.
Thanks for your inputs. I am going to look into the RS-485 link, but it will be interesting to see how far I can take wire-OR'ing the units together first. The limit may turn out to be X units or Y number of feet of link, or some combination. We'll see.
