Technique needed to notify of low memory condition during runtime

You are reading a single comment by @Robin and its replies. Click here to read the full conversation.

•

Gordon
Ok, so taking a very quick look at your code, what you're doing is:
- Sending out a 2kHz square wave
- Using setWatch on this square wave which is gated with something.
Given Espruino's execution speed this, all by itself, is going to be quite a stretch. When you add a watch, the events generated when a pin changes state go into the FIFO (the same one used for uploading code). If you don't handle those quickly enough then you get FIFO_FULL.

So... If that code ever gets enabled while you are uploading then it'll interfere with the code upload.

If you had happened to save the code to flash with 'always run at boot' then it'd really mess things up. Or there's a possibility that if it is running, the upload of new code will be affected

Also, just so you know, if you're trying to save memory then adding 'help' functions like this really won't help:
```
function help() {
  console.log( "    " );
  console.log( "    " );
  console.log( "Tutorial PPI - Programmable Peripheral Interconnect" );
  console.log( "    for the MDBT42Q Breakout board" );
  console.log( "    " );
  console.log( "    " );
  console.log( "Single letter command line helper functions" );
 // ...
```
If you absolutely feel you need them then you could use templated Strings, which will be a lot easier to write, and will use less memory:
```
function help() {
  console.log( `

Tutorial PPI - Programmable Peripheral Interconnect
    for the MDBT42Q Breakout board


Single letter command line helper functions
...
`);
```

•

Robin in reply to @Gordon
Mon 2020.03.30

response to post #10

Thanks for taking a quick peek @Gordon.

'If you don't handle those quickly enough then you get FIFO_FULL.'

Yes understood from a previous post that suggested a limit of ~100 and I'm well below that with sending out just six pulses at this point.

'So... If that code ever gets enabled while you are uploading then it'll interfere with the code upload.'

This one might agree with an observation I made with PPI that peripherals stay enabled, and a means to disable would be nice.

Tutorial example output anomaly using low level access PPI on MDBT42Q breakout board

'to save the code to flash with 'always run at boot' then it'd really mess things up'

Thanks for the tip/reminder. Purposely not using save() and not using minification to rule those out.

'then adding 'help' functions'

I understand, but mostly needed to assist in debug at this point as I'm not able to recall quickly all the variants that are needed. I tried the Template Literals approach, and would be great if it worked as in that suggestion, but it isn't possible to vertically space for legibility, even using an embedded newline char

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
```
console.log( `
Tutorial PPI - Programmable Peripheral Interconnect
    for the MDBT42Q Breakout board
\n
\n
\n
\n
Single letter command line helper functions
...
`);
```
becomes just:
```
Tutorial PPI - Programmable Peripheral Interconnect
    for the MDBT42Q Breakout board
Single letter command line helper functions
...
```
and not what we intended. Had to resort back to the tried and true for now to be able to read legibly.

Perusing the forums for the last year regarding setWatch, I have noticed that most are finding trouble attempting to impliment their trials. IMO there is conflict with the channel concept with how setWatch interacts with the underlying PPI. see March 5th post link below

Although @Oscar indicated some success, there wasn't a definitive clue that setWatch was mastered

Posted on Thu 2nd, January 2020 Problem with setWatch on MDBT42Q

@barry_b_benson hasn't responded as to the success with a 300msec watch

Posted on Sun 7th, July 2019 Piezo doesn't behave well with setWatch()

I had issues that weren't fully resolved six months ago

Posted on Fri 2nd, August 2019 Proper technique needed to nest a setWatch() within a separate setWatch()

and then again with the issues with PPI and this thread

Posted on Thu 5th, March 2020 Tutorial example output anomaly using low level access PPI on MDBT42Q breakout board
Posted on Fri 27th, March 2020 Technique needed to notify of low memory condition during runtime

I only found one reference to PPI and like myself, @TomWS unsuccessful in a solution

Posted on Sun 3rd, March 2019 Getting very random results using OneWire on MDBT42Q

While the simple examples presented seem to open the door, in practical use, not many have explored this feature, so those issues that I have uncovered most likely hadn't been discovered yet.

Technique needed to notify of low memory condition during runtime

About

Espruino