That's exactly it. I should have emphasised that this is by no means a user-ready build; there's still a lot to be done. The implementation is extremely crude and I'm sure the sluggishness can be reduced to more manageable levels by modifying the timeouts etc in the code, or simply activating/deactivating the serial monitoring in uBasic scripts or by other means.
One thing I should definitely emphasise is that this code has been in this state since early last December and I don't plan to do much in the way of development on it - I'm hoping to make it a bit easier for others to continue the work with this information.
Some further information on the technicalities of the code:
Each data packet sent to the camera currently consists of:
1 'handshake' byte with a value of 0 (binary 0b00000000)
1 data byte with 8 bits. eg 4 (binary 0b00000100)
1 error-checking byte which is the inverse of the data byte. eg for a data byte of 4: 251 (binary 0b11111011)
There's no technical reason why there should only be a single data byte. The handshake and error-checking bytes were added by necessity, but are not optimised:
Most significantly, I currently begin each packet with a byte with a value of zero, because electrically that appears as a single long pulse (start bit, 8 inverted data bits and stop bit). I've called this the handshake byte.
To identify whether the first signal received by the code is the handshake byte it is necessary to determine the length of the pulse. Because we have no way of accurately timing at this level I record the number of times I have polled the USB port voltage. If this number is significantly different to a precalibrated value (which may well be different for different cameras, and especially for Digic II vs Digic III) then the data is rejected and the subroutine exits.
I had to include the handshake byte because I was encountering a lot of timing errors due to varying CPU load in the camera. The handshake byte is effectively a measure of CPU load using an external signal.
After the data byte an error checking byte is transmitted; at the moment that's just the inverse of the data byte. (there's a name for this which I can't remember!) This is a very crude and inefficient form of error checking and sheer laziness on my part!
------------------------------------
Details of the USB - serial cable.
I've been unable to determine how accurate the timing is on this particular USB converter (no oscilloscope), but it's likely to be better than the timing on microprocessors which bit-bang [ie the electrical signal is generated by software rather than dedicated hardware] serial, such as PICs. As timing is likely to always be the main issue with this code, I suggest constructing a USB - serial cable if you plan to do any development of this serial code or hardware interfacing with it; it may be useful to troubleshoot errors.
The cable I used was a cheap imitation of a Nokia CA-42, found on eBay.
ebay link (That's the cheapest supplier I could find for the UK)
I believe this contains a Prolific PL-2303 chip, as used in most USB - serial adaptors:
Welcome to ProlificIn any case, the cable sends 5V TTL RS232.
The female USB connector was taken from a short extension lead packaged with a cheap USB hub. This particular moulded connector was very easy to disassemble and reassemble, which is rare with moulded connectors. I've seen these a lot in 'Poundland' shops in the UK. (Also seen here:
ebay link)
Wiring is as follows:
Serial cable TX -> USB female Vcc
Serial cable ground -> USB female ground
To determine which cable is the serial transmit you can use a multimeter connected between ground and the suspect wire; when a connection is opened to the COM port the TX wire will go from 0V to 5V (because of inverted logic, 5V is the idle state in this case)
You may also be able to determine the wires via working backwards from this diagram:
Nokia 2112, 2115, 2270, 2272, 2280, 2285, 3100, 3105, 3108, 3120, 3125, 3200, 3205, 3220, 3585, 3586, 3587, 3588, 3589i, 5100, 5140, 6011i, 6012, 6015, 6015i, 6016i, 6019i, 6020, 7210 pop-port LIKE-DKU-5 or CA-42 cable schematic pinout and signals @ pinouts.ruThe only device that is safe to connect to this cable is your camera. Any other devices may draw current from the serial cable and result in damage to the serial cable (and possibly the device. Not very likely, but that's disclaimers for you).That's all for now.
(Thanks, zeno, but I'm keen to keep this thread fairly concise and on-topic. Would you mind starting a new thread discussing your scripts and amending your post to link to that thread, rather than posting a direct link to the scripts [to avoid questions on those scripts ending up in this thread]?)
