|
|
| Author |
Message |
scibot
Joined: 14 Feb 2009
Posts: 4
|
|
Posted: 15 February 2009, 0:37 AM Post subject: Question about PulseOut? |
|
|
Hello Guys,
I am new to microcontrollers, and was considering buying the ZX-24a. I need to generate repetitive, sequential pulses on multiple pins, with the pulse widths at least at 10us, and the delays between pulses on any two pins at 5us
as a max. Will this controller meet my requirements? Will processing overhead prevent the 5us delay? I would appreciate if someone with an
O-scope could test the delay time between the pulses on different pins and
let me know if the 5us constraint can be met with this controller. Thanks |
|
| Back to top |
|
 |
stevech
Joined: 23 Feb 2006
Posts: 657
|
|
Posted: 15 February 2009, 5:32 AM Post subject: |
|
|
| look at the native mode versions of the modules. Faster. |
|
| Back to top |
|
 |
dkinzer Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 15 February 2009, 17:32 PM Post subject: Re: Question about PulseOut? |
|
|
| scibot wrote: | | Will processing overhead prevent the 5us delay? | The MPU chips on the ZX microcontrollers operate at 14.7456MHz, giving a basic clock cycle time of 67.8nS. Consequently, a 5uS interval comprises only 73 clock cycles. It is almost certain that the VM-based devices (such as the ZX-24a) will not be able to meet this requirement. Even with a native-mode device, the application would need to be very carefully crafted to have any hope of meeting it.
That said, it may be possible to accomplish your objective with some clever programming or with a little external hardware assistance. In order to suggest a possible solution, we would need to know more about the characteristics of the "repetitive, sequential pulses on multiple pins". |
|
| Back to top |
|
 |
scibot
Joined: 14 Feb 2009
Posts: 4
|
|
Posted: 17 February 2009, 2:33 AM Post subject: dkinzer wrote: |
|
|
| Quote: | | In order to suggest a possible solution, we would need to know more about the characteristics of the "repetitive, sequential pulses on multiple pins". |
I thought the following code might work
| Code: | Do
Call Putpin(6, zxOutputLow)
Call Putpin(7, zxOutputLow)
Call Putpin(8, zxOutputLow)
Call PulseOut(6, 10, 1) 'pulse pin 6 10us
Call PulseOut(0, 5, 0) 'delay 5us
Call PulseOut(7, 10, 1) 'pulse pin 7 10us
Call PulseOut(0, 5, 0) 'delay 5us
Call PulseOut(8, 10, 1) 'pulse pin 8 10us
Loop |
How much additional time will be added to the delays, and can
some one measure this while, say looking at pins 6 and 7
with a dual channel O-scope, I think that eliminating the Calls
to pin 0, might yield the inherent processing time, Is this correct?
Thanks |
|
| Back to top |
|
 |
dkinzer Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 17 February 2009, 3:29 AM Post subject: |
|
|
I ran the program below on a ZX-24n and captured the resulting waveform on a logic analyzer. | Code: | Sub Main()
Call PutPin(pinA, zxOutputLow)
Call PutPin(pinB, zxOutputLow)
Call PutPin(pinC, zxOutputLow)
Call PutPin(pinSync, zxOutputLow)
Do
Call PulseOut(pinA, 10e-6, 1)
Call PulseOut(0, 5e-6, 0)
Call PulseOut(pinB, 10e-6, 1)
Call PulseOut(0, 5e-6, 0)
Call PulseOut(pinC, 10e-6, 1)
Call PulseOut(0, 5e-6, 0)
Loop
End Sub | The table below shows the edge-to-edge timing (in uS) that resulted.
| Pin | Rising | Falling
| | 5 | 0 | 10
| | 6 | 49 | 59
| | 7 | 98 | 108
| | 5 | 148 |
With the PulseOut() delay calls commented out, the following timing was measured.| Pin | Rising | Falling
| | 5 | 0 | 10
| | 6 | 31 | 41
| | 7 | 62 | 72
| | 5 | 93 |
Note that this timing cannot be sustained because there will be an RTC interrupt every 1.95mS. Handling this interrupt will cause a significant skew in the timing.
As I suggested in my earlier response, having a description of your objective may lead to an alternate practical implementation. |
|
| Back to top |
|
 |
scibot
Joined: 14 Feb 2009
Posts: 4
|
|
Posted: 22 February 2009, 14:35 PM Post subject: |
|
|
| dkinzer wrote: | | As I suggested in my earlier response, having a description of your objective may lead to an alternate practical implementation. | Sorry for the long delay in additional feed back, but what I am trying to implement is to generate a pulse of a controllable duration on say pin(X), with a controllable delay before the generation of a controllable pulse on pin(Y). This pattern would be repeated for any number of pins, with the repetition rate of the pattern being programmable also. The pin to pin to pin ..... would be a cascade of pulses, a strob , as it were of pulses.
I had a thought that 555 timers might accomplish this in a hardwired fashion, although being able to do it all with software would be much cooler. Thanks again, any and all input is greatly appreciated. |
|
| Back to top |
|
 |
dkinzer Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 22 February 2009, 17:32 PM Post subject: |
|
|
| scibot wrote: | | [W]hat I am trying to implement is to generate a pulse of a controllable duration on say pin(X), with a controllable delay before the generation of a controllable pulse on pin(Y). | Given the pulse and delay durations that you've mentioned, it may be well to consider using an external counter and demultiplexer chip along with OutputCapture(). The counter would be configured to advance after each pulse thereby routing the next pulse to a different output of the demultiplexer.
If you wanted the pulse sequence to auto-repeat, you could use a PWM output instead of OutputCapture() as the pulse source and configure the counter to reset to the desired starting point at the end of each cycle. This could be implemented so that the sequence length is run-time programmable. |
|
| Back to top |
|
 |
scibot
Joined: 14 Feb 2009
Posts: 4
|
|
Posted: 24 February 2009, 12:13 PM Post subject: |
|
|
Your ideas sound like good ideas to me, and as l I said
in my original post I am new to microcontrollers, but your
suggestions give me more to learn, --thats a good thing---
and hopefully I'll get to the point that I can make meaningful,
and helpful post to the forum also. Thanks again !!!!!! |
|
| Back to top |
|
 |
|