Search results for:

Ic. Thanks for clarification. I think I get it: it is 'just' a SW replacement... nice! Like the Bangle.js watches: taking an existing hardware and software and replace the software. Very interesting. The word 'just' just does not do justice to the work you put in, even peeking at the Arduino implementation / its doc.

Was thinking more along the lines of adding a ref pointer to variables. Of course this is not footprint friendly, but preserves source.

Your replacement approach triggered another thought: in dbs, often a local index is built to save space. In code it would be a symbol index to keep the name / preserve the source but having a space to replace it on first run w/ a pointer into variable value space, that holds the value but would also hold also a pointer back to the index entry / name.

I'm sure you already have though of many things, wandered down alleys... and kept sticking to what Espruino interpreter has come to this day. So no urgency to this.

Speeding up variable lookup (and jump address lookup/'calculations') promise the most. Was there ever a thought to have something (changed) in the source that updates when the variable has been looked up? Of course that works only when the code is in RAM and a in/re-direction table that makes GC transparent? So it is not really a JIT compiler but more so an accelerator that does a lot of good especially in loops - similar to what pre-tokenzing does. An accelerator is not JIT compiler nor main stream, but Espruino isn't either. Such an accelerator would be unique and - after all - fit the uniqueness of Espruino (JS engine).

#jeffmer, Bull's Eye! - That's all I can say...

So: you got yourself such a device, ripped out the Arduino stuff and put in an Espruino w/ your code?

I'm kind of curious to know whether there is still enough space left to have a Morse Code interpreter / decypher DX transmissions on SSB?

...here it is... it is in someone elses conversation New to Bangle.js and Espruino. Need help with graphics... Nov 2020

Hit that limit a while ago... if your algorithm can handle a detection and cut-up in multiple 'touching' polys / segments, it is easy to live with the limitation.

I had build a circular multi dial... and on a certain size with close to 360 degrees and expectation of decent smoothness of the 'bent bar'/bow, you run quickly into the limit. Luckily for me, I calculate max 30 points of a segment, note the angel and finish calculating the rest of the segment, draw it, and move on to the next segment until the desired angle is covered. Somewhere in the (difficult to search) forum you can find the code...

Obviously missed this discussion / voting / weighing in...

Not sure my comment changes much from point of view of liking or not liking github for discussion. These are the cons for the current forum:

• not mainstream
  
• created for discussing non-code things
  
• no integration with a real repository
  
• difficult, limited search
  
• limited image integration
  
• formatting has changed over time making a lot of my older, markup using entries unreadable
  
  

I don't want to leave it at cons - and that may be reason for many to be content with the current forum:

• easy to use for simple posts
  
• file / image integration usually sufficient
  

@Jennygrist, what is the motivation to use a pico vs a puck? Pico has no communication. You would have to add that as a separate device. Just to mention one con.

@Gordon, what about the input controls on active overlay, especially the touch?

My best guess is that callback (on time intervals) overrun happens... Did you ever time the anonymous functions in your intervals?

I see sensor driven events - on(...) - which capture data that you then process in 100 and 250 ms intervals. What are the average intervals of you sensor - GPS and pressure - events?

@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... ;-)

@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...).

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.

Thanks for going into all the details.

@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?

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.

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.

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?)

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.

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?

@billsalt

I'm trying to understand your setup:

• You are running 8us (micro second) low pulse with a frequency of 222kHz.
  
• Every pulse increments the readCount by 1.
  
• Every second you print readCount (to the log) and re-set the readCount to 0.
  
  

Is that correct?

@Jean-Philippe_Rey,

I was not expecting BLE to do HTTP. It is more about what you got out of it: inspiration by the solution pattern of using for the 'down/command direction' what works for the 'sensor data collection direction'.

@Jean-Philippe_Rey

addendum re protocols - google it. Used it before sockets were available. Roundtrip times were amazing despite the http overhead. Almost real time I could control the (trojan horse modified) firefox browser... or less intrusive, talk to single page app in another browser over the internet via a nio tomcat / getty server in the internet.

• Bayeux protocol / CometD project
  
• BOSH
  

@Jean-Philippe_Rey

If your setup works for the uplink, could a parallel - independent - same-setup work for the downlink as well?

Of course, this means doubling the BLE devices per sensor location and make the pairs talk to each other as well as on the data collecting side a peer for broadcasting the commands?

It reminds me of the old days - not so long ago - when browser communication was kind of a one-way initiation. Long polling on separate connection and related protocols were the answer to overcome the technical limitations.

@user142416, enjoy the updated code (post #29... could not test it yet, though... if it does not work, used what is in post #25).