Matrix user forums

I am using Flowcode v5.5.2.1 and trying to set up a rising edge interrupt in any port in a dsPIC30f4012 or dsPIC30f4013 and flowcode just allow me to select both edges or none.
Is there something I am missing??

Hi r_romeo,
Have you had a look at this:
http://www.matrixmultimedia.com/mmforum ... 462#p49246

You can import flowchart to your version of V5 Flowcode

Martin

Thanks Martin, I actually was wondering if rising, falling and both edges were available in all ports , I am guessing in just some, from some microcontrollers, I didn't taught this macro depends on hardware
Is this right ??

Hi r_romeo,
The port interrupt macro will be dependent on microcontroller hardware.
This is because there are microcontrollers that will have an internal register allowing to set for rising or falling edge.
Flowcode will allow you to select which pin and edge causes interrupt to be triggered.

Other microcontrollers do not have such a register, so port interrupt will work on both rising and falling edges.
To determine which edge has been triggered has to be done in the software.
In this category some microcontrollers allow to select which pin causes interrupt to be fired on both edges, other microcontrollers do not even allow you to select which pin, therefore Properties of interrupt will be greyed, so only software can be designed to determine which pin and edge caused interrupt to fire.

Hope this makes sense.

Martin

Hello guys!
I found myself pulling hair and scratching my head over the same obstacle of how to properly select the edge on which interrupt occurs within 12F675 micro. When I set an INT on PORT, there is only option to either select or unselect pins, which triggers INT on both edges. However there are options shown in pop-up window (Interrupt properties - select Pin(s)) indicating three types of trigger and denoted by colored squares Green(both edges) Red(rising edge) and Grey(falling edge). I am confused of how to utilize those options properly or if there is a trick I should know of.
If you could comment on this situation I 'd be much obliged.
Thanks.

Hello again,
I looked in the datasheet and found something that could explain the complexity and/or difficulty of what I am trying to achieve.
The link to the datasheet is here:
http://ww1.microchip.com/downloads/en/d ... 41190c.pdf
Please look at the page 14. It says that INTEDG (Interrupt Edge Select) bit is only effecting GP2 or maybe I am under wrong assumption... Could you clarify, please? I am no expert at interpreting datasheets unfortunately and no expert at how internals of the micros work in deep details...
Thanks a bunch.

Hi 1Handypal,
INT interrupt component (pin GP2 so your correct!)
Is not the same as port interrupt on change.

INT has the function to select which edge fires interrupt on, so for that you will need to drag an interrupt component, then select interrupt in INT, then you will need to select rising edge or falling edge.

As for the port interrupt, you will need to select interrupt on port.
With the 12F675, you can only select interrupt on both edges or no edges at all!
As previously explained, the flowchart will have to be setup to detect if rising or falling edge is detected ,since interrupt will be triggered on both.
At least with 12F647 pin selection of port interrupt is possible.
With some older devices, you can't choose which IOC pin has triggered interrupt. so this will also have to be done within software.

Hello Medelec35 and all,
You are as helpful as always has been.
I will keep playing at it.
Thanks for your support!

One thing I have tried to prevent triggers on negative edge is to introduce a significant delay within int. routine. Of course this would not be a preferred way and may cause undesired effects. Could you suggest a more elegant way or give example based on my above posted file?

Hi 1Handypal.

1Handypal wrote:Hello Medelec35 and all,
You are as helpful as always has been.

Thank you
I have altered your Flowchart to only work on GP3 falling edge.
You will nee to remember that that interrupt macro is accessed every time an input is changed.
The secret is to have an input icon to read the state of the GP3 pin, then only act if it's low.
If you have any issues, then interrupt could be firing when detecting contact bounce.
If this is the case then simplest way is use an additional resistor and capacitor:
http://www.zen22142.zen.co.uk/Design/debounce.htm
The alternative is to use a small delay within interrupt macro.
I personally would only use that method if no timer interrupts are used, since while in the interrupt macro, all other interrupts are disabled, until interrupt macro is exited.

This thread maybe useful:
http://www.matrixmultimedia.com/mmforum ... =7&t=12462
since I have posted a flowchart (Bills_leel V1.2) that ignores other IOC pins changing state (except for the only pin interested in).

Martin

Thanks Martin,
And yes, this way works too, confirmed on hardware. The only problem is likely my button is bouncing too much so it's picky sometimes and causing the system not to go into a proper mode.
Now I am trying to avoid using any delays in my flowchart, if I can. Rather use some tricks with timers. For my purpose It is probably better to use polling with trap to read button reliably to avoid false triggers. It seems that interrupt does it way too fast.
Thanks for your support.
Best.

@Martin
Oh, forgot to ask... Did you mention 12F647 and it was not any typo? I found it hard to find part...

1Handypal wrote:@Martin
Oh, forgot to ask... Did you mention 12F647 and it was not any typo? I found it hard to find part...

Yes sorry was a complete typo. I did mean 12F675.
I'm sure sometimes my fingers work independently to my brain, and ignore it some times

@Martin
True enough, same as mine, but I try to perfect myself and be more disciplined as this subject requires attention to details
No problem at all.
Fun all it is !

Hi 1Handypal,
Sorry getting ready for work, so not got time to change to using timer interrupts.
But I have thought of a simple way round issue of a very bouncy switch.
Have a look at attached flowchart. you could try it on your hardware to see if it works

I will post a version using timer interrupts for timing of seconds tonight, and see if you prefer that method?

Martin

Edit: did not see your post as I was typing this post at the same time:

1Handypal wrote: Fun all it is !

I would agree with that

It is pretty late in here. I have to switch myself off and GO TO SLEEP mode.
Thanks for all your input and nice comments. My eyes are shutting down...
Later.

Hi 1Handypal,

I have altered your flowchart to be much more responsive with timer0 interrupt controlling LED's
As soon as you press and release the switch, you should get an instance response and sequence should start at the beginning, no matter what LED is lit or not lit.
These Flowcharts should also take into account contact bounce. I have allowed 20ms for V1.3 (using a delay) and 30 ms for V1.4 not using any delays.

None of the flowchart have been tested on hardware.
Note: Simulation time will be much slower than real time!


Martin

@Martin,
Thanks for your smartly designed flowchart, great example. It is much appreciated and was quite educational for me. I tried to use similar techniques and it actually worked well in hardware.
For now I stick with edge detection within ISR, which gives acceptable results. I discovered another problem in my hardware, being that of inrush current making my power source briefly go down when a load is turned on. It happens briefly and is hardly seen, but makes things go south... Otherwise all is well.
I have another hobby project, which would be a separate thread... Until then I remain thankful.
Cheers.

1Handypal wrote:Thanks for your smartly designed flowchart, great example. It is much appreciated and was quite educational for me.

No problem and your welcome.

1Handypal wrote:For now I stick with edge detection within ISR, which gives acceptable results.

Confused by this.
All the flowcharts posted (including the last two) only work on negative edge detection within ISR Macro.

1Handypal wrote:I discovered another problem in my hardware, being that of inrush current making my power source briefly go down when a load is turned on. It happens briefly and is hardly seen, but makes things go south

I had a similar thing occurred to me. My hardware did not work as expected.
What I did to find out what was going wrong, was to use RS232 as a diagnostic tool.
Every second the total runtime in seconds + any variable I was interested in was send via one pin & GND to UART to USB converter.
I was running Hyperterminal since that was not only displaying values I was interested in, it was also logging to a text file, so I can look back at the history of events,
I discovered that runtime kept resetting to 0 when there was heat demand as hardware operated a relay, which operated a diverter valve. Placing a 100nF mains rated x cap across the relay contacts cured that.
Would have been difficult to find without RS232 sending data.
I used software mode for RS232, as I use the same pin for programing (ISCP Data) as I do for sending out RS232 data. UART to USB converter is just connected across data and ground connections. It simplifies the hardware.

Martin

Hello all,
@Martin. I ended up introducing a 1sec delay into IOC routine along with level check to see if zero. Now it is the way I wanted it to work with no glitches whatsoever. Otherwise, the interrupt way is super sensitive and quick, I had to slow it down. I also introduced a bit of smoothing and RC delay to the button circuit, which further improved noise immunity of the button input. Before it would stop working normal altogether with RC circuit and was prone to false triggers from nearby dishwasher when in use. I am happy now and have learned something in the process.
New projects await
Best to all.

Hi 1Handypal,
Glad your hardware is working the way you want it to work.
Whats even better is learning!
The I want to make more projects bug has set in

Good luck.

Martin