16F877 HSERIN problem with 3th party software

[RFsolution]

'I have the following problem, let me first briefly explain the hard and software
'setup: 16F877A 20mhz 19200 8N1, MAX232, only 2,3,5 are wired from the RS232
'but on the PC end 1,6,4 are wired togheter to avoid Hardware handshaking problems
'Problem: I try to read an AD with the command RAD0 (cr) with a third party software
' like modcom from weeder thenology, or a VB writen program
'If I use a terminal program setup to 19200 8N1 it works fine I tried with 2 terminal
'programs, built in in Microcode studio and with realterm, if I send RAD0 (cr)
' it returns RAD0xxx as many times i request it,after reset of the MCU etc...
' If i run Modcom with a simple datawindow object sending RAD0(cr) @ 19K2
' the PIC does not react
'If i close comports and go back to the terminal program, if have to send RAD0 (cr)
'twice before it reacts
'Modcoms datawindow is polling and sending RAD0 (cr) properly as I checked it with
'a virtual comport and the same terminal program
'I think it has something to do with the initial state of the RX and TX data pins (low/high)
'of the PC's comport
' very strange as i have the same problem with an other 3th party program written in
'VB where i would like to communicate with
' anyone who can point me to a possible solution ?
' Thanks


@__config_HS_OSC

define OSC 20
DEFINE ADC_BITS 8
DEFINE ADC_CLOCK 3
DEFINE ADC_SAMPLEUS 50
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 64 ' 19200 Baud @ 20MHz, 0,16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
' Define LCD registers and bits Easypic 4
Define LCD_DREG PORTD
Define LCD_DBIT 4
Define LCD_RSREG PORTD
Define LCD_RSBIT 2
Define LCD_EREG PORTD
Define LCD_EBIT 3
TRISB = %00000000
TRISC = %10000000
ADCON1= %00000101 ' Set PORTA analog

RCIF VAR PIR1.5 ' Receive interrupt flag (1=full , 0=empty)
dummy var word
AD var byte[7]
B0 var portb.0
B1 var portb.1
char0 var byte
char1 var byte
char2 var byte
char3 var byte
char4 var byte
char5 var byte
nr var byte
bvar1 var byte
menu var byte
tempmenu var byte
inp var byte

menu = 0


loop:

While RCIF = 1
Hserin [char1,char2,char3,char4,wait ($0D)]
RCIF=0
toggle portE.0
lookdown char4,[48,49,50,51,52,53,54,55],nr


if Char1 = "R" and char2 = "A" AND char3 = "D" then
adcin nr,ad[nr]
HSEROUT [char1,char2,char3,char4,dec3 AD[nr],13]
endif

wend
goto loop

[Archangel]

Hi RFsolution,
Are you using a pullup on the Hserin port ?

[RFsolution]

Hi Joe

I think I should say Yes because i'm using Easypic4 from mikroelektronika
but i think i have changed it to pull down or even removed the jumper

But still strange that it works with any terminal program ?

Did you tried Modcom with a simple command ?

I will check the development board to see if there are no hidden pullup's

[mister_e]

I may have some time to investigate about Modcom... if I had the link for it :rolleyes:

It's certainly not down to hardware but how PC software behave.

[RFsolution]

Thanks steve

Here is the link:

http://www.weedtech.com/modcom.zip

[RFsolution]

I may have some time to investigate about Modcom... if I had the link for it :rolleyes:

It's certainly not down to hardware but how PC software behave.


Hi all

I tried the following to exclude some hardware issue

Took another PC with another comport, just to be shure

On my Easypic4 board I checked that no additional Pull-up or down's are available

When I disconnect the MAX232 serial driver the initial state of RC6 = High,
RC7 = Low
When I reconnect the MAX232 RC6 and 7 becomes High
So all looking normal

Then when I measure with my scoop on RC7 with the terminal program running
(so the command RAD0 (cr) is working fine) I see no difference when I run
for example MODCOM

Can anyone try to use MODCOM with a simple program using a serial command
To see if it works at your end
Use HSERIN/HSEROUT 19200 8N1 and a hardware driver like the MAX232

Looking forward !!!

[RFsolution]

Still not solved my problem

anyone who can give modcom a try with his develpment board ?

Thanks

[RFsolution]

I may have some time to investigate about Modcom... if I had the link for it :rolleyes:

It's certainly not down to hardware but how PC software behave.

Steve

Would you still be so nice to have a look for me, i'm at the end of my limited
brainspower

Walter