-
Close enough; actually a positive 8uS pulse (see the earlier scope image). I think the nRF processor was triggering, but the additional processing with setWatch was too much. Per one of your earlier posts, I was getting stack overflow after a few cycles, so it wasn't keeping up potentially because it was triggering on both edges internally and logging time for each. I don't know enough about the internals, but from what you and Gordon have described it makes sense.
Since the toggle flip/flop only has the one edge each cycle, and there is a significant amount of time, it resolves the issue and Espruino can 'keep up'. I had J-K flip flops available since they are a general purpose 1-bit memory and easy to convert to lots of uses. A couple of connections and it becomes a toggle, for example. I don't keep standard logic gates around anymore, especially since I'd need a whole new family to do 1.8V logic work that has become the norm.
Thanks again!
You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
billsalt
@allObjects
Thanks for the feedback. Interesting. The acquisition device pulse is a negative 8us pulse. The MDBT42Q was unable to get triggered on either flank of the pulse. The 74AC109 uses the rising flank on the clock (I assume the acquisition device drives the clock of the flip-flop).... Still seems weird to me that the direct MDBT42Q input was not working but the 74AC109 clock does... A simple NAND constructed R-S flip-flop that would catch the negative flank could have worked too... but would need an extra pin from and JS pulse command on the MDBT42Q to reset it.