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.chandles 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
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'
'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.
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
. . . . our posts crossed . . . .
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,
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
Knowing that function digitalWrite() must do something similar, I tried to track down how that process is done.
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:
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?