Analogue Interrupts (IOC)

[Docara]

Hi

Looking at the data sheet you can have an Interrupt via the analogue comparator - I would like to do the equivalent of a IOC on an analogue pin - how do you do it in FC?

Thanks

[Benj]

Hello,

There is an example here that should help.
http://www.matrixtsl.com/wikiv7/index.p ... -_PICmicro

[Docara]

Hi Ben,

Thanks for the reply.

Couple of questions-

From the link you specified:-

INTCONbits.PEIE = 1; // Enable peripheral interrupts

INTCONbits.GIE = 1; // Enable global interrupts

PIE1bits.CCP1IE = 1; // Enable Capture Compare interrupts

Now, does all the 'Enabling' still have to take place if I am using other interrupts within FC? If I'm using, say, IOC pins already do I still have to enable global interrupts within the C code box
Do I have to disable interrupts at the end on the box
Where does this C box reside within FC chart

In short how do you integrate additional code within FC so both play nicely.

Thanks

[Benj]

Hello,

Add an interrupt icon into your flow chart where you want the comparator interrupt to be enabled. Go into the interrupt icon properties and select the Custom interrupt type. Go into the custom interrupt properties and you can then enter the enable and handler code.

does all the 'Enabling' still have to take place if I am using other interrupts within FC?

No not strictly, if the GIE and PEIE bits have already been set by another interrupt being enabled then you don't have to do it again.

Do I have to disable interrupts at the end on the box

You only need to fill out the disable section if you want to switch off the comparator interrupts. To do this you would add a second interrupt icon where you want the interrupt to be disabled, this time set the properties to disable and then fill out the custom Disable Code section.

[Docara]

Hi Ben,

Aargh I see!! so it really is that flexible!!

I have been following a lot of examples here and everyone seemed to put their interrupts etc at the beginning and I thought it was an idiosyncrasy with FC.

So a follow on question, I think I know the answer, can I take from you answer then that there wouldn't be any issues with FC if an interrupt were enabled 2/3/4 times? (so I could cut and paste code without worrying too much)


Does one need to consider any 'housekeeping' or good practice tasks that need to take place if C code is used within a FC chart?

as an aside, a problem with FC is that because it is such a high level language, arguably crappy coding practices can be tolerated. One of the many things I struggle with is the order and sequence of icons to produce efficient code. Perhaps a good (lengthy) video in this area might help a lot of people to structure their programs to get the most out of FC.

Thanks again.
Matt

[Benj]

Hi Matt,

can I take from you answer then that there wouldn't be any issues with FC if an interrupt were enabled 2/3/4 times? (so I could cut and paste code without worrying too much)

This is fine as long as you always use the same Flowcode macro. Using different macros each time you enable the interrupt will not work.

Does one need to consider any 'housekeeping' or good practice tasks that need to take place if C code is used within a FC chart?

Just note that it won't simulate, other then that it should be fine to use C or ASM where ever you see fit.

as an aside, a problem with FC is that because it is such a high level language, arguably crappy coding practices can be tolerated. One of the many things I struggle with is the order and sequence of icons to produce efficient code. Perhaps a good (lengthy) video in this area might help a lot of people to structure their programs to get the most out of FC.

This is a big topic and from my experience takes practise to do well.

A key point is to try and use macros to do anything where you are repeating code in multiple places or want to tidy up a specific function into a single icon. Using local variables can also help a lot in terms of making things more readable and obvious.

I often find that you create a program and then once it is working you can re-visit the code and improve the functionality and efficiency. I have re-written the code for my propeller display about 4 or 5 times now for different micros and each time I did I found massive efficiency boosts by subtly changing the way things worked.

One key failing is to make things too clever which can make it hard to follow, through to down right incomprehensible, if you're being clever in your coding to save instructions etc then be sure to add a good comment as to why. A lot of people use comments to describe the "what" but the "what" is usually obvious it's the "why" that can be hard to understand after being away from the code for a while.

This is one of my more complex recent projects so you can kind of see the way I generally tend to structure programs. I've been writing a lot in Java recently so this may have started to swing the way I do things.
http://www.matrixtsl.com/mmforums/viewt ... 60&p=78619

Here's an even bigger microcontroller project in Flowcode.
http://www.matrixtsl.com/mmforums/viewt ... 371#p73371

Epic Java project.
https://plus.google.com/communities/115 ... 4809347973

[Brendan]

I can sooo relate to Ben's 'key points'.

I've started off being 'too' clever with unnecessarily modular code (with many macros) in the past, only to sorely regret doing so as the code developed with later changes necessary. On one occasion, it got so confusing that I threw the source away and started again (four 128-bit banks of cascaded read and write shift registers, plus bits shifted into DACs in big chains).

Besides choosing associated variable names that will naturally group alphabetically (e.g. RS232_RxString and RS232_TxString, in preference to RxString_RS232 and TxString_RS232, for example), another trick I've used is to precede names with one-or-more underscores to force groupings of associated variables in lists - such as those that are candidates to become locals in macros at a later stage (etc). The golden rule is carefully considered organisational planning from the outset.

I've also long-since realised the value of verbose 'what and why' commenting, essential for educational mentoring.

All the best,

Brendan