Searching \ for '[PIC] Continuous SPI transmission' 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: 'Continuous SPI transmission'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Continuous SPI transmission'
2011\08\10@083622 by IVP

face picon face
part 1 1134 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

Hi all,

wondering if anyone is using SPI on the dsPIC33

The d/s (70206C) says

6. Data to be transmitted can be written to SPIxBUF by the user software
at any time as long as the SPITBF bit (SPIxSTAT<1>) is clear. The write
can occur while SPIxSR is shifting out the previously written data, allowing
continuous transmission.

but I'm having trouble with that. In the attached analyser capture, you'll
see that only two bytes are sent, although the routine to send 16 bytes
completes. If the SPITBF test is removed and a short delay used instead,
all 16 bytes are sent as they should be

send_w0:
;           btsc    SPI1STAT,#SPITBF  ;either test SPITBF
;           bra     $-2
          mov     w0,SPI1BUF        ;loading sets SPITBF
          call    usec50            ;or use 50us delay
          return

Any ideas ? I use the 'buffer empty' flag on the UART and it works fine,
so I do understand the principle. Without that test the s/w is way faster
than the baud rate and transmissions are lost

In this case, Fcy is 29.4912MHz and the SPI rate is 368.64kHz

TIA

Joe


part 2 2373 bytes content-type:image/gif; name="spi_tbf.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\08\10@091533 by M. Adam Davis

face picon face
Can you give the code examples you used for the two different tests
exactly as you used them?  Right now you've got the bit test commented
out, and the delay in place, but are you sure you didn't have the bit
test commented out accidently for the first test?

Also, are you sure that bra $-2 is correct?  I haven't done assembly
in quite some time, and prefer to use labels anyway, but you might
want to double check that this will loop correctly.

-Adam

On Wed, Aug 10, 2011 at 8:33 AM, IVP <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:
{Quote hidden}

>

2011\08\10@093346 by IVP

face picon face
Hi Adam

> are you sure you didn't have the bit test commented out
> accidently for the first test?

No, the bit test was the original way. Only remming that out and
replacing it with the delay got all 16 out

> Also, are you sure that bra $-2 is correct?

Yep, that's fine

A9F4 AF2240 send_w0 btsc.b 0x0240,#1
A9F6 37FFFE bra send_w0

Thank

2011\08\10@100056 by IVP

face picon face
Ah,

just checked through an errata (80443E) and it looks like SPITBF
is a silicon issue. I've got two batches - $3002 revision, date code
0909 and $3003 revision, date code 1114. They're both mentioned,
so are a heap of others, so looks like I'll have to use delays. Bugger

Jo

2011\08\10@101822 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam@spam@mit.edu [piclist-bouncesspamKILLspammit.edu] On
Behalf
{Quote hidden}

It seems nothing has changed at Microchip then.  I have yet to find
another vendor that consistently releases parts with as many problems as
Microchip.

The errata suggests you can work around the problem by polling the
SPITBF until it gets set, and then polling until it's cleared e.g.

send_w0:
          btsc    SPI1STAT,#SPITBF  ; wait for SPITBF to clear
          bra     $-2
          mov     w0,SPI1BUF        ; load SPI buffer
          btss    SPI1STAT,#SPITBF  ; wait for SPITBF to get set
          bra     $-2
          return

Cheers

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\08\10@153014 by IVP

face picon face
> The errata suggests you can work around the problem by polling the
> SPITBF until it gets set, and then polling until it's cleared e.g.

Mike,

with all due respect to the boffins at Microchip, I've had flag problems
in the silicon before, notably I2C. A polling wait may work, but it can
depend. I wasted an enormous amount of time with the F88 and an
undocumented flag problem caused by broken I2C / IntOsc combinations.
The eventual, reliable, solution was to stay away from that flag

I'll try polling and see if it works. Can I trust it though if I change clock
speed or SPI speed ? (rhetorical - this project involves both, so I'll have
to find out)

Joe

2011\08\10@170821 by Denny Esterline

picon face
.. I wasted an enormous amount of time with the F88 and an
> undocumented flag problem caused by broken I2C / IntOsc combinations.
> The eventual, reliable, solution was to stay away from that flag
>
>
Wow, there's vindication after the fact. About 4 years ago I was involved in
a
project and one small corner of it was an F88 on intOsc as an I2C slave. I
spent
untold hours trying to get it to work, never succeeded. Eventually we cut
our
losses an found a different way around the problem. Glad to know there was
a
silicon bug instead of me just being an idiot.

-Denn

2011\08\10@171304 by IVP

face picon face
part 1 870 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

> The errata suggests you can work around the problem by polling the
> SPITBF until it gets set, and then polling until it's cleared e.g.
> > send_w0:
>           btsc    SPI1STAT,#SPITBF  ; wait for SPITBF to clear
>           bra     $-2
>           mov     w0,SPI1BUF        ; load SPI buffer
>           btss    SPI1STAT,#SPITBF  ; wait for SPITBF to get set
>           bra     $-2
>           return

Mike,

I've tried exactly that and it doesn't work. Attached is a capture. Only
3/16 bytes are sent, although because the first 11 are FF it's uncertain
which 2 of those went, and I won't waste time finding out. It seems
SPITBF takes longer to be set than it takes for the byte to leave the
pin. And this is low speed SPI. It'll be even more useless at the MHz
rates I have to use

Joe

part 2 575 bytes content-type:image/gif; name="SPITBF_wait.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\08\10@204948 by IVP

face picon face
> F88 on intOsc as an I2C slave. I spent untold hours trying to get it
> to work, never succeeded

AFAIK that bug is still undocumented, even though I told MC about
it and they accept it exists. Basically, if you use the F88 IntRC, check
the errata carefully

Jo

2011\08\11@041324 by alan.b.pearce

face picon face
> > F88 on intOsc as an I2C slave. I spent untold hours trying to get it
> > to work, never succeeded
>
> AFAIK that bug is still undocumented, even though I told MC about
> it and they accept it exists. Basically, if you use the F88 IntRC, check
> the errata carefully

Sometimes the way to make it documented is to publish it on their forum.

This then seems to wake the giant and get it referred to someone who documents and publishes it in the errata.


-- Scanned by iCritical.

2011\08\12@070440 by IVP

face picon face
part 1 5545 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

Another couple of things to slow me down with the dsPIC33...802

Below is the set-up for the SPI module, following that a little code

Attached is the analyser capture of two versions of that code. The top
group, waiting for SPIRBF to set, the lower group not waiting

The two things -

(1) the device is sending the correct response, 0x01, at the correct time
(the second byte of SCKs) but it doesn't appear that the data gets into
SPIBUF through the pin. TRISB is set only once, and it would appear
to be an input as the signal on SDI is good. Setting RP11 as SDI, well,
I have to assume that the connection is made inside the PIC. The Unlock
sequence has been done. The UART is remapped and that works fine,
as do SCK and SDO come out of the assigned pins

(2) why does SPIRBF appear to be set after the first set of 8 SCK and
yet not after the second ? It might possibly be that (1) is true - new data
is not getting into the shift register after the first read of SPIBUF and so
therefore the flag will not be re-set

Tried 3 PICs, all new, no change, so it'll be something I'm doing or not
doing, but I've not spotted it yet. And I can't see anything else that needs
to be done to remap, and particularly as all the other pin assignments
work anyway. I don't want to assume that because there's a recognised
fault with SPITBF that there could be a silicon gotcha with SDI

Any thoughts ?

Someone with a similar problem, but with SDI on RB0

http://www.microchip.com/forums/m594951.aspx

Joe

          mov     #0b0000100000001010,w0
;                     0000
;                         1                 SDI1
;                          0                /CS
;                           0
;                            0              SCK1
;                             0             SDO1
;                               0           En
;                                0          RS
;                                 1         /CTS (in)
;                                  0        TX
;                                   1       RX
;                                    0      /RTS (out)
          mov     w0,TRISB

; SPI Din   b7  SDO1 00111 RPn tied to SPI1 Data Output
;     Clk   b8  SCK1 01000 RPn tied to SPI1 Clock Output
;     /CS  b10  SPI /SS
;     Dout b11  SPI1 RPINR20 SDI1R<4:0>, data from card
;
; RP7  = Din (card), SDO o/p
; RP8  = Clk         SCK o/p
; RP10 = /CS         /SS o/p
; RP11 = Dout (card) SDI i/p

          mov     #0b0000011100000000,w0
;                     ---00111---xxxxx     ;RP7 as SDO1
          mov     w0,RPOR3

          mov     #0b0000000000001000,w0  ;RP8 as SCK1
;                     ---xxxxx---01000
          mov     w0,RPOR4

          mov     #0b0000000000001011,w0
;                     ---xxxxx---01011     ;RP11 as SDI1
          mov     w0,RPINR20


          mov     #0b1000000000000000,w0
;                     1                     SPI enable
;                      x
;                       0                   discontinue in idle
;                        xxxxxx
;                              x            SPIROV flag
;                               xxxx
;                                   x       SPITBF, transmit buffer full/empty
;                                    x      SPIRBF, receive buffer full/empty
          mov     w0,SPI1STAT

          mov     #0b0000000100101101,w0  ;initialise at 368.64kHz
;                     xxx
;                        0                  Clk controlled by module
;                         0                 SDO controlled by module
;                          0                8-bit transfers
;                           0               input sampled in middle of bit
;                            1              CPHA = 0, data change on falling edge
;                             0             /SS as normal I/O pin
;                              0            CPOL = 0, idle low
;                               1           Master
;                                011        secondary pre-scale  5:1
;                                   01      primary pre-scale   16:1 -> 368.64kHz (29.4912/80)
          mov     w0,SPI1CON1

          mov     #0xff,w0                ;supply CLK, wait for response
          call    send_w0                 ;with SDO high (FF data)
          bset    LATA,#ri                ;indicator
          btss    SPI1STAT,#SPIRBF        ;test for full receive buffer
          bra     $-2
          mov     SPI1BUF,w2              ;read buffer, *should* clear SPIRBF
;           mov     SPI1BUF,w0              ;dummy reads ?
;           mov     SPI1BUF,w0
          mov     #0x30,w0                ;add #30 for display
          add     w0,w2,w0
          mov     w0,[w5++]               ;store in RAM for display later
          bclr    LATA,#ri                ;indicator

;           call    usec100                 ;delay ? no difference

          mov     #0xff,w0
          call    send_w0
          bset    LATA,#ri
          btss    SPI1STAT,#SPIRBF
          bra     $-2
          mov     SPI1BUF,w2
          mov     #0x30,w0
          add     w0,w2,w0
          mov     w0,[w5++]
          bclr    LATA,#ri

;           call    usec100

          mov     #0xff,w0
          call    send_w0
          bset    LATA,#ri
          btss    SPI1STAT,#SPIRBF
          bra     $-2
          mov     SPI1BUF,w2
          mov     #0x30,w0
          add     w0,w2,w0
          mov     w0,[w5++]
          bclr    LATA,#ri

part 2 4160 bytes content-type:image/gif; name="SPIRBF.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\08\13@012150 by IVP

face picon face
part 1 1798 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

Hi all,

another tedious but eventually illuminating day at the bench .........

After much trial and error

          mov     #0xff,w0                ;supply CLK, wait for response
          call    send_w0                 ;with SDO high (FF data)
          bclr    SPI1STAT,#SPIROV        ;*** must clear overflow flag ***
          btss    SPI1STAT,#SPIRBF        ;before test for full rx buffer
          bra     $-2
          mov     SPI1BUF,w2              ;read buffer
          mov     #0x30,w0                ;add #30 for display
          add     w0,w2,w0
          mov     w0,[w5++]               ;store in RAM for display later

The solution that seems to work is clearing SPIROV before reading
the receive buffer. Every time. Even though the previous read is meant
to prevent SPIROV being set, ie there is no overflow to report because
the previous data has been read

"SPIROV = 1 ; A new byte/word is completely received and discarded.
The user software has not read the previous data in the SPIxBUF register"

I might be wrong but AFAICT this is not documented. It's not in any of
the timing diagrams for example. Clearing SPIROV is mentioned as one
of the steps when setting up the SPI module, but not that it must be used
throughout. And I'm not sure exactly how SPIROV being set stops the
SPIRBF being set. But if this another 33..x02 SPI silicon issue then who
knows

Now what I see on the LCD is / 1 /, which corresponds to 2F 31 2F,
or FF 01 FF when the added #30 is taken off, and that's correct

In one of the forum threads some guy said "I don't mind bug hunting".
Personally I'm getting pissed off finding things wrong with products
and manuals. Days are long and hard enough already thanks

Joe


part 2 1708 bytes content-type:image/gif; name="SPIROV.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\08\13@022559 by Oli Glaser

flavicon
face
On 13/08/2011 06:20, IVP wrote:
> The solution that seems to work is clearing SPIROV before reading
> the receive buffer. Every time. Even though the previous read is meant
> to prevent SPIROV being set, ie there is no overflow to report because
> the previous data has been read
>

Sounds like you have had a bit of a rough time with this..
The issue/solution does ring a bell for me, I'm pretty sure I have resorted to this with another PIC (I know it wasn't a dsPIC but that's as much as I remember) at some point. I think I was probably rushing to tack a prototype or one of my personal projects together and assumed it was something I was doing wrong so didn't look further into it.
    Anyway, thanks for the heads up, I just twigged that this is the same chip I ordered last week (in the "dsPIC for Audio" thread)
I'm just setting up to look at it now so your timing with this info is excellent :-)
If I discover anything more worth knowing while looking at this I'll post it here.

{Quote hidden}

I don't mind too much hunting for bugs I created, but when you're up against something that is undocumented it can be very frustrating I agree - you have no (easy) way of knowing it's not something you are doing, and no-one likes to start a ticket only to find out you missed something simple.
I am far more suspicious of things like silicon issues nowadays, especially since I started working with FPGAs and have some idea of how easy it is to create an obscure/intermittent problem when designing a chip. First thing I usually do is read the errata, but that still doesn't help with issues that have yet to be discovered...


2011\08\13@033043 by IVP

face picon face
> If I discover anything more worth knowing while looking at this I'll
> post it here.

Hopefully I've found the problem, so I'll be moving on with the s/w.
If SPIROV proves not to be the issue I'll find out soon enough and
let you know. And if it is I'll tell MChip support so they can add it to
the errata. Some time

Jo

2011\08\13@230109 by IVP

face picon face
> Sounds like you have had a bit of a rough time with this..

Quite

Here's a curious thing

Works

          mov     #0xff,w0
          call    send_w0
          bclr    SPI1STAT,#SPIROV
          btss    SPI1STAT,#SPIRBF
          bra     $-2
          mov     SPI1BUF,w2

send_w0:   mov     w0,SPI1BUF        ;load SPI buffer
          call    usec50            ;wait at 368.64kH
          return

Don't works -
          mov     #0xff,w0
          call    send_w0
          btss    SPI1STAT,#SPIRBF
          bra     $-2
          mov     SPI1BUF,w2

send_w0:   mov     w0,SPI1BUF        ;load SPI buffer
          call    usec50            ;wait at 368.64kH
          bclr    SPI1STAT,#SPIROV
          return

The difference ? The 'return' it seems

Works OK too

          mov     #0xff,w0
          call    send_w0
          bclr    SPI1STAT,#SPIROV
..... any number of cycles ....
          btss    SPI1STAT,#SPIRBF
          bra     $-2
          mov     SPI1BUF,w2

Weird

Jo

2011\08\13@233552 by Oli Glaser

flavicon
face
On 14/08/2011 04:00, IVP wrote:
> The difference ? The 'return' it seems
>
> Works OK too
>
>             mov     #0xff,w0
>             call    send_w0
>             bclr    SPI1STAT,#SPIROV
> .... any number of cycles ....
>             btss    SPI1STAT,#SPIRBF
>             bra     $-2
>             mov     SPI1BUF,w2
>
> Weird

That does seem weird, yes. Have you any idea what the return might be doing to cause problems?
Have you had a look at what is happening to the various registers involved?
How exactly does it not work - does it even load SPI1BUF the first time round?

2011\08\14@013012 by IVP

face picon face

> any idea what the return might be doing to cause problems?

No idea at all. Very unexpected. You'd think that a seemingly
innocuous instruction would have no affect on a bit in an un-related
register. I mean 'return' ? What can go wrong with 'return' ?

> Have you had a look at what is happening to the various registers
> involved?

No, not even sure if it's worth pursuing TBH

> How exactly does it not work - does it even load SPI1BUF the
> first time round?

There's a sequence of SPI commands to an SDHC card. The
final one is ACMD41, which is where you wait for the card to
finish initialising. With the working code, the loop goes back and
re-issues the ACMD41 until the required response. With the
non-working code, the SPI does the sequence correctly but at
the looping just spits out FFs forever instead of the 12-byte
ACMD41 string, so it's obviously off with the fairies somewhere

I discovered *this* when I discovered the fault with SPIROV
and thought it would be a good idea to include its blcr in the
send routine to save typing and cycles

I've put a ticket in to MChip support to see if they can confirm that
there's a SPIROV bug they didn't know about (plus I can add this
oddity to the pile)

Because the project I'm working on is dependent on SPI I think
I have a case for a refund or bugless replacements under "fit for
purpose". Simply don't trust this IC any more

For the time being, got Duckman DVDs that need watching ;-)))

Jo

2011\08\14@015619 by cdb

flavicon
face
What interrupt level are you using?

I think level 6 is when the SPI starts to work, maybe having it at the wrong level causes strange side effects.

Colin
--
cdb, .....colinKILLspamspam.....btech-online.co.uk on 14/08/2011
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 This email is to be considered private if addressed to a named  individual or HR department, and public if addressed to a blog,  forum or news article.

2011\08\14@031547 by IVP

face picon face
> What interrupt level are you using?

Interrupts are off

> I think level 6 is when the SPI starts to work, maybe having it at the
> wrong level causes strange side effects.

AIUI the interrupt level/priority wouldn't stop a module working. Only
that its IRQ will be processed wrt to the priority setting of anything else
enabled and their respective positions in the natural order in the interrupt
vector table

AIUI

Joe

2011\08\14@115225 by RussellMc

face picon face
> It seems nothing has changed at Microchip then.  I have yet to find
> another vendor that consistently releases parts with as many problems as
> Microchip.

Try Z_l_g.
At least Microchip MAY fix and/or acknowledge  theirs.


           R

2011\08\23@083356 by IVP

face picon face
part 1 2560 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

Hi all,

MChip Support have offered this as a resolution. I need
a C to assembler translation in case I missed something

------------
I wrote a small piece of code in C for SPI2 as follow:
UINT8 writeSPI2( UINT8 value )
{
   SPI2BUF = value;    // write to buffer for TX
   while(!SPI2STATbits.SPIRBF); // complete transfer wait
   return SPI2BUF;        // read the received value
and this is always working without any SPIROV issue.
-----------

Below is typical code I use to send a CMD to an SDHC card. In
it, SPIROV must be cleared right before the buffer read or it
simply doesn't work. Program will not get past the full buffer test

How is MChip's code different ? I notice he uses SPI2 used for
some reason - the dsPIC I have has only SPI1. He didn't say
which PIC he's got his code running on

If I execute this loop, which I think corresponds to the proposed
solution,

t_loop:    mov     #cmd00,w0               ;0 + 0x40
          mov     w0,SPI1BUF
          btss    SPI1STAT,#SPIRBF
          bra     $-2
          mov     SPI1BUF,w2

          mov     #0xff,w0
          mov     w0,SPI1BUF
          btss    SPI1STAT,#SPIRBF
          bra     $-2
          mov     SPI1BUF,w2

          bra     t_loop

all that results is 1/2 an iteration (attached). Flow halts at the very
first SPIRBF test. So his solution isn't appropriate for the dsPIC
I'm asking about. And I've already told him about that loop above.
He's just written in C and told me it works

Please, if you can, consider the code carefully. I'm I wrong ?

Joe

Typical send CMD code

          mov     #cmd00,w0
          call    send_w0
          mov     #0x00,w0
          call    send_w0
          call    send_w0
          call    send_w0
          call    send_w0
          mov     #0x95,w0
          call    send_w0

;wait for '0x01' response

more_00r:  mov     #0xff,w0                ;supply CLK, wait for response
          call    send_w0                 ;with SDO high (FF data)
          bclr    SPI1STAT,#SPIROV        ;must clear overflow flag
          btss    SPI1STAT,#SPIRBF        ;test for full receive buffer
          bra     $-2
          mov     SPI1BUF,w2              ;read buffer
          mov     #0x01,w1                ;wait for CMD0 '0x01' response
          xor     w1,w2,w1
          bra     nz,more_00r

....more code

send_w0:   mov     w0,SPI1BUF              ;load data into SPI buffer
          call    usec50                  ;wait at 368.64kHz
          return

part 2 1237 bytes content-type:image/gif; name="not_a_loop.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\08\23@113946 by Harold Hallikainen

face
flavicon
face
It pretty much looks like you're doing the same thing. I often use code
similar to the C code you've shown, but call it SpiExchange() since it
does both a read and a write. Using that approach makes it so your code
calling it does not have to worry about SPI hardware (status bits,
buffers, etc.). You just pass in a value and get something back. So... I
don't know why your existing code does not work, but I'd structure stuff
similar to what they provided (and name it SpiExchange().

Good luck!

Harold


{Quote hidden}

>            return

2011\08\23@114131 by Harold Hallikainen

face
flavicon
face
As a follow-up, I don't recall what chip you're using, but I recently
found an errata on the PIC24HJ256GP610A about SPI. I have code that
currently works on the non-A version, but does not work on the A version.
Trying to chase that down...

Harold

{Quote hidden}

>            return

2011\08\23@165544 by IVP

face picon face


> As a follow-up, I don't recall what chip you're using

dsPIC33FJ64GP802. The same silicon fault is in several of that famil

2011\08\23@165544 by IVP

face picon face
> You just pass in a value and get something back. So... I don't
> know why your existing code does not work

Well, that's my question to MChip. Which he managed to dodge

I'm wondering whether he tried it in real silicon, have to ask *that* now

>:-(

Jo

2011\08\25@053056 by cdb

flavicon
face
On Wed, 24 Aug 2011 00:33:07 +1200, IVP wrote:
:: He's just written in C and told me it works
::
:: Please, if you can, consider the code carefully. I'm I wrong ?

Silly question, but have you tried it in Microchip C and see what assembler the compiler puts out?

Alternatively, I could do that for you.

Colin --
cdb, EraseMEcolinspam_OUTspamTakeThisOuTbtech-online.co.uk on 25/08/2011
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 This email is to be considered private if addressed to a named  individual or HR department, and public if addressed to a blog,  forum or news article.
 

2011\08\25@060048 by cdb

flavicon
face
Answering my own question, here is the assembler for the code you supplied, changed to SP1.

Compiler is the MikroElectronica C for DSPIC v5.01 - I couldn't be bothered to fire up MPLAB.

;::                void main() {
;::                amount =  writeSPI1(cmd);
       PUSH        W10
       MOV        #64, W10
       CALL        _writeSPI1
::                }
L_end_main:

       POP        W10
L__main_end_loop:
       BRA        L__main_end_loop
; end of _main

_writeSPI1:

;::                unsigned writeSPI1( unsigned value )
;::                SPI1BUF = value;    // write to buffer for TX
           MOV        W10, SPI1BUF
;::                while(!SPI1STATbits.SPIRBF); // complete transfer wait
L_writeSPI10:
        BTSC        SPI1STATbits, #0
        GOTO        L_writeSPI11
        GOTO        L_writeSPI10
L_writeSPI11:
;::                return SPI1BUF;
        MOV        SPI1BUF, WREG
;::                }
L_end_writeSPI1:
       RETURN
; end of _writeSPI1

Colin
--
cdb, colinspamspam_OUTbtech-online.co.uk on 25/08/2011
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 This email is to be considered private if addressed to a named  individual or HR department, and public if addressed to a blog,  forum or news article.

2011\08\25@063421 by IVP

face picon face
> Answering my own question, here is the assembler for the code you
> supplied, changed to SP1

Thanks. Basically it's what I have in assembler

My last reply to MChip was - Have you tried it in the silicon and
what micro ? Nothing back yet. His solution is no good to me if it's
only been tested on an ICE or a micro which doesn't have 'issues'

Jo

2011\08\25@185852 by IVP

face picon face
Colin,

I tried your C code, no go. As it's the same as what I was doing
anyway that's no great surprise. Actually a relief. I shouldn't need
to use a compiler's output to check my assembly code

So I told MChip. Their response -

----------

# you need to modify the following instructions:

RPINR20bits.SDI1R = 17;  // SDI1, RP17-RC1, pin 26, value 17 = RP17
RPOR8bits.RP16R = 7;  // SDO1, RP16-RC0, pin 25, value 7 = 00111 = SDO1
RPOR9bits.RP18R = 8;  // SCK1, RP18-RC2, pin 27, value 8 = 01000 = SCK1

----------

Hmmm, OK. You do know that pin 27 on *my* PIC is AVss ? And
25, 26 are DAC outputs, pretty much the reason for the product ?

Sorry to sound snotty but I really get the feeling MChip Support
is trying to make me do all the work, and spend the $$$, until I fit
their solution

It's frustrating that the tech hasn't tried my code in my PIC, but instead
written his own s/w for a PIC of his choosing. So, after three weeks
we're back to square one. "Here's my code, why doesn't it work ?"

;-(         [and not for the first time with MChip Support]

Jo

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