Connecting Two UARTs?

I have a project which consists of a pair of microcontrollers (PIC16F877A and PIC16F777 to be exact). These function as a unit, with one being the "master" and the other a "slave". They respond to commands sent on a serial port. Electronically they're hooked up with the input going to the master CPU's UART input pin, so it can receive commands and act on them. The master CPU's UART output pin is connected directly to the slave CPU's UART input pin so that it can send commands on to it when necessary.

Unfortunately, it looks like the slave isn't waiting for input on its UART. I'm guessing that it's seeing noise (and thus endless framing errors) on the line, confusing it. So now I'm not sure if the master's properly driving it when not explicitly sending a byte or something.

So in a setup like this, do I need to have a pull-up or pull-down resistor on the serial line between the CPUs or something? 

                 ___________       ___________
        |\      |   CPU 1   |     |   CPU 2   |
        | \     |           |     |           |
Input --|  >----| UART IN   |  ?  |           |
        | /     |  UART OUT |-----| UART IN   |
        |/      |___________|     |___________|
      RS-485
     Receiver

Any hints would be appreciated. Thanks!
Crossposted to electronics and microcontroller

ETA: Solution was found. Thanks to all the suggestions from people here! Actually, it turned out I had the hardware and configuration bits all correct, but just needed to refine the timing a little bit. It turns out that to use the USART, you SET the TRIS bits for both serial pins. Then when you turn on the serial port, it takes over management of the pins, tri-stating the TX line when the serial transmitter is disabled, and driving the output (in spite of TRISC) when the transmitter is enabled.

It also turned out that I didn't need a pull-up or -down resistor, at least in this case. Once I got the timing right, so that the master CPU's transmitter was on and driving the line way before the slave CPU's receiver was turned on and listening, everything worked out just fine.

Zombie

I'm looking for a bit of guidance on choosing a microcontroller.

Overview: To light my water cooling rig with a color corresponding to the water temperature.

The main reservoir in my water cooling system has an acrylic top and bottom. The bottom section has a predrilled whole meant for an LED. My plan is to mount either a dual color LED(red, blue) in this hole. Or drill a second whole and mount 2(again red, blue). Also I will be adding a thermosistor(or some other temp sensor band-gap, etc.) to the loop for temperature sensing.
I would like to have some kind of microcontroller/basic stamp/RISC CPU+Dog watch the thermosistor value(or some kind of interpreter hooked up to the thermosistor) and vary the intensity of the two LED's accordingly. So when the system detects say a temperature of 30C and below only the Blue LED will be lite. But once 35C or more is reached it should slowly add in the red LED while dialing down the blue LED until say 50C. At which point I would like the red LED to be fully lit. I would imagine through the use of 2 PWM channels or output to some kind of external PWM controller. The system will run off the computers powersupply as 12, 5, and 3.3 volts are all readily available.
( Collapse )
hog
  • in0p

OOpic vs Basic Stamp

Hi, I'm new here and don't do the microcontroller thing too often but am driven by task to get back into it :}

I worked with the Stamp some years ago on a "real time" servo controller. Now I need to build a small process control system. I was ready to dust off my old Basic Stamp notes and buy some toys when I found the OOpic. It does have a couple pluses over the Stamp, mostly the virtual-circuits multitasking feature. But besides that I'm still very biased toward the Stamp. There's more ready made parts/boards/gadgets for it, I already own some of the gear and I'm familiar with the Stamp. And I hate judging from appearences, but the OOpic site is not too great (is the English in the manuals like that of the site?)

I already know what all you awesome assembly gurus will say to all this Basic stuff :} But does anyone have OOpic vs Stamp experience? Hopefully this doesn't start a big micro-war, I just want to know if the "multitasking" is worth switching over for. Thanks for any help!

www.parallaxinc.com
www.oopic.com
avitar
  • davmoo

Microcontroller choices

I've been away from the microcontroller world for quite some time now. The last thing I built was around a Motorola 6805...yeah, that long. I realize that what I'm about to ask is mostly a personal choice, a lot like asking "who is better, Santa or the Easter Bunny?", but I'll ask anyway...

Let's pretend you've been away from microcontrollers a really long time. You now need to whip up something that involves controlling a (still) camera and needs fairly accurate timing. You also need to drive a small (128 x 128 or so) lcd (not with live video or photos or anything like that, just time and status and stuff like that). It would be nice if it were fairly cheap to develop on, and thrifty on batteries too. What would you use?

I've been looking at a couple of things, but I'll not mention them yet in order to not taint your answers.
Tweak

Transceivers, Cell Phones, and RS-232.

Transceivers, Cell Phones, and RS-232. Ok, here is my situation, I would like to have my computer communicate large distances to a Microcontroller. I can find simple RS-232 transceivers that will get the job done, but will only communicate a distance of 20 Meters. I found one company that www.maxstream.com that sells RS-232 RF modems that can go up to 30 miles (if you have an extreme antenna). But I would like to communicate with my MCU device over greater distances. Perhaps 100 miles, but it is within a cell site. I don’t mind using a cell phone, but I don’t know how. Could anyone help me out here?
display
  • fub

74.4094 headaches

Not directly microcontroller-related, but I figure there are more people who use 74HCT4094 shift registers in their microcontroller projects.

I have a 'train' of three 74HCT4094 shift registers, that I drive with a PIC 16F628A. I use two of the three shift registers to drive two 7 segment displays -- with the decimal point, that makes for 8 leads. The displays are common anode, so the shift registers have to sink the current from the segments. (The third shift register is for driving something else, which has not been hooked up yet.)
The circuit consists of a PIC driving the shift register train. The strobe lines of all three shift registers are tied together and to a pin of the PIC. The same is the case with the output enable and clock lines. Pin 9 of a shift register is tied to the data line of the next shift register, so that the data will, indeed, shift from one register to the next. The first shift register's data pin is fed directly from the PIC.

To test the circuit, I clock in 1's and 0's alternatingly -- 16 bits in all.

When there is only a shift register in the first socket, it all works as expected: half of the segments is lit up, the other half is off. But when I place a second shift register in the second socket, all segments of both displays all light up -- as if only 0's have been clocked in. This also happens when I leave the second socket empty and place a shift register in the third socket.
When I measure the voltage on, say, the OE pin, I get an even voltage across all the three sockets, so it seems unlikely to me that the extra shift register dips one of the lines below the threshold.

Can anyone help me fix this problem? I'm on a deadline (it's for a christmas present for my dad), and I have been trying to get it to work for four days now...
If you need more information or a clarification, please don't hesitate to comment and ask!

EDIT: I got it to work by driving the second shift register from the PIC and feed its output to the first shift register. There is no reason why it would not work the other way around, but I'm not complaining.

EDIT PART THE SECOND: And now it is broken again... I undid all the changes I made to the circuit, but that didn't help either.
  • Current Mood
    drained drained