UART vs software RS232

I must be missing something but isn't RS232....RS232?

If it's an RS232 data stream, 5v logic 1 and 0v logic 0, there wouldn't be any difference between a UART and software RS232?

I have 2 PICS that work fine together with software RS232, one transmits...the other is a receiver.

But, no matter what I try I can't get a wireless link to work.....modules I know are configured right. (xstream modules).

Only thing in the maxstream documentation is that the serial data interface required is listed as CMOS UART.

Maybe I need to pullup both PIC pins or something? (I think I tried that though).

THANKS.

If the system works with a wire between the two microprocessors then you can say the folowing:
The transmitter does not transmit.
The receiver does not recieve.
Both don't work.
The transmitter or the receiver or both units change the pulse into something else or even invert it.
I should say: Take an oscilloscope and do some measurements.
This is the quickest way to see and solve you problem.

So if the modules are asking for CMOS UART in the data sheet, then you don't see a problem with a direct connection from the PIC pins using software RS232?

The difference may be if signals are inverted or not.
If using SEROUT try HSEROUT.

Norm

I'll try inverting -- that option may be on the module in configuration -- like I say the hardwired connection is fine.

Pardon my lack of knowledge on the matter but what exactly is the difference between
software serin and serout, hserin etc and the UART?

I know the good thing about the UART is that it can run in the background but other than that, what are the differences?

Thanks kindly.

The USART is hardware, is faster (115.2k baud), has a buffer but is not capable of inverting to eliminate an RS232 driver.

If using SEROUT try inverting or non inverting as per the table in PBP help.

Which command for RS232 are you using?

Norm

By command you mean 8N1?

I'm only using 1200 baud.

So what is Hserin and hserout? I'd still like to know the difference between software generated RS232 and "hardware" RS232.

Just the basics of what is going on.

I'll figure out my problem.....might have to unpack my scope. (wherever it is).

QUOTE "By command you mean 8N1?"
I mean statement: SEROUT?

Software RS232 can be inverted/non-inverted in software.
Hardware cannot.

SEROUT PORTB.7,1,["START",13] '1200 true
SEROUT PORTB.7,5,["START",13] '1200 inverted

Norm

Quote:

---

Originally Posted by Normnet

QUOTE

SEROUT PORTB.7,<font color=red>1</font color>,["START",13] '1200 true
SEROUT PORTB.7,<font color=red>5</font color>,["START",13] '1200 inverted

Norm

---

RTFM applies here, in the serout and serout2 sections, you will discover " MODE ", now when using <font color=red>SEROUT</font color>, if you <font color=blue>INCLUDE "modedefs.bas"</font color>, you can specify the mode as in below:

Code:

---

SEROUT PORTB.7,<font color=red>T1200</font color>,["START",13]  '1200 true
SEROUT PORTB.7,<font color=red>N1200</font color>,["START",13]  '1200 inverted

---

RS-232 defines the idle condition as steady MARK. This is -3 to -15 volts AT THE CONNECTOR. Likewise SPACE is a positive voltage of +3 to +15 AT THE CONNECTOR. In contrast, PIC 'idle' is almost always assumed to be 0 volts.

These high(ish) interface voltages are well beyond TTL levels and so an Interface Converter or Line Driver is frequently required such as the older 1488 and 1489 or the newer MAX-232 family. Line Driver chips also serve for electrical protection of the PIC from outside interference and are usualy socketed on the circuit baord for easy replacement as they get zapped fairly often.

Line drivers/interface converters are all INVERTERS. So this means the levels at the PIC are now the opposite of what you mention in your first post. MARK, which was a negative voltage at the connector becomes +5 volts at the PIC. SPACE becomes 0 volts at the PIC.

SERIN allows selection of 'true' and 'inverted'. You use 'true' when you use a line driver or max-232, otherwise use the 'inverted' setting when you have no interface chip in line. HSERIN and SERIN2 expect you to use an inverting interface chip IF you are going to the outside world via an RS-232 connector.

For short distance or internal PIC to PIC comms you can dispense with the line drivers but you will probably get errors in the first character when sending between PICs at TTL levels.

To eliminate these errors all you have to do is condition the interface to 'mark' with a positive voltage long enough for a character time. You only need do this at the start of each message or you can ignore this issue and simply add a few throwaway characters at the start of every message. I find it better to add the HIGH xxx : PAUSE n and get every character every time.

Try using
HIGH TxDpin
PAUSE 1
and then output your message such as..
SEROUT/HSEROUT/SEROUT2 TxDpin, message

HTH
BrianT

I know all about the history of those higher voltages but now in the 0 - 5 volt world....does it really just come down to this?....

HSEROUT and HSERIN needs an inverted input where SEROUT and SERIN can operate either true or inverted? (as long as both ends are the same?)

My device is set to true, 1200 baud, 8N1....having problems with wireless but fine with wired...whether a straight short RS232 or I also have an RS485 connection that can run for a mile. Works like a champ.

I'm going to look closer at it today -- never had much luck with wireless.....(yet).

Fact is though, using serout and serin, phase isn't an issue, as long as both ends are the same, right? Both T or Both N.

Correct?

What is the RS232 spec on the device to which you are interfacing?

Norm

I'm not having any luck -- works great wired though.

As mentioned before, I'm using the PIC (16c65b) SEROUT and SERIN.

The wireless device is a maxstream Xstream X24009 oem module.

The interface listed in the data sheet says CMOS UART (as I mentioned before).

I've tried everything.

Inverting one side, both sides, putting the signals through a 4011 inverter....the scope shows
data on the rcvr and xmtr but I don't have a dual trace so it's really hard to see how the streams are matching up.

Oh well -- I went through this before, I may just give up and move on.

I wish I would have used the PIC's hardware UART in the first place....too late now.

I have a pair of XStream units I've been using for a few years that work great. Just use
true mode and connect PIC I/O-pins directly to them.

It may be that you have them configured for another data-rate or something, but I would
check with Digi or Maxstream to be sure they're working if having problems with them.

Mine worked perfectly right out of the box.

For what its worth, I use LINX RXM/TXM-XXX-LR serial modules with inverted 9600 8N1 with no problems at all. I use serin/serout2 commands and just played with my timing to be able to update both my reciever boards with string data. The serial modules work GREAT up to 3000' away and can go up to 10k baud. I would give them a shot if you are frustrated with the other modules you are using. The price for the pair ~ 25.00 so not too bad. You can also purchase the development board.

Here is one line of code using 8N1 9600 inverted

Code:

---

SERIN2 PORTB.0,16468,[WAIT("TENSION"),DEC4 TN]'TEST 3

---

good luck!

Bruce and Earltyso --

You know, I think it's because I don't have a wait command in my code.

??

On my wired connection, that doesn't seem to be a problem although things are out of sequence a bit after power up....not a big deal with what I'm doing.....but with wireless, it may be mandatory? you think that may be it?

I'm also using 2 qualifiers in my code which I wouldn't think would be a problem as in...
qual1, qual2, data


Bruce, I'm using the X24009 modules -- 1200,8N1 -- I just changed the data rate to 1200 (they're 9600 out of the box) and left everything else at default when I used the XCT-U software and the XIBR setup board.

I'm going PIC serout to PIC serin pin to pin just like you. Both PICs true.

Also, I've never experimented with "timing" -- I'm a picbasic novice in that department....maybe I need to look at that......are you talking about the pulse width or something?

THANKS.

I always use a wait modifier to synch to the first byte in a packet.

This is the line used to receive in my remote sprinkler controller using a pair of
XStream 900MHz OEM modules;

SERIN2 RX,84,[WAIT("A"),CMD,RlyNum,State]

It waits for the A then grabs data. Really simple and it works.

I would probably have used a pair of Linx LR series like Earltyso did, but I built
the remote sprinkler controller LONG before the LR series were available.

Ok -- I'll keep playing with it.

I remember now why I didn't have a wait in there....because I have to keep things moving for counters and other processes....I never tried the wait command but it probably won't hurt anything....few milliseconds at most I guess.

It just keeps ticking me off though because it works prefectly wired, so I hate to be screwing with the code.

Thanks for the input.

A wait with a time-out is what you need. After the time-out the code will jump to the label of you choice.

I'm out to lunch on how to use wait and timeout.

here's my code for the receiver.....


SERIN PORTA.4, T1200, [QUAL1, QUAL2], LOWER, HIGHER

Works fine...looks for 2 qualifier bytes...then shows the data (lower and higher).

Do I even need wait? Is it in there as default because I have the qualifiers?

Also, in my PBP book it only talks about "WAIT" in the SERIN2 page ?


If I'm doing something wrong, how would I write the line above using "wait"?

I tried some things but got errors --

[WAIT, QUAL1,QUAL2], ETC
[WAIT,"QUAL1","QUAL2"] ETC

THANKS AGAIN

:D
That is how you WAIT using SERIN
From the manual:

Quote:

---

‘ Wait until the character “A” is received
serially on Pin1 and put next character into B0
SERIN 1,N2400,[“A”],B0

---

You are waiting on
[QUAL1, QUAL2]

Now to use a time out, again from the manual

Quote:

---

SERIN
Pin,Mode,{Timeout,Label,}{[Qual...],}{Item...}

---

See what we can do here

Code:

---

SERIN PORTA.4, T1200, [QUAL1, QUAL2], LOWER, HIGHER

---

change to this to wait on two QUALs and if QUALs are not received in 100ms, then it jumps to "LABELofCHOICE"

Code:

---

SERIN PORTA.4, T1200,100,LABELofCHOICE, [QUAL1, QUAL2], LOWER, HIGHER

---

Me thinks you are looking at this to hard, relax a bit . ;)

You're right -- that's always the case.

In fact, here is the conclusion.....

I "thought" that I had my code at T1200 but it was at N1200.....BUT, I didn't really care anyway because it was my (mis) understanding that as long as BOTH pics were the same, that it didn't mean diddly squat.

After all, it's just inversion isn't it?...and I was using CMOS inverters on my breadboard...so in my mind, I was trying it "both ways". ?

So, anyway, I just changed both sides to T1200 (I know, that was suggested in the first place).....and all is fine.

BUT what am I missing here?

Like I say, when I set up my wired connection, it didn't matter if I used T1200 or N1200....as long as the were both the same.....it worked either way......so, what am I missing here?

What a pisser.

--Michael

Also --

Is there ANYTHING I can do other than changing the code to T1200?

I have some units already out there using N1200 and was hoping to add wireless function to them.

Again, I tried 4011's but no luck.

When I say anything, I mean ANYTHING.

Could I put another PIC in my wireless module and do something there?

I think also Brian may have hit on it but I still can't plant in my mind why N or T even matter.

He commented that without a line driver use N....with, use true.

I suppose there may be a driver on the module but I'm still totally in the dark why N and T even make a difference -- I mean data is data -- whether it's upside down or not?

With your wired connection you had full control over both modes so you could just program
both PICs to send/receive in inverted or non-inverted modes.

With the Maxstream units your only option is to program the sending/receiving PICs to use
non-inverted modes - if connected directly to the Maxstream modules.

If you prefer inverted mode, then a simple inverter on both ends should do the trick, but it
has to be fast enough to handle whatever data rate you use without messing with timing.

I would opt for a simple firmware change before adding new hardware though. Just my 2c.

Quote:

---

data is data

---

Data is data, but inverted or non-inverted does matter. Think about about it like this -
suppose you program a PIC to receive data in non-inverted mode. This PIC is the RF
module. Now connect another PIC to it that you've programmed to send & receive in
inverted mode. It doesn't work.

If you reprogram the 1st one to use the same mode, it works. You have control over that.
You don't with the Maxstream unit. So you program controllers on both ends to use the correct
mode, or insert a data inverter.

Ok Bruce....thanks.

It's working fine with a direct connection using T1200 on both.

I HAVE to get this solved in hardware though because I have some product out there and the pics are N1200.

Dagnabit...I tried a 4011, a 4093 and even a transistor and couldn't get it to work. I used pullups....tried it all.

Certainly a 4011 can handle the 1200 baud? I'd appreciate any ideas but I must get this thing to work with some external hardware.

I'm using a 4mhz osc but that's not an issue....I just need to pass the 1200 baud right?

I'll always use non-inverted from now on!

Maybe the 4011 is wired backwards for the direction you need to go? Never used one, just guessing.

Sorry to bore you guys with all of this but that's the wonderful thing about forums --
MORAL support.

I now have that eureka moment.

As it turns out, my ultimate intention was to use an RS485 line driver with my wireless because that's the way my wired connection is set up.

But all of my experiments were with the driver out and RS232...I figured I'd work my way up.

Bottom line....

If you want to use N1200 in your PICS, use an SN75176 and simply reverse A and B on the 485 side.

Works great now.

For the life of me though, I couldn't get the RS232 hardware inversion to work.

HIP HIP FRIGGIN HOORAY.