PIC16F877 & Serial Comms

[G4LCH]

Hi Guys,
I am using a 4MHZ 877 with Debug and Serout And Serout2
I have in the latter cases added the mode include to get the correct modes
and ensured that the fuses are set correctly.

A simple routine returns rubbish in the terminal just as debug does

nCounter Var Byte

For nCounter = 1 to 10000
SerOut PORTC.6,N2400,["Hello"]
Pause 3000
Next

I have added the required declare statements as well

Define osc 4 ' We have a 4MHz Clock here

@ DEVICE pic16F877,XT_OSC
@ DEVICE pic16F877,WDT_OFF
@ DEVICE pic16F877,PWRT_ON
@ DEVICE pic16F877,LVP_OFF
@ DEVICE pic16F877,CPD_OFF
@ DEVICE pic16F877,PROTECT_OFF

and used @ DEVICE pic16F877,WDT_ON


DEFINE DEBUG_REG PORTC
Define DEBUG_BIT 6
Define DEBUG_PACING 3000
DEFINE DEBUG_BAUD 2400
Define DEBUG_MODE 0

And altered to inverted in the right state when not using Max232CPE Interface
that does have the correct voltages with 1uf caps on the charge pump pins.

and it still gives Garbage a loop back test works fine on both my PC and the Macintosh so I know that my cable is correct.

is there anything else I should be doing as Visual Basic is reporting framing errors, I adjust the Parity, Stop and data bits to no avail.

A loopback either side of the MAX232 Interface works fine as well so I know that using this test and the scope that the voltages are correct, I have also tested (visual) with my break out box and the signalling is fine.

Do I need any pull-up resistors on the ports ?? nope it still works the same way, I have also sent hex out and viewed the stream in hex mode and its garbage.


any ideas guys ??






This is driving me nuts

[G4LCH]

The debug statement also gives garbage
Mark

[sean-h]

With Serout you need to include this at the top of your code:

Include "modedefs.bas"

N2400 will invert the bits so you can just use a resistor straight onto the serial port.

If you have a max232 then this inverts each bit and you want to send it in True T2400

Regards

Sean.

[G4LCH]

Sean As I said in my note I have the modedefs in there and it compiles 100%
I have also tried it direct with 1k resistors and via an interface and i get garbage in all cases.

Mark

[G4LCH]

With the debug command I have also tried to use 4800 Bps and both inverted and non inverted with no luck still garbage.
Mark

[sean-h]

Mark you say you are using VB.

Have you simply ran up hyperterminal, set the com port to 2400 8 n 1, hit retunr to open port and then looked for the data, this will illiminate another step if the data is clear and then it has to be the VB side of things.

Regards

Sean.

[G4LCH]

I have used my own comms software, hyperterminal etc plus vb (gives me bit stream access) and nothing works.
I have this nagging feeling that this is the comms port to be honest or rarther the wrong caps on teh max232cpe level converter I have built several of these and have used 20uf instead these are proper maxim devices as well
but I have this feeling that it may be possible that the caps are wrong as the ICD does not connect either mmmmmm off to replace the caps I think.

But I have also tried without the interface as well and get exactly the same datastream ... The operating system is irrelevent but I have used W2k and OS X I have windows 98 so I may give this a try, I also need to check the fifo buffers for the W2K box and see if these are not messing me up...

The vaio machine I am using does not want to talk to some devices sometimes and maybe this is the root, of course it could be guess work as the Mac is rock solid.

Mark

[G4LCH]

Its not the serial ports


b var byte

include "modedefs.bas"

for b = 1 to 100
SEROUT PORTB.6,T2400,[#b]
next


Counts as you would expect, on the pic simulator with the code complied for the F84 and simulator set for F84 works great, set compiler to 877 and simulator to the 877 it delivers garbage.

This is telling me that there may be something wrong with my basic compiler
in the include files ?????

this should give 12345 etc but give junk with the 877 selected
Mark

[G4LCH]

After deinstalling all of the software and cleaning the machine (I do many different development tasks) I then re-installed the software components again. Checked the MAX232-Interface with another type of system requireing a level converter this checked out fine.

The same problem existed.

Then I decided to move to hSerOut as I could get closer the baudrate generator values..

Got the picbasic example, and still the same garbage.... Then I got the scope connected and sent a constant stream of one character with a second delay
bingo after some calculations it was easy to see what the problem was

if you use SPBRG = 24 ' Set baud rate to 2400

you get garbage or can only send single characters

but if you use

SPBRG = 23 ' Set baud rate to 2400

as per the spec sheet bingo it works, this means that in picbasic 244 the default defines are not correct for the 877.


the use of debug could be fixed I guess by attacking the mac files (but I will not) because this could be for a reason.

So I will use hSerOut with the above to solve the problem I had.

Don't you just love RS232 lol,

Thanks for all you help guys and if anyone has seen this before and
has a fix then please drop me a line..

Mark
G4LCH

[G4LCH]

Guy's
I have located the real source of the problem. The crystal supplied
by maplins that is marked as 4.00MHz is actually a 3.5MHz crystal.
Hence why the baud rate calcs were off. I swapped this for a real 4.00MHz
crystal and bingo everything works fine. Including the ICD which is cool.

Just thought you should know to always check the actual frequency the pic
is operating at. If a crystal is quoted as 4Mhz and debug or serial routines
give junk and you do have

Define OSC 4

Then the chances are that the crystal is either off frequency or the padding caps are wrong or in my case is 500 odd KHz low.

I located this by first checking the PicBasic includes and their calculations
were correct 100% this pointed to only one thing the crystal was off frequency.

Hope this help someone else.

Mark G4LCH

[sean-h]

Well done Mark, glad you got it sorted!!

It is a head banger when you have triple checked everything and yet it is still not playing ball.
It happens to all of us at one time or another.
I remember a few years ago spending ages on a On Screen Display Chip combined with a Pic Chip and had the weirdest errors I have ever seen.
After spending 2 months checking everything and just living with the problem I then suddenly came across a little sentence in the spec sheet stating that if you are running the bus at so in so speed then increase the Crystal caps by 10pf.
So I did this and the thing flew and worked great.

The good thing about having problems like this, is that it forces you to clean up all your code and re-read every part of the manual to get a cure, even though the problem was not in that area in the first place, but all of a sudden you have learn't alot more than if the code just worked the first time around!!

Regards

Sean.

[G4LCH]

Very true Sean, It was worth it as now I know that my code is 100% ok
and I also learnt a lot about the compiler as well which I would not have done.
I hope that people did / do not mind me making large postings with lots of information and also the solution I do feel its very important to share experiance with the larger audiance.

Thanks to all who commented it did help me.
Mark