!TWVkPwzRSfMDxcMozd:matrix.org

PineTime Development

217 Members
Welcome to PineTime Development, this is a channel for PineTime development related questions. General discussion goes to #pinetime:matrix.org. InfiniTime, WaspOS and all other coding discussion welcome!39 Servers

Load older messages


SenderMessageTime
26 Mar 2024
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> id check the return codes, check the timer isnt null etc 17:31:13
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_6165> it's not null alright, not sure what you mean by return code though 17:36:16
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> xtimerstart returns whether it succeeded or not 17:36:50
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_6165> ok, it does start correctly then :/ 17:37:57
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_6165> ok, it does start correctly then :/ so still no idea 17:41:31
@jf:matrix.codingfield.comJF @a​lex_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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_6165> i'm running in infinisim so printf is printing to my terminal, works fine for the other test outputs 🙂 18:04:53
@jf:matrix.codingfield.comJFoh yes, right. printf() should just work, indeed18:44:26
@jf:matrix.codingfield.comJFMaybe 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:matrix.codingfield.comJFIf 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, though18:58:12
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <p​ipe01> Is it normal for the pinetime to wake up when doing anything with BLEFS? 22:25:28
@everypizza1:matrix.orgeverypizza That's how it works for me 22:26:43
@everypizza1:matrix.orgeverypizza Also the screen doesn't automatically turn off while it's active 22:27:00
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <p​ipe01> I see. I wonder why that is though, seems like it's using more battery for no reason 22:27:16
@jf:matrix.codingfield.comJFThat'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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <p​ipe01> Interesting, thanks 22:38:22
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> 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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> 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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> not a super serious suggestion. but simplicity is nice 23:29:34
27 Mar 2024
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> what does your callback look like 15:02:56
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> you probably want to use RunForDuration? 15:17:11
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> if you look at what longvib does: longVib = xTimerCreate("longVib", pdMS_TO_TICKS(1000), pdTRUE, this, Ring); 15:17:35
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> youre gonna get weird behaviour that way 15:17:52
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <m​ark9064> 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
@p64protocolbot4:matrix.orgPine64 Protocol Droid [D] <a​lex_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@spaetz:sspaeth.de left the room.15:21:10
@trishabusch69:matrix.orgEva B joined the room.19:09:29

There are no newer messages yet.


Back to Room ListRoom Version: 9