π
<-
Chat plein-écran
[^]

Timing issues with the CX II

:32tins: :32tinsktpb: :32tinsktpn: :32tinscas: :32tinstpkc: :32tinstpktpb: :32tinstp: :32tinscastp: :32tinscmc: :32tinscx: :32tinscxcas:

Timing issues with the CX II

Message non lude SixBeeps » 28 Oct 2020, 17:18

Hello all,

I'm writing a program on my Nspire CX II that is rather draw-heavy, and it overall performs terribly. Now, a lot of that is my fault, but something I've noticed is that when I run this program, the timer goes noticeably out of sync. I don't think it's a code issue:

Code: Tout sélectionner
from time import *
...
start_time = ticks_ms()
while True:
  current_time = ticks_ms() - start_time
  ...


Also, here's a video of the program running. Notice the 4-5 second offset by the end of the video. https://www.youtube.com/watch?v=Gpx0eC43tW0
So I think there might be some kind of error with the timer. I plan on purchasing a Hub and using its timer instead so that this issue doesn't occur, but I'd like to hear some other opinions.
Dernière édition par SixBeeps le 29 Oct 2020, 18:10, édité 3 fois.
Avatar de l’utilisateur
SixBeepsPremium
Niveau 0: MI (Membre Inactif)
Niveau 0: MI (Membre Inactif)
Prochain niv.: 0%
 
Messages: 2
Inscription: 29 Oct 2020, 17:36
Localisation: United States
Genre: Homme
Calculatrice(s):
Classe: Calc 1
YouTube: SixBeeps
Twitter: niorg2606
GitHub: SixBeeps

Re: Timing issues with the CX II

Message non lude Vogtinator » 28 Oct 2020, 19:43

Looks like it really just calls TMT_Retreive_Clock, so the OS directly.

The error seems to be 32768 Hz (common clock frequency) vs. 32000 Hz. It seems like the OS expects the timer to run at 32768Hz, but it actually runs at 32000Hz:

187.610s * 32768Hz / 32000Hz = 192.112s
Avatar de l’utilisateur
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Prochain niv.: 64.1%
 
Messages: 167
Inscription: 29 Mar 2014, 15:55
Genre: Homme
Calculatrice(s):

Re: Timing issues with the CX II

Message non lude Vogtinator » 29 Oct 2020, 14:09

SixBeeps a écrit:
Vogtinator a écrit:Looks like it really just calls TMT_Retreive_Clock, so the OS directly.

The error seems to be 32768 Hz (common clock frequency) vs. 32000 Hz. It seems like the OS expects the timer to run at 32768Hz, but it actually runs at 32000Hz:

187.610s * 32768Hz / 32000Hz = 192.112s


Very interesting indeed. So, does the OS
always
report the wrong millisecond reading?


Most likely. I just wrote a quick test program which waits for 10s using the RTC (second resolution only) and shows a diff of the systick (supposed to be 100Hz).
The result is a constant 976 ticks per 10s, which means 97.6Hz instead of 100Hz. This assumes that the RTC is correct, but the difference matches your video.

The OS configures Timer1 of the second timer at 0x900D0000 to interrupt every 20 cycles with a divider of 16, giving 320 cycles total.
Assuming a 100Hz systick, this means the OS expects the timer to run at 32000Hz.
Assuming the RTC is correct, the timer actually runs at 97.6*320 = 31232Hz (???)

I also see that some other functions convert ms to a timer value by doing value << 15 / 1000, which results in a 32768Hz tick. So it's a bit messy.

If so that's concerning :|

For tracking of absolute time there's the RTC and outside of that being ~2.4% slow isn't that bad.
Avatar de l’utilisateur
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Prochain niv.: 64.1%
 
Messages: 167
Inscription: 29 Mar 2014, 15:55
Genre: Homme
Calculatrice(s):

Re: Timing issues with the CX II

Message non lude SixBeeps » 29 Oct 2020, 17:52

Vogtinator a écrit:Assuming the RTC is correct, the timer actually runs at 97.6*320 = 31232Hz (???)

Even stranger. I kinda wonder if TI knew about this or if it was just some kind of overlooked detail.
Vogtinator a écrit:For tracking of absolute time there's the RTC and outside of that being ~2.4% slow isn't that bad.

I was primarily concerned because these kinds of calculators are used for scientific purposes, so having an inaccurate timer could potentially mess something up. I guess having a real timer instead of using a calculator would make much more sense on a professional scale, but still.

In other news, I stuck a "correctional factor" of 1.024 on the current_time variable and it looks like everything is synced properly. Thanks for doing the dirty work of finding out the exact difference!
Avatar de l’utilisateur
SixBeepsPremium
Niveau 0: MI (Membre Inactif)
Niveau 0: MI (Membre Inactif)
Prochain niv.: 0%
 
Messages: 2
Inscription: 29 Oct 2020, 17:36
Localisation: United States
Genre: Homme
Calculatrice(s):
Classe: Calc 1
YouTube: SixBeeps
Twitter: niorg2606
GitHub: SixBeeps

Re: Timing issues with the CX II

Message non lude Vogtinator » 29 Oct 2020, 17:56

I think I got it: It's caused by how the SP804 timer implements the periodic mode in combination with prescaling.

The good news is that this is perfectly reproducible in Firebird as well, so it's possible to look "inside" the timer.

The OS configures Timer1 of the second timer at 0x900D0000 to interrupt every 20 cycles with a divider of 16, giving 320 cycles total.

Is actually wrong! When the timer reaches 0, it does not immediately start again at 20. It only does this reloading on the next tick. The trap here is that this tick is prescaled as well.

As a result, the time between interrupts is actually not (20 * 16) + 1 cycles, but (20 + 1) * 16 cycles. This matches the results as well:

32768Hz / ((20 + 1) * 16) = ~97,52 Hz

To get a proper 100Hz timer with a prescaler of 16, the load value would have to be between 19 and 20, which is not possible. Without prescaler, it's possible to get it much closer:

32768Hz / ((327 + 1) * 1) = ~99,90 Hz

I was able to confirm that using that instead of the OS's own configuration does indeed result in 1000 ticks per 10s, instead of 976.

This little program reconfigures the timer during runtime, so just run it once and the systick should be more accurate:

Code: Tout sélectionner
#include <stdint.h>

int main()
{
        *(volatile uint32_t*)0x900D0008 = 0x00;
        *(volatile uint32_t*)0x900D0018 = 327;
        *(volatile uint32_t*)0x900D0008 = 0x60;
        *(volatile uint32_t*)0x900D0008 = 0xE0;
}
Fichiers joints
tickfix.tns
(4.61 Kio) Téléchargé 13 fois
Avatar de l’utilisateur
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Prochain niv.: 64.1%
 
Messages: 167
Inscription: 29 Mar 2014, 15:55
Genre: Homme
Calculatrice(s):

Re: Timing issues with the CX II

Message non lude parrotgeek1 » 29 Oct 2020, 19:32

Does this also affect the CX 1?

Could ndless itself apply this fix, or would that mess up existing software's speed?
My Projects:
nLoader • OS 3.9 on prototype Nspires - News ArticleTI-82 Advanced App Installer
Prototypes:
Upgrade EVT Nspire CAS+ - News ArticleFix keyboard on prototype TI-Nspire CAS Touchpad
- Highlights: Nspire CX Non-CAS OS 3.3, CX & CX CAS OS 4.4 & 4.5 special reformatting installers (both found by me on TI's site)
Discoveries:
Boot1.5 vulnerability (used in nLoader) • Nspire dev boardsPink CX
Je peux comprendre le français mais je ne peux pas le parler bien.
Avatar de l’utilisateur
parrotgeek1Programmeur
Niveau 11: LV (Légende Vivante)
Niveau 11: LV (Légende Vivante)
Prochain niv.: 80.1%
 
Messages: 740
Inscription: 29 Mar 2016, 01:22
Localisation: USA
Genre: Homme
Calculatrice(s):
GitHub: parrotgeek1

Re: Timing issues with the CX II

Message non lude Vogtinator » 29 Oct 2020, 20:18

Does this also affect the CX 1?


According to Firebird, yes. (I don't have any HW to test that on at the moment)

Could ndless itself apply this fix, or would that mess up existing software's speed?


Only software using the OS timers would be affected, so not Ndless applications. Except for Python or Lua using that value for something long running, it wouldn't really be noticable and even then, 2.4% aren't that much. So I'd say it's not really necessary, especially because it appears like nobody noticed this until now.
Avatar de l’utilisateur
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Prochain niv.: 64.1%
 
Messages: 167
Inscription: 29 Mar 2014, 15:55
Genre: Homme
Calculatrice(s):


Retourner vers Problèmes divers / Aide débutants

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 14 invités

-
Rechercher
-
Social
-
Sujets à la une
Comparaisons des meilleurs prix pour acheter sa calculatrice !
Découvre les nouvelles fonctionnalités en Python de l'OS 5.2 pour les Nspire CX II
Découvre les nouvelles fonctionnalités en Python de l'OS 5.5 pour la 83PCE/84+C-T Python Edition
Omega, le fork étendant les capacités de ta NumWorks, même en mode examen !
1234
-
Faire un don / Premium
Pour plus de concours, de lots, de tests, nous aider à payer le serveur et les domaines...
Faire un don
Découvrez les avantages d'un compte donateur !
JoinRejoignez the donors and/or premium!les donateurs et/ou premium !


Partenaires et pub
Notre partenaire Jarrety Calculatrices à acheter chez Calcuso
-
Stats.
675 utilisateurs:
>663 invités
>6 membres
>6 robots
Record simultané (sur 6 mois):
6892 utilisateurs (le 07/06/2017)

-
Autres sites intéressants
Texas Instruments Education
Global | France
 (English / Français)
Banque de programmes TI
ticalc.org
 (English)
La communauté TI-82
tout82.free.fr
 (Français)