π
<-
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

Unread postby 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: Select all
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.
Last edited by SixBeeps on 29 Oct 2020, 18:10, edited 3 times in total.
User avatar
SixBeepsPremium
Niveau 0: MI (Membre Inactif)
Niveau 0: MI (Membre Inactif)
Level up: 0%
 
Posts: 2
Joined: 29 Oct 2020, 17:36
Location: United States
Gender: Male
Calculator(s):
Class: Calc 1
YouTube: SixBeeps
Twitter: niorg2606
GitHub: SixBeeps

Re: Timing issues with the CX II

Unread postby 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
User avatar
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Level up: 64.1%
 
Posts: 167
Joined: 29 Mar 2014, 15:55
Gender: Male
Calculator(s):

Re: Timing issues with the CX II

Unread postby Vogtinator » 29 Oct 2020, 14:09

SixBeeps wrote:
Vogtinator wrote: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.
User avatar
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Level up: 64.1%
 
Posts: 167
Joined: 29 Mar 2014, 15:55
Gender: Male
Calculator(s):

Re: Timing issues with the CX II

Unread postby SixBeeps » 29 Oct 2020, 17:52

Vogtinator wrote: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 wrote: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!
User avatar
SixBeepsPremium
Niveau 0: MI (Membre Inactif)
Niveau 0: MI (Membre Inactif)
Level up: 0%
 
Posts: 2
Joined: 29 Oct 2020, 17:36
Location: United States
Gender: Male
Calculator(s):
Class: Calc 1
YouTube: SixBeeps
Twitter: niorg2606
GitHub: SixBeeps

Re: Timing issues with the CX II

Unread postby 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: Select all
#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;
}
Attachments
tickfix.tns
(4.61 KiB) Downloaded 10 times
User avatar
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Level up: 64.1%
 
Posts: 167
Joined: 29 Mar 2014, 15:55
Gender: Male
Calculator(s):

Re: Timing issues with the CX II

Unread postby 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:
nLoaderCAS Patcher for ControlXnLaunchy CXM fork (3.9 CAS on B&W) - 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.
User avatar
parrotgeek1Programmeur
Niveau 11: LV (Légende Vivante)
Niveau 11: LV (Légende Vivante)
Level up: 79.1%
 
Posts: 757
Joined: 29 Mar 2016, 01:22
Location: USA
Gender: Male
Calculator(s):
GitHub: parrotgeek1

Re: Timing issues with the CX II

Unread postby 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.
User avatar
VogtinatorPremium
Niveau 8: ER (Espèce Rare: nerd)
Niveau 8: ER (Espèce Rare: nerd)
Level up: 64.1%
 
Posts: 167
Joined: 29 Mar 2014, 15:55
Gender: Male
Calculator(s):


Return to Problèmes divers / Aide débutants

Who is online

Users browsing this forum: Bing [Bot] and 4 guests

-
Search
-
Featured topics
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
-
Donations / Premium
For more contests, prizes, reviews, helping us pay the server and domains...

Discover the the advantages of a donor account !
JoinRejoignez the donors and/or premium!les donateurs et/ou premium !


Partner and ad
Notre partenaire Jarrety Calculatrices à acheter chez Calcuso
-
Stats.
613 utilisateurs:
>581 invités
>25 membres
>7 robots
Record simultané (sur 6 mois):
6892 utilisateurs (le 07/06/2017)

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