fiq design

General discussion about anything related to Ultibo.
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Sun Jul 14, 2019 12:00 am

rvanspaa wrote:I tried commenting out the spinlock/spinunlock & recompiled ultibo, but it made no difference.

That's lucky in a way because I think the spinlock would likely be a mandatory part of the handler in order to prevent a race with other CPUs.

I would have thought the try/finally would potentially be more expensive since it has to save the entire state of the CPU, but you'd have to test it to find out.

rvanspaa wrote:BTW is there a simple way to just recompile one unit of Ultibo, without recompiling the whole thing?

Not really, the way FPC works is that generally the RTL has to be built as one, for some units the are not relied upon by others you can take a copy of them and simply compile out of band but if there are any interdependencies then that becomes impossible.

I do recommend creating yourself a batch file based on the __buildrtl.bat which compiles just the section of the RTL you want in order to save building the entire thing (ie ARM6/7/8 RTL and Packages) everytime.
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 27
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Sun Jul 14, 2019 12:54 am

Ultibo wrote:That's lucky in a way because I think the spinlock would likely be a mandatory part of the handler in avoid to prevent a race with other CPUs.
I would have thought the try/finally would potentially be more expensive since it has to save the entire state of the CPU, but you'd have to test it to find out.


Thanks, I'll give it a try sometime soon. Trying one or two other things first.
rvanspaa
Posts: 27
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Sun Jul 14, 2019 3:05 am

Hi,

I found the cause of the problem. I had defined the "speed" parameter as "word" rather than longword, so by definition the upper limit on speed was 65535. :oops:
Once I replaced if with longword, I started getting much better numbers. :D
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Sun Jul 14, 2019 6:28 am

rvanspaa wrote:I found the cause of the problem. I had defined the "speed" parameter as "word" rather than longword, so by definition the upper limit on speed was 65535. :oops:
Once I replaced if with longword, I started getting much better numbers. :D

Excellent, thanks for letting us know.
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 27
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Sun Jul 14, 2019 11:43 pm

Hi,

Just thought I would show you some testing runs. Note that when the interrupt gets overloaded, the number increases dramatically (see last entry). I suspect this may have something to do with the interrupt not being cleared before the next interrupt is generated, but that's just a guess. BTW, I haven't checked yet, but do interrupts get masked when they happen, by which I mean does the occurrence of an interrupt result in no more being allowed until the current interrupt has completed processing?
BTW "Percentage of interrupts lost" may not be an accurate description of the number calculated. The number is actually the difference between the count from the device and the count accrued in the interrupt itself, as a percentage of the device count.

PS:- PLEASE IGNORE THESE RESULTS. START TIME WAS TAKEN AT WRONG POINT IN CODE, RESULTING IN INTERRUPTS DELAYING COLLECTION OF START TIME!
Attachments
times.zip
(660 Bytes) Downloaded 10 times
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Mon Jul 15, 2019 11:42 pm

rvanspaa wrote:BTW, I haven't checked yet, but do interrupts get masked when they happen, by which I mean does the occurrence of an interrupt result in no more being allowed until the current interrupt has completed processing?

Currently when an IRQ occurs then all IRQs remain disabled until it is serviced, when an FIQ occurs then all further FIQs remain disabled until servicing of the current one is completed. So an IRQ cannot occur again while one is being processed and an FIQ cannot occur again while one is being processed, however an FIQ can (and does) occur while an IRQ is being processed.

The handlers (and the entire core) are all written to allow recursive IRQ and FIQ processing so that a higher priority interrupt can be serviced ahead of a lower priority interrupt. The limitation at present is that the interrupt controller in the Pi 1, 2 and 3 does not support interrupt priority or interrupt masking so until the current IRQ or FIQ has been cleared by the interrupt handler for the specific device then re-enabling IRQ or FIQ would simply trigger another interrupt immediately and cause an interrupt storm.

The new interrupt controller in the Pi 4 (GIC-400) allows both priority and masking which should also allow recursive interrupt handling.

rvanspaa wrote:PS:- PLEASE IGNORE THESE RESULTS. START TIME WAS TAKEN AT WRONG POINT IN CODE, RESULTING IN INTERRUPTS DELAYING COLLECTION OF START TIME!

Ok, we'll wait to see the updated results when you resolve that.
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 27
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Tue Jul 30, 2019 5:15 am

Hi,

Ultibo wrote:Ok, we'll wait to see the updated results when you resolve that.


I've compiled the results of some tests into a little table (see attached).
Attachments
RPi-interrupts.png
RPi-interrupts.png (6.6 KiB) Viewed 321 times
rvanspaa
Posts: 27
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Tue Jul 30, 2019 8:03 am

Hi,

Just one last addition. This falls in the "neither column".

000000E5 - 0261845C - Configuration:- Neither try-finally nor spinlock enabled
000000E6 - 0261845C - Pin # = 43
000000E7 - 0261845C - Actual requested speed = 914285 interrupts/sec.
000000E8 - 0261845C - Run duration = 14.545 seconds
000000E9 - 0261845C - GPIO Interrupt count = 11861706
000000EA - 0261845C - Actual executed interrupt count at end = 11396590
000000EB - 0261845C - Interrupt rate = 783547.362/second
000000EC - 0261845C - Percentage of interrupts lost in interrupt precedure = 3.9211560293266414E+000%
000000ED - 0261845C - Interrupts processed as a percentage of requested = 8.5700559641565363E+001%

I think that's about the best I can get.
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: fiq design

Postby Ultibo » Wed Jul 31, 2019 9:32 am

That at least confirms that the try/finally is more costly than the spinlock (as suspected).
Ultibo.org | Make something amazing
https://ultibo.org
rvanspaa
Posts: 27
Joined: Sat Nov 11, 2017 3:04 am

Re: fiq design

Postby rvanspaa » Thu Aug 01, 2019 12:12 am

Ultibo wrote:That at least confirms that the try/finally is more costly than the spinlock (as suspected).


Indeed, which leads me to ask if the try-finally is really needed? Also, is spinlock needed for a single CPU machine like the RPi?

Return to “Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests