PDA

View Full Version : IOC on the 27k40



longpole001
- 30th July 2018, 07:29
Hi guys

The IOC options on this chip are very good , with both neg/ pos trig selection on most of the ports

The dt_int18-34c currently does not appear the clear IOCxF bits after being trigger even if the flagreset is set



ASM
INT_LIST macro; IntSource, Label , Type, ResetFlag?
INT_Handler IOC_INT, _Rx_mode_IOC , PBP, yes ; Call Rx_mode_IOC subroutine for RF RX_mode

endm
INT_CREATE ; Creates the Interrupt Processor
ENDASM


also enable/disable of IOC " @ INT_DISABLE IOC_INT " ( PIE0.4 = 0) , will not stop the IOC interrupt being set on the IOCxF

the triggered IOC port flag bit needs to be cleared after the interrupt is serviced - eg IOCxF.x = 0

this what i found for my 27k40 silicon 0 ,

but if i am wrong please check and correct me

cheers

Sheldon

mpgmike
- 30th July 2018, 18:06
First, you get a PIR0.4 generic IOCIF that's read only. Second, you also get an IOCAF/IOCBF/IOCCF.PortPin flag that indicates either an IOCAN or IOCAP type flag (since you can use either). the PIR0.4 flag automatically clears when IOCxFs = 0. With that said, you can clear the flag manually in the ISR. If you got IOCAF.2 (RA2 changed state according to your IOCAP/IOCAN Registers), at the end of your ISR add IOCAF.2 = 0 (PBP3). If you are using an ASM ISR, BCF IOCAF,2.

"16.1 Enabling the Module
To allow individual port pins to generate an interrupt, the IOCIE bit of the PIE0 register must be set. If the IOCIE bit is disabled, the edge detection on the pin will still occur, but an interrupt will not be generated."

That being said, we're getting more familiar with how the K40 chip & Data Sheet don't always agree. You could clear the IOCxN/P in the Register to disable IOCIE if PIE0.4 = 0 fails to work.

longpole001
- 31st July 2018, 02:29
yes your correct, in that i could have turned off the IOC port trigger in neg or Pos , which ever was set , but the main toggling the IOC enable wont work as prev k22,k80 where it will stop the IOC being registered on k40 ,

as i am porting code from k80,k22 where the enable / disable of IOC is in many places in code , so having to ensure the IOCxF is cleared where i am disable/ enable, this stops a not required jump to the ISR to clear it , requires a bit of work

its just another step to do on the k40, as there is no main clear of the all IOCxF registers that i can see so far except by manual clearing,
nor a way to ensure a globle enable / disable that ensure that IOCxF wont register a change , after being setup in the IOCxN, IOCxP triggers

only a globle IOC status if triggered in in PIR0.4 as you pointed out in

that said with the flag set on the which IOC was triggered in each port, and if it was negative or positive , you can have a nice branch system for each IOC or group of IOC, possible in the ISR where it was not so great in the k22, k80 IOC system

sheldon

mpgmike
- 31st July 2018, 12:28
You can clear most flags from anywhere by:

IOCAF = 0
PIR1.5 = 0
...etc

Flags for UART require reading the RC1REG to clear the flag, but they are in the exception category.

longpole001
- 5th December 2019, 04:23
hi mike ,

has there any further updates to the int-18-k40 v3.4c


regards

Sheldon

mpgmike
- 6th December 2019, 16:54
Sheldon, lately I've been using XC8 in MPLABX. I fell madly in love with the PIC16F18426 and have used it for a couple projects. Because it was so new that PBP3 didn't yet cover it, I forced myself to get functional with C & MPLABX. I haven't used PBP in a project in about a year now. In fact, I'm using dsPIC33's in projects now that I have the tools. I personally don't have any updates.

Ioannis
- 6th December 2019, 17:07
Well, what is it on that chip that is special?

You are brave enough to tame that beast called MPLABX!

Ioannis

mpgmike
- 6th December 2019, 17:31
Well, what is it on that chip that is special?

- 12-bit ADC2
- 4/4 Timers
- 4 CCP & 2 PWM
- EEPROM
- 20-bit NCO
- PPS
- 4 CLC

I've used it in a couple projects. In one, I needed many PWMs but with PPS where I could swap output pins. In another, I needed the 12-bit ADC, EEPROM, and ALL of the Timers. In another I needed the EEPROM, NCO, PPS, and CLC combo.

In other words, I have found a couple projects where this was the only PIC 8-bit offering to include ALL of the peripherals I needed all in one package.

Having used MPLABX for over a year now, it's like learning anything; the more you use it, the more it just becomes natural. Microchip offers online tutorials to help us learn a wide range of skills regarding their MCUs and tools at:

http://microchipdeveloper.com/training-self:start

I started with PICAXE and believe me, learning the necessary building blocks just to program anything was a long steep hill. After I got proficient with PICAXE I realized I was throttling myself. The PICAXE chips are just PIC chips with a boot loader. However, that limits the capabilities of the chips, and slows them down. With that said...

I saw an ad for PBP3 Basic in Nuts & Volts Magazine. I checked it out and liked what I saw. This opened the entire line of PIC 8-bit MCUs to me, and I could have full control over their functions. I bit & bought. Though it might not seem like such a leap, it took me several months of playing with PBP to get comfortable enough to start using it in my projects. After awhile, I forgot the idiosynchrocies of PICAXE (would have to relearn again).

As for MPLABX, I had been using ASM in many PBP3 projects, so I created a simple ASM project in MPLABX. Once I learned the nuts & bolts of the IDE, I bought a couple books and started learning how to get the job done in XC8. I still only know a fraction of the capabilities of the C programming language, but at least I'm functional. I probably do many things the hard way.

It boiled down to "What is important to me?" "What price am I willing to pay to get what I want (need)?" Then make it happen!

Ioannis
- 6th December 2019, 21:37
Very nice!

Recently I was testing the 16F19176 chip. It has almost all of what you referred except NCO and is also supported by PBP.

I tried many times to take the leap to C but things stopped me(urgent projects, little time etc).

Maybe one day...

Ioannis

longpole001
- 7th December 2019, 02:25
yes i have also fallen in to the trap of using the pic chip that i know or limiting it selection to what PBP supports and also knowing it faster to do it in PBP than to start it in C where i am not as good at it

but the limits of PBP are always nagging me to move on to C permanently and the ability to port to large chips is major factor to drop PBP

8bit chips are so full of features but limited to 128k is major pain at times
richard reminds me is PBP is not great at many things and asm use is key routines are its major benefit

congrats on moving forward on c and MPLAP X

mpgmike
- 8th December 2019, 16:28
I design controllers for a living. It therefore behoves me to learn whatever is necessary to deliver the best product possible. I never went to school for programming, electronics, or anything else specifically tied to designing controllers. Out of necessity, I bought some books & started to learn basic analog electronics a tad over a decade ago. I designed several controllers using only analog ICs and quickly realized I was limiting my abilities without diving into the microcontroller realm. I then bought more books and learned to work with PICAXE.

Fast forward a few years, I usually read in the evenings as opposed to watching TV (we don't have cable or a dish). I am always studying something new, usually related to my work. Without formal training, it invariably takes me longer to get across the finish line than it does others with the schooling. Fortunately we live in the age of the internet. There are wiki sites, YouTube, forums, and a plethora of other resources available, in additional to the traditional books. It took me 4 years to finally get a controller talking to a laptop via USB (and then only with the help of HIDmaker), 2 years to be able to talk to a car via OBD II (using ELM327). My meager virtue is that I don't give up. I persist until I conquer, no matter how long or difficult it may be.

Many on this Forum dabble in electronics as a hobby. During the day they may be working on cars, fixing HVAC, processing data at the local court house, or whatever... in other words, they don't rely on electronics or PIC processors for their daily bread. For them, it's easier to deal with limitations than to conquer new worlds. I chose my career and absolutely love what I do. I have no regrets. But I also don't have the luxurious option of taking time away to attend formal schooling. Therefore the ball is in my court.

Decades ago a mentor impressed upon me to either give it everything I have, or don't accept the challenge at all. It's better to give it my absolute best than a mediocre attempt. Always strive to be the best in my field. I respect anybody that is willing to tackle a new challenge, especially when they're not forced to do so. Those on this forum that use PBP3 as a part of their hobby do so voluntarily. Any efforts spent on learning new things are for their personal gratification. I respect them way more than the person that just goes to work, comes home, eats dinner, then flops on the couch in front of the TV.

Having taken the scenic route to express a point, the punch line is: "to each his/her own". As for learning XC8, until you actually make a decision -- I mean commit to yourself that you're going to do it no matter what -- it will always just be that elusive "some day...". Once you make that commitment, you will probably find that it isn't a matter of being hard, just a matter of taking the time to go through the normal process of learning something new. You already did it at least once if you're using PBP3. It wasn't hard, it just took time.

Ioannis
- 8th December 2019, 23:19
I agree with you although I feel that all this (MPLABX IDE, C etc) is a steep curve. Time keeps me away from this and I guess for others too. Hobby is another thing and a hobbyist may have all the time to experiment.

Also I fell quite confident to start a new project anytime, very fast, with the MCSX and PBP. In no time the PIC is up and running without any cryptic syntax. With known limitations though.

Ioannis

pedja089
- 10th December 2019, 10:13
For same reason I stick to PBP+MPLAB X. And in more than one case I compared very similar programs in C(and microC) and PBP, and PBP is by far smallest. So you can do more in smaller IC.

Ioannis
- 10th December 2019, 14:10
Well, this is a bit subjective matter. Every C compiler is not the same, also has levels of optimizations, and even coding style can affect the resulting hex code size.

In any case here and then, testings show that PBP produces very compact code.

If Charles could further improve PBP with maybe functions, GLCDs, local variables and of course updating with new devices could help PBP to survive and evolve.

It really is a very good and trusty compiler, with no libs as C or Arduino-I know, but giving the user the ability to do his job. Easy, fast and reliable.

Ioannis

Dave
- 10th December 2019, 14:28
I agree 100% Ioannis...