Maker Pro
Maker Pro

PIC Question

S

scada

Jan 1, 1970
0
It's been a couple of years since my last pic project. My source code
receives three bytes, and echoes them back to the terminal, no problem. In
the code I assign each of the three bytes to a variable. Those files are
used in a delay loop which ultimately creates a square wave output on
portb,0. I can't seem to write to the variables! OK I figure that makes
sense, because it is ROM. But how does my receive variables know the bytes?
It is echoing the proper data! By the way, the delay loop works fine by
itself.

Oh yeah, I'm using PIC16C63A
 
A

Anthony Fremont

Jan 1, 1970
0
scada said:
It's been a couple of years since my last pic project. My source code
receives three bytes, and echoes them back to the terminal, no problem. In
the code I assign each of the three bytes to a variable. Those files are
used in a delay loop which ultimately creates a square wave output on
portb,0. I can't seem to write to the variables! OK I figure that makes
sense, because it is ROM. But how does my receive variables know the bytes?
It is echoing the proper data! By the way, the delay loop works fine by
itself.

Oh yeah, I'm using PIC16C63A

You're going to have to give more descriptive information than that.
Source code (the real thing cut and pasted, not re-typed) would help.
 
S

scada

Jan 1, 1970
0
Below is a snip of my code, the pulse generator routine.
I am using a PIC16C63A witch has an internal UART. I am
presently talking @ 2400 baud, 8n1. I am using a terminal
program to comunicate to the pic through an MAX233 chip.
My UART receive routine is through an interupt, it also echoes
back the received data. Three bytes are sent, byte one will be
used elsewhere in my program. Bytes 2 & 3 (recuse2, recuse3)
are copied to "Multbuf & Addbuf" in the routine below. My
variables are all equated to RAM (20h - 30h).
When I run it, I get the bytes echoed back as expected, the
oscilator outputs around 300HZ, which tells me that my two
buffers are not getting the data from recuse (2&3). They seem
to be stuck at "ffh". I'm probably missing something basic, but I just
don't see it. Any ideas?



Go bsf porta,1 ;toggel porta,1 - pulse output
call Loadbuf
bcf porta,1
call Loadbuf
goto Go
Loadbuf movf recuse2,w
movwf Multbuf
movf recuse3,w
movwf Addbuf
Again Decfsz Multbuf ;waste some time
goto Delay
goto Addtime
Delay movlw 02
movwf Times
More Decfsz Times
goto More
goto Again
Addtime Decfsz Addbuf
goTo Addtime
return
 
J

John Jardine.

Jan 1, 1970
0
scada said:
Below is a snip of my code, the pulse generator routine.
I am using a PIC16C63A witch has an internal UART. I am
presently talking @ 2400 baud, 8n1. I am using a terminal
program to comunicate to the pic through an MAX233 chip.
My UART receive routine is through an interupt, it also echoes
back the received data. Three bytes are sent, byte one will be
used elsewhere in my program. Bytes 2 & 3 (recuse2, recuse3)
are copied to "Multbuf & Addbuf" in the routine below. My
variables are all equated to RAM (20h - 30h).
When I run it, I get the bytes echoed back as expected, the
oscilator outputs around 300HZ, which tells me that my two
buffers are not getting the data from recuse (2&3). They seem
to be stuck at "ffh". I'm probably missing something basic, but I just
don't see it. Any ideas?



Go bsf porta,1 ;toggel porta,1 - pulse output
call Loadbuf
bcf porta,1
call Loadbuf
goto Go
Loadbuf movf recuse2,w
movwf Multbuf
movf recuse3,w
movwf Addbuf
Again Decfsz Multbuf ;waste some time
goto Delay
goto Addtime
Delay movlw 02
movwf Times
More Decfsz Times
goto More
goto Again
Addtime Decfsz Addbuf
goTo Addtime
return

Dunno about the 16C63A but a couple of others I've built with serial links
have needed (ater much f****** about) ...

RCSTA.CREN = 0 'Clear any overrun errors. Reset UART. This is critical !
RCSTA.CREN = 1 '

Prevents a total UART lockup. Needs to be an intrinsic part of the
listening or interrupt loop.
*Very* poorly noted in the microchip ""datasheet"". (jj in a Pavlov
reaction, sticks fingers down own throat and retches).
John
 
S

scada

Jan 1, 1970
0
John Jardine. said:
Dunno about the 16C63A but a couple of others I've built with serial links
have needed (ater much f****** about) ...

RCSTA.CREN = 0 'Clear any overrun errors. Reset UART. This is critical !
RCSTA.CREN = 1 '

Prevents a total UART lockup. Needs to be an intrinsic part of the
listening or interrupt loop.
*Very* poorly noted in the microchip ""datasheet"". (jj in a Pavlov
reaction, sticks fingers down own throat and retches).
John

Thanks, John. I do have that in my code...
I may just add a look-up table and use relative addressing. I was hoping
someone could see why this won't work, it would have worked better for me.
 
J

John Jardine.

Jan 1, 1970
0
[...]
Thanks, John. I do have that in my code...
I may just add a look-up table and use relative addressing. I was hoping
someone could see why this won't work, it would have worked better for me.

I missed they'd been "echoed".
The code seems to fully decrement the 2 recuse regs ok. Maybe the recuse
regs are not being loaded in the first place.
john
 
S

scada

Jan 1, 1970
0
John Jardine. said:
[...]
Thanks, John. I do have that in my code...
I may just add a look-up table and use relative addressing. I was hoping
someone could see why this won't work, it would have worked better for
me.

I missed they'd been "echoed".
The code seems to fully decrement the 2 recuse regs ok. Maybe the recuse
regs are not being loaded in the first place.
john
No, they are loaded. I use the recuse regs in my "echo" routine, all three
bytes are returned correctly.
 
Top