Chronos > Software Dev

Deploying camApp from Qt Creator

<< < (3/6) > >>

Matom:
And I  have another question.

Does anyone know what the address of trigger 1 is? I am wondering if it is part of the FPGA code?
I would like to trigger it from the software instead of with an external voltage.

Any help would be very appreciated! :)

tesla500:
Hi Matom,

Sorry, forgot about the block diagram, I need to draw that up still.

Trigger is controlled by the FPGA, the all the trigger inputs are optionally inverted, debounced, then masked, then OR'd together before feeding the trigger delay unit. A register is also OR'd into this for software activation of the trigger, which is not currently used in the software, but does work.

The addresses of interest are
TRIG_ENABLE_ADDR - 3-bits, selects enable (1=enabled) for each trigger source: Bit 0 - IO 1, Bit 1 - IO 2, Bit 3 - Input 3
TRIG_INVERT_ADDR - 3-bits, selects invert enable (1=enabled) for each trigger source: Bit 0 - IO 1, Bit 1 - IO 2, Bit 3 - Input 3
TRIG_DEBOUNCE_ADDR - 3-bits, selects debounce enable (1=enabled) for each trigger source: Bit 0 - IO 1, Bit 1 - IO 2, Bit 3 - Input 3

SEQ_CTL_ADDR, bit 0 (SEQ_CTL_SW_TRIG_MASK) is the software trigger bit, writing a 1 is like making one of the trigger inputs active. Be careful you don't clobber any of the other bits when changing this, use a read-modify-write.

Here's an example of creating a trigger from software:

UInt32 reg = camera->gpmc->read32(SEQ_CTL_ADDR);
camera->gpmc->write32(SEQ_CTL_ADDR, reg | SEQ_CTL_SW_TRIG_MASK);
camera->gpmc->write32(SEQ_CTL_ADDR, reg & ~SEQ_CTL_SW_TRIG_MASK);

Let me know if this helps.

David

Matom:
Dear David,

Thank you very much, it helped a lot! We now have a functioning internal trigger :D
Don't worry about the diagram. It would still be very useful, but we can manage without.

Ideally I would like to turn of the screen, video and everything. Is there an easy way to do that?

Maja

Matom:
Dear David and the rest of Krontech,

I am sorry to keep bothering you about the SW. I am very close to my goal of making an internal trigger that stops the recording if a sudden burst of light appears. I just need a few more suggestions and maybe you can help. (Right now my trigger algorithm slows down the camApp, so it only processes something like 50 fps)

It is my understanding that the camApp runs three parallel threads. Is it possible to shut down one or two of them in order to save processing time? And how would this be done?

Is it possible to turn of the display? Either by using a specific function or by removing all the functions that make the image for the display?

Do you have other suggestions that would save me processing time? 

Maja

DDR:
Hm, I don't think you're going to get more than a couple percent by shutting down the additional threads. I think they're pretty light. I think the display doesn't actually eat any appreciable processing power either, if you're not interacting with it. :-\

I myself would be tempted to look at algorithmic improvements. Sampling fewer pixels, or sampling less often, that sort of thing. I don't know how you've implemented the light detection, though, or really what the bottleneck is there. (I mostly do graphical design work.)

I almost wonder if an led with some sort of amplifier circuit could work as a pluggable trigger. I'm pretty sure one could be constructed for a few bucks in parts, according to the Instructable I found. I don't know your specific use-case though so I can't really offer much usable advice on that front, I think. If you had something else, another camera say, with a light sensor and the ability to output a trigger signal, you could use that as well.

As a side note, sudden light-level changes would probably be a great thing for us to be able to trigger on in general. Sound too. It's theoretically possible… It would be very nice to have built-in.


Whatever happens, best of luck Maja!

Navigation

[0] Message Index

[#] Next page

[*] Previous page