Implementing an additional, high-priority thread for monitoring serial data - page 3 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 [3] 4 5   Go Down

Implementing an additional, high-priority thread for monitoring serial data

  • 42 Replies
  • 22741 Views
*

Offline staylo

  • **
  • 51
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #20 on: 04 / December / 2007, 19:17:32 »
Advertisements
Well, we're getting there. In playback mode (low CPU use) I get up to ~2000 packets received OK for 1 error (pretty cool!) , in recording mode I get ~10 good packets per error (less cool ;)).

This is just because I've been trying to achieve the timing through trial-and-error rather than a procedural approach. So it's barely - but consistently - working when we have a constant CPU load, and when the CPU load varies it topples over in spectacular fashion :o

The pieces will start to fall in place soon.
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #21 on: 05 / December / 2007, 06:21:00 »
So, in Record mode, how do we check the USB faster than every 10 msec ?


Do you know if there is a single command that will fire the shutter directly ?




David
Logged
*

Offline crunchy_3d

  • *
  • 25
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #22 on: 06 / December / 2007, 01:20:01 »
Quote from: staylo on 04 / December / 2007, 19:17:32
Well, we're getting there. In playback mode (low CPU use) I get up to ~2000 packets received OK for 1 error (pretty cool!) , in recording mode I get ~10 good packets per error (less cool ;)).
...
The pieces will start to fall in place soon.

Any progress?
Have you tried switching off the LCD screen before running tests? It has been discovered (by chance) that execution of "read keyboard" routine runs at exact 10ms interval only when LCD display is switched off. When it is switched on, execution interval varies. It seems that LCD screen routines have relatively high priority and they might interfere with your program as well?!?
« Last Edit: 06 / December / 2007, 01:54:50 by crunchy_3d »
Logged
*

Offline staylo

  • **
  • 51
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #23 on: 06 / December / 2007, 16:16:03 »
Quote from: crunchy_3d on 06 / December / 2007, 01:20:01
Any progress?
Have you tried switching off the LCD screen before running tests? It has been discovered (by chance) that execution of "read keyboard" routine runs at exact 10ms interval only when LCD display is switched off. When it is switched on, execution interval varies. It seems that LCD screen routines have relatively high priority and they might interfere with your program as well?!?

That's interesting, thanks! Work's got in the way last evening and today (Finished too late to contemplate working on CHDK), but I've had an idea for a different approach which should improve the accuracy and make the code adapt easily to different CPU loads.

Quote
So, in Record mode, how do we check the USB faster than every 10 msec ?

Do you know if there is a single command that will fire the shutter directly ?

David

I'll send you an email when I get a chance, we'll see if we can get the camera sync times down. :) There's a command somewhere for firing the shutter directly.
Logged
*

Offline staylo

  • **
  • 51
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #24 on: 09 / December / 2007, 11:53:44 »
Right, spent a lot of time on this this weekend (including losing several hours through not realising that the operator ! is not equivalent to ~ in C - grr  :P) and now have it working in a stable manner at 4800 baud. The code's ripe for improvement, but it works.

Previously I'd been communicating via a PICAXE programmable chip, but I've now been able to communicate from a PC or Pocket PC to the camera. The bad news is it requires a small bit of electronics inbetween to get the RS232 voltages into the range desired by the camera (I'm currently using a darlington driver IC and a 5V supply), the good news is we should be able to power this electronics from the RS232 port of the PC or Pocket PC (or whatever - even mobile phones have RS232 ports)) and potentially get very good range.

An example of the kind of flexibility this gives: My demo app runs on a Pocket PC and has two sliders: focus and zoom, and a shutter button. The focus and zoom can each be set to one of 32 positions (though the A series only goes from 0 - 8 ), and the shutter can be held for taking continuous shots.

I'll polish up the code a little later on and post a link.
Logged
*

Offline staylo

  • **
  • 51
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #25 on: 10 / December / 2007, 18:10:51 »
Here we go, though only for advanced users at the moment: Attached is the kbd.c file (for generic folder), used with fingalo's 125 build code. Tested successfully with A640 and A630, no idea what else it'll work with (But fingalo's research suggests it most likely doesn't work with the G3 :( )

Again, you need a bit of electronics to convert the signal from RS232 levels to a high of ~3V - 5V and a low of 0V. I'm using a darlington driver IC and a seperate 5V source at the moment.

RS232 settings are 4800 baud, 8 data bits, no parity and at least 1 stop bit.

A constant stream of data is best since the camera is only listening to the port for a few milliseconds at a time.

Code is setup for the following scheme: 3 bytes transmitted for 1 byte of data; 1st byte is a handshake byte with a value of 0, 2nd byte is data byte, 3rd byte is an error checking byte (data byte with each bit inverted). (Example in VB.NET below) It's very easy to expand the code to carry more bytes.

Code: [Select]
    Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
        Dim x(2) As Byte
        x(0) = 0
        x(1) = Command
        x(2) = 255 - x(1)
        Serial.Write(x, 0, 1)
        Serial.Write(x, 1, 1)
        Serial.Write(x, 2, 1)
    End Sub
Attached scripts: checkerrors.BAS : Just displays the value of the last received data byte.

Better examples and more documentation to follow tomorrow. I'm running out of time again, and it seems to be at the state necessary for my needs, so won't be doing much active development, but please ask any questions.
Logged
*

Offline crunchy_3d

  • *
  • 25
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #26 on: 11 / December / 2007, 01:37:29 »
Staylo, congratulations! I am also trying to fetch USB signal as fast as possible (by using another approach). However, I'll probably apply some of your "ideas" in my code as well.
Logged
*

Offline crunchy_3d

  • *
  • 25
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #27 on: 14 / December / 2007, 14:00:02 »
Congratulations again! The USB signal is detected within few microseconds!

Quote from: staylo on 06 / December / 2007, 16:16:03
There's a command somewhere for firing the shutter directly.

Do you know such function? Anybody else knows how to trigger "shoot_full" function directly??
Logged
*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #28 on: 14 / December / 2007, 14:17:25 »
Quote from: crunchy_3d on 14 / December / 2007, 14:00:02
Do you know such function? Anybody else knows how to trigger "shoot_full" function directly??
Currently, the only way is to emulate shutter button press. But you can try to find appropriate function.
Logged
CHDK Developer.
*

Offline staylo

  • **
  • 51
Re: Implementing an additional, high-priority thread for monitoring serial data
« Reply #29 on: 14 / December / 2007, 14:53:13 »
You're right, I was thinking of the command to add a shoot task to the queue:

kbd_sched_shoot();
Logged
Pages: 1 2 [3] 4 5   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal