Main Site Documentation

Control camera shutter using level trigger: very precise GPIO toggle needed (uSec)


#1

Hi all,

this is my first post!
The ability to program in C# / NETMF recently drew my attention. The project I am prototyping now does nothing really fancy: move some stepper motors, readout some sensors, etc. All certainly easilly doable in NETMF and any of the GHI boards.

But, there one time critical operation I am worried about:
I need to trigger a camera, varying it’s shutter time on every frame. For this, the camera supports a so called “level trigger mode”. On rising edge exposure starts, on falling edge it stops, so the width of the pulse is the shutter time.
For my application shutter times will probably vary between 100uSec to 8ms. For the shortest shutter of 100uSec, being off by 1uSec is acceptable, but 5uSec (5%) would already be too noticeable.

I’ve digger though all docs I could find and figured the following options:

  1. The OutputCompare class, with it’s new SetBlocking method. I’ve read the blocking function is more accurate. But how accurate? Down to one uSec?

  2. Code it in RLP directly. I’ve found a post here saying that flipping a GPIO on/off through RLP takes about 1,25uSec. That is good. I combine that with RLPext.delay(uSec). But then, what is the accuracy of RLPext.delay? Is it down to the uSec?

  3. Though flipping a GPIO is much faster with RLP, I guess the 1,25uSec are attributed to the time of the function calls. Can’t that be done much faster by just setting some register value directly? Is this doable?
    Also: I’ve already found about the RLPext.delay() function. But I see no way to get the processors “tick count” in RLP. Shouldn’t that be available to RLP?

  4. Use the PWM unit. Unfortunately I saw no way to generate a single pulse, I didn’t even find a method to turn the PWM unit completely off, to reconfigure it and re enable it when the camera is ready for the next exposure.
    Can that be done? I’m hoping it must not be done though disposing the object - it sounds like a bad idea to create and dispose maybe around a hundred “PWM” objects per second.
    Also: I’m not sure the PWM can be configured at the needed time spans of say 100uSec to 8ms.

So, I’d love to hear some thought’s from you guys.

I did not order a board yet. I’m eying a FEZ Cobra (currently out of stock), mainly because the board already has all I need or plan to play with (Ethernet, Serial, CAN). If needed, I could go with the ChipworkX.

Best regards
Mark

PS: I had already almost given up NETMF after reading about it’s non RT nature, thread scheduling of 20ms, etc. It’s good that I looked more closely at the GHI docs and found about RLP.
@ GHI guys: I think you should explain the RLP feature more prominently on your website(s). This is in my eyes a very important feature that greatly expands the usability of your products.


#2

[quote]1) The OutputCompare class, with it’s new SetBlocking method. I’ve read the blocking function is more accurate. But how accurate? Down to one uSec?
[/quote]
Yes to uSec

[quote]2) Code it in RLP directly. I’ve found a post here saying that flipping a GPIO on/off through RLP takes about 1,25uSec. That is good. I combine that with RLPext.delay(uSec). But then, what is the accuracy of RLPext.delay? Is it down to the uSec?
[/quote]
You can even code an assembly and make it more accurate! In RLP you are running right on the processor with full direct control.

[quote]3) Though flipping a GPIO is much faster with RLP, I guess the 1,25uSec are attributed to the time of the function calls. Can’t that be done much faster by just setting some register value directly? Is this doable?
Also: I’ve already found about the RLPext.delay() function. But I see no way to get the processors “tick count” in RLP. Shouldn’t that be available to RLP?
[/quote]

The processor has multiple timers, just use one for your own purposes.

[quote]4) Use the PWM unit. Unfortunately I saw no way to generate a single pulse, I didn’t even find a method to turn the PWM unit completely off, to reconfigure it and re enable it when the camera is ready for the next exposure.
[/quote]
PWM is not meant to generate “one pulse” but like I said, in RLP you can control the PWM registers and implement any drivers you like.

[quote]Can that be done? I’m hoping it must not be done though disposing the object - it sounds like a bad idea to create and dispose maybe around a hundred “PWM” objects per second.
Also: I’m not sure the PWM can be configured at the needed time spans of say 100uSec to 8ms.
[/quote]

100uS to 8mS is slow! I wouldn’t worry about it at all. To try things out, you only need a $40 FEZ Panda :slight_smile: I heard it would be the best $40 you invested in a product in a long time :slight_smile:


#3

Great to hear this Gus. I’ll go for the Cobra, mainly because I would need some soldering and the Ethernet shield with the Panda.

You mentioned timers: do I use these through RLP_Task?

OutputCompare probably uses RLP.Delay + RLP.WritePin in blocking mode. Downside is probably it uses all processor resources while running.

Do you think I can also get the uSec accuracy using timers/RLP-Tasks?
I am guessing this does not block the CPU.

By the way, what does OutputCompare do in non blocking mode - is it using timers? How accurate is it?

Regards Mark


#4

What you are looking to do is real easy to accomplish if I understand you needs right. Why don’t you get started on NETMF then then we can cover RLP when you are ready. We will be here ready to help :slight_smile:

You most critical time is 100uS! That is nothing for a 72Mhz 32-bit processor, that is 14nanoSec/instruction, or 7143 instructions per 100uS :slight_smile: