The Craftmans Shop > Radio Control Models
Bruder Manitou 2150 - RC conversion
russ57:
Delay certainly executes a loop. Not sure about pulse in, I've not used that.
Pulsein long notes it uses interrupts, so that may be better.
If you are looking for pulses on many pins you may be better writing your own routine.
Russ
AdeV:
--- Quote from: ddmckee54 on December 20, 2019, 11:31:27 AM ---
Let me ask you this, what do know about the timing of the pulsein function? I'm not sure, but from what I read it sounds like if I tell the Nano to do a pulsein on a particular digital pin, it's going to sit there and wait until it sees that pulse. Program execution basically stops? Does program execution also stop during a delay, like I think it does?
--- End quote ---
Can't say I've ever used pulseIn - I'd have to go read up on it. Delay certainly stops program execution, and IMHO is to be avoided at all costs (except in the very very simplest of applications).
--- Quote from: ddmckee54 on December 20, 2019, 11:31:27 AM ---If that's what happens then I can see why everyone says you should use interrupts instead of the pulsein function. At 2 milliseconds per channel, when you add in some time separation between channel pulses, and some time at the end so the receiver knows there's a new pulse string coming - then we're looking at a 20-30 millisecond time for a complete pulse string. That's a longggg time for the Nano to be sitting there twiddling it's proverbial thumbs.
--- End quote ---
I guess it would depend on whether the Nano has other stuff to be getting on with, whilst it's waiting on pulses to come in. If there's literally no processing except when a pulse is received, then a blocking operation is OK. I suspect that isn't the case, so yeah, you'd be better off using interrupts. The usual rule is, keep your interrupt processor as tight as possible (this usually means incrementing or setting a variable only), and let the main loop pick up the fact it's changed. That's why I try to do FSM style programming on Arduinos, so the main loop can run around quickly, which makes it responsive to changes of state. The interrupts are what trigger the new state.
Gotta go, visitors arriving.
kayzed1:
AdeV, if knock on door=visitor then GoTo door :thumbup:
AdeV:
So.... this morning, whilst waiting for my brain to warm up, I had a quick read of pulseIn and pulseInLong - and it does look like they are blocking calls.
A quick google around showed a few options; my go-to option would be to use interrupts. In the interrupt handler, simply set a variable to the current value of the clock (IIRC micros()), and possibly a variable showing whether the pin went high or low (although you could do that in the main loop). Then, in the main loop, examine the clock variable & compare to your last known variable; if it's changed, either a pulse just started, or just finished; either way, process as applicable.
Another option - useful if you're not bothered about getting precise pulse timings, and you've got a fairly tight main loop; is simply to scan the pin states on every loop & process accordingly. However, you definitely don't want to use digitalRead() for that - it's too slow. There's a register you can examine directly which will give you the pin states without all the overhead; I can't remember what it is off the top of my head, but a bit of googling should give you the answer. The nice thing about that is you can read all the pin states in one op; then either spin through them using a bit shift, or even do a bitmap comparison for patterns of interest.
Either way - lots of ways to skin that particular cat! (poor cat)
ddmckee54:
I'm only going to be monitoring 2 channels, and all I care about is the width of the channel pulse in micro-seconds. By the very nature of the RC channel pulse train, those pulses can NEVER occur at the same time so I can use brute force on this and have these 4 interrupts:
Channel 1 rising - record the current program time in microseconds
Channel 1 falling - calculate the channel 1 pulse width in microseconds
Channel 2 rising - record the current program time in microseconds
Channel 2 falling - calculate the channel 2 pulse width in microseconds
If the pulse width value is less than 1000, I'll just shove 1000 in for the pulse width. That way I don't need to worry about what's going to happen when the program time rolls over in the middle of a pulse. Eazee-Peazee.
I got my assortment of "robot" parts over the weekend, I'm now the proud owner of a variety of gears, all in Mod 0.5, with bores of 2mm, 2.5mm and 3mm. Along with some mostly useless pulleys, wheels, and I think they're supposed to be paddle-wheels? My slow boat from China also brought me my slip-rings. The bottom line, I was working on the design for the slew drive over the weekend and I've just about got it done in CAD. If I've got my numbers right, I'll be able to slew the cab at a little over 2 rpm at full speed - which I think is about right?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version