Searching \ for '[PIC]: Need SPI code for 16F877' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=spi
Search entire site for: 'Need SPI code for 16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Need SPI code for 16F877'
2001\08\05@171405 by Brandon Fosdick

flavicon
face
As I've mentioned before, I'm trying to use the MCP2510 in a project.
The SPI module on the 16F877 is driving me crazy. Does anybody have code
for it that I can use? Or even just some helpful hints? I'm about ready
to forget the hardware module and just bit-bang it, but I didn't see any
code on piclist for that either. A quick search of google didn't provide
any usefull answers.

I think I can TX a byte by just loading it into SSPBUF and then waiting
for it to leave. But I have no idea how to get the thing to receive a
byte. I keep getting the last byte that I wrote to SSPBUF.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\06@131201 by Sam Linder

flavicon
face
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}

2001\08\06@141300 by Scott Dattalo

face
flavicon
face
On Mon, 6 Aug 2001, Sam Linder wrote:

> Brandon:
> Here's some SPI code I wrote for the PIC16F877. Hope it works for you. If
> you have any questions, let me know.

<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

--
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


2001\08\06@142223 by Sam Linder

flavicon
face
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.


{Original Message removed}

2001\08\06@165810 by Scott Dattalo

face
flavicon
face
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


2001\08\06@210646 by Olin Lathrop

face picon face
>     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_OUTolinTakeThisOuTspamembedinc.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


2001\08\06@213240 by Tony Nixon

flavicon
picon face
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


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
.....salesKILLspamspam@spam@bubblesoftonline.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


2001\08\06@215605 by Dan Michaels

flavicon
face
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.

--
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


2001\08\06@220144 by Dan Michaels

flavicon
face
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


2001\08\06@223343 by Sebastian Garcia

flavicon
face
Hi Tony,


----- Original Message -----
From: Tony Nixon <Tony.NixonspamKILLspamENG.MONASH.EDU.AU>
To: <.....PICLISTKILLspamspam.....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


2001\08\06@223356 by Sebastian Garcia

flavicon
face
| >     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


2001\08\06@225845 by Tony Nixon

flavicon
picon face
Dan Michaels wrote:
{Quote hidden}

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_OUTspamTakeThisOuTbubblesoftonline.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


2001\08\06@233239 by Dan Michaels

flavicon
face
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


2001\08\06@233444 by Scott Dattalo

face
flavicon
face
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}

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


2001\08\06@235644 by steve

flavicon
face
> 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: stevebspamspam_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


2001\08\07@005901 by steve

flavicon
face
> 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@stevebKILLspamspamtla.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.


2001\08\07@011017 by Sebastian Garcia

flavicon
face
Hi Scott,

----- Original Message -----
From: Scott Dattalo <KILLspamscottKILLspamspamDATTALO.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.


2001\08\07@045753 by Spehro Pefhany

picon face
At 04:13 PM 8/7/01 +1200, you wrote:

>I think you could be a bit more generous with the capacitance. A
>single HC series input is typically 50-100pF.

This is high by 10:1. Here, check it out (Cin, page 3):
http://www.fairchildsemi.com/ds/MM/MM74HC00.pdf

Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\08\07@062453 by John

flavicon
face
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 <spamBeGoneSamLspamBeGonespamIN-INC.COM>
>Subject: Re: [PIC]: Need SPI code for 16F877
>
>Instead of just criticiz......
..
..
<snippo>

{Quote hidden}

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:                TakeThisOuTjsandEraseMEspamspam_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.


2001\08\07@073946 by steve

flavicon
face
> >I think you could be a bit more generous with the capacitance. A
> >single HC series input is typically 50-100pF.

As soon as I saw the quoted bit I thought, who wrote that rubbish.
Oh  - me.

> This is high by 10:1. Here, check it out (Cin, page 3):

Indeed it is. Sorry for the brain fart.

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: RemoveMEstevebspamTakeThisOuTtla.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.


2001\08\07@090619 by Olin Lathrop

face picon face
> Probably so, but even Microchip suggest something like....
>
>      bsf   portb, clock_bit
>      nop
>      bcf   portb, clock_bit

The minimum pulse length depends on the external circuit.  If the PIC output
is driving a single 74HC input via a reasonably short wire on the same board
(like into the clock input of a flip-flop), then 200nS is plenty.  More
capacitance requires a longer pulse to compensate for the slower rise time.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinEraseMEspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\08\07@111648 by Douglas Butler

flavicon
face
{Quote hidden}

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.


2001\08\07@123043 by Sam Linder

flavicon
face
John:
I'm glad I was able to help by providing my SPI code which has worked for me
consistently in spite of all the warnings being posted. It directly drives a
DS1305 RTC.

When I provide code on this list, it is meant to help others by showing them
what worked for me. It isn't meant to be a gold standard. Many times PICers
just need to see how someone got something working. They can then modify it
to their hearts content.

While I appreciate those who try to help me avoid potential problems, the
old adage is still true: It's not necessarily what you say, it's how you say
it.
Sam....
"May the roof over your head
never leak until it rains gold."

    ("`-''-/").___..--''"`-._
     `6_ 6  )   `-.  (     ).`-.__.`)
     (_Y_.)'  ._   )  `._ `. ``-..-'
   _..`--'_..-_/  /--'_.' ,'
  (il),-''  (li),'  ((!.-'



{Original Message removed}

2001\08\07@150619 by Olin Lathrop

face picon face
>         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.

There would be no time at all for settling because the BSF write would occur
on the same clock edge as the XORWF read.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspam_OUTspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\08\16@095927 by Olin Lathrop

face picon face
> 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, RemoveMEolinTakeThisOuTspamspamembedinc.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


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...