1. soumyasairaj

    Thread Starter New Member

    Mar 31, 2014
    1
    0
    Is there any priority settings of interrupts in PIC16F877A?
    I have another doubt also that,can we set TRIS register of any port in bitwise?
     
  2. Papabravo

    Expert

    Feb 24, 2006
    10,135
    1,786
    #1. No, not in hardware. You are of course free to check for interrupt flags in any order that you choose.
    #2. Yes, the TRIS registers can be the destination of a READ-MODIFY-WRITE operation that affects a single bit only.

    If I misinterpreted what you are asking I apologize and encourage you to ask more precise and well formed questions.
     
  3. tshuck

    Well-Known Member

    Oct 18, 2012
    3,531
    675
    The midrange 16F PICs don't support prioritized interrupts - any interrupt will load the PC with the same address which will branch to your interrupt service routine, which, as papabravo pointed out, can be checked in whatever order you want, making interrupts checked first a higher priority.

    Yes, you can set bits in a register bitwise - the TRIS register is no exception ( but be aware of RMW issues).
     
  4. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,019
    +1 Specifically, never do a bsf/bcf on any TRIS port that might have peripherals that change the IO direction direction especially I2C and PSP.

    My personal recommendation is to always shadow PORT and TRIS in midrange. That means maintain a copy of the PORT/TRIS in RAM, modify it then write the whole byte to the port with movwf.
     
  5. John P

    AAC Fanatic!

    Oct 14, 2008
    1,632
    224
    People are talking as though the read-modify-write feature applies to TRIS registers, and I don't think it does: aren't they just regular registers, as far as setting and clearing bits is concerned? If I'm wrong, maybe someone can point to a section in the data manual that describes it.

    Also, if "priority" in interrupts means a high-priority one interrupting a lower one, that's a feature that PIC16 processors don't have--once an interrupt is entered, the hardware won't jump out of it into another interrupt. You do have the option of testing interrupt flags in any order, if more than one is set and you haven't yet responded to any of them, but that's an unusual situation.
     
  6. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,019
    All bsf/bcf are done internally by r-m-w, it just usually doesn't matter since the data in the byte being operated on is stable - RAM and most SFRs for instance. Later databooks confirm this (sec 23.1 in the 10F320) says:
    In those cases where the bits in the byte being operated on are volatile like output port bits that are subject to noise or other level-changing phenomena you have the notorious r-m-w situation that we all know and hate.

    Not as obvious (until you run into it) is the problem where peripherals or other logic may control certain bits in a register independently of the value written to them. SDA (RC4) is one of these. When an I2C slave grabs SDA to send an ACK to the master it does it (at least on our 16Cxx parts of the day) through the TRIS register. If at that unfortunate moment you do a r-m-w to TRISC, it will change SDA from input to output (because the SSP slave asserts ACK - output 0 - through the TRIS bit) and lock the I2C data line low. This behavior is not well documented - I encountered it some years ago and confirmed the issue with uCHIP engineers. There were other registers with similar problems as well but now I just shadow the whole thing, TRIS and PORT and poof- no problems.

    The r-m-w problem to TRIS may not be confined to midrange. Some years ago we ported our modules to the 18F using LAT for outputs to eliminate r-m-w on the outputs BUT found we still had to shadow TRISC to avoid the I2C ACK problem (on the 18F6622 at least). We did specific testing on the issue and that's what we wound up having to do. As I said, I always shadow PORTC and TRISC on all 8 bit PICs and shadow ALL ports on non-LAT parts.

    Whether and what issues persist on newer non-LAT parts, I couldn't tell you. I do find it telling that enhanced-midrange and the newer low-midrange (10F320) are getting LAT registers. Finally.

    INTCON is another register that has had problems. Back in the day, you had to poll GIE after you bit-cleared it to ensure that between the r-m part of the r-m-w the part didn't get interrupted, reenabling GIE at the end of the interrupt service. Then there was the 17Cxx one where clearing GIE with pending interrupts caused an interrupt to the non-existent vector 0000h. *Kaboom* That's why I take a brute force approach to ALL r-m-w.

    YMMV.
     
    Last edited: Apr 1, 2014
  7. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    So why would you think every glitch makes it to the data sheet?
     
  8. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,019
    ErnieM likes this.
  9. John P

    AAC Fanatic!

    Oct 14, 2008
    1,632
    224
    Thank you, JohnInTX. It' worth confessing a little ignorance to pick up some interesting facts like those!

    I did a search of the SSP Module Overview in the instructions for the PI16F690 and looked for anything of a similar kind. The first thing I saw was this note that actually applies to SPI mode, not I2C. I've managed to avoid using I2C on a PIC except once as master with an external EEPROM, but I am contemplating a design with a PIC as an SPI slave, so it's more of a concern.

    When the SPI is in Slave mode with SS pin control enabled (SSPM<3:0> bits of the SSPCON register = 0100), the state of the SS pin can affect the state read back from the TRISC<4> bit. The peripheral OE signal from the SSP module into PORTC controls the state that is read back from the TRISC<4> bit (see Section 17.0 "Electrical Specifications" for information on PORTC). If read-write-modify instructions, such as BSF, are performed on the TRISC register while the SS pin is high, this will cause the TRISC<7> bit to be set, thus disabling the SDO output.

    I didn't see anything about the effect you mentioned in I2C mode, but you say that's not well documented anyway. However, it seems that the output lines are controlled via the TRIS register in I2C mode (because they are open drain, I assume) so I can imagine that there's room for trouble. Thanks for pointing this stuff out.
     
  10. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,019
    JohnP: Your excerpt on the SPI/SSP is a perfect example of how easy it is to be uninformed on the subtleties of r-m-w. I read that excerpt as a red flag. Others might not if they haven't been bit by it or have the perfectly reasonable expectation that the documented way to flip bits in a register won't cause program or peripheral failure. But I know that it can, and now you do as well.

    uCHIP contributes to the problem, couching the root issue by describing specific cases - add a couple of NOPs between consecutive outputs, use delays after driving capacitive loads, watch SS/ in the SPI slave and on and on. Accordingly, there are still those who insist that its all related to the external design (see ErnieM's link) and refuse to acknowledge reality which is SHADOW.THE.STINKIN'.PORTS. We can't help those guys but I'm glad that we could help you.

    Good luck.
     
  11. MrChips

    Moderator

    Oct 2, 2009
    12,414
    3,353
    Hi John. I admire your loyalty to Microchip PICs. I found so many holes in the design that I abandoned them many years ago. I contacted them on occasions about bugs in their hardware and as far as I know they never corrected them.
     
    JohnInTX likes this.
  12. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,019
    Thanks, Chips. I frequently wonder about that myself and understand your position completely. At least I know where most of the bodies are buried so have a leg up on most users but it does take the fun out of it sometimes.

    As it happens, my client base is Microchip-based for the most part, many originally referred to me by Microchip. It would be hard to kick them to the curb by not offering continuing support.

    A good practical reason, I suppose, is that once developed and deployed, PICs are just bulletproof. That and the fact that uCHIP keeps making even the old PICs makes the clients happy. Sometimes too happy. I've been trying to move a few onto better and much cheaper parts but many won't budge off what works for them. That means that I have to maintain the old emulators and such.

    That said, I have gotten to the point where I won't entertain any new projects using midrange. An 18F or better can almost always be used, even if it costs a few pennies more.
     
  13. MrChips

    Moderator

    Oct 2, 2009
    12,414
    3,353
    About ten years ago we had a spurious behavior with an OEM product. I had to reverse engineer the product and code in the PIC chip and narrowed the problem down to the way interrupts were being handled. I don't recall the exact problem but it is buried in my notes somewhere.

    I have some embedded products using PICs and my clients keep requesting them which I gladly keep supplying.
     
  14. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    5,435
    1,305
    Just wait until you get hardware faults in the PICs!

    I have one product where one out of every 20 or so PICs has a hardware memory fault. No amount of full erasing or reprogramming can fix the bad chip, it's always bad. And the other 19 are always perfect.

    Fortunately we have a failsafe way to test the PICs and just discard the bad ones. It doesn't increase the total chip cost much throwing out 5% of them, and the client doesn't want to reengineer using a different PIC.

    The problem exists on every batch they buy of that PIC, over years now, even buying from different vendors, with different manufacture date codes etc. It must be a bad spot on the main fab artwork on one chip, so when they etch the silicon one PIC out of 20 on that wafer is always a bad one.

    And even to this day it is not listed on the errata document for that PIC.
     
    JohnInTX likes this.
  15. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    Good lord, extra testing, product going from incoming to the dumpster, plus the sneaking suspicion one day some will sneak out to production (or customers!) anyway.

    Why not buy a batch from Microchip them selves, then return the rejects AND demand corrective action reports. Rinse, wash, repeat until they actually fix the problem.

    What part is this so I can avoid it?
     
    JohnInTX likes this.
  16. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,019
    +1. WooHoo! I've not encountered such a repeatable issue but would get with uCHIP pronto. They should be able to get you good parts. In cases like this, you can also request a specific part number for the screened chips. This PN is assigned to you directly to avoid confusion in purchasing.

    You didn't say who the vendors were but I'm with ErnieM, buy direct, screened with your own PN. Franchised distributors will also handle custom PNs through uCHIP.

    Let us know what happens and what PIC is it?
     
  17. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    5,435
    1,305
    Hi Ernie, I'm not at liberty to say too much about the issue or which PIC it is. I will say it is an 18F series part.

    There's no "extra testing" or throwing product out, it's a through hole part so the client always tests the PIC after programming and before soldering. And there's no bad ones that can sneak through, the bad ones always test bad on every test and the good ones are always perfect. There's no "if" or changes over time. That's why I mentioned it, it is so cut and dried hardware fault.

    All batches are bought from Microchip themselves, as far as I know. They are bought from Mchip australia or an Asian Mchip branch for slightly cheaper pricing. These are original Mchip PICs bought through Mchips distribution channels.

    The decisions are not mine, they are up to the client. There's no reward to me for being Mchip's unpaid quality control officer on someone else's product.

    And Mchip have shown me ZERO appreciation for the great many years I have used and promoted thir micros. :)

    Sorry, I'm not allowed to say. I don't even know the exact nature of the hardware fault other than writing to lowRAM locations seems to trash some high memory locations. I'm sure it has something to do with the RAM paging but I don't know if writing to the low RAM writes to the high RAM instead, or, if writing to the low RAM writes to the high RAM as well. My test does not determine which.

    That is as much checking as was done; devising a RAM test procedure to show if the hardware RAM error exists or not, and the test is 100% reliable.

    Of course you may have used that PIC, and never used those high RAM locations, or you may have bought some of the 19 out of 20 which did not have the fault.


    What happens is for years the client programs the PICs, runs the test, and throws out roughly 1 of 20 PICs. And will continue to do so. ;)
     
Loading...