[SOLVED] PIT questions

[HugeCode]

Hi all. I'm trying to make hobby OS and I have successfully proceeded to state when I'm able to make some PIT support. But I don't understand something about counters. So I have these two questions:

• 1. When working with counter 0 (system clock) there is OUT pin connected to IRQ0 on PIC. When is the interrupt requested? When OUT is low or high?
  2. When using Mode 3, there is OUT low for COUNT/2 clocks and hight for COUNT/2 too. Is the state of OUT changing after every clock, or it's for first half of counting and then it changes? If it's not changing after every clock cycle, whats first (LOW or HIGH)?

Please help.

[skeen]

When working with counter 0 (system clock) there is OUT pin connected to IRQ0 on PIC.

I'm going to assume your on an x86, where this is correct.

When is the interrupt requested? When OUT is low or high?

The PIC has two primary modes of operation, level- and edge- triggered, both of these are active high (trigger when the input on IRx is high).

Do notice however that the connection between the PIT and the PIC is not standardialized, however usually its connected directy, or through a buffer (mostly on old systems, when the PIT was a chip of its own).

[skeen]

When using Mode 3, there is OUT low for COUNT/2 clocks and high for COUNT/2 too. Is the state of OUT changing after every clock, or it's for first half of counting and then it changes? If it's not changing after every clock cycle, whats first (LOW or HIGH)?

The state changes after half the counting, and I do believe that it starts high and then drops to low after half the counts, but if you need a definitive answer, you'll need to check the spreadsheet.

[HugeCode]

Thanks.
According to your answer on first question.... When holding OUT high for more clocks: does the interrupt occur every clock or only once?
In PIC ICW4 there are bits for buffered mode. Does it have something to do with what you wrote? Or it's different? In that case, what does the buffered mode mean? Maybe fire interrupt on next cycle and not now?

[gravaera]

This thread is afflicted with people who have not read the official Technical Reference Manual for the i8254 PIT.

[Brendan]

Hi,

• 1. When working with counter 0 (system clock) there is OUT pin connected to IRQ0 on PIC. When is the interrupt requested? When OUT is low or high?

The PIC detects an IRQ when the PIT's OUT goes from low to high.

• 2. When using Mode 3, there is OUT low for COUNT/2 clocks and hight for COUNT/2 too. Is the state of OUT changing after every clock, or it's for first half of counting and then it changes? If it's not changing after every clock cycle, whats first (LOW or HIGH)?

Immediately after programming the PIT (setting the "mode word"); the OUT would be high for COUNT/2 clocks and then low for COUNT/2 clocks. For example, if the count is "65536 ticks" (about 55.2 ms) then OUT would be high for "32768 ticks" (about 27.1 ms), then OUT would be low for another "32768 ticks" (about 27.1 ms), then it will go high again (causing the PIC to detect an IRQ) and stay high for "32768 ticks" and low again for another "32768 ticks", then high (another IRQ) then low, then high (another IRQ) then low, ...

Note: If the count is odd this isn't entirely accurate - OUT would be high for "count/2 rounded up" clocks and then low for "count/2 rounded down" clocks. This means that the OUT signal wouldn't be a perfect square wave (but the IRQ would occur at the expected times). Also, if you set "count = 1" the universe will implode.

Finally, if you read the count then you should know that in mode 3 the PIT actually does "count = reload value" and then each tick it does "count = count - 2" (and the reload happens twice as often); which means that the count you read will be decreasing twice as fast. For this reason it's better to use mode 2 if you read the count (where the PIT does "count = reload value" and then "count = count - 1" each tick).


Cheers,

Brendan

[HugeCode]

OK. But when running level triggered mode: will the IRQ occur every clock it's hight or only once?

BTW in PIC ICW4 there are bits for buffered mode. Does it have something to do with what you wrote? Or it's different? In that case, what does the buffered mode mean? Maybe fire interrupt on next cycle and not now?

Thanks.

[Combuster]

This thread is afflicted with people who have not read the official Technical Reference Manual for the i8254 PIT.

will the IRQ occur every clock it's hight or only once?

Same lack of reading and sensible thinking seems to go for the PIC.

[Brendan]

Hi,

OK. But when running level triggered mode: will the IRQ occur every clock it's hight or only once?

In this case you'd get an IRQ as soon as the PIT's output goes high, and then another IRQ every time you send an EOI for the previous IRQ (until the PIT's output goes low again). This is what's known as an "IRQ flood" (e.g. 100% of CPU time spent servicing IRQs as fast as it can send the EOIs). There's no sane reason to misconfigure the PIC like this.

BTW in PIC ICW4 there are bits for buffered mode. Does it have something to do with what you wrote? Or it's different? In that case, what does the buffered mode mean? Maybe fire interrupt on next cycle and not now?

"Buffered mode" was something about using the PIC chip to control an external buffer placed between the PIC chip and the CPU's bus.

Note that the PIC chip was designed for a wide range of different types of computers. For "PC compatible" systems a lot of the things the PIC chip is capable of are entirely useless and don't make any sense at all; and for modern chipsets (where the "PIC chip" is part of much larger chip) a lot of the useless/pointless/unusable features of the original PIC chip typically aren't supported.

One example of this is "buffered mode". There never was any external buffer placed between the PIC chip and the CPU's bus for "PC compatible" systems and the feature made no sense; and it's very likely that a modern chipsets won't bother with it at all (e.g. where the chipset's datasheet says something like "unused, must be zero").


Cheers,

Brendan

[HugeCode]

Thanks alot.