12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

Hi. I am after a clear answer cause i'm trying the PIC Datasheets and 
its giving me a headache! What i would like to know is, say my 
PIC16F877 is running on a 4MHz clock, how long does it take for 
example to turn a bit on? If i did this:

bsf LED
bcf LED

How long would the LED be on for? 1us? I have read that most 
instructions take 1 cycle, which do not? I'm guessing Goto and Call?

Hope someone can help, cause i need my timings to be correct as i'm 
trying to make a DMX Controller with my PIC.

Thanks

Paul
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> Hi. I am after a clear answer cause i'm trying the PIC Datasheets and 
> its giving me a headache! What i would like to know is, say my 
> PIC16F877 is running on a 4MHz clock, how long does it take for 
> example to turn a bit on? If i did this:
> 
> bsf LED
> bcf LED

don't do this, google RMW problem

> How long would the LED be on for? 1us? 

1us

> I have read that most 
> instructions take 1 cycle, which do not? 

> I'm guessing Goto and Call?

every instruction that can change the PC (except for the normal 'next
instruction) takes 2, and skipped instructions still take 1.

> Hope someone can help, cause i need my timings to be correct as i'm 
> trying to make a DMX Controller with my PIC.

use one with a UART

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

At 08:16 AM 13/03/2006, Paul wrote:
 >Hi. I am after a clear answer cause i'm trying the PIC Datasheets and
 >its giving me a headache! What i would like to know is, say my

Perhaps you need to consult an eye care specialist.

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

The Instruction Set table is pretty specific.  For the 16F87XA 
devices, for example, there are 35 instructions.  Twenty six of 
these take 1 cycle, unconditionally.  Five take 2 cycles 
unconditionally and the remaining 4 can take 1 or 2 cycles depending 
on whether the the skip is taken, in which case 2 cycles are 
required.

You should understand the Read-Modify-Write issue but there isn't 
anything you can do about it.  It's discussed in 15.1 of the 16F87XA 
datasheet.  ANY instruction that operates on a file register 
performs a Read-Modify-Write operation.

Richard

--- In piclist@picl..., Phil Seakins <pseakins@...> wrote:
>
> At 08:16 AM 13/03/2006, Paul wrote:
>  >Hi. I am after a clear answer cause i'm trying the PIC 
Datasheets and
>  >its giving me a headache! What i would like to know is, say my
> 
> Perhaps you need to consult an eye care specialist.
>
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I have looked into USART. Looks good, my only concern is that i need 
a certain type of Init signal for the DMX Protocol. Can the USART do 
this - Stay high when not in use. At the start of the pulse train go 
low for 22 pulses the go high for 2 pulses, then the 9 bit signal 
can be sent. Another problem i have noticed, but hopefully solved is 
that i need 2 stop signals, that is why i am using 9 bit, send the 
usual 8 bit data first, then the last bit is high, giving me 2 stop 
signals. After the last stop signal i need to send up to 512 more 
bytes. Can the PIC USART do this?

Thanks,
Paul
--- In piclist@picl..., "Wouter van Ooijen" <wouter@...> 
wrote:
>
> > Hi. I am after a clear answer cause i'm trying the PIC 
Datasheets and 
> > its giving me a headache! What i would like to know is, say my 
> > PIC16F877 is running on a 4MHz clock, how long does it take for 
> > example to turn a bit on? If i did this:
> > 
> > bsf LED
> > bcf LED
> 
> don't do this, google RMW problem
> 
> > How long would the LED be on for? 1us? 
> 
> 1us
> 
> > I have read that most 
> > instructions take 1 cycle, which do not? 
> 
> > I'm guessing Goto and Call?
> 
> every instruction that can change the PC (except for the 
normal 'next
> instruction) takes 2, and skipped instructions still take 1.
> 
> > Hope someone can help, cause i need my timings to be correct as 
i'm 
> > trying to make a DMX Controller with my PIC.
> 
> use one with a UART
> 
> Wouter van Ooijen
> 
> -- -------------------------------------------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu
>
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

>You should understand the Read-Modify-Write issue but there isn't 
>anything you can do about it.
>
If you take a good HL language (e.g. JAL) the Read-Modify-Write issue is 
completly solved !
Stef Mientki

>  
>

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In piclist@picl..., Stef Mientki <s.mientki@...> wrote:
>
> 
> >You should understand the Read-Modify-Write issue but there isn't 
> >anything you can do about it.
> >
> If you take a good HL language (e.g. JAL) the Read-Modify-Write 
issue is 
> completly solved !
> Stef Mientki

As I read the datasheet, there is no solution to the problem; at 
least for the 16F87XA.  EVERY instruction that references a file 
register uses Read-Modify-Write even if only to do something like 
CLRF PORTB.  Section 15.1 of the 16F87XA datasheet is VERY specific 
about this.

This is, however, very different from Section 9.1 and 9.10 of the 
Mid-Range MCU Family manual where it describes only BSF, BCF, XORWF, 
ADDWF as R-M-W instructions.  See Question 4 of section 9.12

See also Question 4 of section 29.6 where it states that CLRF is not 
a Read-Modify-Write.

How odd that the Mid-Range Family manual says CLRF is NOT a R-M-W 
instruction while the 16F87XA datasheet says it is.  Which do you 
believe, the datasheet or the family manual.

It is also worth noting that the R-M-W problem is simply a case 
where the value written to the latch is not (yet) reflected on the 
pin.

Now, it is certainly possible to read the port and save the input 
conditions, change any output pins and send it back to the port.  
But, when the value is stored back in the port, it is still a Read-
Modify-Write.  The saved value can be tested for input conditions 
and this 'shadowing' is a common technique - particularly for 
interrupt on change bits.

But, I still don't see how a high level language can do something 
that can't be done in hardware or assembly language.

The Mid-Range manual has a bunch of examples in Section 9.  Even if 
it doesn't agree with the datasheet.

Richard
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

>But, I still don't see how a high level language can do something 
>that can't be done in hardware or assembly language.
>  
>
It can be done in hardware easily, but for some obscure reason microchip 
didn't do that.
It can be done in software, to give you a hint:
try overloading the (bit) writing-part of the IO-port (other memory 
location aren't a problem).

Stef Mientki
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> (the RMW issue)
> As I read the datasheet, there is no solution to the problem; at 
> least for the 16F87XA. 

a solution (IMHO *the* solution) is to use a shadow register

> EVERY instruction that references a file 
> register uses Read-Modify-Write even if only to do something like 
> CLRF PORTB.  Section 15.1 of the 16F87XA datasheet is VERY specific 
> about this.

AFAIK movwf does not read the destination first, but even if it did it
would not matter because it upadtes all 8 bits (and so does CLRF).

> How odd that the Mid-Range Family manual says CLRF is NOT a R-M-W 
> instruction while the 16F87XA datasheet says it is.  Which do you 
> believe, the datasheet or the family manual.

I would believe the datasheet, or maybe the (MIT!) piclist

> But, I still don't see how a high level language can do something 
> that can't be done in hardware or assembly language.

Nobody says that a HLL can do something a LLL can't do, but quite a lot
of persons will say that a HLL can do it *easier*.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

At 02:37 PM 3/13/2006, Wouter van Ooijen wrote:

>AFAIK movwf does not read the destination first, but even if it did it
>would not matter because it upadtes all 8 bits (and so does CLRF).
>
> > How odd that the Mid-Range Family manual says CLRF is NOT a R-M-W
> > instruction while the 16F87XA datasheet says it is.  Which do you
> > believe, the datasheet or the family manual.

Andrew Warren has covered this quite explicitly in the past.  He 
emphatically states that ALL operations are R-M-W, at least on the 12 
bit and 14 bit core parts.

This explains the problems people have had in the past with RBIF 
interrupts being missed because a write to port B occurred in the 
same instant that a port change was occurring.  The act of writing 
port B causes an 'invisible' read to occur, which clears RBIF.

While I still use the Mid-Range Family manual as a reference, I 
ignore sections that have proven to be wrong between the time the 
manual was released and now.  My paper copy has a significant amount 
of red high-lighter in it.  Suppose I should take the time to do the 
same to the electronic version.  I'm pretty sure I have an early copy 
that allows editing.  Have to wait 'til I have time, though.

dwayne

-- 
Dwayne Reid   <dwayner@dway...>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 22 years of Engineering Innovation (1984 - 2006)
  .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
     `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.
	

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )