Frequency of a function generator

reads the output of a function generator

is not quite enough to know what to do. From the code I assume you have to measure the frequency - do you?

Depending on the hardware you use - clock of the processor - you get more or less done... So your interrupt routine has to be as short as possible (1). The interrupt routine is setup with the setWatch and gets triggered by the rising edge of the signal coming from the function generator...

Your debounce is a bit odd for multiple reasons... (2)

Having challenges with resources requires usually to take a more elaborate way to go after the problem than the obvious one... (3) Also to go for precision, you try to read multiple times or over a time span and do some math to get to the detail... (4)

I do not want to do your home work - and familiarity with a language is not the problem here (5) - so I try to support you in exploring options... I numbered the hot spots with (1)...(5), where some variation / action is needed.

You are correct in the way that JS is for certain things too slow for the blunt or brute force approach, because it is interpretative and with Espruino even interpreted from source code (and not from 'compiled' byte code as for example in the browser); therefore the advice is correct and you follow the instructions found at the linked page. For your information: an free running, empty loop gets you to a few kHz. But with how Espruino handles hardware interrupts (6) you may - for a first stab at the problem (with limited, but may be even sufficient precision) - get away without going that deep 'into the woods'.

Regarding (5): you define period but use periodo in the devision which will give you for sure a division by 0 error... (btw, for showing code in the forum, use the </> code in the menu bar of the text entry area and paste your code in lines between the tripple-back-ticks).

Regarding (6): to give you some hints here in relation with your code: @Gordon, the creator of Espruino is fully aware of the timing challenges an interpreted language has in handling of hardware interrupts. So what he did is building two layers: a low level, fast implementation of catching the interrupt, do the minimum of work like collecting the times an stick the information as an event object into an event queue. When the processor then finds time to handle the events in the queue in the slower java script layer as 'connected' to pin and directed with function by the setWatch() to process this event object - you called it x - you get pretty far in handling short bursts of fast paced events... But if there are two many, the event queue will overflow... in other words, you may need to disconnect the watch using clearWatch() within sufficient time to prevent that... or you use a different approach, such as advised.

Due diligence will get you there!