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?
I have another doubt also that,can we set TRIS register of any port in bitwise?
+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.Yes, you can set bits in a register bitwise - the TRIS register is no exception ( but be aware of RMW issues).
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: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.
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.23.1 Read-Modify-Write Operations
Any instruction that specifies a file register as part of
the instruction performs a Read-Modify-Write (RMW)
operation. The register is read, the data is modified,
and the result is stored according to either the instruction
or the destination designator ‘d’. A read operation
is performed on a register even if the instruction writes
to that register.
So why would you think every glitch makes it to the data sheet?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.
Ha! I caused some ripples with that one...
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.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.
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.J...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.
+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.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.
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.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.
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.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.
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.What part is this so I can avoid it?
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.JohnInTX said:...
Let us know what happens and what PIC is it?
Thread starter | Similar threads | Forum | Replies | Date |
---|---|---|---|---|
P | How ADC value stores inside ADRESH and ADRESL register for pic16f877a .. #2 | Microcontrollers | 1 | |
microcontroller pic16f877a | Homework Help | 1 | ||
T | ARDUINO CODE TO PIC16F877A CODE | Microcontrollers | 1 | |
A | variable delay in PIC16F877A | Microcontrollers | 5 | |
Hx711 interfacing with PIC16F877A | Microcontrollers | 2 |
by Aaron Carman
by Jake Hertz
by Jake Hertz
by Jake Hertz