1. Home
  2. Electronics Design
  3. PIC Question

PIC Question

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

Reply to
scada
Loading thread data ...

problem. In

are

makes

bytes?

by

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.

Reply to
Anthony Fremont

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

Reply to
scada

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
Reply to
John Jardine.

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.

Reply to
scada

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

Reply to
John Jardine.

me.

No, they are loaded. I use the recuse regs in my "echo" routine, all three bytes are returned correctly.

Reply to
scada

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.