Serial Communication

[micah4242]

Greetings I have been working with pic basic pro. I am trying to receive serial data sent by my basic stamp. This data is supposed to represent the humidity and temperature. Eventually I will set up my circuit with a rf module, but right now I am trying to get it to work with just a wire connecting my pic and my basic stamp.

My stamp is sending a Serout command.

My pic is set to receive on Serin2.

My problem is it doesn't seem to matter what the baud mode or baud rate is. I always seem to get the same results.

For example I tried to send 70 on my basic stamp. The hex value for this is 46. The pic sort of receives this but it seems to have added a 1 infront of the number.

After testing my serout command with my digital scope I confirmed that when I serout 70 the hex value 46 is sent out just like it is supposed to. The binary for 46 is 0100 0110. When My pic receives this value it seems to always have a 1 infront of the binary number and the whole binary number seems to get shifted to the right. The pic gets the value 1010 0110 (A6 instead of 46). I am not sure what causes this but regardless of what i send this 1 is always the most significant bit of the byte recieved. I have tried inverted mode ture mode, open drain, and about every other configuration I can think of.

My goal if it is possible is to send a tempature byte which represents the temp, a a humidity byte which represents the humidity. I want to do this using one serout command from my basic stamp, and a serin2 command on the pic.

Any suggestions would be appreciated

Thanks
Micah

[Squibcakes]

Hi,

I am not quite sure what you are trying to say. Are you saying that your PC is sending the data or the PIC is sending the data?

Your DECIMAL to HEX conversion method is not the way to send out the data.

You need to convert it to ASCII in your program, then have the PIC send it. The PC will then display the DECIMAL equiv.

The easy way to do it is to add 30H to each digit... In your case:

30H + 7 = 37H
30H + 0 = 30H

70(D) = 37h 30h should be sent out, along with a CR and LF.

So in your program send out these 4 ASCII chars to display on the PC:

37 30 0D 0A

I hope this works.

[micah4242]

The idea of sending everything as an ascii is a very good idea. This way when you are sending a zero, you don't get 8 bits that do not change at all.

The basic stamp uses a pic microcontroller at its core. I am using the basic stamp to send serial data with the serout command. I am using the pic16f84 to receive the data with the serin2 (pic basic pro) command.

The problem I am having is if I use the basic stamp to serout a 1, which is 0000 0001, then for some reason the pic 16f84 will receive 1000 0001. I have verified with a digital scope that the basic stamp is sending out correct data with the its serial command. When I send a 2 with the serial command of the basic stamp. The pic 16f84 will receive 1000 0010. This same thing happends when I send out a 3 I get 1000 0011. But if I send out a 4 or any number higher the results get really random. I have tried many baud modes, such as true, inverted, open drain, driven, and this same thing keeps happening. I have even used many different baud rates, and I still get the same result.

I have read of others have this same problem. I have read of a person sending a 0, 1, 2, 3.... all the way to 100, and only about 30 percent of all the data send was received correctly. The guy that did this was using the serout2 and serin2 commands while using to pics which were exactly the same. I found another person who actually got it to work. They suggested that sometimes the compiler doesn't always get the timing of these commands worked out.

I have tried all the suggestions I have read about, and I am still stuck.

[Melanie]

Don't be too hasty in blaming the PBP Compiler... if there was a problem you would have the majority of users up in arms, and since this clearly is not the case we have to consider other factors.

You've not given us the complete picture to be able to properly comment. (a) What Baud Speed are you using?, (b) What Oscillator Frequency are you using for the PIC?, (c) What Oscillator Xtal, Resonator, Internal etc are you using for the PIC?, and it always helps to know (d) what version of PBP are you using? (e) are you able to post the section of PBP code you're using? Sometimes people (including myself) can miss the obvious and another pair of eyes helps.

[micah4242]

(a) What Baud Speed are you using?,
I have tried baud speeds from 300 to 2400, true or inverted. This seems to have ot affected the results.

(b) What Oscillator Frequency are you using for the PIC?,

4Mhz Xtal

(d) what version of PBP are you using?

I am using the free evaluation version of Pic Basic Pro that can be downloaded at the rentron website.

(e) are you able to post the section of PBP code you're using? Sometimes people (including myself) can miss the obvious and another pair of eyes helps.

The basic stamp is using the code. (PBASIC)
temp = 0
For index = 1 to 100
serout 3, 16780, [temp]
temp = temp + 1
pause 500
next

The pic 16f84 is using the code
read:
serin2 PORTB.0, 16780, [temp]
...
Then I put my code to display the variable on a lcd. I don't have this code on this computer. It is in my lab, which doesn't have internet access. The display seems to always be consistant with what ever I send.
I can post the exact code tomorrow if you would like, after I get a copy on floppy disk and and take it to this computer.
...
goto read

[johnramsbottom]

The MSB (most significant bit) is the last one to be transmitted in a serial word. The stop bit comes on the next time cell. As the stop bit is effectively always a '1' it just may be that the stop bit is being incorrectly read as the MSB due to a timing problem such as a wrong baud rate or the cell receive sampling being to late.
Just a thought!

John R

[Squibcakes]

I was thinking along those lines too. Do stamps use start bits?

Why dont you try sending the data out from the pic instead and see if you still get errors

[micah4242]

The stop bit is probably being read incorrectly that would certainly explain the MSB most significant bit problem. It would be nice if anyone had an actual working transmitter and receiver schematic and code. Perhapes then I may be able to fix my problem. I thought of another method that might work. Convert the temp byte from serial to 8 bits parallel. Then send this data through 8 bit encoder then the transmitter then the receiver. Then I would use the 8 bit decoder, and finally use a parallel to serial converter. This way I can send as many bytes as I want. Before each byte I can send a value such as 0, 1, 2,... so that all the receiver has to do is wait for a byte. If it is 0 then it knows that the next byte is going to be the tempature value. After this value is received the receiver goes back into the main hold loop. If 1 comes in then it will process the if then loop associated iwth 1. I tried using the 74595 serial to parallel converter. It seems if I run the code that simply operates this ONE chip then the serial to parallel conversion works perfectly. But if I use this same exact code along with the code use to generate my tempature and humidity bytes, then for some reason the timing gets messed up.

So it seems that no matter which way I go I can seem to get this simple project to work.

Thanks for all your help

[johnramsbottom]

Yes, any asychronous serial data uses start and stop bits and the idea has been in use since the 60's. It is usually used where RS232 is involved. It is also used in MIDI. The actual voltages and currents differ widely between systems. The standard format is: start bit, a number of data bits (usually 8) starting with the LSB and finishing with the MSB, then the stop bit. If more data is to be sent then the new start bit can be sent immediately after the stop bit. A start bit can occur at any time following the stop bit time cell however. Obviously each bit occupies the same time interval or cell. The number of time cells per second is the baud rate.

As far as the polarity is concerned any bit which causes a voltage that is different to the resting voltage of the signal is called a 'mark'. The start bit is a mark as are the '0's. The stop bit and the '1's are the same as the resting voltage of the serial signal. This can be a bit confusing as one might expect the signal to rest at the '0' level but this is not the case.

The receiver's sampling clock is reset at the start of every start bit so a slight baud rate disagrrement between transmitter and receiver is not serious. However, a larger error will eventually cause wrong bits to be sampled in the receiver. This happens first to the later bits in the word (MSBs) because more time has elapsed to allow a sampling time error to build up.

I would advise the pseron with the problem to try raising the receiver baud rate slightly. If this is a PIC then the SPBRG value needs to come down a touch (not up).

John R

[johnramsbottom]

Micah I mentioned experimenting with the SPBRG value to adjust the baud rate. This is of course only relavant on PICs with an on board USART. I'm sorry I've only just realised you're using a 16F84 so obviously everthing's being done in software. All the same, if you can raise the baud rate a little on the receivong PIC try it and see how you get on. I only use assembler language so don't understand the code you show.

John R

[micah4242]

Raising the baud rate on the pic is a real good idea. I will have to try that. Thanks

[micah4242]

Another problem exists besides the 1 in the MSB position. The data transmission is very speratic. I think no matter what if we don't find a way of using a buffer like those in a USART then this async. transmission will always have problems.
Pics do very well when sending data to a computer because computers have USARTS. But Pic to Pic transmission doesn't have any buffer at all.

[Squibcakes]

I too was using a 16F84 chip and was having problems receiving data at one stage.

I found that the internal ram of the 16F84 was way too small (something like 68 bytes??) for my data project ( receiving NMEA string from a GPS )...

I started using a 16F628 chip which has 256 bytes of ram and runs at a faster clock speed. This eliminated my data problems.

You may want to use that chip which is directly pin for pin compatible to the 16F84 (and cheaper too)!

J

[micah4242]

I was looking at the pic 16F628 today. I noticed that it has an onboard uart. Would it be possible to look at your code and your protocol that you used to send the data. Perhapes even a schematic.

Does anyone have pic basic or pic basic pro code. Assembler would work too, but I would need help setting it up to be used on the pins that I would have available.

[Squibcakes]

I haven't had time to play with the USART feature yet. I have always just connected the Pic to a MAX232 chip and left it at that.

Other than that I just send the data out using this command:

SEROUT2 PINOUT, 188, [DATA]

Works well for me.

[johnramsbottom]

Onboard USARTs are well worth making use of. I write some fairly complex programs for commercial MIDI use and often have to use the available USARTS because the PIC software processing can not afford enough time to concentrate on the serial data directly. Dealing with serial communication just in software is ok but the great advantage of a USART is that it looks after itself by operating at the same time as the PIC is processing software. I find them particularly useful for receiving. You can use the appropriate interupt flag (which can just be polled rather than interrupt if you like) to 'tell' the software when a new byte has been received. For transmisison, a similar flag lets you know when the buffer can accept a byte for sending out. The only thing to watch is making sure you get the registers associated with the USART set up correctly!

John R

[micah4242]

I guess I will have to look at the data sheet to see if I can figure it out. It is over 100 pages, but I guess that is okay. Most tutorials you find on the internet are for the the 16f84.

Thanks again

[johnramsbottom]

There aren't that many pages just for the USART section and its quite informative. At the end of each section it verifies exactly what you need to do. The main thing is getting the correct bits set in the associated registers at the start of the program in order to tell the USART exactly how you want it to behave. Dealing with the USART after that is easy. If you have any difficulty let me know.

John R

[micah4242]

Well I did some more testing today. I found that when I sent my serial out command from my basic stamp through the rs232 to my debug terminal that the numbers are perfect. When I did the same thing using my pic no matter the baud rate or mode, The terminal always got junk. So I have concluded that somehow the real cause of the problem is with the oscilator timing.

The basic stamp runs at 20Mhz but everthing is tokenized so the timing is always constant. I am wondering if there is a special formula with pics of how the external osscilator is supposed to be setup while using the serial in and serial out commands.

I am still looking into that other Pic that has the UART but I am afraid that it might be too complicated for me to figure out, and I would still be in the same boat.

[Squibcakes]

Those Usarts sound pretty good.. I will have to have a play with tme some day.

Just a thought... When programming your pic, do you need to select the type of oscillator set up? ie Xtal, RC types etc.. Maybe that is not set correctly and is giving you the strange data errors???

[micah4242]

Well my development board is setup to have the ability to run on many osscillator types. All I have to do is set a switch on the board and change some configuration settings in my programming software. I actually tried changing the oscillator and I still got the exact results that I had before.

I think that the idea of having data received in the background using a hardware buffer uart is a good idea in principle anyway. I will just have to spend a few hours and comb over the 140 page data sheet for that pic chip.

Thanks for your help

[micah4242]

I found some really cool chips on www.parallax.com. This is the company that makes the basic stamp. They have something called the IR buddy. The makes wireless infrared transceivers very affordable, and easy to use.

The pair of IR transceivers is about $60 USD and the code for the basic stamp is included. This code can easily be used with pic basic pro as it is upwards compatible. These IR buddies have onboard microcontrollers to buffer incoming data. It is able to work on at least 4 different carrier frequencies. The onboard microcontroller makes it really easy to communicate bi directionally with stamps or pic microcontroller.

I may go this route instead of the rf route. Because this way I can now have bidirecitonal communication. Cheaper than I can have simplex communication with the rentron rf modules.

[micah4242]

Greetings to all! I finally figured out my problem. You need to use a 4MHz crystal or resonantor when working with serial commands. Once I fixed this everything was great.

[TaylorLogic]

stamps are laim

why you bother posting about them?

real men use pics for the hole project

this forum is for serious stuff not lego

[Squibcakes]

I have to agree.. PIC chips are a lot cheaper than stamps..

I wouldn't feel as bad frying a pic than a stamp.... so stick with the pic dude!

[micah4242]

After all these years I have finally found what is wrong. In order to send serial the onboard crystal must be at 4mhz or higher. If it is higher it must be setup such as "Define 20". To indicate at twenty. In this post I was sending from a basic stamp which is actually a pic to a pic. My problem was that the pic was not running on a 4mhz clock. Once the clock is updated then the serial comes in just fine

[rhino]

You could have saved yourself 3 years of work by searching through these forums. I can't count how many times it has been mentioned that you should atleast use a 4Mhz crystal for serial communications. I'm sure you would have run into the Define command for clock speed as well. Wow.... 3 years.... really?