Capture/Compare on the SX-28
LoopyByteloose
Posts: 12,537
I believe this can be done purely in software [noparse][[/noparse]a Virtual Perpheral], but I am wondering if an ISR is required or special I/O pins [noparse][[/noparse]such as Port B's edge detection]
Primarity I am trying to have 4 PWM signals captured in a series and stored as values to be recalculated and mixed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Primarity I am trying to have 4 PWM signals captured in a series and stored as values to be recalculated and mixed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Comments
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Ability may get you to the top, but it takes character to keep you there."
·
Well, it is r/c PWM, which is roughly a 20 microsecond pulse, but wanders. And the ON cycle is between 1 and 2 microseconds or according to Guenther's text it may only need to be between 1.3 and 1.7 microseconds.
From what I understand you don't need to measure the width of the whole pulse, merely the width of the on time. How accurately? Is 1% asking too much? Obviously, the rougher the measurement, the easier it is to do, but I am unsure of how rough is useful. 1/256 of 2 microseconds would require one byte; 1/16th would require one nibble. I suspect those the most convienent choices as I would be counting in a File Register.
I suppose that given those parameters, all I have to do is poll and increment the four inputs rather than actually to a capture/compare emulation. As I understand it, the R/C reciever outputs the pulses in series [noparse][[/noparse]one after another] and if I know the sequence I can start with the #1 in an ISR and move immediately on to #2 after #1 shuts down. [noparse][[/noparse]In otherwords, I do not have to seek information from all 4 in a random sequence or simultaneously].
Alternatively, I may be wrong and all the Pulses are arriving concurrently. This would require a different strategy.
This is an old challange as I was trying to write an Assembly language equivalent of the SAMs Autopilot and the jump from C to Assembly for this is a bit unclear.
Your discussion of the SX-48 Timers revived my interest.· But they seem to only measure on input each.· So,I still wonder if capture/compare happen to be something that Virtual Periphercal can or cannot do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
· Do you mean milliseconds ? That would be much more do-able.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Ability may get you to the top, but it takes character to keep you there."
·
I've always thought your timimg is better than mine.
I did locate a 16bit Timer VP by Bruce Wilson that seems useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Post Edited (Kramer) : 2/13/2006 2:13:56 PM GMT
Something along the lines of:
' Wait for reset DO PULSIN pin, 1, x LOOP UNTIL x = 0 ' Read next 4 pulses cnt = 0 DO PULSIN pin, 1, x IF x > 0 THEN values(cnt) = x INC x ENDIF LOOP UNTIL cnt > 3The default resolution for PULSIN in 10uSec, that is 1% of a 1mSec pulse.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Ability may get you to the top, but it takes character to keep you there."
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
And, I really don't want to use an SX-48 or SX-52 [noparse][[/noparse]with their timers] as this has already been designed and built in an SX-28. But it was coded with ByteCraft C.
Nonetheless, I will take a look at the SX/B. It seems nobody has a simple explanation for inputing R/C. I did Google quite a bit.
As I also said, I have 4 inputs and I don't have a scope so I am not sure if they are simultaneous or sequential. But it would seem that the SX-48/52 would only allow 2 inputs without using a VP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Barello has a assembler project·that describes·mixing 2-channel RC input channels into an H-bridge (http://barello.net/Papers/RCtoPWM/index.htm) and a C/Assembler project that exercises 4 RC channels via a joystick (http://barello.net/Papers/ServoPulseGenerator/index.htm). He seems to use the AVR microprocessor in C and Assembly, but translation shouldn't bee all that difficult.· As far as resolution of the PWM pulse, Barello seems to achieve 1 microsecond.
Blick has a project note for a dual channel PWM to H-Bridge written in C·(http://www.bobblick.com/techref/projects/sv2hb/sv2hb.html).·
In each project, you may have to read both·the description and code to get a clear picture of the R/C input.
Daniel
I thought you wanted to read the PWM pulse train that actually gets transmitted & received. This has all the channels in one signal.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Ability may get you to the top, but it takes character to keep you there."
·
Daniel,
I am trying to move a C program into SASM, so a C project doesn't help much.
Of course you say that Barello has an Assembler file, but it isn't for an SX - it is an Amtel product [noparse][[/noparse]which has a different Capture/compare setup].
Bob Blick seems a bit closer to home [noparse][[/noparse]with a PIC], but again I see a hardware capture/compare setup programed in C.
Bean,
From what I understand that combined channel is not truly PWM. It is an FM [noparse][[/noparse]frequency modulated] Pulse. I would have to acutally have to capture in more detail and decode frequency shifts. It is an interesting project, but I would have to receive, demodulate, and so on.
Time for me to just think in through.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Post Edited (Kramer) : 2/14/2006 4:17:04 PM GMT
Have you seen the following:
http://entertainment.howstuffworks.com/rc-toy.htm·shows how a cheap R/C toy's radio stream is constructed.· This is R/C in the only sense of remote control, limited control functions; it seems to use a·nonstandard radio stream.
Ron Jesme has posted a ultra-ligh-weight standard R/C receiver project at http://www.tcrobots.org/members/rjesm.htm·(about halfway down the page to Micro Receiver.· The linked article (http://tcrobots.org/articles/a05.htm) goes into some detail of his reverse engineering the R/C radio signal and its breakdown into channel control.
Perhaps I misunderstood, though.
If the situation warrents, post the C and we might be able to help you with the SX implementation.
Daniel
Additional articles are referenced at the end of the document.· The document describes the R/C radio signal rather completely, and seems to confirm Jesme's view of the same.
Daniel
Post Edited (daniel) : 2/14/2006 7:58:19 PM GMT
It is well modularized, and should be easy to lift and reuse.
-AGM-
The SX28 really only has the RTCC as a timer, and your challenge is best handled with an ISR.
I have attached some assembler code using an 8 channel state machine to determine the low duration of 8 sequential pulses from an RC receiver.
Because there is some inconsistency in the "end of sequence" determination among receivers, I'll leave it to yourself to figure that part out.
My implementation is meant as a tutorial; it is by no means the best way to do things. Use of subroutines would substantially shorten the code, but would cloud the operation of the state machine somewhat.
I have compiled, but NOT yet run this code as that is not convenient time just now, so it may still have some bugs.
Hope you can learn from it.
Cheers,
Peter (pjv)
I knew somebody must have done something similar [noparse][[/noparse]I am just not that original].· I will take a look.
Thanks Peter [noparse][[/noparse]pjv],
I took a look at your contest code and your style of notation is quite clear - very enjoyable to read.
FOR those of you who suggested building a reciever - I ALREADY HAVE a 4-channel reciever.· I want to mix and modify 4 separate channels of PWM·data at the reception end.
I spent some time today reviewing what I think it would take and an ISR is definetly part of it.
I have to capture the beginning and the end of each pulse just to get started, then I have to get the difference.
If I cannot restart the timer for each pulse, I have to trap values when the counter rolls over and do a special routine.
Then having done that, repeat the process 4 times. And the cycle repeats approxiably every 20 millaseconds [noparse][[/noparse]that creates another programing detail to work out].
I don't have a scope and I think I would need 4 inputs anyway [noparse][[/noparse]which is too expensive for me]. So I am just hoping that Jen's Autopilot article is right and the 4 pulses come one after another if you keep the inputs straight.
And YouALL,
Everyone else seems to want to drag me off the topic into RF electronics [noparse][[/noparse]away from digital] or into switching to C programing in another piece of hardware. Thanks for the effort, but I am interested in doing this in the SX and SASM and in software.
The C code is posted at the 3rd Prize contest winner in the 2005 SX Contents - Jen Altenburg's SAM flight controller.
I think I have a start.· I should be doing some of the work so I can learn.· Right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Post Edited (Kramer) : 2/15/2006 1:27:55 PM GMT
1) Let the virtual peripherals work in the background via the ISR, constantly updating registers with the most recent R/C input values.
2) The main code just loops, pulling the input values from the virtual peripheral's registers and acting on those values, using the most recent data to update the ouputs.
No need to worry about the 20ms timing, nor about the order of the input channel pulses.
This is the beauty of the SX's speed, and of the transparency of a well crafted virtual peripheral! Your big timnig/programming concerns are simplified into several smaller/easier tasks.
Even better, once you create a virtual peripheral to read a particular type of input, or to send a particular type of output, you can reuse that code in project after project.· No long piece of linear code that is application specific. No counting of assembler instructions to get the timing tweaked just right. No wasted time rewriting code for problems you've already solved.
-AGM-
Post Edited (Andrew G. Miller) : 2/15/2006 7:41:36 PM GMT
Use port B.· Set the 4 pins you need to interrupt on the first edge you want.· When an edge-detect interrupt fires off, change the direction of the edge detect for the pin that caused the interrupt.· When the second interrupt for that pin fires, record the time difference between the two.· You can use prescalers to scale the resolution of RTCC so that 255 fits over your maximum pulse width.· Or you could have a timer virtual peripheral running.
Is this at all what we're talking about?
I am learning a lot about how to collaborate and how to sort through different peoples approaches to writing SASM.
I too thought that I should use Port B, but I checked the AS BUILT board and it uses Port A.
Andrew came through with the most appropriate code.
[noparse][[/noparse]But be careful, it is buried as a 'Conditional R/C Reciever Routine' in over 30 pages of SASM.]
30 pages of code! For one chip.
The actual useful information comes out at one and one-half pages.
So I am moving ahead.
I suspect that if my ISR is fast enough, I can afford to miss the edge detection. Of course it means that I don't have the interupt either. Do I really need another interupt? I suspect not this one as it might upset the timing.
Andrew seems to think 127 pulses is adequate, so I have a lot of room for moving the timing around in code.
One of the problems with using the edge detecting is that I have to 'waste' a couple of steps of code to switch direction. So why bother? And it does limit me to Port B.
There are lots of ways to do this that are wasteful and I certainly have thought of my share.
Andrew simply has a Register assigned to each Input Pin and it is incremented when that Pin is High. Each pin is polled at a rate that is roughly 2ms/127.
Since there is a 2ms pulse with roughly a 18ms no pulse [noparse][[/noparse]could be much shorter] on one channel, you just immediately process the data for all ports after the last channel shuts down.
With front-to-back reception of 8 channels [noparse][[/noparse]8x2ms max] You still have about 4ms to do so under the worst case with 8 channels [noparse][[/noparse]but I am using only 4 channels].
In sum, I seem to be getting some very compact, simple code that can easily handle a full 8 channels of R/C PWM inputs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Quit worrying about the order of the input pulses!!! Quit worrying about 20mS timing!!! [noparse]:)[/noparse]
The R/C Input ISR code keeps a counter of all the input pulse lengths. When a pulse ends, the ISR checks if that pulse length was in range (1ms-2ms). If that pulse width is in range, the ISR moves that counter into·that counter's·result register. Your main loop code should only look at the result registers, not at the counters.
There is no need for the main loop to wait for all/any of the pulses. The result registers will always have the latest/last valid signal values received. The main code can continuously loop using/re-using these constantly updating values. If your main loop is faster/slower than 20mS, no problem.
(The only timing to be concerned with is the 1/256mS timing of the ISR, which you set with retiw, CPU speed, and maybe an ISR multiplexer.)
The values in the result registers are 7-bit, shifted to 8-bits. That is still better than 0.5degree/bit of resolution for your +/-30degree transmitter stick.
-AGM-
Post Edited (Andrew G. Miller) : 2/17/2006 12:25:00 AM GMT
I do understand now.
It appears the whole concept of 'capture/compare' is not needed in this case.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan