swiSleep()

Je suis resté sans support de la mise en veille pour mes programmes jusqu'en juillet 2009, puis j'ai copié un petit bout de code qui permettait de s'approcher pas trop mal de cette fonction. Thoduv dans un post précédent, expliquait alors qu'il y avait techniquement moyen de faire mieux, que l'approche était en cours d'intégration dans la libnds, et que ça lui donnait du fil à retordre pour son "Lapinou Jumps" ...

Du coup, je me retrouve maintenant avec deux bouts de code qui tentent de mettre le programme en veille : mon "code utilisateur" sur l'ARM9 et le "code système" sur l'ARM7... et de temps en temps, le programme qui éteint la console au lieu de se mettre en veille >_<

Here's how 'sleeping' is implemented in the "devkitpro-r32" : there are SLEEP_DISABLE and SLEEP_ENABLE messages that can be sent to the powerValueHandler on the ARM7. When sleep is enabled on the ARM7, systemSleep() is invoked by inputGetAndSend() directly when the lid is closed for more than 20 frames (1/3 second). The ARM9 "acknowledges" this by echoing the PM_REQ_SLEEP message and the ARM7 side then proceed to the suspension of execution through the hardware power management register. swiSleep() on the ARM7 is the core of this shutdown. The rest is turning off the speaker, changing LED stats, etc.

So far, it makes my programs randomly shutdown with low probability when one closes the lid. I still have to define whether it's due to an intermix of the old code with the new lib or to something more intrinsic to swiSleep()... That's not really a problem for runme or apple assault, but it will definitely be a nuisance for the editors. Also, I haven't seen anything sending _SLEEP_DISABLE or _SLEEP_ENABLE, though, while it would be a good thing that I could prevent the DS to enter sleep mode in the middle of a wifi transfer. I'm also unsure of the reason for that 1/3 second delay, and I fear it could lead to gameplay issues (the game state change too much while I'm closing the lid).