 | | Re: Ir transmission —John Cooper
|
| | | (...) Perhaps EMIT? would do (...) I'm nearly done with my NQC to pbFORTH port of the IR proximity detector, but I'm stuck where I have at present got a 30ms delay (Sleep(3) in NQC). I expect it isn't critical but the current detector works so well (...) (26 years ago, 14-Apr-99, to lugnet.robotics.rcx.pbforth)
|
| | | |
| | | | | RE: Ir transmission —Ralph Hempel
|
| | | | (...) Alas, I only used the firmware timers available as core RCX firmware calls. I can look through Kekoa's disassembly to see if there are higher resolution timers available ( I think the motor timers might be useful ) In general, NQC hooks in (...) (26 years ago, 15-Apr-99, to lugnet.robotics.rcx.pbforth)
|
| | | | |
| | | | | | Re: Ir transmission —John Cooper
|
| | | | (...) The bytecode interpreter does it, which is what NQC maps to (opcode 43). I'd prefer a timer (or access to a clock) with millisecond resolution rather than a delay because things will get interesting whan multitasking. What is the CPU clock (...) (26 years ago, 16-Apr-99, to lugnet.robotics.rcx.pbforth)
|
| | | | |
| | | | | | RE: Ir transmission —Ralph Hempel
|
| | | | (...) I think its around 16 Mhz for the crystal and 4 MHz for the cycle time. I think there is a msec timer buried in the OC1A handler (see Kekoa's disassembly) I agree that we want something to trigger a run flag instead of having to check the (...) (26 years ago, 16-Apr-99, to lugnet.robotics.rcx.pbforth)
|
| | | | |
| | | | | | Re: Ir transmission —John Cooper
|
| | | | (...) Well, in the spirit of FORTH there should be no finite number, just create and destroy them on the fly as and whan you need them. I have been wandering around the internet looking and found that hForth has one already: \ hForth multitasker \ \ (...) (26 years ago, 17-Apr-99, to lugnet.robotics.rcx.pbforth)
|
| | | | |
