[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Waiting for a bit in a register to be cleared: which strategy?
On lug 03 11:15, Mouse wrote:
> I'm not sure what's "brutal" about those, but OK...
My ignorance about this kind of operations. Now I better understood,
thanks to your and Taylor's comments.
> Actually, because of your "& (uint32_t) NOT_CLEARED", it works
> regardless of the other bits in register A: you are masking off all but
> the low bit.
Oh, my fault. You are right.
> The other 31 bits - you're using bus_space_read_4, so it's reading 31
> bits. If register A is an 8-bit register
No, in this case it is a 32 bit register: this is why I used
> Efficient in terms of what resource? That is, what measure of
> efficiency are you interested in here?
Above all, the code complexity (not the hardware resource consumption).
> I'm having trouble thinking of one for which there's anything
> wrong with what you have.
OK, this is good!
> Check out the definition of __BIT - it is no different in practice
> from more or less what you're already doing.
Yes, now I better understood.
> There are multiple ways to do this.
> The simplest is probably to just put a limit on the iteration count:
> But this makes the timeout inherently dependent on the host CPU speed.
Yes, I excluded this because I would like to avoid using the CPU for
(potentially) millions of cycles and - as you said - because of the
CPU-dependent variable increment.
> If that's a problem, you could add a delay in the loop
I think this is the best in my case.
> If the device can be made to generate an interrupt when the bit
> changes, another answer is to make your driver enable that interrupt
> and go to sleep waiting for it. The changes for that are too large for
> me to give here; depending on the surrounding code structure, they may
> involve significant rearrangement.
Yes, check out my answer to Taylor, with a link to the device
documentation. Interrupts are maybe the ideal solution, but I'm
completely unable to handle them in a driver. I'm a complete newbie.
> The last two options have the advantage that they release the CPU to do
> other useful work while waiting. They have the disadvantage that they
> decrease responsiveness - the delay from the bit changing to the code
> reading register B increases significantly.
Yes, of coure.
> One is that busy-waiting is inefficient in that it does not allow the
> CPU to do any other useful work while waiting; if the delay is long
> compared to the time required to context-switch to doing other useful
> work, and there is, or might be, other useful work to do, this can be
I think the bit is cleared almost immediately, according to how I guess
the device works, so this could not be the case.
> The other is that, as I wrote, for some buses and some devices, you
> have to access a register as the correct width or it will not work
> I don't
> know enough about your setup to tell whether it's an actual mismatch,
> nor, if it is, whether the difference matters.
I am sure that a 32 bit access is correct. My reply to Taylor (see the
bottom of the text) should provide all the elements to evaluate the
Thanks for your help!
Main Index |
Thread Index |