26 Mar 2024 |
Pine64 Protocol Droid | [D] <mark9064> id check the return codes, check the timer isnt null etc | 17:31:13 |
Pine64 Protocol Droid | [D] <alex_6165> it's not null alright, not sure what you mean by return code though | 17:36:16 |
Pine64 Protocol Droid | [D] <mark9064> xtimerstart returns whether it succeeded or not | 17:36:50 |
Pine64 Protocol Droid | [D] <alex_6165> ok, it does start correctly then :/ | 17:37:57 |
Pine64 Protocol Droid | [D] <alex_6165> ok, it does start correctly then :/ so still no idea | 17:41:31 |
JF | @alex_6165 I'm not sure printf() is implemented in InfiniTime and that may be why you don't see any log when the callback is called. Did you check that the callback is called using a breakpoint, for example? If you want to write logs to the RTT console, you should use NRF_LOG_INFO("Callback") instead of printf(). And also make sure the RTT logger is enabled by setting NRF_LOG_ENABLED, NRF_LOG_BACKEND_RTT_ENABLED and NRF_LOG_BACKEND_SERIAL_USES_RTT to 1 in sdk_config.h (https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/sdk_config.h#L8122) | 17:55:19 |
Pine64 Protocol Droid | [D] <alex_6165> i'm running in infinisim so printf is printing to my terminal, works fine for the other test outputs 🙂 | 18:04:53 |
JF | oh yes, right. printf() should just work, indeed | 18:44:26 |
JF | Maybe there's a bug on the implementation of FreeRTOS timers in InfiniSim ? I don't think we use them a lot in InfiniSim, so it may have gone unnoticed.
From what I can see in the code, all the Timer API is re-implemented in InfiniSim and is based on SDL_Timer. | 18:56:51 |
JF | If you want to debug this, you could start by having a look at xTimerCreate(), xTimerStart() and timer_callback_wrapper() in timer.cpp (https://github.com/InfiniTimeOrg/InfiniSim/blob/main/sim/timers.cpp#L39).
As an example, I see that the parameter xTicksToWait of the function xTimerStart() is not used. Not sure if this is expected or not, though | 18:58:12 |
Pine64 Protocol Droid | [D] <pipe01> Is it normal for the pinetime to wake up when doing anything with BLEFS? | 22:25:28 |
everypizza | That's how it works for me | 22:26:43 |
everypizza | Also the screen doesn't automatically turn off while it's active | 22:27:00 |
Pine64 Protocol Droid | [D] <pipe01> I see. I wonder why that is though, seems like it's using more battery for no reason | 22:27:16 |
JF | That's because InfiniTime disables most of the internal devices (including the memory chip) in sleep mode. To ensure that all the devices needed for the BLEFS to work are enabled, we simply wake the watch up while it's processing BLEFS requests | 22:37:45 |
Pine64 Protocol Droid | [D] <pipe01> Interesting, thanks | 22:38:22 |
Pine64 Protocol Droid | [D] <mark9064> i wonder if it's really worth going through the hassle of sleeping the SPI and flash for the 5uA it costs to keep them awake. increasing the system task period saved more like 60-70 in comparison | 23:18:47 |
Pine64 Protocol Droid | [D] <mark9064> itd allow removing the whole donotgotosleep thing which is pretty horrible and should definitely be a counter rather than a boolean. would also simplify things like loading watchfaces using external resources while the watch wakes the touch panel etc, file transfers in the background, dfu wake constraints | 23:29:14 |
Pine64 Protocol Droid | [D] <mark9064> not a super serious suggestion. but simplicity is nice | 23:29:34 |
27 Mar 2024 |
Pine64 Protocol Droid | [D] <alex_6165> i'm now just running it on the pinetime and i'm getting inconsistent behaviors as well, sometimes the timer triggers properlly (using haptic feedback) sometimes it does it after wayyyyy longer than the set time | 13:11:33 |
Pine64 Protocol Droid | [D] <alex_6165> also are there any specific considerations i should take into account if I want long running tasks ? like a recurrent task every hour all day ? | 15:01:52 |
Pine64 Protocol Droid | [D] <mark9064> what does your callback look like | 15:02:56 |
Pine64 Protocol Droid | [D] <alex_6165> essentially:
void REM::test(TimerHandle_t xTimer) {
REM *remInstance = static_cast<REM *>(pvTimerGetTimerID(xTimer));
remInstance->motorController.hapticFeedback();
}
where hapticfeedback is just a simple change in the motorController for a single pulse:
void MotorController::hapticFeedback() {
xTimerStart(longVib, 0);
vTaskDelay(pdMS_TO_TICKS(1000));
xTimerStop(longVib, 0);
}
I've run more tests now and it seems more consistent at the time of writing, i'm not sure what could have affected the ones I did this morning, I was waiting on a 5s timer, and it was taking anywhere between 4-10s | 15:14:11 |
Pine64 Protocol Droid | [D] <mark9064> you probably want to use RunForDuration ? | 15:17:11 |
Pine64 Protocol Droid | [D] <mark9064> if you look at what longvib does: longVib = xTimerCreate("longVib", pdMS_TO_TICKS(1000), pdTRUE, this, Ring); | 15:17:35 |
Pine64 Protocol Droid | [D] <mark9064> youre gonna get weird behaviour that way | 15:17:52 |
Pine64 Protocol Droid | [D] <mark9064> tbf the whole motorcontroller is kinda cursed, it's not really designed to handle multiple things asking for the motor at once | 15:21:11 |
Pine64 Protocol Droid | [D] <alex_6165> yeah i noticed, i wonder if my earlier problem (which has not repeated itself yet) could just have been two things asking for the motor at once by chance | 15:34:21 |
28 Mar 2024 |
| @spaetz:sspaeth.de left the room. | 15:21:10 |
| Eva B joined the room. | 19:09:29 |