Disable slack overflow in the simulator?

Hello all Wave tone1,

I am working on a mock, acting as a `Toybox.BluetoothLowEnergy` replacement.

It thus have to print the command sent, as well as triggering the correct delegate with the correct value...

But I always get a 'Stack Overflow Error', has the number of functions on the stack can be quite larger than the 8 (from memory) the physical stack can handle.

My question is then the following:

Is there a way to run the simulator so that the 'Stack Overflow Error' is ignored?

Thank you!

++GG

ps: I am not using any testing feature. Should I?

  • No way to ignore a stack overflow.  You'll see the same thing on a real device and it's probably easier to find and fix in the sim.

    Not sure now you plan to replace Toybox.BluetoothLowEnergy.  What's there is the interface to what's available to CIQ at the FW level.  Things like you can only receive 22 bytes in reads and notifies, there's no security, and what can be seen with scanning may not be everything.

  • Thank you for your answer.

    Oh no! I do not plan on replacing `Toybox.BluetoothLowEnergy'. Just mocking it to check the flow of commands sent & received, to validate with the HW team...

    Well, I guess I'll have to think of something else Stuck out tongue closed eyes ...

    Anyway, thank you for your answer!

    ++GG

  • I'm not sure about the details of your mock and why it needs to go more than 8 function levels deep, but, assuming that...

    - the deeply nested calls don't have to be synchronous

    - your code can determine a priori when the limit will be reached

    - you have a spare Timer.Timer available to your app (3 are available)

    ...maybe you could use a Timer.Timer to invoke an async callback that continues your execution flow asynchronously at the appropriate points?

    Again, idk how your mock works, but maybe the whole thing could be based on async callbacks?

  • Why not jus use Toybox.BluetoothLowEnergy?  There are a couple of samples in the SDK.  The Nordic nrF52840 dongle is about $10 US, and a thing52, maybe $40.  That will give you some actual "hands on" testing in the sim.  There are things you wont see in a mock up, such as a very limited size for data received, and things like a max of 3 services.  It's all pretty much driven by callback.

    For something that may be closer to what you are doing, I did this blog post a few years back using a raspberry pi as the device I'm connecting to, though it's impossible to find a pi today.

    https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

  • We already have a dongle, but that is not the question.

    We would like to log all the message sent, and received, in the order they occur.

    This log could then be used as a validation for our app, or sent to the FW team for debugging, or else... 

    The perquisite of mocking Toybox.BLE being that it our code base is not changed.
    Also, it can be run on the simulator, by anyone, without any extra hardware...

    I'll give @FlowState's suggestion a try and will keep you updated Slight smile

    Thanks a lot!

    ++GG

  • Why not just use the actual BluetoothLowEnergy and add println calls in the code? That will log what's happening and the order, and if you include a timestamp with the println, you can see how long things take.  You can get this data in the sim or on a real device.  You'll miss things if you try to run in the sim without an actual connection, like the need to queue requests.  Seems like you are spending a whole lot of time trying to get this to work to save $10 for a dongle.

  • 10 bucks for the dongle. But between 300 to 500$ for one device Wink

  • Thank you for your suggestion! I was not aware of that monkey-c feature. 

    But indeed, it looks like a very good contender in this case.

    I'll give it a try asap and keep you updated.
    In the meantime, thank you very much! Smile

    ++GG

  • With a dongle, a great deal can be seen without a device using the sim, and you see what actually occurs and when, as long as the sensor is available.  With my BLE apps, I do most of my testing in the sim, and I involve a real device for this like the BLE range

  • Using a Timer to split things up would make more sense if you had issues with the Watchdog Timer.  Not sure how well it would fit with a stack overflow