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 bus_space_read_4. > 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 > significant. 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 device. Thanks for your help! Rocky
