Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Can TMR1 be used as a 16-bit shift register?

Status
Not open for further replies.
Dang you better watch them ladders we not kids any more stuff us tuft old guys think can't hurt us does now. Glade your better
 
Since I walked into the hospital the day after the accident, there was a brief discussion among some personnel whether I met the definition of an emergency. After the x-rays, there were no more questions about that, but one person did tell me I was a tough, ol' goat. ;)
John
 
I thought I would wrap this up and add the code I forgot to add earlier.

To review:
MCU=16F1519
Sensor=AS5048A (rotary, 14-bit angle sensor from Austria MicroSystems)
Language=MPASM
SPI mode= 3-wire (MOSI tied high at sensor; MOSI TRIS=1 and tied low at MCU)

Code:
Test0                              ;used on error to provide external warning
;     movlb     2                  ;not used in simulation                 |B2
;     BSF       LED                ;                                       |B2   
;     DelayCy   (25*msecs)
;     BCF       LED                ;                                       |B2
;     DelayCY   (25*msecs)

;setup serial port

     MOVLB     4              ;SPI controls in Bank4                       |B4
     MOVLW     b'00000001'    ;
     MOVWF     SSPCON1        ;CKP=0,master clk=Fosc/16

;04.25.15 tried all 3 settings for <3,0>, Fosc/64 did not work, others did,
;hung up on waiting for the BF flag bit. Fosc/16 should work wtih all Fosc
;up to 32 MHz.  AS5048 internal clock is ca. 5 MHz. ˜˜

     CLRF      SSPSTAT       ;CKE=0                                       |B4
    
GetSPI
  
     MOVLB     4              ;                                            |B4
     BSF       SSPCON1,SSPEN  ;enables serial port                         |B4     
     MOVLB     2              ;                                            |B2
     BCF       CSn            ;!CS                                         |B2
     MOVLB     4              ;                                            |B4
;    MOVLW     0xFF           ;alternative to zeros                        |B4                    
;    MOVWF     SSPBUF         ;                                            |B4
     CLRF      SSPBUF         ;alternative                                 |B4
      
GetBUFF 
;NB:Polling SSPSTAT,BF seems to work as well as polling PIR1,SSPIF and
;doesn't require bank switching.   
     btfss     SSPSTAT,BF
     goto      $-1
     movf      SSPBUF,w
     movwf     SPI_H
     CLRF      SSPBUF
     btfss     SSPSTAT,BF
     goto      $-1           
     movf      SSPBUF,w
     movwf     SPI_L       
     BCF       SSPCON1,SSPEN  ;disable SPI port
     movlb     2              ;                                            |B2
     bsf       CSn            ;set !SS(CSn)high
;     NOP                      ;debugging
ErrTest
     BTFSS     SPI_H,7
     GOTO      Test0
     BTFSC     SPI_H,6
     GOTO      Test0
     BCF       SPI_H,7
;     DelayCy   (300*msecs)
;     DelayCy   (300*msecs)
     goto      GetSPI

Note: CKE (clock edge select)=0, CKP (clock polarity)=0 (idle low)

The only problem so far is that the first read is often zero and goes to the error loop. Subsequent reads are mostly OK with a rare parity error in simulation.

John
 
You don't need to disable/enable SPI module. It won't do anything if you keep it enabled all the time.

About the first read - may be the sensor needs some sort of delay between CS down and the beginning of the transmission. Your rate might be too fast too.
 
_NorthGuy,

Thank you for the comments.

I set it up on my bench with an LCD readout (release build). The LED error rate is low and is, so far as I can tell from simulation, due to an occasional parity problem. I was thinking of adding a nop or whether maybe the 3-wire configuration itself was the culprit. I will try those approaches and see what happens.

As for the MSSP/SPI module, MC makes it clear to start first and stop last. I interpret that to mean it can be left on. I just have it the way it is for developing this module. If I get so far as actually using it, I will only go out periodically, say every 100 msecs to get the data.

You have been a great help in getting this far. As usual, I was making it more complicated than it really is.

Regards, John
 
NorthGuy
I tried adding NOP's (0 to 3) after clearing CSn, tried doing 4-wire, and have left SPEN on. All to no avail in avoiding the parity error. I then set the MCU to 8 MHz, which had no effect by itself, but when I set the master clock ratio to Fosc/4 from Fosc/16 it works noticeably better. I still get a few parity failures, but many more non-failures. The actual value read regardless of parity error is not noticeably different allowing for ± a couple of counts.

I have not tested that configuration using 4-wire mode.

Do you even bother with checking the parity bit? Maybe a faster clock is needed to "catch it?" The bit<14> error flag rarely, if ever gets set.

John
 
MSSP doesn't have built-in parity check, so I assume you're talking about a bit transferred by the slave device (I've never used this one). In this case, you probably need to calculate parity and compare it to the check bit.

As to the speed, it is not restricted to FOSC/4 or FOSC/16. There's a setting in MSSP, which lets you specify a variable speed in SSPADD (SSPCON1.SSPM = 0b1000), with your final speed being FOSC/(4*(SSPADD-1)). You can make it working at some really slow speed, then adjust to higher speed as needed.
 
The parity bit was a misunderstanding by me of an ambiguous sentence in the datasheet. That problem has been resolved and is described in more detail here: https://www.electro-tech-online.com/threads/logic-analyzer-choice.144533/#post-1219351

Since I stopped trying to make the "parity alarm" bit disappear, it has worked like a charm. I wish it had simply been identified as a parity bit in the datasheet. Now, I have to figure out how to attach the angle encoders to the loader joints on my tractor.

I need to measure two joints, circled in red on this model:
upload_2015-5-3_14-18-29.png


John
 
I use two angle sensors on excavators to get similar information.... We put one on the first section ( before the first joint ) and one after to get the second sections angle... BUT!! you are looking for the angle of the bucket... This can be done with simple potentiometers... I only need to know the position of the bucket, not its angle.....
 
Do you use angle sensors or accelerometers? I recall you linking to some accelerometers with which you had experience earlier. For my tractor, the inherent bounce was too much for the accelerometer-- or at least more than I wanted (±2° or so).

The tractor pivots are pretty crude compared to my excavator's. They look like seamless, welded tubing with a half-hard or alloy steel pin. I was thinking of mounting the magnet in the pin opposite the zerk grease fitting. Then mounting the electronics in something like a bearing cap pressed into or over the tubing. Since this is very early in the design, I need to avoid any modifications to the tractor that are not completely reversible. In other words, if I bore out a pin to take a magnet, I could leave the pin as is or replace it with a new pin, should that be necessary. But, I am not going to be drilling any mounting holes in frame members. I will just use mounting tape.

I haven't been able to get outdoors since my accident. I am thinking another week or two, and I will be able to start playing again with everything except ladders.

John
 
Accelerometers are in fact angle sensors.... The ones I use have inbuilt smoothing to enable you to use them as angle sensors... These are obviously dearer than accelerometers as they only have X, Y and Z information...

As I have posted before.. They are £30+ but work for me.... Coupling an accelerometer requires the maths to determine the angle.... Loads on the internet have done this... If you trawl the arduino sites you'll find code.. Unfortunate in C++ so a bit of work, as you use assembly!!

A pot and an arm would suffice just as well....
 
Status
Not open for further replies.

Latest threads

Back
Top