DCT type IV implementation
As we finished with the basic camera functionality and tested the first Eyesis4π built with the new 10393 system boards (it is smaller, requires less power and, is faster) we are moving forward with the in-camera image processing. We plan to combine our current camera calibration methods that require off-line post processing and the real-time image correction using the camera own FPGA resources. This project development will require switching between the actual FPGA coding and the software implementation of the same algorithms before going to the next step – software is still easier to design. The first part was in FPGA realm – it was to implement the fundamental image processing block that we already know we’ll be using and see how much of the resources it needs.
DCT type IV as a building block for in-camera image processingWe consider a small (8×8 pixel) DCT-IV to be a universal block for conditioning of the raw acquired images. Such operations as lens optical aberrations correction, color conversion (de-mosaic) in the presence of the lateral chromatic aberration, image rectification (de-warping) are easier to perform in the frequency domain using convolution-multiplication property and other algorithms.
In post-processing we use DFT (Discrete Fourier Transform) over rather large (64×64 to 512×512) tiles, but that would be too much for the in-camera processing. First is the tile size – for good lenses we do not need that large convolution kernels. Additionally we plan to combine several processing steps into one (based on our off-line post-processing experience) and so we do not need to sub-sample images – in our current software we double resolution of the raw images at the beginning and scale back the final result to reduce image degradation caused by re-sampling.
The second area where we plan to reduce computations is the replacement of the DFT with the DCT that is designed to be fed with the pure real data and so requires less arithmetic operations than DFT that processes complex input values.
Why “type IV” of the DCT?Fig.1. Signal flow graph for DCT-IV
We already have DCT type II implemented for the JPEG/JP4 compression, and we still needed another one. Type IV is used in audio compression because it can be converted to a modified discrete cosine transform (MDCT) – a procedure when multiple overlapped windows are processed one at a time and the results are seamlessly combined without any block artifacts that are familiar for the JPEG with low settings of the compression quality. We too need lapped transform to process large images with relatively small (much smaller than the image itself) convolution kernels, and DCT-IV is a perfect fit. 8-point DCT-IV allows to implement transformation of 16-point segments with 8-point overlap in a reversible manner – the inverse transformation of 8-point data may be converted to 16-point overlapping segments, and being added together these segments result in the original data.
There is a price though to pay for switching from DFT to DCT – the convolution-multiplication property being so straightforward in FFT gets complicated for DCT[1]. While convolving with symmetrical kernels is still simple (just the kernel has to be transformed differently, but it is anyway done off-line in our case), the arbitrary kernel convolution (or just a shift in image space needed to compensate the lateral chromatic aberration) requires both DCT-IV and DST-IV transformed data. DST-IV can be calculated with the same DCT-IV modules (just by reversing the direction of input data and alternating the sign of the output samples), but it still requires additional hardware resources and/or more processing time. Luckily it is only needed for the direct (image domain to frequency domain) transform, the inverse transform IDCT-IV (frequency to image) does not require DST. And IDCT-IV is actually the same as the direct DCT-IV, so we can again instantiate the same module.
Most of the two-dimensional transforms combine 1-d transform modules (because DCT is a separable transform), so we too started with just an 8-point DCT. There are multiple known factorizations for such algorithm[2] and we used one of them (based on BinDCT-IV) shown in Fig.1.
Fig.2. Simplified diagram of Xilinx DSP48E1 primitive (only used functionality is shown)
DSP primitive in Xilinx ZynqThis algorithm is implemented with a pair of DSP48E1[3] primitives shown in Fig.2. This primitive is flexible and allows to configure different functionality, the diagram contains only the blocks and connections used in the current project. The central part is the multiplier (signed 18 bits by signed 25 bits) with inputs from a pair of multiplexed B registers (B1 and B2, 18 bits wide) and the pre-adder AD register (25 bits). The AD register stores sum/difference of the 25-bit D-register and a multiplexed pair of 25-bit A1 and A2 registers. Any of the inputs can be replaced by zero, so AD can receive D, A1, A2, -A1, -A2, D+A1, D-A1, D+A2 and D-A2 values. Result of the multiplier (43 bits) is stored in the M register and the data from M is combined with the 48-bit output accumulator register P. Final adder can add or subtract M to/from one of the P, 48-bit C-register or just 0, so the output P register can receive +/-M, P+/-M and C+/-M. The wrapper module dsp_ma_preadd_c.v reduces the number of DSP48E1 signals and parameters to those required for the project and in addition to the primitive instance have a simple model of the DSP slice to allow simulation without the DSP48E1 source code for convenience.
Fig.3. One-dimensional 8-point DCT-IV implementation
8-point DCT-IV transformThe DCT-IV implementation module (Fig.3.) operates in 16 clocks cycles (2 clock periods per data item) and the input/output permutations are not included – they can be absorbed in the data source and destination memories. Current implementation does not implement correct rounding and saturation to save resources – such processing can be added to the outputs after analysis for particular application data widths. This module is not in the coder/decoder signal chain so bit-accuracy is not required.
Data is output each other cycle (so two such modules can easily be used to increase bandwidth), while input data is scrambled more, some of the items have to appear twice in a 16-cycle period. This implementation uses two of the DSP48E1 primitives connected in series. First one implements the left half of the Fig.1. graph – 3 rotators (marked R8, and two of R4), four adders, and four subtracters, The second one corresponds to the right half with R1, R5, R9, R13, four adders, and four subtracters. Two of the small memories (register files) – 2 locations before the first DSP and 4 locations before the second effectively increase the number of the DSP internal D registers. The B inputs of the DSPs receive cosine coefficients, the same ROM provides values for both DSP stages.
The diagram shows just the data paths, all the DSP control signals as well as the memories write and read addresses are generated at the defined times decoded from the 16-cycle period. The decoder is based on the spreadsheet draft of the design.
Fig.4. Two-dimensional 8×8 DCT-IV
Two-dimensional 8×8 points DCT-IVNext diagram Fig.4. show a two-dimensional DCT type IV implementation using four of the 1-d 8-point DCT-IV modules described above. Input data arrives continuously in line-scan order, next 64-item block may follow either immediately or after a delay of at least 16 cycles so the pipelines phases are correctly restarted. Two of the input 8×25 memories (width can be reduced to match input data, 25 is the width of the DSP48E1 inputs) are used to re-order the input data.As each of the 1-d DCT modules require input data at more than a half cycles (see bottom of Fig.3) interleaving with the common memory for both channels is not possible, so each channel has to have a dedicated one. First of the two DCT modules convert even lines of 8 points, the other one – odd lines. The latency of the data output from the RAM in the second channel is made 1 cycle longer, so the output data from the channels also arrive at odd/even time slots and can be multiplexed to a common transpose buffer memory. Minimal size of the buffer is 2 of the 64 item pages (width can be reduced to match application requirements), but having just a two-page buffer increases the minimal pause time between blocks (if they are not immediate), with a four page buffer (and BRAM primitives are larger even if just halves are used) the minimal non-immediate delay of the 16 cycles of a 1-d module is still valid.
The second (vertical) pass is similar to the first (horizontal) one, it also has individual small memories for input data reordering and 2 output de-scrambler memories. It is possible to use a single stage, but the memory should hold at least 17 items (>16) and the primitives are 16-deep, and I believe that splitting in series makes it easier for the placer/router tools to implement the design.
Next stepsNow when the 8×8 point DCT-IV is designed and simulated the next step is to switch to the Java coding (add to our ImageJ plugin for camera calibration and image post-processing), convert calibration data to the form suitable for the future migration to FPGA and try the processing based on the chosen 8×8 DCT-IV. When satisfied with the results – continue with the FPGA coding.
References[1] Martucci, Stephen A. “Symmetric convolution and the discrete sine and cosine transforms.” IEEE Transactions on Signal Processing 42.5 (1994): 1038-1051. pdf
[2] Rao, K. Ramamohan, and Ping Yip. Discrete cosine transform: algorithms, advantages, applications. Academic press, 2014.
[3] 7 Series DSP48E1 Slice, UG479 (v1.9), Xilinx, Sep. 2016. pdf
12/16/16 [imagej-elphel][master] by AndreyFilippov: merged with nc393 branch
merged with nc393 branch
12/16/16 [imagej-elphel][master] by AndreyFilippov: merged with nc393 branch
merged with nc393 branch
Boot options 393
Internal NAND flash (default):
← Older revision Revision as of 00:27, 17 December 2016 Line 17: Line 17: ==<font color="blue">Boot instructions</font>== ==<font color="blue">Boot instructions</font>== ===Internal NAND flash (default)=== ===Internal NAND flash (default)=== -* Make sure the recovery card is not inserted+* Make sure the recovery card is not inserted (recovery card can stay in) * Power on * Power on OlegNAND flash boot rootfs
Boot options 393
Poky 2.0 manual
Write files to media and boot:
← Older revision Revision as of 23:04, 16 December 2016 (5 intermediate revisions not shown)Line 38: Line 38: </font> </font> ==<font color="blue">Output files</font>== ==<font color="blue">Output files</font>== -Found in the poky's deploy directory: +The names are listed as they appear in the u-boot configuration header file - actual output files have different names: -* files for rootfs in NAND Flash: '''poky/build/tmp/deploy/images/elphel393/nand/'''+ -* files for rootfs on MMC (micro SD card): '''poky/build/tmp/deploy/images/elphel393/mmc/'''+ - + -These names are listed as they appear in the u-boot configuration header file - actual output files have different names:+ * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') -* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers+* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers. +** ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition +** ''elphel393/bootable-images/nand/devicetree.dtb'' - mount rootfs from NAND flash * '''uImage''' - kernel, drivers * '''uImage''' - kernel, drivers -* '''rootfs.ubifs''' or '''rootfs.tar.gz''' - rootfs+* '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' - rootfs in different formats + +They are found poky's deploy directory '''elphel393/poky/build/tmp/deploy/images/elphel393/''', linked to +'''elphel393/bootable-images/''' for convenience. + +* complete set of files for rootfs in NAND Flash: ''elphel393/bootable-images/nand/'' +* complete set of files for rootfs on MMC (micro SD card): ''elphel393/bootable-images/mmc/'' -==<font color="blue">Boot options</font>==+==<font color="blue">Write files to media and boot</font>== -===Boot from micro SD card (rootfs)===+===Boot from micro SD card=== -* The micro SD card/adapter must be modified for this boot mode (to keep CD pin high) - only then the camera will boot+* Use recovery or regular μSD card * EXT4 partition mounted as '''/''' * EXT4 partition mounted as '''/''' -* [[Sd_boot_rootfs|Detailed instructions]]+[[Sd_boot_rootfs|Detailed instructions]] -===Boot from NAND flash (rootfs)===+===Boot from NAND flash=== * The default boot option - power on. * The default boot option - power on. * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' -* [[NAND_flash_boot_rootfs|Detailed instructions]]+[[NAND_flash_boot_rootfs|Detailed instructions]] ===Notes=== ===Notes=== -* It is possible to unpack rootfs to RAM not mounting any partitions ('''/''' in RAM, ramdisk):+* [[Boot_options_393|'''Read more''']] about boot options. -** Changes are not stored+ -** Boot faster?+ -** Work faster?+ -** Modify env commands in the u-boot (in elphel393.h or when in the u-boot command line)+ -** Carefully check the actual and hardcoded images' sizes in the u-boot (elphel393.h) and the device tree (elphel393_xxx.dts) with the actual sizes.+ ==<font color="blue">Setup</font>== ==<font color="blue">Setup</font>== OlegPoky 2.0 manual
Boot options:
← Older revision Revision as of 22:54, 16 December 2016 (3 intermediate revisions not shown)Line 38: Line 38: </font> </font> ==<font color="blue">Output files</font>== ==<font color="blue">Output files</font>== -Found in the poky's deploy directory: +The names are listed as they appear in the u-boot configuration header file - actual output files have different names: -* files for rootfs in NAND Flash: '''poky/build/tmp/deploy/images/elphel393/nand/'''+ -* files for rootfs on MMC (micro SD card): '''poky/build/tmp/deploy/images/elphel393/mmc/'''+ - + -These names are listed as they appear in the u-boot configuration header file - actual output files have different names:+ * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') -* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers+* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers. +** ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition +** ''elphel393/bootable-images/nand/devicetree.dtb'' - mount rootfs from NAND flash * '''uImage''' - kernel, drivers * '''uImage''' - kernel, drivers -* '''rootfs.ubifs''' or '''rootfs.tar.gz''' - rootfs+* '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' - rootfs in different formats + +They are found poky's deploy directory '''elphel393/poky/build/tmp/deploy/images/elphel393/''', linked to +'''elphel393/bootable-images/''' for convenience. + +* complete set of files for rootfs in NAND Flash: ''elphel393/bootable-images/nand/'' +* complete set of files for rootfs on MMC (micro SD card): ''elphel393/bootable-images/mmc/'' -==<font color="blue">Boot options</font>==+==<font color="blue">Write files to media and boot</font>== ===Boot from micro SD card (rootfs)=== ===Boot from micro SD card (rootfs)=== -* The micro SD card/adapter must be modified for this boot mode (to keep CD pin high) - only then the camera will boot+* Use recovery or regular μSD card * EXT4 partition mounted as '''/''' * EXT4 partition mounted as '''/''' -* [[Sd_boot_rootfs|Detailed instructions]]+[[Sd_boot_rootfs|Detailed instructions]] ===Boot from NAND flash (rootfs)=== ===Boot from NAND flash (rootfs)=== * The default boot option - power on. * The default boot option - power on. * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' -* [[NAND_flash_boot_rootfs|Detailed instructions]]+[[NAND_flash_boot_rootfs|Detailed instructions]] ===Notes=== ===Notes=== * It is possible to unpack rootfs to RAM not mounting any partitions ('''/''' in RAM, ramdisk): * It is possible to unpack rootfs to RAM not mounting any partitions ('''/''' in RAM, ramdisk): -** Changes are not stored+** Changes will not be stored -** Boot faster?+ -** Work faster?+ ** Modify env commands in the u-boot (in elphel393.h or when in the u-boot command line) ** Modify env commands in the u-boot (in elphel393.h or when in the u-boot command line) ** Carefully check the actual and hardcoded images' sizes in the u-boot (elphel393.h) and the device tree (elphel393_xxx.dts) with the actual sizes. ** Carefully check the actual and hardcoded images' sizes in the u-boot (elphel393.h) and the device tree (elphel393_xxx.dts) with the actual sizes. +** Don't want to waste RAM ==<font color="blue">Setup</font>== ==<font color="blue">Setup</font>== OlegBoot options 393
Ezynq
"Free" the code part:
← Older revision Revision as of 18:13, 16 December 2016 Line 14: Line 14: <b>as of 2016/03/18...</b> <b>as of 2016/03/18...</b> * u-boot-xlnx master-next branch is removed long ago - so the link above is broken * u-boot-xlnx master-next branch is removed long ago - so the link above is broken + +<b>as of 2016/06/25...</b> +* ezynq depends on original u-boot instead of u-boot-xlnx ==Supported boards== ==Supported boards== Oleg12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Add disk reading test to camogm_test
Add disk reading test to camogm_test
12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Add disk reading test to camogm_test
Add disk reading test to camogm_test
12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm
Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm
12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm
Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm
12/15/16 [linux-elphel][master] by Mikhail Karpenko: Process late IRQs, add time stamps to datascope
Process late IRQs, add time stamps to datascope
12/15/16 [linux-elphel][] by Mikhail Karpenko: Process late IRQs, add time stamps to datascope
Process late IRQs, add time stamps to datascope
Tmp manual
Boot options 393
Other boot options:
New page
==<font color="blue">Description</font>==Normally camera boots from the internal NAND flash memory, and it is always possible to boot it from the micro SD card, so even corruption of files on the internal flash will not "brick" the system. There are no buttons or switches on the camera - it should be instructed to change the boot source. Always booting from micro SD is not practical - in that case it would not be possible to leave a non-bootable card (intended just for image/video storage) in the camera slot.
There are two ways to switch camera to the micro SD boot mode.
One requires camera to be connected to the host computer with the USB cable (micro USB socket under the network jack - marked "console" on the picture). There is an internal USB-to-serial converter in the camera (CP2103) that offers 4 additional GPIO signals in addition to just the serial connection. One of these signals selects the boot source (GPIO0 - 0 - MMC, 1 - NAND), another (GPIO3 - 0 reset, 1 - normal operation). Unfortunately GPIO control of the CP2103 is not in a mainline cp210x Linux driver so this functionality requires a modified version (see instructions below).
Another way to "tell" the camera to boot from the μSD card instead of the internal NAND flash is to use a mechanically modified card or card adapter (such cards are provided with the camera). Standard specifies two alternative ways for detection of the card presence - one is a mechanical switch (closed when the card is inserted), another is a pull-up resistor on a data line. Camera uses both signals at boot time to determine the boot source:
* Switch not closed, pull-up resistor not detected -> no card present, boot from the internal NAND flash
* Switch closed -> data (non-bootable) card present, boot from the internal NAND flash
* Switch not closed, pull-up resistor is detected -> bootable card present, boot from the MMC card
{|
|[[File:Recover mmc.jpeg|130px|thumb|Fig.1 Recovery μSD card ('cut' corner) - forces the system board to boot from it]]
|}
==<font color="blue">Boot instructions</font>==
===Internal NAND flash (default)===
* Make sure the recovery card is not inserted
* Power on
===Recovery micro SD card===
Requirements:
* A modified card that doesn't lock the mechanical CD pin in the slot - it's done by carefully filing off the corner (see Fig.1) - most cards have circuitry there and get damaged. Use the one that came with the camera or order a new one.
Instructions:
* insert the card, power on
===Regular micro SD card===
Requirements:
* μUSB-to-USB cable
* Linux: compile [https://sourceforge.net/p/elphel/cp210x_gpio/ci/master/tree/ cp210x driver]
Instructions:
* Power on
* Connect the camera's console port (see Fig.2, right under the μSD slot) to PC using μUSB-to-USB cable
{|
|[[File:NC393-CS marked ports.jpeg|thumb|200px|Fig.2 10393 camera ports]]
|}
* Reload the cp210x driver:
** unplug the μUSB-to-USB cable
** In the terminal from the directory where the driver was built, run:
sudo rmmod cp210x
sudo insmod cp210x.ko
** plug the cable back (the driver will stay loaded until the PC is rebooted).
* In the terminal from the directory where the driver was built, run:
./cp210x_gpio.py 0x6;
./cp210x_gpio.py 0xe;
* To reboot back to NAND flash w/o power cycling:
./cp210x_gpio.py 0x7;
./cp210x_gpio.py 0xf;
===Other boot options===
The instructions are defined by the 3 options above.
They define where the camera will load the u-boot, device tree and kernel from: μSD card or NAND flash. The location of rootfs ("/") is set in the device tree. Available locations for rootfs:
* '''any μSD card partition'''. The default device tree parameter is:
bootargs = "cma=336M console=ttyPS0,115200 root=/dev/mmcblk0p2 rw ip=192.168.0.9 earlyprintk rootwait rootfstype=ext4";
* '''any internal NAND flash partition'''. The default parameter is:
bootargs = "cma=336M console=ttyPS0,115200 root=ubi0:elphel393-rootfs rw ip=192.168.0.9 earlyprintk rootwait rootfstype=ubifs ubi.mtd=4,2048";
* '''any internal SSD''' (if installed) partition. There is no default device tree.
* '''RAM''' - unpack an archive from a μSD card FAT32 partition into RAM but it was tested a while ago:
bootargs = "cma=336M console=ttyPS0,115200 root=/dev/ram rw ip=192.168.0.9 earlyprintk ramdisk_size=262144";
'''To build a custom device tree''', see [http://wiki.elphel.com/index.php?title=Poky_2.0_manual SDK manual]'''
==<font color="blue">cp210x_gpio.py -h</font>==
$./cp210x_gpio.py -h
usage: cp210x_gpio.py [-h] [-d DEVICE] [-m MASK] [gpio_value]
positional arguments:
gpio_value hex value for GPIO. Example (GPIO[3:0]): 0xf - all
1's, 0x0 - all 0's. If not specified - read GPIO only
optional arguments:
-h, --help show this help message and exit
-d DEVICE, --device DEVICE
USB device. Default: /dev/ttyUSB0
-m MASK, --mask MASK hex value for masking out GPIO bits: 1 - enable
rewrite, 0 - disable. Example (GPIO[3:0]): -m 0xf
[[Category:393]] Oleg
Boot options 393
New page
==<font color="blue">Description</font>==Normally camera boots from the internal NAND flash memory, and it is always possible to boot it from the micro SD card, so even corruption of files on the internal flash will not "brick" the system. There are no buttons or switches on the camera - it should be instructed to change the boot source. Always booting from micro SD is not practical - in that case it would not be possible to leave a non-bootable card (intended just for image/video storage) in the camera slot.
There are two ways to switch camera to the micro SD boot mode.
One requires camera to be connected to the host computer with the USB cable (micro USB socket under the network jack - marked "console" on the picture). There is an internal USB-to-serial converter in the camera (CP2103) that offers 4 additional GPIO signals in addition to just the serial connection. One of these signals selects the boot source (GPIO0 - 0 - MMC, 1 - NAND), another (GPIO3 - 0 reset, 1 - normal operation). Unfortunately GPIO control of the CP2103 is not in a mainline cp210x Linux driver so this functionality requires a modified version (see instructions below).
Another way to "tell" the camera to boot from the μSD card instead of the internal NAND flash is to use a mechanically modified card or card adapter (such cards are provided with the camera). Standard specifies two alternative ways for detection of the card presence - one is a mechanical switch (closed when the card is inserted), another is a pull-up resistor on a data line. Camera uses both signals at boot time to determine the boot source:
* Switch not closed, pull-up resistor not detected -> no card present, boot from the internal NAND flash
* Switch closed -> data (non-bootable) card present, boot from the internal NAND flash
* Switch not closed, pull-up resistor is detected -> bootable card present, boot from the MMC card
{|
|[[File:Recover mmc.jpeg|130px|thumb|Fig.1 Recovery μSD card ('cut' corner) - forces the system board to boot from it]]
|}
==<font color="blue">Boot instructions</font>==
===Internal NAND flash (default)===
* Make sure the recovery card is not inserted
* Power on
===Recovery micro SD card===
Requirements:
* A modified card that doesn't lock the mechanical CD pin in the slot - it's done by carefully filing off the corner (see Fig.1) - most cards have circuitry there and get damaged. Use the one that came with the camera or order a new one.
Instructions:
* insert the card, power on
===Regular micro SD card===
Requirements:
* μUSB-to-USB cable
* Linux: compile [https://sourceforge.net/p/elphel/cp210x_gpio/ci/master/tree/ cp210x driver]
Instructions:
* Power on
* Connect the camera's console port (see Fig.2, right under the μSD slot) to PC using μUSB-to-USB cable
{|
|[[File:NC393-CS marked ports.jpeg|thumb|200px|Fig.2 10393 camera ports]]
|}
* Reload the cp210x driver:
** unplug the μUSB-to-USB cable
** In the terminal from the directory where the driver was built, run:
sudo rmmod cp210x
sudo insmod cp210x.ko
** plug the cable back (the driver will stay loaded until the PC is rebooted).
* In the terminal from the directory where the driver was built, run:
./cp210x_gpio.py 0x6;
./cp210x_gpio.py 0xe;
==<font color="blue">cp210x_gpio.py -h</font>==
$./cp210x_gpio.py -h
usage: cp210x_gpio.py [-h] [-d DEVICE] [-m MASK] [gpio_value]
positional arguments:
gpio_value hex value for GPIO. Example (GPIO[3:0]): 0xf - all
1's, 0x0 - all 0's. If not specified - read GPIO only
optional arguments:
-h, --help show this help message and exit
-d DEVICE, --device DEVICE
USB device. Default: /dev/ttyUSB0
-m MASK, --mask MASK hex value for masking out GPIO bits: 1 - enable
rewrite, 0 - disable. Example (GPIO[3:0]): -m 0xf
[[Category:393]] Oleg
Pages
