Edge Detection on a signal using Teensy 4.0

[BlueTurtle]

Hello everyone,

I'm trying to use digital potentiometer IC AD5293 (Datasheet, Page 8 Timing Diagrams) with my project and I was wondering how I can read the Ready signal go low without using interrupts to confirm correct operation of the part (other than measuring the resistance with a multimeter ofc ). I don't want to use interrupts because I don't want rest of the circuit to be effected if there is a problem with that Ready line. I'm thinking there *might* be a problem because I will be placing it near (though I will route signal traces away from switching lines) a buck converter cicruit on my board. Although certainly I hope it won't have any problems, this will be the first board I'm designing and want to take precautions.

Thank you very much for your time and answers.

 

[defragster]

Any general function summary info without going to the data sheet?

Is the ready line of interest only after each change? How often is a change requested?

Interrupts turn on and off easily. First try would be:
>> Enable interrupt on CHANGE perhaps LOW - but it may be low already from prior change?
>> Make change POT set POT_SET=change
>> in _isr() check for change:
-- if LOW indicating ready, set a flag POT_SET=ready, disable interrupt.
-- If HIGH not ready - set POT_SET=not_ready leave _isr() to fire again when it drops.

 

[BlueTurtle]

Any general function summary info without going to the data sheet?

Is the ready line of interest only after each change? How often is a change requested?

Interrupts turn on and off easily. First try would be:
>> Enable interrupt on CHANGE perhaps LOW - but it may be low already from prior change?
>> Make change POT set POT_SET=change
>> in _isr() check for change:
-- if LOW indicating ready, set a flag POT_SET=ready, disable interrupt.
-- If HIGH not ready - set POT_SET=not_ready leave _isr() to fire again when it drops.

Hey!
Sorry yes you are right we don’t need to dive into datasheet. Ready is normally high and for one cycle it is pulled low to indicate that the write is successful and it is pulled high again by the IC. I haven’t used interrupts before but definitely disabling it would work. Will look more into interrupts. Thank you!

 

[defragster]

some variation of post #2 should work then. Will need appropriate logic - using some status flag a volatile variable ' POT_SET ' to track change given the IC action forcing it … per the datasheet

If the POT puts it 'high one cycle' - then catching that would be best with interrupt - going HIGH says it saw change request, then going LOW says it was completed. Leaving int _isr() on when HIGH for it to drop LOW until ' pulled high again by the IC ' would make sure it isn't missed. And disable of _isr() when LOW seen will confirm in loop() or other code that the last change was made.

Good luck. If you get a simple test working it would be fun to see the code.

Some time back I've posted example code that had a GPS sending messages. I set interrupt on the Rx UART line to know when the message transmit started to log the TIMESTAMP. The _isr() would disable itself - and when the GPS message receive was complete, it would enable the _isr again for the next message. It was effective and the _isr() was disabled otherwise bit transitions would hit the _isr() a couple times per byte. Not sure how to find that with easy search - it was on a UNAV thread that has been dormant some time

Look here :: forum.pjrc.com/threads/48450-uNav-AHRS

The pin to interrupt isn't needed - but works out the same just given pin number to watch.

 

[BlueTurtle]

some variation of post #2 should work then. Will need appropriate logic - using some status flag a volatile variable ' POT_SET ' to track change given the IC action forcing it … per the datasheet

If the POT puts it 'high one cycle' - then catching that would be best with interrupt - going HIGH says it saw change request, then going LOW says it was completed. Leaving int _isr() on when HIGH for it to drop LOW until ' pulled high again by the IC ' would make sure it isn't missed. And disable of _isr() when LOW seen will confirm in loop() or other code that the last change was made.

Good luck. If you get a simple test working it would be fun to see the code.

Some time back I've posted example code that had a GPS sending messages. I set interrupt on the Rx UART line to know when the message transmit started to log the TIMESTAMP. The _isr() would disable itself - and when the GPS message receive was complete, it would enable the _isr again for the next message. It was effective and the _isr() was disabled otherwise bit transitions would hit the _isr() a couple times per byte. Not sure how to find that with easy search - it was on a UNAV thread that has been dormant some time

Look here :: forum.pjrc.com/threads/48450-uNav-AHRS

The pin to interrupt isn't needed - but works out the same just given pin number to watch.

Alrighty. Will take a look. I have another question though... I need interrupts for a switch, to know if someone opens the door while the device is working or wants to stop its operation. If I disable all the interrupts I wont be able to use another interrupt right? Can I specifically disable one interrupt and not the others?

 

[BlueTurtle]

some variation of post #2 should work then. Will need appropriate logic - using some status flag a volatile variable ' POT_SET ' to track change given the IC action forcing it … per the datasheet

If the POT puts it 'high one cycle' - then catching that would be best with interrupt - going HIGH says it saw change request, then going LOW says it was completed. Leaving int _isr() on when HIGH for it to drop LOW until ' pulled high again by the IC ' would make sure it isn't missed. And disable of _isr() when LOW seen will confirm in loop() or other code that the last change was made.

Good luck. If you get a simple test working it would be fun to see the code.

Some time back I've posted example code that had a GPS sending messages. I set interrupt on the Rx UART line to know when the message transmit started to log the TIMESTAMP. The _isr() would disable itself - and when the GPS message receive was complete, it would enable the _isr again for the next message. It was effective and the _isr() was disabled otherwise bit transitions would hit the _isr() a couple times per byte. Not sure how to find that with easy search - it was on a UNAV thread that has been dormant some time

Look here :: forum.pjrc.com/threads/48450-uNav-AHRS

The pin to interrupt isn't needed - but works out the same just given pin number to watch.

https://forum.pjrc.com/threads/58193-Port-Pin-Edge-Detection I think this will do for my purposes. Will report back when I have it working

 

[defragster]

Alrighty. Will take a look. I have another question though... I need interrupts for a switch, to know if someone opens the door while the device is working or wants to stop its operation. If I disable all the interrupts I wont be able to use another interrupt right? Can I specifically disable one interrupt and not the others?

Only a single pin interrupt is involved. Interrupts are never disabled in the indicated code. Only the Teensy response to a pin change is enabled or disabled.

The other code may work to good effect for the purpose at hand - but the indicated code does not have any problematic side effects.

 

[defragster]

Also that code is for T_3.2 - hopefully the same refs work on the T4 in use.

Also will have to be aware still of the IC AD5293 behavior of forcing the pin and making sure to check and clear at the right times as it will go from HIGH to LOW to HIGH in some fashion. And after the change will be held only 'one cycle it is pulled low' then go HIGH again.

That will involve some degree of timed polling - though in the end if it is HIGH that is all that matters - although the _isr() method would allow knowing it went to low after the requested change before returning high. That would be confirmation that the change command was processed that could be missed given two changes in short order.