Most recent activity
-
I tried the 'cutting edge build' and have verified that it is working with my 8uS pulse using
{repeat:true,edge:"falling",hispeed:true}
Thanks @Gordon and @allObjects
-
Thanks @Gordon! I'll flash the bleeding edge firmware and give it a go, and report back.
I thought the flip flop solution inventive, but certainly am not interested in the flying chip circus longer term :-}
-
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!
-
@Gordon and @allObjects: solved! I used a J-K flip flop (74AC109) inline configured as a toggle. Then changed the setWatch to edge: 'both'. Pretty simple hardware solution.
Doing my SPI transfers in the setWatch with enough time, helps confirm that the issue was the narrow pulse.
-
-
@Gordon and @allObjects thanks for your assistance and advice. I tried the inline C (below) and had almost identical behavior. The 8uS pulse width just is not working. I'll take a look at the PPI function, but my guess is at this point it would be more reliable to go directly to nRF native coding.
var c = E.compiledC(` // void press(bool) // int get() volatile int data; void press(bool state){ data++; } int get() { int r = data; data = 0; return r; } `); setWatch(c.press, D16, {repeat: true, edge:'both', irq: true}); console.log("watch set");
-
Using the PWM method how; could you explain? Your idea of using a counter and resetting it on a timer would be completely asynchronous to the acquisition chip A/D; that's not going to work. I need to synchronize on the interrupt pulse and don't see how Espruino can be used in this way as a 'pulse stretcher' without additional hardware.
-
@allObjects sorry about that; used to typing the 'k'. If you look at that scope image, you'll see that it is actually 222 Hz. Plenty of time. I'd already run the numbers to make sure I had the time to do the SPI operations, even with Espruino timing on the SPI enable.
I think I either need to do a bit of pulse stretching hardware, or just ditch Espruino and head directly to C. I was hoping to avoid that since I'm just prototyping, but alas.
My other thought was whether it would be possible to so some inline C to trigger setWatch with a shorter pulse. Any thoughts on that?
Appreciate your insights!
-
Also known as "billsalt"
Bill Saltzstein
Code Blue Consulting/Code Blue Communications
Bluetooth and Medical Device Consultant
http://www.linkedin.com/in/billsaltzstein