Comparator External Connections

[SteveHx]

I am attempting to use the COMP section to build a relaxation oscillator. There appear to be a number of interactions between sections, some of which are subtly documented and some for which I find no documentation. For instance, the inability to set a GPIO output once a task is connected to a pin is documented but well-hidden. The fact that enabling a pin as a comparator input completely disables both digital inputs and digital outputs is not documented anywhere that I can find.

Bottom line is that I have everything working nicely as it should, except that the comparator sometimes appears to miss a transition and thereafter is hung. I fundamentally just need to be able to place the comparator output on a digital output pin, but the only way I can find to do that is via the crossing events from the comparator, feeding set and clr tasks of GPIOTE. This causes the same sort of problems as the early IBM PCs using edge-triggered interrupts: If you miss one, you're dead forever. Is there a better way to get the comparator output to appear on a pin? If not, how best can I initialize things to ensure that I don't miss a transition?

[bjorn-spockeli]

HI Steve,

SteveHx said:

Bottom line is that I have everything working nicely as it should, except that the comparator sometimes appears to miss a transition and thereafter is hung. I fundamentally just need to be able to place the comparator output on a digital output pin

Could you elaborate on what you mean by the comparator missing a transition? In my mind If the comparator misses a transition, then the output from the comparator would be unchanged so it would not help to output the comp output to a GPIO. 

Best regards

Bjørn

[SteveHx]

In essence I'm building a relaxation oscillator using the comparator. In my initial reading of the datasheet I missed the fact that it's apparently not possible to directly place the comparator output on an I/O pin, so I fell back to using the event / task / PPI mechanism. The transition event trips a task to flip the state of a GPIO pin. I a transition is ever missed, the output doesn't change state, and the oscillator therefore stops forever.

Fundamentally all I need is to be able to place the comparator output directly on an I/O pin. I know I could have firmware read the RESULT register and set a pin, but that's not feasible in my application. I have a stopgap solution whereby the firmware checks to see if the oscillator has stopped and gives it a kick start, but that's pretty messy and really not a good solution.

[bjorn-spockeli]

Yes, but my question was if there is a valid transition on the Comparator pin or not? IF there isnt, then is this transition is not detected by the comparator? If that is the case then outputing the comp output to a GPIO will not solve the problem. Or to you mean that the Comparator correctly detects the transition, but does not generate the transition event?

As far as I know there is no other way than using PPI and GPIOTE to output the Comparator output on a GPIO. 

[hmolesworth]

Very interesting post; we would like the same functionality for a similar purpose. Given that the crossing event (being edge-triggered) may be missed, is it possible to connect the Compare Result register (0x400) to the PPI, or is that denied to it not being within the Events register groupings? My suggestion is based on the fact that the PPI link could in theory be set to any register, but I haven't tried this. The datasheet states Pointer to event register. Accepts only addresses to registers from the Event group but that might be misleading and any register address could perhaps work .. The Compare Result register register looks like t is the direct comparator output without any edge detection involved.

[hmolesworth]

I'm now wondering about the PPI 16MHz sample clock, which is effectively a synchronous sample of an asynchronous event (the comparator output transition) and is therefore subject to metastable issues. From the documentation:

On each PPI channel, the signals are synchronized to the 16 MHz clock, to avoid any internal violation of setup and hold timings. As a consequence, events that are synchronous to the 16 MHz clock will be delayed by one clock period, while other asynchronous events will be delayed by up to one 16 MHz clock period. Note that shortcuts (as defined in the SHORTS register in each peripheral) are not affected by this 16 MHz synchronization, and are therefore not delayed.

The shortcut register might be a useful alternative, but it's not immediately clear how that can be used on the comparator. It provides a fast (non-PPI) access to Start, Stop and Sample Tasks on the comparator. This implies a better way of updating the Result register without using the PPI:

The immediate value of the comparator can be sampled to RESULT register by triggering the SAMPLE task.

Worth trying the SHORTS, methinks; I see no link from Output so we can only try the Up, Down and Cross events to trigger Sample and hence bypass the PPI and potential metastable condition.