Reaction time (callback) and wakeup

Device Code
1

I have done some tests to see the reaction time of the IMP and the wakeup time (measured).

See attached pdf for the details of the test (code, scope screenshots, etc)

I have a few questions:
1. Does the 50-80uS the lowest callback reaction time possible as it turned out from my measurements?

2. Is there a way to ensure a data reaches the IMP services (and a possible vimp too)? It does not matter if it’s slow just be 100% reached the servers.

3. The wakeup test has shown kinda big delay between the pin 1 change and IMP waked up - I know there are things like logging in to server etc. so the server.sleepfor might not be the best method. What I need is to keep the IMP in low power till something happens, wakeup, do the job (which probably will be a SPI/I2C/UART read from a controller), parse it, ensure the result reaches the IMP service and sleep back again. Does this doable with a reaction time less than 600-700mS what I’ve seen on my measurements?
2
  1. 50-80uS is actually not bad here. We’ll always be working to improve this time, but low latency IO should be dealt with by the imp OS (eg: serial buffering, pulse counting, etc). We’ve got some more stuff in the pipe which may help here… but what are you looking for?

    2. The data will reach the server, but you may not see it in the web client if you’re using server.show() as the web client looks for changes and reloads - but can easily miss updates. It’s not intended to be tightly coupled to the devices. If you’re wanting to log data, use server.log().

    3. Wakeup is currently very slow, as it reloads the squirrel from the server. When all the squirrel-in-flash things are done, this should be down to sub 100ms, possibly much, much faster.
3

1. I wanted to know for bitbanging "protocol" what is the limit for reaction time after edge change. Below 100uS should be enough so it's fine. 

2.  Good news - I will use log than.

3. Than for now I will avoid deep sleep and go with the normal edge callback, we'll see the deep sleep when the flash things are done.

Ty for the feedback.

4

We’re working on a bitbang list, where you specify the transaction in advance then “run” the bitbang, which will give much better resolution.


5

Bitbanging list is even better, already tried such thing for other rf chips and worked well. Waiting for it …