Post by thread:[PIC]: Need SPI code for 16F877

Brandon: Here's some SPI code I wrote for the PIC16F877. Hope it works for you. If you have any questions, let me know. Sam.... "May the roof over your head never leak until it rains gold." ("`-''-/").___..--''"`-._ `6_ 6 ) `-. ( ).`-.__.`) (_Y_.)' ._ ) `._ `. ``-..-' _..`--'_..-_/ /--'_.' ,' (il),-'' (li),' ((!.-' // ***************************************************************** // spi.c // // Author: Sam R. Linder // // // ***************************************************************** // external functions // external global variables // internal functions unsigned char ReadByteSPI(void); void WriteByteSPI(unsigned char writebyte); // global variables unsigned char rdataval; unsigned char wdataval; unsigned char loopcount; //***************** // Bit Declarations //***************** // SPIPORT = Port-C // SPICLK_OUT = pin-3 // SPIDATA_IN = pin-4 // SPIDATA_OUT = pin-5 #define SCLK SPIPORT,SPICLK_OUT #define DATAIN SPIPORT,SPIDATA_IN #define DATAOUT SPIPORT,SPIDATA_OUT unsigned char ReadByteSPI(void) { #asm CLRF STATUS // select bank-0 clrf _rdataval movlw 08 // set loop count movwf _loopcount // save it bcf STATUS,C // clear Carry R0: bsf SCLK // set SCLK high bcf SCLK // set SCLK low bcf STATUS,C // clear Carry btfsc SPIPORT,SPIDATA_IN bsf STATUS,C // set Carry rlf _rdataval,f // rotate Carry bit into memory location decfsz _loopcount,f // decrement loop count, skip next line if zero (we're done) goto R0 // else loop back to read next data bit #endasm return (rdataval); } // end of ReadByteSPI() void WriteByteSPI(unsigned char dataval) { #asm clrf STATUS // select bank-0 movwf _wdataval // save data byte to write movlw 08 // set loop count movwf _loopcount // save it bcf STATUS,C // clear Carry W0: rlf _wdataval,f // rotate msb of _zdataval into Carry bcf DATAOUT // assume bit = 0 (set DATAOUT low) btfsc STATUS,C // test Carry bit (skip next line if Carry = 0) bsf DATAOUT // set DATAOUT high bsf SCLK // set SCLK high bcf SCLK // then low decfsz _loopcount,f // decrement loop count, skip next line if zero (we're done) goto W0 // else loop back to output next data bit #endasm } // end of WriteByteSPI() // end of module spi.c {Original Message removed}

On Mon, 6 Aug 2001, Sam Linder wrote: > Instead of just criticizing, if you have a better suggestion would it not be > courteous to explain it? This method has worked fine for me to date. Sorry to sound critical... I assumed you had seen the other recent e-mails regarding the Read-modify-Write gotchas associated with bcf/bsf's on I/O ports. There are several ways to work around this. A common way is to simply shadow I/O's with a variable. Perform all of the operations on the shadow and then copy the shadow to the I/O Port. A little more efficient is this though: ; Toggle an I/O: ; (assuming the last access to PORTB was a "long time" ago... movf PORTB,W iorlw 1<<clock_bit movwf PORTB andlw ~(1<<clock_bit) movwf PORTB The key thing to note is that the I/O port is not read between the successive writes. If this is part of the loop, then read the I/O port outside of the loop. Here's a way to transmit a byte: movlw 8 movwf count movf PORTB,W loop: andlw ~(1<<data_bit) ;assume a zero btfsc byte_to_send,0 ;check next bit iorlw 1<<data_bit ;nope, it's a one movwf PORTB ;Write the data bit iorlw 1<<clock_bit ;clock it movwf PORTB andlw ~(1<<clock_bit) movwf PORTB rrf byte_to_send,F ;prepare for next bit decfsz count,F goto loop ; Trick: rrf byte_to_send,F ;ninth rotation will restore ;the transmit byte. Scott -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> movf PORTB,W > iorlw 1<<clock_bit > movwf PORTB > andlw ~(1<<clock_bit) > movwf PORTB Note that this still does a read/modify/write. However, I think the RMW problem has been blown out of proportion. It only matters if 1: you have other bits in the port that you will be toggling between input and output and you don't explicitly set their state when switching to output, and 2: if the external circuit holds a PIC output in its opposite state. You have full control and knowledge of #1. #2 is rare because it usually means poorly designed hardware, although it could legitimately happen for short periods of time (a few uS) after the output is switched if the external circuit has considerable capacitance. Therefore, for most cases, the original code was just fine: bsf portb, clock_bit bcf portb, clock_bit This will put out a pulse that is one instruction time long. This is a reasonable thing to do, for example, when clocking an external flip flop. I've done this sort of thing a number of times when multiplexing one of the ports as a data bus. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, spam_OUTolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Olin.L wrote: ..... 2: if the external circuit holds a PIC output in >its opposite state. You have full control and knowledge of #1. #2 is rare >because it usually means poorly designed hardware, although it could >legitimately happen for short periods of time (a few uS) after the output is >switched if the external circuit has considerable capacitance. > Yeah .... I don't think it is all that rare, or a case of poor design of hardware. More like another Microchip gotcha. How often do you hang a cap straight on a port pin for noise filtering, or drive an RC on output? Standard small values 1K and 1 nF gives a 1 usec time constant, as do 10K and 100 pF. And if you actually do want noise-filtering, then 1 usec ~ 160khz is not gonna do such a great filter job --> caught by the M.gotcha. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Hi Tony, ----- Original Message ----- From: Tony Nixon <Tony.NixonKILLspamENG.MONASH.EDU.AU> To: <.....PICLISTKILLspam.....MITVMA.MIT.EDU> Sent: Monday, August 06, 2001 10:24 PM Subject: Re: [PIC]: Need SPI code for 16F877 | Olin Lathrop wrote: | | > Therefore, for most cases, the original code was just fine: | > | > bsf portb, clock_bit | > bcf portb, clock_bit | | | Probably so, but even Microchip suggest something like.... | | bsf portb, clock_bit | nop | bcf portb, clock_bit And this is proposed also for the general case of a read followed by a write to the port (i.e with two mov's), letting the logic state to stabilize, although the quantity of nop's is load(and frequency)-dependent. To avoid these nop's they suggest a series resistor at the pin. | -- | Best regards | | Tony | Best Regards, S.- -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

| > movf PORTB,W | > iorlw 1<<clock_bit | > movwf PORTB | > andlw ~(1<<clock_bit) | > movwf PORTB | | Note that this still does a read/modify/write. Just to be sure: The movwf 's (?). (the movf not because destiny is W) | However, I think the RMW problem has been blown out of proportion. It | only | matters if 1: you have other bits in the port that you will be toggling | between input and output and you don't explicitly set their state when | switching to output, and 2: if the external circuit holds a PIC output in | its opposite state. You have full control and knowledge of #1. #2 is | rare | because it usually means poorly designed hardware, although it could | legitimately happen for short periods of time (a few uS) after the output | is | switched if the external circuit has considerable capacitance. You forgot the open-source pin possibility, when it's configured as output but being driven externally. | Therefore, for most cases, the original code was just fine: | | bsf portb, clock_bit | bcf portb, clock_bit | This will put out a pulse that is one instruction time long. This is a | reasonable thing to do, for example, when clocking an external flip flop. | I've done this sort of thing a number of times when multiplexing one of | the | ports as a data bus. | | | ******************************************************************** | Olin Lathrop, embedded systems consultant in Littleton Massachusetts S.- -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Dan Michaels wrote: {Quote hidden}> > At 11:24 AM 8/7/01 +1000, you wrote: > >Olin Lathrop wrote: > > > >> Therefore, for most cases, the original code was just fine: > >> > >> bsf portb, clock_bit > >> bcf portb, clock_bit > > > > > >Probably so, but even Microchip suggest something like.... > > > > bsf portb, clock_bit > > nop > > bcf portb, clock_bit > > > > This only adds in another 0.2 usec with a 20 mhz xtal. Isn't > gonna help a great deal if a good-sized cap is hanging on the > pin. I guess it comes down to a bit of common sense. Xtal speed VS pin capactiance, and because writes followed by reads take less than a clock cycle for the data recognition, probably closer to a Q cycle, I guess the NOP helps a bit - but as you mention not in every case :-) [Snip] 5.3.2 SUCCESSIVE OPERATIONS ON I/O PORTS The actual write to an I/O port happens at the end of an instruction cycle, whereas for reading, the data must be valid at the beginning of the instruction cycle (Figure 5-6). Therefore, care must be exercised if a write followed by a read operation is carried out on the same I/O port. The sequence of instructions should be such to allow the pin voltage to stabilize (load depen-dent) before the next instruction which causes that file to be read into the CPU is executed. Otherwise, the previous state of that pin may be read into the CPU rather than the new state. When in doubt, it is better to separate these instructions with a NOP or another instruction not accessing this I/O port. Therefore, at higher clock frequencies, a write followed by a read may be problematic. [Snip] -- Best regards Tony mICros http://www.bubblesoftonline.com EraseMEsalesspam_OUTTakeThisOuTbubblesoftonline.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Tony.N wrote: .......... >I guess it comes down to a bit of common sense. Xtal speed VS pin >capactiance, and because writes followed by reads take less than a clock >cycle for the data recognition, probably closer to a Q cycle, I guess >the NOP helps a bit - but as you mention not in every case :-) ........ Yeah, you have to trade the NOP time [eie, xtal value] off against "exactly" what is hanging off the port. I really don't think the implications of what is going on here are all that "obvious". Just for the heck of it, I checked the piclist archives, and found 171 msgs related to read-modify-write in the past year or so. I think it really is fairly easy to get burned by this - and I'll bet most people here have fallen into the trap at least once. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On Mon, 6 Aug 2001, Sebastian Garcia wrote: > | > movf PORTB,W > | > iorlw 1<<clock_bit > | > movwf PORTB > | > andlw ~(1<<clock_bit) > | > movwf PORTB > | > | Note that this still does a read/modify/write. > > > Just to be sure: The movwf 's (?). (the movf not because destiny is W) No it's not the movwf's. For some reason Olin decided to clip out the comment leading up to this snippet and thus presenting it out of context. The comment said something like, "If PORTB hasn't been written to for a 'long time' then you can do something like this". The issue is that the midrange (and 12-bit, but not the 18cxxx) devices don't have an I/O output latch that is independent of the output driver. So reading an I/O port cause the those values to be written out again. I realize that sentence is confusing, but imagine an I/O line having a capacitor tied to it. It takes time to cause the capacitor to charge to a new state. So suppose the capacitor is uncharged and you try charging by setting an I/O high. If you READ the I/O port, immediately following the write, there's a good chance it's still low. If it turns out that it is low, then this will refrech the output latch with a zero and then drive the capacitor low again! Most of the times you don't have a capacitor tied to an I/O line. But it's not uncommon to have 10 to 100 pF of parasitic capacitance sitting on an I/O line. Is this a problem? A PIC I/O has around ~ 30 to 50 ohms output impedance (I'm just guessing this ...). Taking the worst case of 50 ohms and 100 pF leads to a 5nS time constant. Even when the clock is 20Mhz, this is hardly a factor. So the typical case is probably okay with the BCF/BSF's. I'd only begin to really worry when driving external cables and similar cases. Something like bit-banging an I2C prom would most probably work just fine. Hey, who was the bonehead complianing about the original SPI code? {Quote hidden}> > | However, I think the RMW problem has been blown out of proportion. It > | only > | matters if 1: you have other bits in the port that you will be toggling > | between input and output and you don't explicitly set their state when > | switching to output, and 2: if the external circuit holds a PIC output in > | its opposite state. You have full control and knowledge of #1. #2 is > | rare > | because it usually means poorly designed hardware, although it could > | legitimately happen for short periods of time (a few uS) after the output > | is > | switched if the external circuit has considerable capacitance. > > > You forgot the open-source pin possibility, when it's configured as output > but being driven externally. I thought open-source only worked for software :). Scott -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> However, I think the RMW problem has been blown out of proportion. It > only matters if 1: you have other bits in the port that you will be > toggling between input and output and you don't explicitly set their > state when switching to output, and 2: if the external circuit holds a > PIC output in its opposite state. You have full control and knowledge > of #1. #2 is rare because it usually means poorly designed hardware, #2 is common if you are pin bashing I2C and doing other things as well. Steve. ====================================================== Steve Baldwin Electronic Product Design TLA Microsystems Ltd Microcontroller Specialists PO Box 15-680, New Lynn http://www.tla.co.nz Auckland, New Zealand ph +64 9 820-2221 email: stevebspam_OUTtla.co.nz fax +64 9 820-1929 ====================================================== -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> Most of the times you don't have a capacitor tied to an I/O line. But > it's not uncommon to have 10 to 100 pF of parasitic capacitance > sitting on an I/O line. Is this a problem? A PIC I/O has around ~ 30 > to 50 ohms output impedance (I'm just guessing this ...). Taking the > worst case of 50 ohms and 100 pF leads to a 5nS time constant. Even > when the clock is 20Mhz, this is hardly a factor. So the typical case > is probably okay with the BCF/BSF's. I'd only begin to really worry > when driving external cables and similar cases. Something like > bit-banging an I2C prom would most probably work just fine. Hey, who > was the bonehead complianing about the original SPI code? I think you could be a bit more generous with the capacitance. A single HC series input is typically 50-100pF. The more important number is the 100ns from clk to output valid and the input setup time which is TBD in the few datasheets I looked at. If you assume it is of the same order as the output delay, that's most of a 20Mhz OSC cycle and the pin load becomes more important. I also disagree with the BCF/BSF being OK. They're the ones that get you because even though the instruction infers it's just a bit, the whole byte is read, modified and written back. If your I2C device is ACKing on another pin at the time, you've been got. Steve. ====================================================== Steve Baldwin Electronic Product Design TLA Microsystems Ltd Microcontroller Specialists PO Box 15-680, New Lynn http://www.tla.co.nz Auckland, New Zealand ph +64 9 820-2221 email: @spam@stevebKILLspamtla.co.nz fax +64 9 820-1929 ====================================================== -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hi Scott, ----- Original Message ----- From: Scott Dattalo <KILLspamscottKILLspamDATTALO.COM> | On Mon, 6 Aug 2001, Sebastian Garcia wrote: | | > | > movf PORTB,W | > | > iorlw 1<<clock_bit | > | > movwf PORTB | > | > andlw ~(1<<clock_bit) | > | > movwf PORTB | > | | > | Note that this still does a read/modify/write. | > | > | > Just to be sure: The movwf 's (?). (the movf not because destiny is W) | | No it's not the movwf's. For some reason Olin decided to clip out the | comment leading up to this snippet and thus presenting it out of | context. The comment said something like, "If PORTB hasn't been | written to for a 'long time' then you can do something like this". | | The issue is that the midrange (and 12-bit, but not the 18cxxx) | devices don't have an I/O output latch that is independent of the | output driver. So reading an I/O port cause the those values to be | written out again. I realize that sentence is confusing, but imagine | an I/O line having a capacitor tied to it. It takes time to cause the | capacitor to charge to a new state. So suppose the capacitor is | uncharged and you try charging by setting an I/O high. If you READ the | I/O port, immediately following the write, there's a good chance it's | still low. If it turns out that it is low, then this will refrech the | output latch with a zero and then drive the capacitor low again! I understand the R-M-W issue, and I think of it as divided in two classes: 1) R-M-W *instructions* over the port (In fact these kind of instructions acts the same way over any register, but AFAIK there have no critical effects on other than the ports). That's while executing, in the same Q cycle. 2) R-M-W *operations*, done by a pair of instructions accessing the port, in adjacent Q cycles (or between some instructions). I guess You are talking here about case (2), while I was talking about case (1). My doubt is *who* are the R-M-W instructions, other than the well known 'bcf' and 'bsf'. I think the only R-M-W instruction in that posted code is the movwf because it reads register f (in fact, being f equal to PORTB, it reads the port *pins*), then process it (I assume it modify only the different bits in comparison to W), and then writes the register f (writes the port latch). Please let me know if I'm wrong. I never saw documented who are the R-M-W instructions and I'm supposing this based on the Q-cycle activity of each instruction...(from the instruction set description). | Most of the times you don't have a capacitor tied to an I/O line. But | it's not uncommon to have 10 to 100 pF of parasitic capacitance | sitting on an I/O line. Is this a problem? A PIC I/O has around ~ 30 | to 50 ohms output impedance (I'm just guessing this ...). Taking the | worst case of 50 ohms and 100 pF leads to a 5nS time constant. Even | when the clock is 20Mhz, this is hardly a factor. So the typical case | is probably okay with the BCF/BSF's. I'd only begin to really worry | when driving external cables and similar cases. Something like | bit-banging an I2C prom would most probably work just fine. Hey, who | was the bonehead complianing about the original SPI code? Now that You mention I2C, I've read a MChip tip that shows the R-M-W fact as a "feature", for handling I2C bus conflicts, and for "fault-tolerant systems". | > | However, I think the RMW problem has been blown out of proportion. It | > | only | > | matters if 1: you have other bits in the port that you will be toggling | > | between input and output and you don't explicitly set their state when | > | switching to output, and 2: if the external circuit holds a PIC output in | > | its opposite state. You have full control and knowledge of #1. #2 is | > | rare | > | because it usually means poorly designed hardware, although it could | > | legitimately happen for short periods of time (a few uS) after the output | > | is | > | switched if the external circuit has considerable capacitance. | > | > | > You forgot the open-source pin possibility, when it's configured as output | > but being driven externally. | | I thought open-source only worked for software :). Me too! :o) Change for: open-drain. And in my other mail I've swapped read and write... :o) Best Regards, S.- -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hello Sam, Scott & PIC.ers, mmmm... I've been well helped by your SPI code, Sam. Thanks for that, & I've now got `up-and-running' bit-bashed asm code for driving an AD7715 16bit bridge transducer front end for my instruments. It works really well, and I don't mind sharing it with anyone else who wants to do this kind of thing. Why didn't I use the MSSP in the 16f877? Let's not go there... it's a long story. I'm sure what Scott was getting at <in his sideways fashion> was your code's non-use of read-modify-write instructions. This was one of the mods. I made for the 7715 routines & learnt long ago < ie the hard way :( > that any bit-twiddling instructions otta be wrapped in mirror registers. best regards, John >Date: Mon, 6 Aug 2001 11:22:47 -0700 >From: Sam Linder <spamBeGoneSamLspamBeGoneIN-INC.COM> >Subject: Re: [PIC]: Need SPI code for 16F877 > >Instead of just criticiz...... .. .. <snippo> {Quote hidden}><snip> >> bsf SCLK // set SCLK high >> bcf SCLK // set SCLK low ><snip> > > >Are you sure that's the way you want to toggle an I/O? It probably >works fine, most of the time.... butt... > > >Scott e-mail from the desk of John Sanderson, JS Controls. Snailmail: PO Box 1887, Boksburg 1460, Rep. of South Africa. Tel/fax: Johannesburg 893 4154 Cellphone no: 082 741 6275 email: TakeThisOuTjsandEraseMEspam_OUTpixie.co.za Manufacturer & purveyor of laboratory force testing apparatus, and related products and services. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

{Quote hidden}> -----Original Message----- > From: Dan Michaels [EraseMEoricomUSWEST.NET] > Sent: Monday, August 06, 2001 9:56 PM > To: RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU > Subject: Re: [PIC]: Need SPI code for 16F877 > > > At 11:24 AM 8/7/01 +1000, you wrote: > >Olin Lathrop wrote: > > > >> Therefore, for most cases, the original code was just fine: > >> > >> bsf portb, clock_bit > >> bcf portb, clock_bit > > > > > >Probably so, but even Microchip suggest something like.... > > > > bsf portb, clock_bit > > nop > > bcf portb, clock_bit > > > > This only adds in another 0.2 usec with a 20 mhz xtal. Isn't > gonna help a great deal if a good-sized cap is hanging on the > pin. Due to instruction pipelining the single noop more that doubles the settling time between the write of the bsf and the read of the bcf. For example a really bad way to do it would be: movlw clock_bit bsf portb, clock_bit xorwf protb The xorwf would invert whatever it read as the result of the bsf and there would be virtually no time for settling. Sherpa Doug -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> I guess it comes down to a bit of common sense. Xtal speed VS pin > capactiance, and because writes followed by reads take less than a clock > cycle for the data recognition, probably closer to a Q cycle, I guess > the NOP helps a bit - but as you mention not in every case :-) There are *0* Q cycles between a write and a read in the next instruction. Read data gets latched internally at the beginning of a cycle, and write data gets written to the output latches at the end of a cycle. If you write something and want to read the reaction of the external circuit, you need at least one NOP, even if the PIC output is just wired right back to the PIC input. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, RemoveMEolinTakeThisOuTspamembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics