OSDev.org

RTC, obviously; the RTC chip fires at exactly 1024 per second (or at another integer value if you told it to, in the first place). The PIT fires at non-integer frequencies f.ex. 18,2 per second so it is simpler to make a delay function with the RTC.

Moreover, you will perhaps like a design similar to mine, where the PIT is scheduler-only related and the RTC for delays, timestamping, calls after a specified time. That way the scheduler is sure it won't be delayed by the other functionality.

Cheers

Thank you, it works
If I want to use IRQ8, is there anything special I need to do? I got an ISR and all that, and I use to enable the IRQ, but I still dont get no IRQ fireing

stupid IRQs, I cant get IRQ 8 working. I?ve mapped it into interrupt 0x28. I unmask IRQ 8 (IRQ0 on the slave) and IRQ2 (connection to the PIC slave), I?ve written an ISR and all that, but the IRQ8 isnt fireing..

Hi,

Jess wrote: stupid IRQs, I cant get IRQ 8 working. I?ve mapped it into interrupt 0x28. I unmask IRQ 8 (IRQ0 on the slave) and IRQ2 (connection to the PIC slave), I?ve written an ISR and all that, but the IRQ8 isnt fireing..

Does your initialization code:
- Set the Prescaler control bits and Periodic Interrupt rate control in RTC REGISTER A
- Set PIE, Periodic Interrupt Enable (and clear the other interrupt sources) in RTC REGISTER B
- Add your IRQ handler to the IDT
- Unmask IRQ8 in the PIC chips
- Read from RTC REGISTER C to clear any stale IRQs

..and does your IRQ handler:

- Read from RTC REGISTER C to clear the IRQ
- Test the value read from RTC REGISTER C to see if it was the periodic interrupt that caused the IRQ (this step only necessary if you enable more than 1 interrupt source in RTC REGISTER B).
- Update some sort of (volatile) count variable
- Send the EOI to both PIC chips


Cheers,

Brendan

Jess wrote: Gotta register

Dont do it twice.

Adek336 wrote:RTC, obviously; the RTC chip fires at exactly 1024 per second (or at another integer value if you told it to, in the first place). The PIT fires at non-integer frequencies f.ex. 18,2 per second so it is simpler to make a delay function with the RTC.

Moreover, you will perhaps like a design similar to mine, where the PIT is scheduler-only related and the RTC for delays, timestamping, calls after a specified time. That way the scheduler is sure it won't be delayed by the other functionality.

PIT, obviously. ;D At least for short delays. The RTC can only be programmed to fire at particular frequencies, so any delay period implemented using the RTC will end up being rounded off. You can get closer to the exact specified time using the PIT.

Moveover, if you are attempting to delay for a short period of time, it's probably more critical that you meet that time as closely as possible than it is that the next ordinary task switch occurs on schedule. Ordinary task switches aren't time critical, and ought to be implemented on an lower priority IRQ. Tieing the general purpose scheduler to the RTC helps make sure more critical timing intervals can be set independently on the PIT and not be delayed by the scheduler.

No I dont read the RTC REGISTER C, gotta find this..

I guess I also need to unmask IRQ2 (cause IRQ8 is on the slave), right?

Works great now, thanks yall

Got a problem, but I dont know if it?s the emulator (bochs) or my code.
I send this to the status register A
0 010 0110

That will cause 1028 interrupts / second(I think). But then I loop until I?ve got 10 000 interrupts (that would be about 10 seconds)... But this only takes about one second, not 10 as I want it to

this is my code: and my IRQ handler: It goes to fast, but as I mentioned before, it may be caused by the emulator?

You won't get accurate timing from Bochs (Or any other emulator for that matter) simply because it IS an emulator.

Without a real PIT/RTC the interrupts you're receiving are not going to be anything like accurately timed, will depend on how fast the emulator is running, and will vary from run to run of the emulator.

In short test timing code on a real PC for accurate values.

Alright thanks..
just finding it weird cause such thing should be faster on real hardware?

Nope, not at all.

Ever noticed that if you're running Linux on Bochs it will blank the screen really quickly when idle? And the clock on any simulated OS will run fast?

Bochs will simulate the PIT at stupid speeds when not busy, and torturously slow speeds when under load.

VMWare gets closer, but still isn't perfect.

As I said, the only way you'll get accuracy is to run on real hardware.

Alright, thank you works great on real hardware

You could try the 'PIT' option in Bochs It will give you some semblance of real speed (although not accurate as Curufir already pointed out)

Curufir wrote: Without a real PIT/RTC the interrupts you're receiving are not going to be anything like accurately timed, will depend on how fast the emulator is running, and will vary from run to run of the emulator.

Bochs is deterministic, so it shouldnt vary from run-to-run. Because bochs emulates every part of the cpu and common MB hardware instead of virtualizing it, you are guaranteed that timings will be consistent with each other from one run to the next, though (as we have all experienced) not consistent with real life. If you ever want bochs to lend a hand helping you deal with race conditions (just last week it helped me tremendously) I suggest not using any specific PIT options to make it more like real-time, or at least keep in mind that it might affect the determinism.

I recently had a problem where, because the emulated floppy responds so quickly, I was getting an interrupt to wake up a process before it had been put to sleep, causing it to wait forever. by enabling the gdb stubs and stepping through my code, i was able to see that, when it was about to put the process to sleep, it jumped to the interrupt handler. Thats one reason that OS testing in an emulator like bochs can be very handy, even if it does mess with stuff like real time.