Sync PIC16F684 output with FOSC/4 clock?

Thread Starter

Fordy

Joined Nov 29, 2011
15
I'm using a PIC16F684 with the internal clock, and FOSC/4 on RA4.

In order to control another system, I need to send commands when RA4 clock is high.

Is this as simple as just sending the data for 4 (internal) clocks per bit?

This seems to make sense to me, but I've no experience communicating between chips like this, so would appreciate the confirmation.


Thanks in advance,
 

Markd77

Joined Sep 7, 2009
2,806
You may be able to send fixed data on one pin, but sending changing data might not be possible.
You only get one instruction cycle for each complete cycle of the CLKOUT pin.
The port is supposed to change at the start of Q1 so to send data on a single pin (Eg PORTA, 0) you could use:
Rich (BB code):
movlw b'00000001'
movwf PORTA      ;1 bit
CLRF PORTA         ;0 bit
CLRF PORTA         ;0 bit
CLRF PORTA         ;0 bit
movwf PORTA      ;1 bit
movwf PORTA      ;1 bit
movwf PORTA      ;1 bit
CLRF PORTA         ;0 bit
to send one byte.
Doing it this way means you can't really use the rest of the port for outputs during transmission (can be used for inputs).
If you tried using "bsf PORTA, 0 bcf PORTA, 0" instead you would most likely run into the read/modify/write problem and the data would end up garbled.

 

Attachments

Thread Starter

Fordy

Joined Nov 29, 2011
15
Oh, that should be okay then.

Presumably that also applies if using the internal oscillator?

I'm using the divided CLKOUT to clock another chip, and I'm also sending instructions to it, valid when the clock is high.

So if I understand you correctly, any and all instructions and outputs must happen on a high of that clock line anyway?

Thanks again,
 

ErnieM

Joined Apr 24, 2011
8,377
In order to control another system, I need to send commands when RA4 clock is high.

Is this as simple as just sending the data for 4 (internal) clocks per bit?
Nope. These "4 (internal) clocks per bit" is the instruction rate, the basic rate that instructions are performed. Nothing can happen faster then this clock, and it is also difficult to do anything useful at this same rate beyond a square wave where each period of the square takes 2 instructions (n cycles takes 2n instructions).

You would do better to use two I/O pins, one as your clock, one as your data. Much slower but it's workable. You could also drop the clock pin if you follow a serial data protocol.

The best method is to select a different device and use one of the communications modules (serial, SPI, I2C...) to handle the communications.
 

Thread Starter

Fordy

Joined Nov 29, 2011
15
Nope. These "4 (internal) clocks per bit" is the instruction rate, the basic rate that instructions are performed. Nothing can happen faster then this clock, and it is also difficult to do anything useful at this same rate beyond a square wave where each period of the square takes 2 instructions (n cycles takes 2n instructions).

You would do better to use two I/O pins, one as your clock, one as your data. Much slower but it's workable. You could also drop the clock pin if you follow a serial data protocol.

The best method is to select a different device and use one of the communications modules (serial, SPI, I2C...) to handle the communications.
I'm aware nothing can happen faster, I don't need it to.

I need to clock the other chip, and send certain commands on the highs of this clock.

I did consider using another data pin fr the clock, but it needs to be constant as I also need to receive data back.

Perhaps I could do it with an interrupt on the data in pin?

This is not so easy as OP believes, as this must be synchronized.
I am aware, see the thread title. That's why I'm asking for help- I know I need it!
 

takao21203

Joined Apr 28, 2012
3,702
Well FOSC/4 is not relevant for this.

This is the instruction cycle.

If you use software serial port, you need many instructions for each bit. But, you can use any number of bits.

If you use hardware serial port, you can transfer faster and/or in the background. But you can only transfer 8bit multiples.

Usually such transfer between 2 controllers in software is done with synchronous serial port. Clock, data, and a ready signal.

If you want half or full duxplex, it is even more complex.

I use such a link between controllers for my serial LED display. It is done in software. I solved it by simply resetting the slave controller.
 

Markd77

Joined Sep 7, 2009
2,806
I did consider using another data pin fr the clock, but it needs to be constant as I also need to receive data back.

Perhaps I could do it with an interrupt on the data in pin?
Nope, an interrupt is going to take several instruction cycles and you only get one per bit.
I don't think this is likely to be possible using CLKOUT pin.
Presumably this needs to be fast, you might be able to use an external crystal which could be faster than the internal oscillator, then use normal I/O pins for clock and data. Alternately use the USART if it's a standard communications protocol.
 

takao21203

Joined Apr 28, 2012
3,702
The problem is most likely your controller will do other things than only to send or receive data.

How can you ensure minimum response time?

This can be done with interrupt.

If you want more than master -> slave, you should use hardware serial port.
 

tshuck

Joined Oct 18, 2012
3,534
The problem is most likely your controller will do other things than only to send or receive data.

How can you ensure minimum response time?

This can be done with interrupt.

If you want more than master -> slave, you should use hardware serial port.
No, this cannot be done with interrupts. The processor would be operating at the absolute limit, it cannot spare the 1 or 2 instructions for an interrupt. It would be doing all it can to change its pins at the correct time, never mind adding in interrupts and returns and whatnot.

OP: How does the receiving chip understand it is getting valid data and not just the transmitter is doing something else? Remember, anything else the transmitter is doing messes up the timing. I will go with others and recommend SPI....or is there a reason against you using SPI?
 

takao21203

Joined Apr 28, 2012
3,702
No, this cannot be done with interrupts. The processor would be operating at the absolute limit, it cannot spare the 1 or 2 instructions for an interrupt. It would be doing all it can to change its pins at the correct time, never mind adding in interrupts and returns and whatnot.

OP: How does the receiving chip understand it is getting valid data and not just the transmitter is doing something else? Remember, anything else the transmitter is doing messes up the timing. I will go with others and recommend SPI....or is there a reason against you using SPI?
What have I wrote about whatnot?

It is used to start the serial transfer or how do you know? How can the host know when to start? Or the master when to receive?

Sorry for the misunderstanding.

Also OP writes nothing about the data rate and/or clock frequency, and/or the serial controller devices.
 

tshuck

Joined Oct 18, 2012
3,534
What have I wrote about whatnot?
... an interrupt requires a return which is another instruction cycle... determining which interrupt takes even more time...you need the whatnot, regardless of whether or not you've stated it...

It is used to start the serial transfer or how do you know? How can the host know when to start? Or the master when to receive?

Sorry for the misunderstanding.
This is why I'm asking:rolleyes:

Also OP writes nothing about the data rate and/or clock frequency, and/or the serial controller devices.
...if transferring at Fosc/4, the datarate is given. Clock frequency is irrelevant as our times are relative to it. The recipient is assumed to be able to operate at the speed necessary to read the information.
 

takao21203

Joined Apr 28, 2012
3,702
Ah. AFAIK a host can only transfer at FOSC/4 through the hardware serial port.

We need to use a protocol here, and to know about the connected device.

I think the original question was about something else- if there is a sync required.

Not required, since the device is only driven at FOSC/4.

So it can receive FOSC/16 at max.

Why not parallel both OSC IN signals? It actually works.

Then it can also receive at FOSC/4. There is no sync required for this when using the hardware serial ports.

I have done this with 3x PIC 16f59, all OSC IN are connected, but only one OSC OUT is used with a coil, Why use 3 when you only need one? Don't know how many could be connected.
 
Last edited:

Thread Starter

Fordy

Joined Nov 29, 2011
15
Thank you all for your input.

I think I should explain more to clarify, and perhaps to you all a more clear solution will become apparent.


The other chip is not an MCU of my programming, it's an HTRC11001T - an RFID reader/filter.

The communication protocol given in the datasheet sounds simple enough - "a three wire interface consisting of SCLK, data in, data out".

SCLK and DIN are Schmitt-Trigger inputs, DOUT is open drain with an internal pull-up.

Comms intialised by a low-high transition on DIN while SCLK is high.

READ_TAG command (which for now let's assume is the only command I am interested in) is given by three highs on DIN (again, while SCLK is high of course).

Read mode is then terminated by a high-low transition on DIN while SCLK is high.


So I need my program to:
- Fire off 1-1-1 on the highs of SCLK.
- Listen to the returned data, again when SCLK high.
- Output D_0 - D_7 in parallel
- Repeat

The complication as far as I am concerned is making it happen timely with SCLK. I don't know whether I can simply set SCLK high, set data, set SCLK low, set data, set SCLK high, etc. I think perhaps it would be possible, since this clock is used only for the communication, the HTRC has an internal oscillator for its own firmware.

I haven't mentioned SPI because I've never used it, so it wouldn't have occurred to me, and the datasheet doesn't mention it.


Thanks again!


PS:
As a general point, (but to avoid a separate post), is it valid to assign some name to a specific pin for easier reference?
ie:
Rich (BB code):
MyName    equ  PORTA,0
Given of course that PORTA is already assigned to the hex in the include file.
 
Last edited:

Markd77

Joined Sep 7, 2009
2,806
If you read AN98080 it looks like the I2C protocol and doesn't mention a minimum speed that I could see.
In fact with the glitch filter on it recommends a maximum rate of 25k bits per second for the two wire protocol (DIN and DOUT connected together).
Most PICs don't have a hardware master I2C port so a bit of bitbanging is probably in order.
It's easily possible to do over 100k bits per second with a PIC clocked at 4MHz so 25k is a walk in the park.
 

Markd77

Joined Sep 7, 2009
2,806
So I need my program to:
- Fire off 1-1-1 on the highs of SCLK.
Looks to me like it should be 111----- where - is "don't care", ie send 8 bits.

As a general point, (but to avoid a separate post), is it valid to assign some name to a specific pin for easier reference?
ie:
Rich (BB code):
MyName    equ  PORTA,0
Given of course that PORTA is already assigned to the hex in the include file.
Yes that's fine.
 

Thread Starter

Fordy

Joined Nov 29, 2011
15
Looks to me like it should be 111----- where - is "don't care", ie send 8 bits.


Yes that's fine.
1) Datasheet says it enters read-mode immediately after the third 1.

2) Awesome, thanks.


So how does this look as a quick draft?

Rich (BB code):
read
bsf     SCLK
nop
bsf     DOUT
call    delay
bcf     SCLK
nop
bcf     DOUT
call    delay
;x3

listen
bcf     SCLK
call    delay
nop
nop
bsf     SCLK
call    delay
movf    DIN,0
movwf   CN0

;<snipped>

bcf     SCLK
call    delay
nop
nop
bsf     SCLK
call    delay
movf    DIN,0
movwf   CN7

goto    read
Where SCLK is SCLK, and DIN/OUT is DOUT/IN from HTRC.
 

takao21203

Joined Apr 28, 2012
3,702
If you read AN98080 it looks like the I2C protocol and doesn't mention a minimum speed that I could see.
In fact with the glitch filter on it recommends a maximum rate of 25k bits per second for the two wire protocol (DIN and DOUT connected together).
Most PICs don't have a hardware master I2C port so a bit of bitbanging is probably in order.
It's easily possible to do over 100k bits per second with a PIC clocked at 4MHz so 25k is a walk in the park.
I2C is always SCL and SDA.
3-wire is SPI,

Don't get why you write "Most PICs don't have I2C".
Most PICs actually do have a serial port.

SPI and I2C don't have a minimum speed actually.

OP using assembler or C?

Yes it is better to write:

Rich (BB code):
#define sclk PORTAbits.RA0
So what's up with this RFID chip? I2C or SPI? I2C devices always have the serial protocol in the datasheets and SPI chips also have it- it is different, not compatible.
 

Thread Starter

Fordy

Joined Nov 29, 2011
15
I2C is always SCL and SDA.
3-wire is SPI,

Don't get why you write "Most PICs don't have I2C".
Most PICs actually do have a serial port.

SPI and I2C don't have a minimum speed actually.

OP using assembler or C?

Yes it is better to write:

Rich (BB code):
#define sclk PORTAbits.RA0
So what's up with this RFID chip? I2C or SPI? I2C devices always have the serial protocol in the datasheets and SPI chips also have it- it is different, not compatible.
Assembly.

Ah, thanks for that, fixed a whole host of errors.

Neither, as far as I can tell. No mention of either in the datasheet - it only describes the protocol exactly as I did in my last post.
 

Markd77

Joined Sep 7, 2009
2,806
I2C is always SCL and SDA.
3-wire is SPI,

Don't get why you write "Most PICs don't have I2C".
Most PICs actually do have a serial port.
Maybe it's not true I2C, but it is more similar to I2C than SPI. The two data lines can be connected together to make it a two wire interface. It also has the start bit as the data line rising while the clock is high, which SPI doesn't have.
I didn't write "Most PICs don't have I2C"
For proper I2C master mode you need a PIC with a MSSP module, which the F684 (and also most other PICs) doesn't have.
Without it you have to manually set and clear the clock line for master mode, and in my mind if you have to do that you may as well do the whole lot in software.
 
Top