allObjects

Most recent activity

• MPR121 module - how to know when an electrode is touched?

  in Pico / Wifi / Original Espruino • 2 days, 15 hours

  

  @Gordon, skimming over the code in post #38 as the extension (and post #39 in its use), I think that the 4th 'item' in post #39 should read .baselineData as said in post #39 by @mix2009 (instead of repeating 3th 'item' .filteredData). ...just in case for what you will copy into the update of the module... ;-)

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 2 weeks, 1 day

  

  @Gordon, this new option is absolutely great news. I was looking for something about detectable minimum pulse width, but could not find it. Now we know another tech spec detail and dependency on power (saving) mode.

  I do not really care about the reported pin state, because when push comes to shove, I control it anyway myself. Important is that the pulse comes thu. This even helps for complicated debouncing.

  @billsalt 's addition of the flip flop that cuts the frequency in half and watching both edges is really a great solution pattern.

  The most though I liked the test driver. When I suggested it a while ago I was not sure if it is possible to create such a short pulse... now it's proven (I got the idea from another test driver implementation when exciting an LC circuit for figuring the resonance: Espruino controlling LC resonance experiment in HAM Radio class. In this example I was not sure how high the frequency could go. Since for finding the resonance frequencies, excitement works also just 'provoking' along the harmonics...).

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 2 weeks, 4 days

  

  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.

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 2 weeks, 6 days

  

  Thanks for going into all the details.

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 3 weeks

  

  @billsalt

  @Gordon 's point to not look for the other flank makes sense. I did not think about this. BUT: it looks like that you have a different issue: either the pulse has not enough energy to make it detectable or the wiring/pull-up/pull-down is still an issue.

  I'm also surprised that the acquisition device sends only a pulse. Interrupt pins - if we are looking at one here - go low until the interrupt is cleared. May be the acquisition device can be programmed differently and behaves like that.

  You mentioned the pulse to be visible in the screenshot of the DSO, channel 4. With everything wired up, could you detect the pulse on the NRF52832 pin with the DSO?

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 3 weeks, 1 day

  

  Using the PWM driven pin is there to only 'exercise'/drive your code for figuring timing limits. That is all.

  Again, validate some of the wirings and signal behavior and pin mode setup (with pull up/down?) before setting up the watch. The input pins are so sensitive that the wiring capacity is enough to not produce a signal flank when the source is not a push/pull (only an open drain or source).

  From what I understand is: about every 4.5ms you get a pulse - interrupt from the acquisition device - that should trigger sending over spi 32 bits to the acquisition device and read 64 bits back from it and then do something with these 64 bits.

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 3 weeks, 1 day

  

  222Hz is much better... because I know that an empty loop in Eskpruino a a few KHz at max. Said such, you can use another pin on your device and create the input signal with a PWM as mentioned before. With not too much capacity in the sense wiring and good contacts, I'm sure you can get reliable results. With 222Hz, you have about 4ms to spend between each of the pulses.

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 3 weeks, 1 day

  

  Driving the code with an emulator in which you have control over the frequency is meant only to figure the max frequency you code can handle.

  Are you trying to bit-bang something?

  You are aware that a 220kHz frequency has a full cycle time of 4.5us only? 8us pulses don't even fit in... somehow - for me - the numbers do not add up.

  Can you tell be about the acquisition chip? (in dm or else?)

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 3 weeks, 1 day

  

  Do you have a way to control the firing frequency? For example w/ PWM driven pin (of a second Espruino device to minimize interference)?

  I would start at the rate of 100Hz and then crank it up until it becomes 'a wash' (measurements all over the place).

  If the expected firing frequency cannot be safely handled, you have to switch approach: you run a register/counter on a pin and read and reset the value every second. The counting would be uninfluenced by what else is going on your device. Proper timing comes then important - who to reset timer and start period and do the read-out. For better control you could make it inline assembler or compiled C function and call it from JS. There are examples in the forum (tutorial?) how to setup counter register and read and reset it. It was for the STM chips... I'm not sure if it works exactly the same way for the NRF52832... some data sheet and coding examples from the web may help you.

• setWatch issue

  in Puck.js, Pixl.js and MDBT42 • 3 weeks, 1 day

  

  My guts tell me that Espruino is too slow to actually make it that fast...

  There are ways to make it faster by hooking directly into the interrupt... but because JS

  interpretation takes so much time you always miss hits... Did you check the error flag? I guess the internal event queue overflows within no time.

  Do you want to measure how many pulses happen in a second?