Triggering 5 TTL clocks simultaneously

[mister_e]

you don't really need that kind of switch.... place a pull-up or pull down resistor will do the job as well.

For the logic analyser stuff... great idea if you have one. Case not, if you still have an analog scope, it's easy to build one with few CMOS components.

[TurboLS]

We have a DigiView in the lab. I have never used one, so I am gonna take a few hours one day just to learn the ropes. But yeah, I definitely have one to work with. Also, since this is a camera, I think a physical button was the way to go, since, down the road, we want to make this thing hand held.

[TurboLS]

OK, I think I realized why my data is taking so long to transfer. It is because the PIC is sending the character representations of 1's and 0's, which are 49's and 48's. Is there a way to send out true binary data? (Matlab picks up the 48's and 49's which is how i figured the whole thing out.) thanks.

[TurboLS]

OK, I have increased the baud rate to 38,400 baud. I have exactly 407,680 8 bit samples to take. I am sampling at about 3.6kHz. How long do you think it should take to sample the data, do the A/D conversion, and send it off chip serially at these speeds?

Here are my time calculations:

407680 samples = 3261440 true bits of data. However, since the PIC can only send out the ASCII representation of the formats I want (mainly decimal and binary), each number (the 2 in 255 for example) requires 5 bits to store since the decimal value of the character '2' is 50. So technically, each bit of data sampled on the PIC requires 5 bits to transfer. So I estimated that since there are 5 bits to send for each bit sampled, the total amount of data to transmit is 16,307,200 bits. So, if the data were already on chip, it would take about 8 minutes to get it all out. Then I added the amount of time it takes to sample the data, which is about 3 minutes (with slack) and so the whole thing should take around 10 minutes, right? Wrong, hyperterminal has been reading data for over a half hour and is still going. Should I use a faster sampling rate since I can now send data out at 38,400 baud? Am I overloading the stack? I don't know.

thanks for any input.

[TurboLS]

OK, we got the logic analyzer working and I think some of the commands are taking a lot longer than I had expected.

The horizontals are not even close to 50% duty cycle as one is high for 960 usec and low for 140usec (the other horizontal is opposite). I was shooting for more in the neighborhood of 140usec for both the high and low for both clocks. In addition, I can't seem to see the vertical on the logic analyzer at all. Maybe i need to adjust some settings, but I'm gettin kinda worried.

thanks for all the help.

My updated code is below:

' Connect analog input to (RA0)
' Connect clocks to PORTB
' PORTB.0 is the Reset Clock
' PORTB.1 is the Vphase1 clock
' PORTB.2 is the Vphase2 clock
' PORTB.3 is the Hphase1 clock
' PORTB.4 is the Hphase2 clock
' The reset will be connected to a HWPM clock pin #17, USE FEEDBACK WIRE!!
' Connect pin 2 from the DB9 connector to PORTC.6
' Have a +5V source ready to touch PORTA.2 to trigger clocking process

include "modedefs.bas"

' Define ADCIN parameters
Define ADC_BITS 8 ' Set number of bits in result
DEFINE OSC 20 ' Sets clock speed to 20Mhz


' Define HPWM parameters
DEFINE HPWM1_TIMER 2
DEFINE CCP1_REG PORTC
DEFINE CCP1_BIT 2 ' RC2

TRISC.1 = 0 ' HPWM automatically does this for you, but just in case
CCP1CON = %00001100 ' PWM mode

HPWM 1,127,3600 ' RC2/CCP1 3.6kHz @ ~50% duty

' Define interrupt parameters
INTCON2 = %01000000 ' External Interrupt on Rising Edge
INTCON.7 = 0 ' Disables global interrupts
TRISA = %11111111 ' Set PORTA to all input
ADCON1 = %00001110 ' Set PORTA digital, except for bit 0
TRISB = %00000001 ' Set PORTB to all output, except for bit 0
Pause 500 ' Wait .5 second
Pause 500 ' Wait .5 second

horizpulse var byte
vertpulse var byte
adval var byte ' Create adval to store result

horizpulse = 1 ' Initialize counters, initial states
vertpulse = 1
PORTB.1 = 0
PORTB.2 = 0
PORTB.3 = 1
PORTB.4 = 0
PORTB.5 = 0 ' LED off indicates that the camera is not transferring data

buttonloop:
IF PORTA.2 = 1 then
PORTB.5 = 1
GOTO vertloop
else
PORTB.5 = 0
GOTO buttonloop ' Waits for 5V that signals shutter is closed
ENDIF
vertloop:
horizpulse = 1
PORTB.1 = 1
PAUSEUS 139
PORTB.1 = 0
PORTB.2 = 1
PAUSEUS 139
PORTB.1 = 1
PORTB.2 = 0
PAUSEUS 139
PORTB.1 = 0
PAUSEUS 270
vertpulse = vertpulse + 1
IF vertpulse < 512 THEN
GOTO horizloop
ELSE
PORTB.5 = 0
GOTO buttonloop
ENDIF
horizloop:
INTCON.1 = 0 ' Resets interrupt flag to 0
Resetcheck: ' Loops back to make sure the PORTB.3 goes low and
IF INTCON.1 = 0 THEN ' PORTB.4 goes high as close
GOTO Resetcheck ' to the external trigger's rising edge as possible
ENDIF
PORTB.3 = 0
PORTB.4 = 1
PAUSEUS 139
PORTB.4 = 0
PORTB.3 = 1
PAUSEUS 15
ADCIN 0, adval ' A/D 8 bit value from PORTA.0 into adval
SEROUT2 PORTC.6,16390,[DEC adval] ' Output 8 bit word serially to PC from C.6
PAUSEUS 87
horizpulse = horizpulse + 1
IF horizpulse < 784 THEN
GOTO horizloop
ELSE
PAUSEUS 270
GOTO vertloop
ENDIF
END

[TurboLS]

OK, so I commented out the serout2 line and now the high time is 140 usec and the low is 420usec. I think this means that the serout2 command line is taking 540usec to execute for some reason. Is there any reason for this?? Can I speed it up??

After i did that test, I commented out the pauseus 15 and pauseus 87 in addition to the serout2 and it was almost perfect high 150 usec and low 140 usec. The weird part is that i have pauses for the high, but none for the low and they are still in synch. So, yeah basically the serout2 command is taking for ever.

[mister_e]

use HSEROUT or access direct to the internal USART registers. SERIN/SEROUT and others are good when your PIC don't have any internal USART OR when you want to use multiples serial i/o's

@20MHZ you'll be able to use higher baudrate than with the PBP statements.