Page 2 of 5
Posted: Mon Mar 10, 2008 12:27 am
by eddyb
don't work volatile method
the setup code is:
Code: Select all
void timer_install(int frequency)
{
int divisor = 1193180 / frequency;
// Send the command byte.
outportb(0x43, 0x36);
// Divisor has to be sent byte-wise, so split here into upper/lower bytes.
char l = (char)(divisor & 0xFF);
char h = (char)( (divisor>>8) & 0xFF );
// Send the frequency divisor.
outportb(0x40, l);
outportb(0x40, h);
/* Installs 'timer_handler' to IRQ0 */
irq_install_handler(0, timer_handler);
}
@jamesm:
your method to set frequency doens't work: if i set 1 Hz, is faster than 11000 Hz. So, u should repair
LE:: the timer handler
is not executed when i'm in the loop. i verified this
Posted: Mon Mar 10, 2008 2:28 am
by jal
eddyb wrote:@jamesm: :P your method to set frequency doens't work: if i set 1 Hz, is faster than 11000 Hz. So, u should repair
Of course it doesn't work, the slowest you can set the thing is about 18Hz (used by the original PC).
JAL
Posted: Mon Mar 10, 2008 2:37 am
by eddyb
jal wrote:eddyb wrote:@jamesm:
your method to set frequency doens't work: if i set 1 Hz, is faster than 11000 Hz. So, u should repair
Of course it doesn't work, the slowest you can set the thing is about 18Hz (used by the original PC).
JAL
I said if freq is bigger, multitasking is slower(eg: 100 is faster than 10000)
Posted: Mon Mar 10, 2008 2:42 am
by JamesM
jal wrote:eddyb wrote:@jamesm:
your method to set frequency doens't work: if i set 1 Hz, is faster than 11000 Hz. So, u should repair
Of course it doesn't work, the slowest you can set the thing is about 18Hz (used by the original PC).
JAL
As mentioned on the tutorial page, had you bothered to read it.
I wrote:The programmable interval timer is a chip connected to IRQ0. It can interrupt the CPU at a user-defined rate (between 18.2Hz and 1.1931 MHz).
Posted: Mon Mar 10, 2008 2:51 am
by eddyb
so between 19 hz and 1100000 hz?
doesn't matter, anyway.
but why if i'm in a loop, the irq handler forgot to be executed? i've put a line that put something on the screen. that happens until i enter this loop
Posted: Mon Mar 10, 2008 3:27 am
by JamesM
How many times does the handler get executed in total? (before you "enter the loop")
Is it once, perchance?
Posted: Mon Mar 10, 2008 9:48 am
by quok
At this point I'd be pretty tempted to see the timer handler code itself. Are you forgetting to acknowledge the IRQ to the PIC?
Posted: Tue Mar 11, 2008 1:59 am
by eddyb
until i enter the loop, it is executed about 100 times per second
Posted: Tue Mar 11, 2008 2:43 am
by JamesM
eddyb wrote:until i enter the loop, it is executed about 100 times per second
How do you know? How many seconds actually elapse before you enter the loop? I would have thought "almost none", given what code you've shown. What else do you do that takes up so many seconds that you can get ~100 IRQs acknowledged?
Posted: Tue Mar 11, 2008 2:48 am
by Brendan
Hi,
eddyb wrote:until i enter the loop, it is executed about 100 - 1000 times per second
Do you know this, or are you assuming this?
Perhaps it's operating at 100 to 1000 times per second for a total of 0.01 to 0.001 seconds before your loop starts (and only firing once)...
In general, the CPU doesn't know the difference between "straight" code and a loop.
As I mentioned earlier there are problems with 2 CPUs, but in both of these cases the problem involves instructions that lock the bus (an explicit "LOCK" instruction prefix and/or an "XCHG" instruction that implicitly locks the bus). One is relatively rare/old Cyrix chips that you're not using, and one involves Pentium 4 with hyper-threading (and I really don't believe your OS is capable of using hyperthreading). Secondly, your loop doesn't do anything that locks the bus anyway. Therefore buggy CPUs are not the problem, therefore there isn't any difference between "straight" code and a loop, therefore your code or your compiler is buggy.
I *severely* doubt the compiler is buggy. I don't even need to know which compiler you're using to say this, because no compiler has ever been so buggy that it'd mess up such a simple loop (and I doubt any compiler ever will be that buggy).
That leaves your code and nothing else.
The loop itself has nothing to do with the problem. IMHO it only looks like the loop causes the problem because the code before the loop is too short for you to notice if the IRQ fires or not.
Cheers,
Brendan
Posted: Tue Mar 11, 2008 2:57 am
by eddyb
i've put some code that display(every time when the time handler is executed) some text on the screen. but i've modified at 100 times (was to faster); this is the code
Code: Select all
if (timer_ticks % 100 == 0)
put_dec(timer_ticks);
at each second, it put on the screen the number of the ticks
Posted: Tue Mar 11, 2008 3:47 am
by JamesM
at each second, it put on the screen the number of the ticks
Yes, but now many times does the text appear on the screen? Once?
Posted: Tue Mar 11, 2008 5:20 am
by zaleschiemilgabriel
eddyb wrote:(was to faster); this is the code
Code: Select all
if (timer_ticks % 100 == 0)
put_dec(timer_ticks);
What is timer_ticks? Check how it is declared and incremented, and if the condition (timer_ticks == 100) might be skipped (this could happen if you don't increment timer_ticks yourself, if you declared it wrong (it should probably be static/global), or if you reset it somewhere inside your loop). If you want more help with this, I think you're gonna have to post more code than that...
Posted: Tue Mar 11, 2008 9:55 am
by eddyb
JamesM wrote:at each second, it put on the screen the number of the ticks
Yes, but now many times does the text appear on the screen? Once?
Oh, man
many times i want. PS a image is more than 1000 words
Posted: Tue Mar 11, 2008 9:58 am
by JamesM
Probably best to just tar up your source and post it as an attachment (or post a link to it on the web). It would be easier to diagnose if we see the context.