http://bretjohnson.us/forum

Dear.

I have working on a real-time system made with djgpp.
If usb is bios enabled I have some problems. Some times someone takes the cpu control for a 500 us, I I don't know who.
I have solved the proble disabling USB from biios and using PS2 as keyboard input.

But nowadays PS2 are not present in pcs and I have to use USB as keyboard input. The new PCs based on Intel Soc don't have USB 1.0.

I have disabled via Interrupt controller all the interrupts but not =0 interrupt and the problem persist. Who an in which manner do you think takes the CPU control.

With your drivers I hane solved the problem, but I cannot use it because USB 1.0 is dissapearing

Thanks

I am working on a USB 2.0 host driver right now, but it is still under development. I'm not sure when it will be done. It will hopefully solve most/all of your problems.

When you enable USB support in the BIOS for mice and keyboards, it does some weird things. To process the keystrokes, the CPU goes into System Management Mode (SMM), a special CPU mode that bypasses all of the "normal" processes, including Protected Mode. There really isn't anything you can do about it except not let the CPU go into SMM, which you can't do if you want the BIOS to control the mouse and/or keyboard.

Thanks Bret.

I supose that SMM works similar to an standard interrupt. I will search information about it. The question is if I can catch SMM I can control the time when it is managed.

Thanks

I really doubt that you'll be able to trap SMM. It's initiated in hardware, through the SMI# pin on the CPU via a signal that comes from the PCI bus. It's hardware, not software. And, I don't think there's any way to temporarily disable the SMI pin with software (something equivalent to a CLI instruction or disabling the NMI via the CMOS), though there may be something in the MSR's somewhere or something that will let it happen. I think the only way you can manage it is to get it out of the SMM realm altogether, which means you can't use the BIOS.

But, if you figure out a way to do it, I'd sure be interested in the details.

Dear.

I am working on an Atom e3800 SoC. In register "SMI_EN - SMI Control and Enable (SMI_EN)—Offset 30h" from Power Management Controller from chipset is posible to disable SMI outside processor.

pdf: atom-e3800-family-datasheet.pdf (page 4356).

For my realtime I have one interruption every 1 ms. As I only uses one of evry 2 interrupts, in one interrupt I disable SMI and in the other I enable it. It works more or less.

When the USB takes the controll it takes a lot of time +-500 us. Do you think that could be possible to reduce this time via chipset?.

Thanks

So, you have the SMI disabled half the time. Since there's no "buffer" for the SMI lead, does that mean you're only seeing about half of the USB keystrokes, or is the SMI lead held high until it is acknowledged by the SMM code? What do you mean by "more or less"?

Which chipset are you referring to that you might need to replace? I don't think changing hardware will help much if at all -- the delay is caused by the time it takes to switch in and out of SMM and run the BIOS SMM code.

I enables and disables SMI everi 2 ms, in my tests I have no loose any keystroke, I supose it works similar to interrupt controller, SMI is asserted but as it is masked is not serviced, and becames serviced when I reenables SMI.

The question is that in the semicycle where SMI is enabled it can take cpu controll for about 500 us, I need this time to send CAN-OPEN messages (The CANOPEN card has not output buffer and I have to use interrupts to send new messages every time one is sended).

My question where if you know if it is possible to change USB performance, via PCI registers, or via BIOS functions, to reduce the time which is used for SMI service.

Thanks

It's good that you're not losing keystrokes. I don't think there's any way to reduce the time it takes to process the SMM code (around 500 microseconds in your case). That's built into the BIOS, and I don't think there's any way to change it. I think the only thing you can do is to try and make sure it never gets called, or at least that it doesn't get called when you don't want it to be.

Where is your 1 ms interrupt coming from -- are you using INT 70h or have you reprogrammed INT 08 or something else? You might be able to increase the interrupt rate and leave the SMI disabled for longer periods of time?

I am using intruupt 0 (INT08H), I have reprogram the timer chip to generate 1 ms interrupt and I call the old interrupt with a rate of 18 Hz +-.

I can reduce the interrupt rate as I am controlling some cnc motors making pid on every axe. I cannot reduce the rate because if I do it the system becomes more and more instable.

At the end I put a 100 us delay inside second interrupt (Interrupt where I am reciving canopen tellegrams, the card has input buffer but not output buffer). Before the delay I enable smi and after it I disables it and the system seems to works fine.

Only one thing, if I press Block Desp key (Catalan keyboard, I don't know the english name of the key, is between "print" key and "Pause" key) the system stops for a 25 ms.

At the moment I am trying to solve the Block key trouble.

Bret I have to aknowledge you by your help telling me that the problem wher in SMI.

Glad I could help.

In English, the key between PrintScreen/SysReq and Pause/Break is the Scroll Lock key. It's rarely used for anything practical, though I have seen it used in some spreadsheet programs. When Scroll Lock is enabled (it's a BIOS setting), instead of moving to the next cell up or down in the spreadsheet it moves the whole spreadsheet up or down on the screen. I also use the Scroll Lock status in one of my experimental/unreleased programs as well, one called KEYS2JOY which allows you to use the keyboard like a joystick (if you don't have a real joystick for a program that requires a joystick).

Some BIOSes insert really long delays when you press the ScrollLock, CapsLock, and/or NumLock keys. You might also want to see if you get the same delay when you press the CapsLock or NumLock keys, since I suspect they may have the same issue. One thing you can try is to use my SCANCODE program to intercept the ScrollLock key and turn it into some other key that doesn't cause a delay, or have it do nothing at all.

It's possible that SCANCODE will not really work all that well on a real-time system, but you could try it and see.

EDIT:
I also just thought of this. The delay could also be associated with the ScrollLock LED status light on the keyboard. I know sometimes it takes the keyboard a LONG time to process the LED request, but I have also seen BIOSes that purposely insert long software delays (I have no idea why they do it, I just know they do sometimes). Whether it's the BIOS or the keyboard hardware causing the problem, effectively disabling the ScrollLock key with SCANCODE should help, I think.

Hi Bret.

At the end I have solved the scroll problem catching int09 vector and when I see the scroll code on the keyboard chip port I don't call keyboard isr. I have to do that with all the keys that works with leds. As I can see every time someone works with led there are a do while loop waiting data port be empty.

The problem has been solved blocking caps lock, pause scroll and print key.