Printable View
16F18877
Any idea why it would do that?
The PIC is running normally, and then the IOC flags get set when I pull the USB cable on the MeLabs programmer (or unplug the header).
I know my encoders can jitter, but I'm not even touching them.
EDIT: My configs for brown out in case it helps:
Code:_BOREN_ON & _BORV_LO
i guess it begs the questions
what ioc flags were triggered ?
what pins had any ioc functions active?
These, at random.Code:IOC_COM1_Swap_flag var IOCAF.4
IOC_COM2_Swap_flag var IOCCF.1
IOC_NAV1_Swap_flag var IOCBF.5
IOC_NAV2_Swap_flag var IOCBF.2
Only IOC was used, no other peripherals used on these pins.
I tried external pull-ups just now, in case the internal were just borderline, but that didn't make a difference.
EDIT: Using this wiring:
Attachment 9750
These are pushbuttons, not rotary encoders with wonky shafts that can jitter whenever the cat farts.
I'm certain it has something to do with voltage levels as the PIC loses power.
IOC flags are randomly triggered when VDD is cut with a switch, but not on MCLR.
Values are READ from DATA at PIC start-up. IOC flags on pushbuttons are used to swap values left to right, then WRITE back to memory.* By the end of the video, all values have swapped places without pushing any buttons.
https://www.youtube.com/watch?v=qdepvGAJCRs
Ceramic bypass/decoupling capacitors are often better .
a particularly bad practice, you should always check that it was an actual keypress [ in that was held for a definitive time] before actioning itQuote:
IOC flags on pushbuttons are used to swap values left to right, then WRITE back to memory
key activity should be ignored until power is stable
I have 0.1uF on VDD/VSS pins, 0.1uF on the switch input pins and 0.01uF on the encoder input pins; all ceramic caps.Quote:
Originally Posted by richard
That's what the IOC flag was used for; to check if a button was activated. If I'm going to have to check if a key has been pressed, IOC is of no advantage to me. I didn't understand why you guys were not in favour of using IOC for this, but now I'm understanding a lot better why it wasn't good idea.Quote:
Originally Posted by richard
I've already gutted the IOC code and I'm checking the pins for change in value. Those 4 SWAP buttons were the last ones, and then I noticed things were going wacky with my stored data.
I always have at least PAUSEUS 200 at program startup. I have no idea how to check if power is stable on shut-down.Quote:
Originally Posted by richard
I've given up on the 16F18877; I had switched to these for IOC, internal pull-ups and Schmitt Trigger features. But they're much more finicky than a 16F1937 with external pull-ups, 74HC14 ICs and just polling the pins in MainLoop.
The 16F1937 is like a tank; less fancy but it keeps on trucking.
That is a false assumption, all the IOC flag says is that a edge was detected, you need way more info to determine if it was a valid key press, at a minimum you need to know if its still "active" and if it was "active" for a reasonable time. no simple hw debounce solution will do all the workQuote:
That's what the IOC flag was used for; to check if a button was activated.
don't forget a 0.000000025S [thats 25nS ] pulse can trigger an ioc event , would you call that a key press
how about 25uS what about 1mS , for my money i would ignore anything less than 50mS
glacially slow for a Pic@32MHz
ps , switches on long leads and breadboards are potentially difficult cases also
I know that now.Quote:
Originally Posted by richard
The 74HC14 with Bourns' debounce was doing very well. I'm rewiring that back in now to redo testing.Quote:
Originally Posted by richard
I'll post results when I have everything back up and running. It was surprisingly stable before I migrated to a 16F18877.Quote:
Originally Posted by richard
Switches and encoders are all mounted on headers, same for power jack, USB connector and 7805.Quote:
Originally Posted by richard
The only leads for switches will be from 74HC14 to PIC, and I keep those on 2 breadboard area maximum. The only PIC with long leads is for the LCDs.
The USART leads (in white) will branch out from the USB PIC out to the SW and ENC PICs (the END lead is 5in straight line, so about 6in when strung out).
Attachment 9751
to get away from all the needless 7416 chips plus the flexibility of pps as a bonus https://www.picbasic.co.uk/forum/images/icons/icon7.pngQuote:
It was surprisingly stable before I migrated to a 16F18877.
That was my original goal, to reduce cost, complexity and real estate.Quote:
Originally Posted by richard
I gotta admit, PPS, was a neat bonus. I was truly impressed with the 16F18877.
I would not give up on the 18877 chip. Sometimes the view seems great but has pitfalls and all you need is to sleep on this. Next day will come the aha moment!
Ioannis
Yeah, I'm giving it another shot cause I need a PIC with ADCON. I just find it so finicky, so many registers to set JUST RIGHT.Quote:
Originally Posted by Ioannis
Ioannis, guess what...
https://www.picbasic.co.uk/forum/sho...-on-input-pins
I found the root of most of my problems with this PIC. :biggrin: