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

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.