Help clear the fog Low Level Access PPI GPIO at jshardware.h for MDBT42Q breakout board

Wed 2021.04.07

Continuation of thread Using low level access PPI on MDBT42Q breakout board from 2020.
(can't believe a year has passed!)

After a quick review of a basic 'Hello World' ARM Cortex M4 programming,

htt ps://www.youtube.com/watch?v=w3M3oDBsIXs

rather than follow that flash process, I'd like to extend a function, or create a new suite of functions to solve the following:

Ultimate project goal would read and write user programmable pulse generation, both in pulse width, duration and count. I require much finer control than what is currently apparent.

Following the datasheet, it appears I need to bit control registers of this peripheral:

p.238 25 RTC — Real-time counter

http://www.espruino.com/datasheets/nRF52832_PS_v1.0.pdf

Knowing that function digitalWrite() must do something similar, I tried to track down how that process is done.

From jswrap_io.h I have located that declaration:
L22 void jswrap_io_digitalWrite(JsVar *pinVar, JsVarInt value);
The definition may found in the corresponding source:
L267 void jswrap_io_digitalWrite()
the actual pin output appears to be at:
L277 jshPinOutput(jshGetPinFromVar(pinPtr), value&1);
from which jspin.c that function source may be found:
L258 void jshPinOutput(
and within that function the actual output value:
L263 jshPinSetValue(pin, value);

but dead ends at L104 jshardware.h function declaration page.

Tried again with the function(s) I'd most likely need to modify or recreate:

L219 void jswrap_io_digitalPulse(Pin pin, bool value, JsVar *times)
L225 jshPinPulse(pin, value, time);

This too dead ends at L199 jshardware.h

At this point my assumption is that there is an internal modulue, say 'native.c' that contains that functionality, but that guess is way off as on close inspection, there isn't a reference in that file either. What process/procedure allows/maps these functions to the output pins? Where/what is code to map function jshPinSetValue() to control the hardware pin?

Over a year ago, I was successful at a basic build just using a GitHub clone of Espruino, but unable to locate my notes on how I did that, then. Maybe the flash page perhaps?

So my hunch is I clone jswrap_io , modify as required and eliminate all errors until successful.

I'm seeking a basic overview of what file content is necessary, along with some basic guidance on what is needed to create a new developer defined pulse function, where to put it (do I clone the exisiting jswrap_io.c/.h edit and use those modified files in my project?) and how to manipulate the bits within registers according to the Nordic nRF52 datasheet. Maybe it is as simple as L18 void jswrap_io_poke() and if so, is there a suitable example that can get me over that ledge?

Thank you

Hi - what specific requirements did you have for timings? The RTC only runs at 32kHz so you may find it's not accurate enough for you.

One of the Timers might be better - but these are already exposed by NRF52LL JS library, which I think would likely be the best solution for you.

But to answer your question:

• targets/nrf5x/jshardware.c handles the vast majority of actual hardware communication
  
• This file uses the Nordic hardware APIs as much as possible, so you could check those out for a reference
  
• Some of the hardware is used by Bluetooth and we have only limited control/usage of it - it's listed at the top of jshardware.c
  

Thr 2021.04.08

Thanks much @Gordon for that relative path. Now for the 'Friday Funnies!' We'll all get a good laugh at my expense. . . .

Lack of familiarity with VSCode caused me to have blinders on when using the hyperlink to both function definitions and declarations. I couldn't get passed why there was no corresponding .c file anywhere in each of the visible views. While using the file explorer within Windows10 was time consuming, and experience has taught me that if an internal System Service hasn't completed indexing, it is quite possible that the desired file is never (reasonable time frame) found. So I went to Google to search GitHub. None there either. So, I falsely determined that the content I was after was somehow pre-compiled into one of the .bin files used to flash Espruino, having no other explanation. Using the relative path that you provided, I searched GitHub again, and this time a result. So, curiosity forced me to find the reason why a search yesterday didn't locate that file.

    Drum Roll Please . . . . . the funny part . . . .

I went through Chrome History to locate the search string. Couldn't believe my eyes! While I had used the wildcard '*' to perform the recusive file search using File Explorer yesterday, when I jumped to using the Browser, I had only searched for 'hardware.c' without the wild card as not permitted, at GitHub. Looks legit when typed, but somehow never registered the omission. okay, . . . . stop laughing . . . please!! ;-b)

Lesson here: Enjoy your youth and quick thinking mind while you have it - I'll get the last laugh on the other side

Back to the project:

'The RTC only runs at 32kHz so you may find it's not accurate enough for you'

Yes, it is around 100 times too slow. I may resort back to triggering external clocking hardware with Javascript, and make use of the setWatch() GPIOTE peripheral to detect pulse edges.

'One of the Timers might be better'

The issue I had here was that I couldn't get a narrow enough pulse, and a train of pulses in a narrow enough time interval. Back then, I shelved the project at that point, but would need to put some time in to determine the limitations.

'Some of the hardware is used by Bluetooth and we have only limited control/usage of it'

Thanks for that tid-bit. I may resort back to the WiFi, also having the extra memory benefit.

My goal was to create a nice tutorial with a specific goal of a pulse generator and counter using the under utilized MDBT42Q breakout board. During that development, I discovered the lack of products with a suitable use within the music industry. Using a schmitt trigger, I created a proof of concept while working through the PPI link in post #1 above. Filtering out harmonics was doable with Javascript and some math I found online, but the response, around 1/3 second was just too slow, and the ear picks that up. External hardware may be my only choice. The tutorial would have covered both, with the intent to market the super-duper version, however, should I scrap that pie-in-the-sky goal, I may complete the limited slower range version for others to tinker with.

The issue I had here was that I couldn't get a narrow enough pulse

You're talking about using digitalPulse? There is a known issue there which is on my list of stuff to fix, however I'm talking about the hardware timers...

https://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.4.pdf chapter 24, TIMER

This one should go quite fast: http://www.espruino.com/NRF52LL#create-a-square-wave-on-pin-d0-with-the-inverse-of-the-square-wave-on-d1-

However to create a train of timed pulses, I believe you could also (ab)use PWM (chapter 47 in the above link).

Interestingly it even shows you the register accesses required, so it shouldn't be too hard to look at the 'REGISTERS' section underneath and then turn those into poke32 commands.

. . . . our posts crossed . . . .