Lost memory after publish?

@tjp, that recommendation was in context of NOT using threading so you are correct if he does continue to use it. :wink:

1 Like

Duh! Right, I forgot (over lunch) that you had suggested that! lol Got my head in the game now :stuck_out_tongue_closed_eyes:

1 Like

And even with MT:
It (or better the cloud-keeping tasks) would get executed regularly by the system thread, but if for some reason that thread gets stalled having the application call Particle.process() might help there - at least once this “issue” gets dealt with
https://github.com/spark/firmware/issues/659

Wow,

My PC dies for an hour and look what happens ;-)). Again I will try to respond to all comments here -

tjp : Yup I can relate - but then again developers just LOVE to move on to NEW code, and not finish existing stuff - so of course an Electron looks ‘exciting’ ;-)) - I know - I am a developer ;-)).

ScruffR : - its not so much my pressing timescales - its been a while since 0.4.7 and the prospect on no new release before October 2016 was a show-stopper !!!.
As I recall - there was some talk that the watchdog was being reset in a timer interrupt :open_mouth: - thats a NO NO !!! and defeats the whole point of a watchdog - no bite ;-).
Now though I am confused about disabling Threading - IF (your later response and others) Particle.process() is now simply a stub, then the system stuff gets done when I exit loop() anyway ??? which in my case is every second anyway. So what gets processed when my code calls a ‘delay(xxx)’ - and why is millis() better ???. Oh no - do you mean that ‘delay(xxx)’ is simply a software loop and does not call FreeRTOS taskdelay :-O. Sorry but I am used to using the FreeRTOS delay - which simply restarts the task after a delay period :open_mouth: - allowing other tasks a piece of the action. A software loop is just a waste of time :-O. If this is so then its pretty obvious why my code could be slowing down the system task :-O. Sorry - I ‘assumed’ that delay was more than a code loop !!. NB delayMicroseconds is (shall we say) less than accurate and is a primary reason why my 1Wire code was failing - delays are WAY more than the number passed in - I 'scoped it and could see the effects!!.

I WAS using the FreeRTOS timers at one point but disabled those when attempting to fix my 1wire issues :-O.

Looks like I need to review MUCH of my code then…as its based on some bad ‘assumptions’ (ie second-guessing what the docs don’t tell me ;-)).

I am now utterly confused…

Does Particle.process() do anything (threading mode and non-threading mode) ???.

Is ‘delay(xxx)’ a simple program loop :-O.

What interrupts does ‘noInterrupts()’ disable - all or just some (affects timings)

Thanks again

G

delay() currently does in fact loop and from time to time calls Particle.process() (hence the millis() suggestion of @peekay123) (in non-threaded mode, but threaded uses boost::this_thread::sleep(boost::posix_time::milliseconds(millis));).
(Link to code bellow)

In MT Particle.process() seems to do very little leaving the cloud keeping to the system thread.
But as the above issue #659 shows for some features to work you still need to drop out of loop().

In non-MT Particle.process() does the pretty much the same as dropping out of loop().

But dropping out of loop() does next to nothing in MANUAL mode but all is done by Particle.process(), so I’m not sure what happens in MT if neither does anything useful when it comes to Particle.functions() and Particle.subscribe() (this could be investigated by looking at the open source or by @mdma ;-))

The docs do lag behind and hence some of us keep looking into the open sources if in doubt (or ask people who already did or know some other way :sunglasses:)

noInterrupts() - I recently looked into that very code but must admit I’m not sure anymore :blush: I think it was all and it disables the user exposed EXTI lines (see follow-up below).

BTW: Particle was not just moving on to the Electron without finishing off the Photon. It was in the business plan already but limited HR and unexpected issues got in the way of schedules (personal impressions here).


Follow up on noInterrupts():
Here you can find the current implementation of the wiring command: https://github.com/spark/firmware/blob/develop/wiring/src/spark_wiring_interrupts.cpp line 107ff
And here the HAL implementation for the STM32F2xx Particles (Photon/P0/P1/Electron): https://github.com/spark/firmware/blob/develop/hal/src/stm32f2xx/interrupts_hal.c line 206ff

delay()
The wiring command calls system_delay_ms() which can be found here (line 340ff)
https://github.com/spark/firmware/blob/develop/system/src/system_task.cpp
threaded:
https://github.com/spark/firmware/blob/develop/hal/src/gcc/delay_hal.cpp

2 Likes