A method and system for starting a driving recorder

Abstract

The present application relates to the technical field of recording device control, and particularly relates to a driving recorder starting control method and system. The method comprises the following steps: based on the driving recorder being powered on, a boot loader starts a real-time operation unit of the driving recorder; the real-time operation unit of the driving recorder loads a main operation unit kernel from a storage medium to a memory unit point by point, the main operation unit kernel responds and starts to run a main control application program; when the main control application program runs, a camera and an encoder are immediately initialized, encoded video data is written into a memory cache area through non-waiting cache response, and a mounting operation of an external storage device is intermittently and asynchronously executed. Through asynchronous mounting storage and memory cache optimization technology, the application realizes starting recording in a short time and data lossless, thereby improving the starting speed and reliability of the driving recorder.

Description

Technical Field

[0001] This invention relates to the field of recording device control technology, and in particular to a method and system for controlling the start-up of a vehicle recorder. Background Technology

[0002] Currently, most mainstream car dashcams on the market adopt solutions based on Linux embedded systems. Their standard startup and recording process is as follows: After the device is powered on, a bootloader (such as U-Boot) runs. U-Boot initializes the hardware and loads the Linux kernel from storage media (such as Flash) into memory. After the Linux kernel boots, it mounts the root file system (RootFS), which is also stored in Flash. After the file system is successfully mounted, the user-space application (such as the main recording program) runs. The recording program then initializes the camera module, encoding chip (such as H.264 / H.265 encoder), and... External storage devices (such as SD cards) only acquire video streams from the camera, encode them, and write them to the SD card after all software and hardware initialization is complete. Although this process is stable and reliable, it takes a long time from startup to the start of recording, usually 15 to 30 seconds or even longer. The bottleneck lies in the long loading and initialization time of the Linux kernel, the slow mounting of complex file systems (such as ext4), the loading and initialization of large user space applications, and the further delay in recording start time due to SD card detection and mounting. This results in a "blind spot" in monitoring between the vehicle's ignition and the start of recording, during which traffic accidents cannot be recorded, causing the dashcam to lose its core protection function. Summary of the Invention

[0003] Therefore, it is necessary to provide a dashcam start control method and system to solve at least one of the above-mentioned technical problems.

[0004] To achieve the above objectives, a method for controlling the start-up of a vehicle dashcam is provided, the method comprising the following steps:

[0005] Step S1: After the dashcam device is powered on, the bootloader starts the dashcam's real-time operation unit; the dashcam's real-time operation unit loads the main operation unit kernel from the storage medium to the memory unit point-to-point, and the main operation unit kernel responds and starts to run the main control application;

[0006] Step S2: When the main control application runs, the camera and encoder are initialized immediately, and the encoded video data is written to the memory buffer through a wait-free buffer response. At the same time, the external storage device is mounted intermittently and asynchronously.

[0007] Step S3: After the external storage device is successfully mounted, the video data in the memory buffer is transferred to the external storage device through time-series backtracking migration, and the encoded video data is continuously written to the external storage device through a circular queue.

[0008] Optionally, a dashcam start-up control system is provided for the aforementioned dashcam start-up control method, the dashcam start-up control system comprising:

[0009] The kernel loading and boot module is used to start the real-time operation unit of the dashcam after the dashcam device is powered on. The real-time operation unit of the dashcam loads the main operation unit kernel from the storage medium to the memory unit point-to-point. After the main operation unit kernel responds and starts, it runs the main control application.

[0010] The cache control module is used to immediately initialize the camera and encoder when the main control application runs, and write the encoded video data into the memory cache area through a no-wait cache response, while performing the mounting operation of external storage devices intermittently and asynchronously.

[0011] The video transfer module is used to transfer video data in the memory buffer to the external storage device through time-series backtracking migration after the external storage device is successfully mounted, and to continuously write the encoded video data to the external storage device through a circular queue.

[0012] The beneficial effects of this invention are:

[0013] 1. A customized real-time operating system (RTOS) is used to replace the traditional bootloader, which efficiently completes hardware initialization and loads the main operating unit kernel. At the same time, after the main operating unit kernel starts up, it does not need to wait for the external storage device to be mounted. It immediately initializes the camera and encoder and starts recording, realizing recording within 6 seconds after power-on, completely eliminating the monitoring blind spot during the startup phase.

[0014] 2. Encoded video data is temporarily stored in a memory buffer. After the external storage device is successfully mounted, all data from the beginning of the recording to the present is completely transferred to the external storage device, ensuring that no recording data is lost from the first frame, resulting in extremely high reliability.

[0015] 3. External storage device mounting adopts an intermittent asynchronous execution method. Even if the external storage device cannot be recognized temporarily or fails to mount, the system can still continuously store recording data in the memory cache, ensuring normal recording function for a period of time. At the same time, it can notify users of device abnormalities through an alarm mechanism, improving the ability to deal with abnormal situations.

[0016] 4. By fully leveraging existing hardware resources (such as memory units, storage media, and processors), significant performance improvements can be achieved simply by optimizing the system boot process and decoupling recording and storage operations through software architecture innovations. This eliminates the need to replace the hardware platform with a more expensive one, resulting in a significant cost-effectiveness advantage. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the steps of a dashcam start-up control method;

[0018] Figure 2 This is a schematic diagram of a dashcam structure.

[0019] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0021] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0022] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0023] To achieve the above objectives, please refer to Figures 1 to 2 A method for controlling the start of a vehicle dashcam, the method comprising the following steps:

[0024] Preferably, in step S1: after the dash cam device is powered on, the bootloader starts the real-time operation unit of the dash cam; the real-time operation unit of the dash cam loads the main operation unit kernel from the storage medium to the memory unit point-to-point, and after the main operation unit kernel responds and starts, it runs the main control application.

[0025] Optionally, in step S1, the recorder's real-time operation unit loads the main operation unit kernel from the storage medium to the memory unit point-to-point, including:

[0026] After the recorder's real-time operation unit is started, it first cuts off the power supply to all partitions in the storage medium except for the main operation unit's kernel storage partition, and only retains the power supply circuit for the kernel storage partition;

[0027] The recorder's real-time operation unit divides the main operation unit kernel into several data blocks of equal length and starts dual-thread parallel processing. One thread reads the data blocks, and the other thread transfers the read data blocks to the memory unit.

[0028] After each data block is transmitted, the recorder's real-time operation unit calculates the feature value of that data block in the memory unit;

[0029] The calculated feature value is compared with the preset feature value of the data block in the storage medium. If they match, the next data block is processed. If they do not match, the data block is read and transmitted again.

[0030] After all data blocks have been transmitted, the recorder's real-time operation unit calculates the overall characteristic value of the complete kernel data spliced ​​in the memory unit. Only after the overall characteristic value matches the preset value is the main operation unit kernel started.

[0031] In one embodiment, after the real-time operation unit of the recorder is started, a low-level signal is output through the integrated power control module to cut off the power supply circuit of the storage medium (used to store the dashcam system data and kernel files, and the data can be retained for a long time after power failure) except for the main operation unit kernel storage partition (address 0x00000000-0x00600000), the user data partition (0x00600001-0x07FFFFFF) and the configuration file partition (0x08000000-0x08FFFFFF), and only the kernel storage partition is powered, with the voltage stabilized at 3.3V±0.02V;

[0032] It should be noted that the real-time operation unit of the dashcam reads the main operation unit kernel (i.e., the Linux kernel, which is the core of the dashcam's main system, managing hardware resources and process scheduling; the total file size is 7.68MB), splits it into 48 equal-length data blocks of 163,840 bytes (160KB), and then relies on the task scheduling function of the customized real-time operating system (optimized for dashcams, only responsible for hardware initialization and kernel loading, with fast response and low resource consumption) to start two independent threads: one reads data blocks sequentially from the kernel storage partition of the storage medium at a rate of 40MB / s, and passes them to the other thread through the system's internal shared data buffer (addresses 0x10000000-0x10003FFF), which then transfers the data blocks to the memory unit (high-speed temporary storage device, temporarily storing running kernel data, address 0x80000000) at a rate of 60MB / s.

[0033] In another embodiment, after each 163,840-byte data block is transmitted, the recorder's real-time operation unit calls the built-in feature value calculation module to calculate the feature value of the corresponding storage area (a continuous 160KB address space starting from 0x80000000) in the memory unit. At the same time, it reads the corresponding preset feature value from the preset feature value storage segment (address 0x005F0000-0x005FFFFF) of the kernel storage partition of the storage medium and compares them bit by bit. If they match, the next block is processed; if they do not match, they are read and transmitted again until they match.

[0034] In another embodiment, after all 48 data blocks have been transmitted, the real-time operation unit of the recorder calculates the overall feature value of the complete kernel data (total size 7.68MB) spliced ​​in the memory unit, compares it bit by bit with the preset value read from the preset overall feature value storage address (0x005EFFFF) of the kernel storage partition of the storage medium. After they are completely consistent, a 3.3V high-level signal lasting 8ms is sent to the kernel start trigger pin of the main operation unit to trigger the kernel start.

[0035] It should be noted that the above values ​​are only for the current example, and in practice, appropriate parameters can be selected according to the storage medium capacity, bus bandwidth and CPU specifications.

[0036] Of particular importance is that, in step S1, after the main operating unit kernel responds and starts, the main control application runs as follows:

[0037] After the main operating unit kernel starts, it directly locates the storage address of the startup file of the main control application, skipping the scan of the startup files of other applications in the system;

[0038] The main operating unit kernel only loads the video encoding driver and camera driver required by the main control application, and loads the video encoding driver first, and then loads the camera driver after the encoding driver is initialized.

[0039] The main operating unit kernel allocates an independent memory area for the main control application, dividing it into an instruction storage segment and a data storage segment, with a blank isolation segment set between the two segments;

[0040] After the main control application is started, the main operation unit kernel monitors the execution time of the main control application's instructions in real time. If the execution time of a certain instruction exceeds the limit, the instruction is paused and the initialization instructions of the camera and encoder are executed first.

[0041] After the main control application completes the camera and encoder initialization, the main operation unit kernel releases the memory occupied by the blank isolation segment and merges the released memory into the data storage segment.

[0042] In one embodiment, after the main operating unit kernel starts, it calls the internally preset main control application startup file address mapping table (the table stores the path and index of the startup file in the Flash storage medium) to directly locate the startup file storage block, without scanning the startup file paths of other applications such as the settings program and video playback program.

[0043] It should be noted that the kernel only loads the drivers required by the main control application: through the built-in driver loading module, it first sends a loading command to the H.265 video encoding driver. After the driver initialization is completed, it sends back a 3.3V signal that lasts for 5ms. After the kernel detects the signal, it sends a loading command to the 1080P camera driver to complete the communication connection between the driver and the camera hardware.

[0044] Specifically, the kernel uses the memory management module to allocate 512MB of independent memory to the main control application, which is divided into an instruction storage segment for storing binary execution instructions and a data storage segment for storing temporary data. A 2MB blank isolation segment is set between the two segments and filled with 0xFF to avoid data interference.

[0045] In another embodiment, after the main control application is started, the kernel starts the process monitoring module (monitoring at a 10ms cycle) and sets the upper limit of the execution time of a single instruction to 100ms; if the instruction times out, the instruction is paused through the interrupt control module, triggering priority scheduling, and the camera and encoder initialization instructions are executed first.

[0046] It should be noted that the main control application executes the camera initialization command (sets 1920×1080 resolution, 30fps frame rate, and receives hardware ready signal) and the encoder initialization command (sets 8Mbps bit rate, 50 I-frame interval, and receives hardware ready signal); after the kernel confirms that the hardware is ready, it uses the memory reclamation module to release the isolated segment memory, and then uses the memory merging module to merge it into the data storage segment.

[0047] Preferably, in step S2: when the main control application is running, the camera and encoder are initialized immediately, and the encoded video data is written to the memory buffer through a wait-free buffer response, while the external storage device is mounted intermittently and asynchronously.

[0048] Optionally, step S2, writing the encoded video data to the memory buffer using a wait-free buffer response, includes:

[0049] Two parallel storage channels are set up in the memory buffer. The first channel receives the currently generated encoded video data, and the second channel temporarily stores the received encoded video data.

[0050] Encoded video data is written to the first channel in units of frames. When the first channel is full of a frame of data, it automatically switches to the second channel to receive the next frame of data.

[0051] Once the first channel is full of frame data, the frame data is immediately copied to the end of the second channel. After copying is complete, the frame data in the first channel is cleared.

[0052] At fixed intervals, the feature identifiers of the same frame data in the first channel and the second channel are compared. If the identifiers are inconsistent, the second channel is updated based on the frame data in the first channel.

[0053] When the storage capacity of the second channel reaches its limit, the earliest stored frame data is deleted in chronological order of storage time to make room for new data.

[0054] In one embodiment, two parallel storage channels are set in the memory buffer (divided from memory units, with a total capacity of 128MB, which can be adjusted according to the total capacity of memory units and the recording resolution requirements in actual applications). The first channel is allocated 64MB of storage space to receive the currently generated encoded video data, and the second channel is also allocated 64MB of storage space to temporarily store the received encoded video data. The encoded video data is written to the first channel in units of frames. The size of each frame is set to approximately 500KB based on 1080P resolution, 30fps frame rate and H.265 encoding standard. If 720P resolution or H.264 encoding standard is used, the size of a single frame can be adjusted accordingly.

[0055] In another embodiment, when the data stored in the first channel reaches 500KB (i.e., a frame of data is full), the memory channel switching module automatically switches to the second channel to receive the next frame of data. After the first channel is full of frame data, a data copying thread is immediately started to copy the frame of data to the end of the second channel at a rate of 100MB / s. The copying rate can be optimized and adjusted according to the memory read and write performance parameters. After the copying is completed, the memory cleanup module clears the frame of data in the first channel to free up space for receiving new frame data.

[0056] In another embodiment, a data verification thread is started every 200ms. The verification interval can be flexibly set according to the data transmission stability requirements. The thread reads the feature identifier (a 128-bit MD5 value calculated based on the frame data, or other hash algorithms such as SHA-1 can be used to generate the feature identifier) ​​of the same frame data in the first channel and compares them. If the identifiers are inconsistent, the data update module overwrites and updates the corresponding frame data in the second channel with the frame data of the first channel as the standard. When the storage capacity of the second channel reaches the upper limit of 64MB, the data eviction mechanism is started. The earliest stored frame data is identified and deleted in the order of storage time. Each time a frame (about 500KB) of data is deleted, the corresponding storage space is freed up for the new data, ensuring that the second channel has the ability to continuously store temporary data.

[0057] Optionally, before writing the encoded video data frame by frame to the first channel, the following may also be included:

[0058] Before writing each frame of encoded video data into the first channel, add a synchronization marker of fixed length at the beginning of the encoded video data.

[0059] During the writing process, a detection thread is started to monitor the integrity of the synchronization flag in real time. If the synchronization flag is found to be damaged, the writing of that frame of data is stopped immediately.

[0060] Reacquire the encoded video data corresponding to the frame, add a new synchronization identifier, and write it back to the first channel;

[0061] If the synchronization flag is corrupted in two consecutive writes, the encoded video data corresponding to that frame will be temporarily stored in the spare sub-area of ​​the memory buffer.

[0062] When the spare sub-area is full of three frames of data, the repair thread is started to re-add the synchronization flag to the data in the spare sub-area and then write it to the second channel.

[0063] In one embodiment, before each frame of encoded video data (based on the H.265 encoding standard, approximately 500KB per frame at 1080P resolution and 30fps frame rate) is written to the first channel, a synchronization identifier of fixed length 16 bytes is added at the beginning of the encoded video data by the data identifier generation module. This synchronization identifier consists of a "0xAA55" start bit, an 8-byte frame sequence number, a 4-byte timestamp, and a 2-byte check bit. During the writing process, a synchronization identifier detection thread is started. This thread reads the synchronization identifier at the beginning of the encoded video data in real time at a rate of 10MB / s. The integrity of the synchronization identifier is monitored by comparing the logical relationship between the "0xAA55" start bit, the check bit, and the frame sequence number. If an error in the start bit, a mismatch in the check bit, or a jump in the frame sequence number is detected, a pause signal is immediately sent through the data writing control module to stop the writing of that frame of data.

[0064] In another embodiment, the data retransmission module then sends an instruction to the encoder to reacquire the encoded data of the frame. After the encoder re-outputs the encoded data of the frame, the data identifier generation module adds a new 16-byte synchronization identifier (the frame sequence number is consistent with the original frame, and the timestamp is updated to the regeneration time). Then, the data write control module writes the encoded video data corresponding to the frame back into the first channel. If the synchronization identifier detection thread determines that the synchronization identifier is damaged in both consecutive write processes, the data temporary storage module transfers the encoded video data corresponding to the frame (including the two damaged synchronization identifiers) to the spare sub-area of ​​the memory buffer. The spare sub-area is divided from the memory buffer, and the total capacity is set to 1.5MB (which can store 3 frames of 500KB encoded data).

[0065] It should be noted that when the data stored in the spare sub-area reaches 3 frames (total capacity 1.5MB), the synchronization identifier repair thread is automatically started. This thread first deletes the original damaged synchronization identifiers of each frame of data in the spare sub-area, and then calls the data identifier generation module to re-add 16-byte synchronization identifiers to the encoded video data corresponding to each frame (the frame number is arranged in the original frame order, and the timestamp is the original frame acquisition timestamp). After the repair is completed, the 3 frames of data in the spare sub-area are written to the second channel in the order of the frame number through the data transfer module.

[0066] Optionally, the external storage device mounting operation performed intermittently and asynchronously in step S2 is specifically as follows:

[0067] After the main control application starts the mounting thread, it first sends a low voltage wake-up signal to the external storage device, and then waits for a preset time before detecting the response signal from the external storage device.

[0068] If a response signal is received, a standard voltage power supply command is sent to the external storage device to switch to standard voltage mode; if no response signal is received, a low voltage wake-up signal is sent again at fixed intervals.

[0069] After switching to standard voltage mode, the mounting thread sends a device model and interface protocol read command to the external storage device;

[0070] Select the corresponding mount instruction set based on the interface protocol information and execute the mount operation;

[0071] If no response is received for any of the following commands: standard voltage power supply command, device model and interface protocol read command, the command will be sent repeatedly, up to a maximum of three times. If no response is received after three attempts, the mounting process will be suspended, and the low voltage wake-up procedure will be re-executed after a longer interval.

[0072] In one embodiment, after the main control application starts the mounting thread, it sends a 1.8V low-voltage wake-up signal for 200ms to the external storage device (SD card) through the external storage device interface module. After sending, it waits for 500ms and then checks whether a 0.9V response signal for 100ms is received through the interface module signal detection pin. If a response signal is received, a standard voltage power supply command containing a 3.3V target voltage and a 100ms switching duration is sent to put the external storage device into standard voltage mode. If no response signal is received, the low-voltage wake-up signal is resent after a 1s interval.

[0073] In another embodiment, after switching to standard voltage mode, the mounting thread sends a device model and interface protocol read command containing an instruction identifier (0x01), a 32-byte read length, and a 2-byte checksum through the interface protocol communication module. It then receives 32 bytes of data from the external storage device, containing the device model (e.g., SDHC UHS-I) and the SD 3.0 interface protocol. Subsequently, it calls the corresponding mounting instruction set for SD 3.0 (including initialization, partition detection, and file system identification instructions) to perform the mounting operation. Each step of the standard voltage power supply instruction, device model, and interface protocol read command waits for a 300ms response. If no response is received, the instruction is resent, up to a maximum of three times. If no response is received after three attempts, mounting is paused, and the low-voltage wake-up process is re-executed after a 5-second interval.

[0074] Optionally, after the main control application starts the mount thread, it also includes:

[0075] During the intermittent period, the mounting thread enters a low-power mode, keeping only the detection pin of the external storage device interface active.

[0076] The detection pin sends detection pulses at a fixed frequency. If a feedback pulse from an external storage device is detected, the mounting thread is immediately woken up.

[0077] If no feedback pulse is detected, the interval between the next detection pulses will be extended, with the duration of each extension increasing by a preset ratio.

[0078] Once the detection interval is extended to the maximum threshold, continue detecting at that interval until a feedback pulse is detected or a forced mount command is received from the main control application.

[0079] In this embodiment, after the main control application starts the mounting thread, when the mounting thread enters an intermittent period, i.e., the interval between two low-voltage wake-up signal transmissions, it switches to a low-power mode through the thread power consumption control module. In this mode, only the detection pin of the external storage device interface remains active, and the power supply to other non-essential functional modules of the mounting thread is turned off. The detection pin sends a detection pulse at a fixed frequency of 1Hz, with the pulse signal voltage set to 3.3V and the pulse width to 50ms. The detection pin monitors the feedback signal from the external storage device in real time. If a feedback pulse of 2.5V and a pulse width of 30ms is detected from the external storage device, a wake-up command is immediately sent to the mounting thread through the wake-up signal triggering module. This causes the mounting thread to exit low-power mode and resume the mounting process. If the detection pin does not detect a feedback pulse within a 1Hz frequency cycle, the interval adjustment module extends the transmission interval of the next detection pulse by a preset ratio of 1.5 times (i.e., the interval is 1.5s after the first extension, 2.25s after the second extension, and so on). When the detection interval is extended to the maximum threshold of 10s, the interval adjustment module stops the extension operation and continues to send detection pulses at a 10s detection interval until the detection pin detects a feedback pulse from the external storage device, or receives a forced mounting command (instruction identifier is 0x02) sent by the main control application through the instruction transmission module, and then triggers the mounting thread to resume the mounting process.

[0080] Optionally, the immediate initialization of the camera and encoder in step S2 specifically involves:

[0081] When initializing the camera, three reset commands are sent to the camera, with a fixed interval between each reset command. After the reset, the camera status register is read.

[0082] If the status register shows normal, write the resolution parameter to the camera. After writing, wait for a fixed time and read the status register again to confirm that the parameter was written successfully.

[0083] Start the camera image acquisition function, acquire the first frame of the image, and immediately turn off the acquisition function to sample and detect the pixels of the frame.

[0084] If the sampling test results meet the standards, the acquisition function will be restarted and the system will return to normal operation. If they do not meet the standards, the resolution parameters will be adjusted, and the parameter writing and sampling test will be re-executed.

[0085] In one embodiment, when initializing the camera, the main control application sends three reset commands to the camera (1080P resolution model) through the camera communication interface (I2C interface). The reset command is an 8-bit binary data "0x01", and the interval between each transmission is a fixed duration of 200ms. After the three reset commands are sent, the 8-bit data of the camera status register (address 0x00) is read through the I2C interface. If the 0th bit of the status register is "0", it indicates that the camera reset is normal.

[0086] It should be noted that after the status register displays normally, the main control application writes the resolution parameter to the camera parameter register (address 0x02) via the I2C interface. The parameter value "0x03" corresponds to a 1920×1080 resolution. After writing, wait for a fixed duration of 100ms, and then read the status register (address 0x00) again. If the first bit of the register is "1", it confirms that the resolution parameter was written successfully. Subsequently, the main control application sends an image acquisition start signal (high level 3.3V, lasting 50ms) to the camera via the GPIO pin to start the camera's image acquisition function. After the camera acquires the first frame of image and transmits it to the memory buffer (address 0x84000000-0x8407A1FF, capacity 5MB) specified by the main control application, the main control application immediately sends an acquisition stop signal (low level 0V, lasting 50ms) to stop the acquisition function.

[0087] In another embodiment, the main control application calls the image sampling and detection module to sample the first frame image in the memory buffer at intervals of 100×100 pixels, for a total of 100 pixels. It then checks whether the RGB color value of each pixel is within a preset range (R: 0-255, G: 0-255, B: 0-255). If the color values ​​of all 100 sampled pixels meet the standard, the acquisition start signal is sent again through the GPIO pin to restart the camera's acquisition function and return it to normal operation. If the color value of any sampled pixel exceeds the preset range, the resolution parameter is adjusted to "0x02" (corresponding to 1280×720 resolution), and the parameter is rewritten to the camera parameter register. After waiting 100ms, the status register is read to confirm successful writing, and the image acquisition, closing, and sampling detection process is repeated.

[0088] Of particular importance, the immediate initialization of the camera and encoder in step S2 also includes:

[0089] When initializing the encoder, a clock calibration command is sent to the encoder. After calibration is completed, the internal clock frequency value of the encoder is read.

[0090] If the clock frequency value is within the preset range, the encoding format parameters are written to the encoder, and the encoder pre-encoding mode is started after writing.

[0091] Input a fixed length of test data into the precoding mode, obtain the precoding result output by the encoder, and calculate the compression ratio of the precoding result;

[0092] If the compression ratio is within the preset range, the pre-encoding mode is turned off and the normal encoding mode is started; if it is not within the preset range, the internal clock is recalibrated and the parameter writing and pre-encoding test is performed again.

[0093] In one embodiment, when initializing the encoder, the main control application sends a clock calibration command to the video encoder (H.265 encoding standard model) through the encoder communication interface (SPI interface). The command is 16-bit binary data "0x0001", and the calibration process lasts for 100ms. After the calibration is completed, the 32-bit data of the encoder's internal clock frequency register (address 0x03) is read through the SPI interface to obtain the current clock frequency value.

[0094] In another embodiment, if the clock frequency is within a preset range of 25MHz ± 1MHz, the main control application writes encoding format parameters to the encoder parameter register (address 0x05) via the SPI interface. The parameter value "0x02" corresponds to H.265 encoding format, 1080P resolution, and 30fps frame rate. After the parameters are written, the main control application writes the instruction "0x04" to the encoder control register (address 0x01) to start the encoder pre-encoding mode. The main control application inputs a fixed-length 10MB test data (which is a preset standard video frame sequence) to the pre-encoding mode through the data transmission module. After the encoder pre-encodes the test data, it outputs the pre-encoding result. The main control application obtains the pre-encoding result through the data receiving module and calculates the compression ratio of the pre-encoding result (compression ratio = pre-encoding result size / original test data size).

[0095] In another embodiment, if the compression ratio is within the preset range of 30:1-50:1, the main control application writes a "0x08" instruction to the encoder control register to disable the pre-encoding mode, and simultaneously writes a "0x10" instruction to start the normal encoding mode. If the compression ratio is not within the preset range, the main control application resends the clock calibration instruction to the encoder, repeats the clock calibration and clock frequency reading process, and after the clock frequency value meets the requirements, it re-executes the process of writing encoding format parameters, starting the pre-encoding mode, inputting test data, and calculating the compression ratio.

[0096] Preferably, in step S3: after the external storage device is successfully mounted, the video data in the memory buffer is transferred to the external storage device through time-series backtracking migration, and the encoded video data is continuously written to the external storage device through a circular queue.

[0097] Optionally, step S3, which involves transferring the video data from the memory buffer to an external storage device via time-series backtracking migration, includes:

[0098] Once the external storage device is successfully mounted, the main control application reads the starting identifier of the first frame of video data in the memory buffer and establishes a time-series backtracking index based on the starting identifier. The time-series backtracking index records the correspondence between the storage offset address of each frame of data and the acquisition timestamp.

[0099] The main control application uses the time-series backtracking index to reverse locate the physical storage location of each frame of data in the memory cache according to the order of the collected timestamps, forming an ordered backtracking path;

[0100] The first video data segment is read along the ordered backtracking path and written to the external storage device. At the same time, a time-series mapping table is created in the external storage device to record the start timestamp, end timestamp, and storage address of the data segment.

[0101] In one embodiment, after the external storage device is successfully mounted, the main control application accesses the memory buffer through the memory data reading module and reads the 16-byte synchronization identifier at the start position of the first frame of video data. The synchronization identifier includes a "0xAA55" start bit, an 8-byte frame sequence number, a 4-byte acquisition timestamp, and a 2-byte check bit. Based on the acquisition timestamp in the synchronization identifier and the physical address of the first frame data in the memory buffer, the main control application establishes a timing backtracking index through the index building module. The index is stored in the form of a linked list, and each index entry records the correspondence between the storage offset address of each frame data (the offset relative to the start address of the memory buffer, in bytes) and the acquisition timestamp. The storage interval of the index entry is consistent with the data storage interval of each frame.

[0102] In another embodiment, the main control application extracts the acquisition timestamps of all frame data in the time-series backtracking index through the time-series sorting module, and locates the physical storage location of each frame data in the memory cache in reverse order of the timestamps from earliest to latest according to the storage offset address in the index entry, forming an ordered backtracking path sorted by acquisition time.

[0103] In another embodiment, the main control application reads the first 10MB of video data (containing 20 frames) at a rate of 80MB / s along the ordered backtracking path via the data transmission module, and writes the data segment to a designated partition of the external storage device via the external storage device interface module. At the same time, the main control application creates a timing mapping table in a designated directory of the external storage device via the mapping table creation module. Each record in the mapping table contains the start timestamp (first frame acquisition timestamp), end timestamp (20th frame acquisition timestamp), and storage address in the external storage device for the data segment. Each record occupies 64 bytes of storage space, of which the start timestamp and end timestamp each occupy 16 bytes, and the storage address occupies 32 bytes.

[0104] Optionally, step S3, which involves transferring the video data from the memory buffer to an external storage device via time-series backtracking migration, further includes:

[0105] After the first segment of data is written, the main control application locates the starting position of the next segment of data in the time backtracking index of the memory cache based on the end timestamp of the time mapping table, thus avoiding repeated reading of the transferred data.

[0106] If a data segment break is detected during the backtracking reading process, the main control application will backtrack a preset number of frames based on the storage offset address of the frame before the break, reconfirm the data continuity, and then continue to transfer the data.

[0107] After all data has been transferred, the main control application compares the time-series backtracking index in the memory cache with the time-series mapping table of the external storage device. Once it confirms that the timestamp coverage is completely consistent, it deletes the transferred data from the memory cache.

[0108] In one embodiment, after writing the first 10MB video data (including 20 frames) to the external storage device, the main control application obtains the end timestamp (the 20th frame acquisition timestamp) of the time-series mapping table in the external storage device through the mapping table reading module. Then, through the index matching module, it searches for the index entry corresponding to the end timestamp in the time-series backtracking index in the memory cache. The next index entry of the index entry is used as the starting position of the next data segment, ensuring that subsequent readings only target un-transferred data and avoiding repeated readings of already transferred data.

[0109] In another embodiment, if during the data reading process along the ordered backtracking path, the data continuity detection module compares the acquisition timestamp interval of adjacent frame data (normal interval 33ms, corresponding to a 30fps frame rate) and finds that the timestamp interval between two frames exceeds 100ms, it determines that the data segment is broken. The main control application uses the backtracking positioning module to backtrack the offset address corresponding to 5 frames of data based on the storage offset address of the frame before the break, rereads the acquisition timestamp and synchronization identifier of these 5 frames of data, and confirms that the data continuity is restored (the timestamp interval between adjacent frames returns to the range of 33ms±5ms). Then, it continues to perform data transfer from the next index item of the frame before the break.

[0110] In another embodiment, after all video data has been transferred, the main control application extracts the start and end timestamps of all frame data in the time-series backtracking index of the memory buffer through the data comparison module, and at the same time extracts the start and end timestamps of all data segments in the time-series mapping table of the external storage device. The timestamp coverage of the two is compared segment by segment. After confirming that they are completely consistent, the memory cleanup module deletes all transferred video data in the memory buffer and releases the occupied memory space (the total released capacity is consistent with the total amount of transferred data).

[0111] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0112] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A method for controlling the start-up of a vehicle dashcam, characterized in that, Includes the following steps: Step S1: After the dashcam device is powered on, the bootloader starts the dashcam's real-time operation unit; The recorder's real-time operation unit loads the main operation unit kernel from the storage medium to the memory unit point-to-point. After the main operation unit kernel responds and starts, it runs the main control application. In step S1, the real-time operation unit of the recorder loads the main operation unit kernel from the storage medium to the memory unit point-to-point, including: After the recorder's real-time operation unit is started, it first cuts off the power supply to all partitions in the storage medium except for the main operation unit's kernel storage partition, and only retains the power supply circuit for the kernel storage partition; The recorder's real-time operation unit divides the main operation unit kernel into several data blocks of equal length and starts dual-thread parallel processing. One thread reads the data blocks, and the other thread transfers the read data blocks to the memory unit. After each data block is transmitted, the recorder's real-time operation unit calculates the feature value of that data block in the memory unit; The calculated feature value is compared with the preset feature value of the data block in the storage medium. If they match, the next data block is processed. If they do not match, the data block is read and transmitted again. After all data blocks have been transmitted, the recorder's real-time operation unit calculates the overall feature value of the complete kernel data spliced ​​in the memory unit. Only after the overall feature value matches the preset value is the main operation unit kernel started. Step S2: When the main control application runs, the camera and encoder are initialized immediately, and the encoded video data is written to the memory buffer through a wait-free buffer response. At the same time, the external storage device is mounted intermittently and asynchronously. Step S3: After the external storage device is successfully mounted, the video data in the memory buffer is transferred to the external storage device through time-series backtracking migration, and the encoded video data is continuously written to the external storage device through a circular queue.

2. The dashcam start control method according to claim 1, characterized in that, Step S2, which involves writing the encoded video data into the memory buffer using a wait-free buffer response, includes: Two parallel storage channels are set up in the memory buffer. The first channel receives the currently generated encoded video data, and the second channel temporarily stores the received encoded video data. Encoded video data is written to the first channel in units of frames. When the first channel is full of a frame of data, it automatically switches to the second channel to receive the next frame of data. Once the first channel is full of frame data, the frame data is immediately copied to the end of the second channel. After copying is complete, the frame data in the first channel is cleared. At fixed intervals, the feature identifiers of the same frame data in the first channel and the second channel are compared. If the identifiers are inconsistent, the second channel is updated based on the frame data in the first channel. When the storage capacity of the second channel reaches its limit, the earliest stored frame data is deleted in chronological order of storage time to make room for new data.

3. The dashcam start control method according to claim 2, characterized in that, Before the encoded video data is written to the first channel in frames, it also includes: Before writing each frame of encoded video data into the first channel, add a synchronization marker of fixed length at the beginning of the encoded video data. During the writing process, a detection thread is started to monitor the integrity of the synchronization flag in real time. If the synchronization flag is found to be damaged, the writing of that frame of data is stopped immediately. Reacquire the encoded video data corresponding to the frame, add a new synchronization identifier, and write it back to the first channel; If the synchronization flag is corrupted in two consecutive writes, the encoded video data corresponding to that frame will be temporarily stored in the spare sub-area of ​​the memory buffer. When the spare sub-area is full of three frames of data, the repair thread is started to re-add the synchronization flag to the data in the spare sub-area and then write it to the second channel.

4. The dashcam start control method according to claim 1, characterized in that, The specific steps of executing the external storage device mount operation intermittently and asynchronously in step S2 are as follows: After the main control application starts the mounting thread, it first sends a low voltage wake-up signal to the external storage device, and then waits for a preset time before detecting the response signal from the external storage device. If a response signal is received, a standard voltage power supply command is sent to the external storage device to switch to standard voltage mode; if no response signal is received, a low voltage wake-up signal is sent again at fixed intervals. After switching to standard voltage mode, the mounting thread sends a device model and interface protocol read command to the external storage device; Select the corresponding mount instruction set based on the interface protocol information and execute the mount operation; If no response is received for any of the following commands: standard voltage power supply command, device model and interface protocol read command, the command will be sent repeatedly, up to a maximum of three times. If no response is received after three attempts, the mounting process will be suspended, and the low voltage wake-up procedure will be re-executed after a longer interval.

5. The dashcam start control method according to claim 4, characterized in that, After the main control application starts the mount thread, it also includes: During the intermittent period, the mounting thread enters a low-power mode, keeping only the detection pin of the external storage device interface active. The detection pin sends detection pulses at a fixed frequency. If a feedback pulse from an external storage device is detected, the mounting thread is immediately woken up. If no feedback pulse is detected, the interval between the next detection pulses will be extended, with the duration of each extension increasing by a preset ratio. Once the detection interval is extended to the maximum threshold, continue detecting at that interval until a feedback pulse is detected or a forced mount command is received from the main control application.

6. The dashcam start control method according to claim 1, characterized in that, Step S2, which immediately initializes the camera and encoder, specifically involves: When initializing the camera, three reset commands are sent to the camera, with a fixed interval between each reset command. After the reset, the camera status register is read. If the status register shows normal, write the resolution parameter to the camera. After writing, wait for a fixed time and read the status register again to confirm that the parameter was written successfully. Start the camera image acquisition function, acquire the first frame of the image, and immediately turn off the acquisition function to sample and detect the pixels of the frame. If the sampling test results meet the standards, the acquisition function will be restarted and the system will return to normal operation. If they do not meet the standards, the resolution parameters will be adjusted, and the parameter writing and sampling test will be re-executed.

7. The dashcam start control method according to claim 1, characterized in that, Step S3, which involves transferring the video data from the memory buffer to an external storage device via time-series backtracking migration, includes: Once the external storage device is successfully mounted, the main control application reads the starting identifier of the first frame of video data in the memory buffer and establishes a time-series backtracking index based on the starting identifier. The time-series backtracking index records the correspondence between the storage offset address of each frame of data and the acquisition timestamp. The main control application uses the time-series backtracking index to reverse locate the physical storage location of each frame of data in the memory cache according to the order of the collected timestamps, forming an ordered backtracking path; The first video data segment is read along the ordered backtracking path and written to the external storage device. At the same time, a time-series mapping table is created in the external storage device to record the start timestamp, end timestamp, and storage address of the data segment.

8. The dashcam start control method according to claim 1, characterized in that, Step S3, which involves transferring the video data from the memory buffer to the external storage device via time-series backtracking migration, also includes: After the first segment of data is written, the main control application locates the starting position of the next segment of data in the time backtracking index of the memory cache based on the end timestamp of the time mapping table, thus avoiding repeated reading of the transferred data. If a data segment break is detected during the backtracking reading process, the main control application will backtrack a preset number of frames based on the storage offset address of the frame before the break, reconfirm the data continuity, and then continue to transfer the data. After all data has been transferred, the main control application compares the time-series backtracking index in the memory cache with the time-series mapping table of the external storage device. Once it confirms that the timestamp coverage is completely consistent, it deletes the transferred data from the memory cache.

9. A vehicle dashcam start control system, characterized in that, For executing the dash cam start control method as described in claim 1, the dash cam start control system includes: The kernel loading and boot module is used to start the real-time operation unit of the dashcam after the dashcam device is powered on. The real-time operation unit of the dashcam loads the main operation unit kernel from the storage medium to the memory unit point-to-point. After the main operation unit kernel responds and starts, it runs the main control application. The cache control module is used to immediately initialize the camera and encoder when the main control application runs, and write the encoded video data into the memory cache area through a no-wait cache response, while performing the mounting operation of external storage devices intermittently and asynchronously. The video transfer module is used to transfer video data in the memory buffer to the external storage device through time-series backtracking migration after the external storage device is successfully mounted, and to continuously write the encoded video data to the external storage device through a circular queue.

Images