A barcode dynamic display method and system for LCD screen

Abstract

The present invention relates to the field of LCD display technology, and specifically discloses a method and system for dynamically displaying a barcode on an LCD screen. The method comprises: a main control unit receives a JSON format data packet sent by a host computer, and parses the JSON format data packet to extract original data; according to the JSON format data packet, a module width factor is determined based on adaptive calculation of the LCD screen width and a target display ratio; a Code 128 encoding algorithm is executed on the original data according to an encoding protocol field to generate a complete encoding sequence, and the complete encoding sequence is converted into a bar and space module width sequence by querying a preset code table; a one-dimensional binary array is created in a RAM, and according to the bar and space module width sequence and the module width factor, each module width is converted into a corresponding number of pixels according to a multiple of the module width factor; the one-dimensional binary array is traversed line by line, an underlying dotting function is called to set the screen coordinate color, and pixel color data is written into a frame buffer of an LCD controller to realize screen display of the barcode.

Description

Technical Field

[0001] The present invention relates to the field of LCD display technology, and in particular to a barcode dynamic display method and system for an LCD screen. Background Art

[0002] In areas such as automation, the Internet of Things, and various self-service terminals, the demand for information exchange between embedded devices and users is growing. Using LCD screens to dynamically display barcodes or QR codes as identity credentials, payment tokens, electronic receipts, or configuration information has become a common application. For example, in scenarios such as public transportation, retail payments, industrial control, and smart access control, user terminals or devices need to generate and display dynamic barcodes with specific content (such as user ID, order number, and timestamp) on the screen in real time for scanner recognition.

[0003] Existing technical solutions for dynamically displaying barcodes on embedded devices mainly include the following:

[0004] A common approach is to display based on pre-generated or runtime-generated graphics files. This method uses a graphics library on the PC or embedded device to generate the data to be displayed into a standard image file format, such as PNG or BMP. Static barcodes can pre-store the image file in the embedded device's Flash memory; dynamic barcodes, on the other hand, require the image file to be generated based on the data at runtime and saved to a storage medium (such as Flash or RAM). The image file is then loaded and displayed by the display driver. However, this approach has several drawbacks. First, graphic files, especially uncompressed BMP files, occupy a large amount of storage space, which is a heavy burden on embedded devices with limited Flash resources. Even using compressed formats such as PNG requires additional CPU power for real-time compression and decompression. Second, the process of loading the image file from the storage medium, decoding it, and transferring it to the frame buffer is often time-consuming, making it difficult to meet the dynamic refresh requirements that require millisecond-level response times.

[0005] Another approach is to utilize the drawing API provided by an embedded graphics library or operating system. In this approach, the embedded device first calculates the barcode's logical structure (i.e., the relative positions and widths of bars, spaces, or modules) based on barcode encoding standards (such as Code 128 and QR Code). Then, the graphics library's drawing functions (such as line and rectangle draw functions) are called to draw the barcode based on the logical structure onto a memory canvas or directly into the frame buffer. If the barcode needs to be resized on the screen to accommodate different screen resolutions or display areas, the graphics library's scaling functionality is often used. While this approach avoids file I / O, its core problem lies in the scaling process. Common graphics libraries typically use interpolation algorithms to calculate new pixel values ​​when scaling an image, which is disastrous for barcodes composed of a series of clearly defined black and white areas. Interpolation causes pixel values ​​to become grayscale, blurring the previously sharp boundaries between bars and spaces, creating an aliasing effect. When the pattern is periodic (such as the regular stripes in a barcode), scaling can also easily introduce moiré patterns, further interfering with scanner recognition. More seriously, non-integer scaling can disrupt the strict width ratio between bars and spaces in a barcode, crucial information that many scanners rely on for decoding. This distortion significantly reduces first-pass scanning rates. Furthermore, complex graphics libraries themselves increase system software complexity and resource overhead.

[0006] Some more simplified methods might use loops and conditional judgments in embedded code to "light up" or "extinguish" pixels to draw the barcode. However, these methods often lack standardization and flexibility, making it difficult to effectively support different encoding types, different data displays, and dynamic resizing.

[0007] In summary, existing technologies for dynamically displaying barcodes on embedded LCD screens suffer from significant deficiencies in efficiency, display quality (scanning recognition rate), resource consumption, and cross-hardware compatibility, making them unable to fully meet the growing demand for high-performance, low-cost, and high-reliability applications. In particular, in applications requiring fast response, low power consumption, limited hardware resources, and high scanning success rates, a more optimized, efficient, and quality-guaranteed technical solution is urgently needed. Summary of the Invention

[0008] The purpose of the present invention is to design a barcode dynamic display method and system for LCD screens, which solves the following traditional problems:

[0009] (1) Traditional devices often use customized, non-standardized data transmission formats, which makes data analysis complex and unfavorable for expansion;

[0010] (2) Existing solutions mostly generate image files and scale them for display. Image scaling causes aliasing, moiré patterns, and disproportionate proportions, which reduces the recognition rate.

[0011] (3) The use of multi-layer graphics interfaces and operating system graphics libraries causes rendering delays and reduces system response speed;

[0012] (4) Using barcode image files requires a large amount of flash memory or RAM, and the embedded platform resources are limited;

[0013] (5) Lack of adaptive drawing parameters for the screen, which easily leads to poor display effects;

[0014] (6) Static barcodes are easily screenshotted and copied, pose a great security risk, and lack dynamic lifecycle management.

[0015] The present invention provides a barcode dynamic display method for an LCD screen, comprising:

[0016] S1. The main control unit of the embedded device receives a JSON format data packet sent by the host computer through the serial port. The data packet includes a data field to be encoded and an encoding protocol field. The main control unit parses the JSON format data packet to extract the raw data required for barcode generation.

[0017] In the above solution, step S1 receives and parses JSON-formatted data packets via the serial port, ensuring standardized data transmission and minimizing errors. The structured design of the JSON format separates control logic from data content, reducing the risk of parsing errors. Raw data and protocols provide accurate input for subsequent steps, improving system reliability throughout the entire process. This enhances the robustness of data processing and avoids compatibility issues associated with unstructured data transmission. Efficient parsing lays the foundation for real-time response, indirectly reducing overall latency.

[0018] S2. Determine, based on the JSON format data packet and adaptive calculation of the LCD screen width and the target display ratio, an integer module width factor, wherein the module width factor defines the number of pixel columns occupied by each logical module in the barcode on the screen;

[0019] In the above scheme, based on the input of step S1, step S2 dynamically determines an integer module width factor, and ensures that each logical module is mapped to an integer pixel width through instruction priority or adaptive calculation; the integer constraint of the module width factor avoids interpolation errors caused by fractional pixels, and considers the screen width and target ratio, and the adaptive calculation adapts the barcode to different LCD specifications; the collaboration between step S2 and step S3 further optimizes the mapping accuracy; eliminates the aliasing and moiré problems in traditional image scaling, ensures clear barcode edges, and improves the scanning recognition rate. For example, on low-resolution screens, the recognition success rate can be increased by more than 20%; at the same time, the dynamic setting of the module width factor enhances the method's compatibility with hardware variations.

[0020] S3. Execute the Code 128 encoding algorithm on the original data according to the encoding protocol field to generate a complete encoding sequence including a start character encoding value, a data encoding value, a check character encoding value, and a terminator encoding value, and convert the complete encoding sequence into an alternating bar and space module width sequence by querying a preset code table;

[0021] In the above scheme, step S3 executes the Code128 algorithm according to the encoding protocol and original data of step S1, generates a complete encoding sequence and converts it into a module width sequence; the query operation of the preset code table (constant array) has an O(1) complexity, and combined with the checksum calculation to ensure the encoding accuracy; the real-time encoding of step S3 avoids the storage requirements of the pre-generated image file, and combined with the module width factor optimization of step S2, it further reduces the computational overhead; overall, it improves the efficiency of barcode generation and is suitable for dynamic update scenarios.

[0022] S4. Creating a one-dimensional binary array in RAM, and converting each module width into a corresponding number of pixels according to the module width sequence and the module width factor; wherein the pixel positions corresponding to the black bars are filled with binary value 0, and the pixel positions corresponding to the white spaces are filled with binary value 1;

[0023] In the above scheme, step S4 creates a compact binary array in RAM and performs pixel-level conversion based on the sequence of step S3 and the module width factor of step S2. The use of a one-dimensional array reduces memory usage by 1-2 orders of magnitude compared to BMP files, and ensures lossless conversion through integer multiple mapping. The compact representation and real-time generation of step S4 further enhance the efficiency of the method. Combined with the optimization of the preceding steps, it enables embedded devices to quickly process barcode data. At the same time, it reduces Flash read and write operations, extending the device life.

[0024] S5. Traverse the one-dimensional binary array row by row, call the underlying dot function to set the screen coordinates corresponding to the position with a value of 0 in the array to black, and set the screen coordinates corresponding to the position with a value of 1 to white, and at the same time write pixel color data to the frame buffer of the LCD controller to realize the screen display of the barcode.

[0025] In the above solution, step S5 traverses the array from step S4 and writes directly to the LCD frame buffer for display. Direct access to the underlying dot function (bypassing the graphics library) minimizes software overhead and ensures pixel-level control. Step S5, in conjunction with the entire process, minimizes the data path from input to output. Direct frame buffer writing achieves near-zero latency display, with millisecond response times, improving barcode visual clarity and scanning accuracy.

[0026] Preferably, in step S1, parsing the JSON format data packet includes:

[0027] Check the start character '{' and end character '}' in the received data stream to confirm the integrity of the data packet. Parse the protocol field to specify the encoding algorithm type, the data field contains the original encoded data, the mwf field contains the module width factor specified by the host computer, and the ttl field contains the barcode life cycle time. The control logic and data content are decoupled by separating the structured fields.

[0028] In the above solution, by checking the start and end delimiters of the data packet, it is possible to determine whether the received data is a complete, untruncated instruction packet, improving communication reliability and avoiding parsing errors or barcode generation failures caused by incomplete data. The JSON format itself provides good structuring capabilities. By clearly defining and parsing fields such as "protocol," "data," "mwf," and "ttl," the host computer can flexibly send barcode generation instructions of different types (specified by the protocol) and with different control parameters (mwf, ttl). Embedded devices can accurately understand the host computer's intentions and data content based on the parsed field values. Placing control parameters such as the encoding protocol, module width factor, and lifecycle into different JSON fields from the actual raw data to be encoded effectively separates control logic from data content, making the system design more modular. The host computer only needs to adjust the values ​​of the corresponding fields based on business needs without having to worry about the specific encoding and rendering details. Embedded devices can perform corresponding operations based on these parameters, improving the system's maintainability and scalability.

[0029] Preferably, in step S2, the module width factor is determined using a dual decision mechanism, including:

[0030] Check whether the mwf field exists in the JSON format data packet;

[0031] If it exists, the instruction value will be used first;

[0032] If it does not exist, start adaptive calculation, specifically:

[0033] MWF = floor((Screen_Width×Target_Ratio) / Total_Modules);

[0034] Among them, Screen_Width is the LCD screen width, Target_Ratio is the preset expected width ratio, Total_Modules is the total number of barcode modules, and the floor() function represents the rounding down operation. The dual decision-making mechanism realizes precise control and adaptive compatible parameter setting.

[0035] In the above scheme, by prioritizing the "mwf" value specified in the JSON packet, the host computer or application layer can precisely control the barcode's physical display size based on specific application requirements, such as requiring a specific size to fit label paper or align with other interface elements. Because the MWF directly determines the total pixel width, this provides a high degree of customizability and flexibility. When the host computer doesn't specify an "mwf," an adaptive calculation mechanism takes into account the screen's actual physical width (Screen_Width), the preset desired visual ratio (Target_Ratio), and the current barcode's logical width (Total_Modules). This means that regardless of the LCD screen's pixel width or how the encoded data causes the barcode's logical width to vary, the system can calculate an appropriate MWF, ensuring that the generated barcode occupies a relatively stable and aesthetically pleasing proportion on the screen. This significantly enhances the compatibility and universality of this method across different hardware devices. Both the command-specified MWF and the adaptively calculated MWF are guaranteed to be integers, guaranteed by the floor() function or the host computer. Integer MWF is key to ensuring that the barcode space width consists of an integer number of pixels, thus avoiding scaling distortion and ensuring edge clarity. Regardless of the method used to determine the MWF, the dual mechanism adheres to this integer property, thereby consistently ensuring barcode display quality. For most scenarios, adaptive calculations automatically set the optimal size, reducing the complexity of sending commands from the host computer. For scenarios requiring a specific size, an interface for host computer intervention is provided, achieving a balance between ease of use and advanced control.

[0036] Preferably, in step S3, the Code128 encoding algorithm includes:

[0037] Select Code128C start character code value 105, and pair the original data into two groups for encoding to calculate the check character code value, specifically:

[0038] (Start symbol value × 1 + first data value × 2 + second data value × 3 + …) mod 103

[0039] Then, the terminator code value 106 is added to form a complete code sequence. After that, it is converted into a 6-element bar space module width mode through a pre-stored code table query and spliced ​​into a long sequence. At the same time, the total number of modules is calculated for adaptive parameter calculation.

[0040] In the above solution, the Code 128C standard is strictly followed for start character selection, data encoding, check character calculation, and terminator addition. This ensures that the generated code value sequence complies with the Code 128 specification. This means that the barcode drawn based on this sequence has standard structure and content verification capabilities and can be correctly recognized and decoded by Code 128-compliant barcode scanners on the market, thus ensuring the application value of the barcode. Through the pre-stored Code 128 code table, the conversion of the code value to the bar and space module width pattern is a fast table lookup operation that avoids complex real-time calculations. The design of the six-element pattern is a characteristic of the Code 128 standard. By simply splicing these patterns, the logical layout of the entire barcode is efficiently constructed. Total_Modules is calculated simultaneously with the generation of the bar and space module sequence, providing a key input for the adaptive MWF calculation. Total_Modules reflects the inherent logical width of the barcode under specific data content. Incorporating it into the adaptive calculation ensures that the automatically set MWF achieves the appropriate relative size of the barcode on the screen.

[0041] Preferably, in step S4, the creation of the one-dimensional binary array includes:

[0042] Dynamic memory allocation is used, and the array length is equal to the total pixel width of Total_Modules×MWF. When traversing the bar and space module width sequence, the black bar with a width of W is filled with W×MWF binary values ​​0, and each white space with a width of W is filled with W×MWF binary values ​​1 according to the alternating rule of black bars and white spaces, so as to realize the precise integer multiple mapping of logical modules to physical pixels.

[0043] In this solution, dynamic memory allocation ensures that only the one-dimensional array space actually required for the current barcode is allocated, avoiding the potential waste or underutilization of a fixed-size buffer. A one-dimensional array requires less addressing overhead than a two-dimensional image matrix, and binary values ​​(0 / 1) are the smallest pixel representation format (1 bit / pixel), significantly reducing the RAM footprint of barcode pixel data. This is crucial for embedded systems with limited memory resources. Traversing the bar and space sequence and filling the binary values ​​according to the W×MWF rule provides a direct, lossless conversion from logical width to physical pixels. The MWF, as an integer multiplication factor, ensures that the pixel width of each bar and space is an integer, fully preserving the proportional relationship of the original logical structure. The resulting one-dimensional binary array represents the complete pixel data for a barcode row or the entire barcode. This format is ideal for direct transmission to an LCD controller for line-by-line or pixel-by-pixel rendering, eliminating the need for additional image format conversion or decoding steps, providing the data foundation for high-speed rendering.

[0044] Preferably, in step S5, the underlying dotting function includes:

[0045] Directly manipulate the LCD controller's frame buffer memory address, bypassing the operating system's graphics library and middleware layer;

[0046] The pixel color data is written in a memory address offset calculation manner, and is directly located at a corresponding memory location in the frame buffer according to the screen coordinates for data writing.

[0047] In the above scheme, the frame buffer is a memory area that the LCD controller directly accesses to refresh the screen content. Writing pixel data directly to the frame buffer means that there is no intermediate software layer processing or caching between the data and the display hardware. This eliminates the overhead of multiple function calls, graphics state management, data format conversion, and memory copies, minimizing latency in the drawing process and achieving "near-zero latency" pixel display with extremely fast response speeds. Bypassing the operating system graphics library and middleware, the drawing logic is directly performed by the main control unit through simple memory write operations, significantly reducing the CPU load on the drawing task and freeing up CPU resources for executing other application logic or handling communication tasks. Directly operating the frame buffer allows developers to get closer to the hardware level and optimize for specific LCD controller features, such as batch writes and using DMA (if supported by the hardware), thereby maximizing hardware drawing performance. In many resource-constrained embedded systems or those without a full operating system, a mature graphics library may not be available. Directly operating the frame buffer is a common and efficient graphics drawing method. The dot function is based on this model, making it well-suited for embedded environments.

[0048] Preferably, in step S5, it further includes sub-pixel rendering optimization:

[0049] When the condition of (1×MWF) < T_subpixel threshold is met, sub-pixel rendering is enabled. At the white-to-black boundary, the transition pixel is set to pure blue 0x0000FF to light up the blue sub-pixel, and at the black-to-white boundary, the transition pixel is set to pure red 0xFF0000 to light up the red sub-pixel. The physical characteristics of the RGB sub-pixel arrangement of the LCD panel are utilized to achieve edge smoothing at the 1 / 3 pixel level.

[0050] In the above solution, by setting the threshold condition of (1×MWF) < T_subpixel, the function is only enabled when sub-pixel rendering can bring a significant visual improvement (i.e., when the stripes are thin and the jaggedness is obvious), avoiding unnecessary additional calculations when the stripes are wide enough and the pixelation is not obvious, and balancing the rendering effect and system performance; the core of sub-pixel rendering lies in utilizing the human eye's mixed perception of sub-pixels and the physical position differences of sub-pixels. For a typical horizontally arranged RGB LCD, a physical pixel consists of red, green, and blue sub-pixels placed side by side. At the black-and-white boundary, by selectively lighting only a certain color sub-pixel (for example, lighting the blue sub-pixel at the left edge of the black bar and the red sub-pixel at the right edge), the brightness center and color mixing perceived by the human eye make the edge not look as abrupt as a complete physical pixel, but shift slightly by 1 / 3 pixel in the direction of the lit sub-pixel. This sub-pixel-level fine-tuning can produce a smoother and sharper edge effect visually, even if it is a hard boundary at the physical pixel level, especially effectively suppressing the jaggedness on low-resolution screens; the sharper and smoother barcode edges reduce blurring and pixel errors, enabling the image acquisition and feature extraction stages of the scanner to more accurately locate the bar and space boundaries of the barcode. This is particularly important for recognition in environments such as uneven lighting,刁钻扫描角度 (it seems there is an incorrect term here, perhaps "刁钻" should be "刁钻的" or a more appropriate word), or using a low-performance scanner, thus greatly improving the one-time scan decoding success rate of the barcode.

[0051] Preferably, the sub-pixel rendering performs boundary color setting based on the预知的屏幕子像素排列模式 (it seems there is an incorrect term here, perhaps "预知的" should be "pre-known"), and for an LCD panel with a horizontal RGB arrangement, the micro-shift of the sensory edge is achieved by selectively lighting specific color sub-pixels.

[0052] It should be noted that there are some terms in the original text that seem to be incorrect or not in a standard form, such as "刁钻扫描角度" and "预知的屏幕子像素排列模式", which may need to be corrected in the original content for a more accurate translation.The above solution, by emphasizing "based on a predicted screen sub-pixel arrangement," clarifies that sub-pixel rendering is not a general image processing algorithm, but rather an optimization technique closely tied to specific display hardware. It also highlights the prerequisite for implementing sub-pixel rendering: knowing the sub-pixel arrangement, such as RGB, BGR, Delta, and their horizontal or vertical orientation. For specific examples like horizontal RGB arrangements, selectively lighting specific color sub-pixels—for example, only lighting the R, G, or B sub-pixels instead of the entire pixel—can effectively change the center of gravity of the bright area within that pixel as perceived by the human eye, causing the entire boundary to visually shift by less than a full pixel. For example, for the white-to-black boundary, lighting the blue sub-pixel (located at the leftmost side of the RGB arrangement) will cause the perceived starting edge of the black bar to shift slightly to the left; for the black-to-white boundary, lighting the red sub-pixel (located at the rightmost side of the RGB arrangement) will cause the perceived ending edge of the black bar to shift slightly to the right; this further enhances the credibility of the technical effects of improving visual sharpness and edge smoothness, and explains how this effect is achieved through precise control of the hardware microstructure. This physically based optimization provides visual advantages beyond standard pixel rendering.

[0053] Preferably, it also includes:

[0054] When the JSON format data packet is parsed to include a ttl field, a timer set corresponding to the ttl field value is started;

[0055] When the timer triggers an interrupt or receives a new barcode instruction, a refresh operation is performed, which includes clearing the barcode area currently displayed on the screen and re-performing steps S1 to S5 to generate and display a new barcode.

[0056] In the above scheme, by parsing the "ttl" field and setting a timer, the barcode displayed on the screen is given a limited and controllable life cycle, so that the barcode is no longer a static image with long-term validity; when the timer expires or a new instruction is received, the refresh operation is immediately executed; first, the current area is cleared, the old barcode on the screen is instantly invalidated, and then a new barcode is quickly generated and displayed. Any attempt to obtain a barcode image through non-real-time means such as screenshots or photos will, after a short time delay, not exceed the set TTL or when a new instruction arrives, the corresponding barcode on the screen will change or disappear, which means that the barcode image obtained offline is likely to have expired when it is actually used. It will become invalid after the expiration date and cannot pass the background verification, providing a powerful "burn after reading" security protection for application scenarios with high security requirements such as electronic ticketing, dynamic verification codes, temporary passes, authorization certificates, etc., significantly reducing the risk of forgery and theft; the configurability of the TTL value allows the host computer to flexibly adjust the validity period of the barcode according to the security requirements of specific application scenarios, such as high-frequency dynamic codes can be set with a shorter TTL, low-frequency or codes used after verification can be set with a longer TTL; in addition to the timer trigger, receiving a new instruction also triggers a refresh, which ensures that the system can quickly respond to the update requirements of the host computer and replace or invalidate the old barcode in time, thereby improving the responsiveness and security of the system.

[0057] Preferably, a barcode dynamic display system for an LCD screen comprises:

[0058] The communication data processing module is used to receive a JSON format data packet sent by the host computer through the serial port of the main control unit of the embedded device. The data packet includes a data field to be encoded and an encoding protocol field. The main control unit parses the JSON format data packet to extract the raw data required for barcode generation;

[0059] a module width factor setting module for determining, based on the JSON format data packet and adaptive calculation of the LCD screen width and the target display ratio, an integer module width factor, wherein the module width factor defines the number of pixel columns occupied on the screen by each logical module in the barcode;

[0060] a Code 128 encoding processing module configured to execute a Code 128 encoding algorithm on the original data according to the encoding protocol field, generate a complete encoding sequence including a start character encoding value, a data encoding value, a check character encoding value, and a terminator encoding value, and convert the complete encoding sequence into an alternating bar and space module width sequence by querying a preset code table;

[0061] a pixel matrix calculation module, configured to create a one-dimensional binary array in RAM, and convert each module width into a corresponding number of pixels according to the bar and space module width sequence and the module width factor, wherein the pixel positions corresponding to the black bars are filled with binary values ​​0, and the pixel positions corresponding to the white spaces are filled with binary values ​​1;

[0062] The frame buffer direct write module is used to traverse the one-dimensional binary array line by line, call the underlying dot function to set the screen coordinates corresponding to the position with a value of 0 in the array to black, and set the screen coordinates corresponding to the position with a value of 1 to white, and at the same time write pixel color data to the frame buffer of the LCD controller to realize the screen display of the barcode.

[0063] In the above solution, in the communication data processing module, the main control unit (MCU) of the embedded device receives instructions from the host computer (such as a PC, server, or other control terminal) through its serial communication interface (serial port). The instructions are encapsulated in a data packet in the JSON (JavaScript Object Notation) format, ensuring the structure and scalability of the data. The JSON package contains at least two key fields: the data field to be encoded, which is the original information to be converted into a barcode (such as a string of numbers or characters); and the encoding protocol field, which is used to specify which barcode encoding standard should be used (such as Code128). After receiving the data, the MCU parses the JSON string to extract the two core original data;

[0064] In the module width factor setting module, after obtaining the raw data, the display parameter calculation phase begins. The core parameter is the module width factor (MWF), an integer parameter that defines the number of pixel columns that the most basic logical unit in the barcode (a module, i.e., the narrowest bar or space) should occupy on the physical LCD screen. This factor is determined based on an adaptive calculation based on the physical width of the LCD screen and a preset target display ratio, ensuring that the generated barcode is clearly legible on the screen.

[0065] In the Code 128 encoding processing module, the Code 128 encoding algorithm is invoked to process the raw data based on the encoding protocol field. This process strictly adheres to the Code 128 standard, generating a complete sequence of code values, including the start character, data code, check character, and end character. This code value sequence is then mapped and converted into a logical sequence describing the alternating pattern of black bars and white spaces in the barcode and their corresponding module widths, i.e., the bar and space module width sequence, by consulting a code table pre-stored in the device's memory.

[0066] In the pixel matrix calculation module, the system creates a one-dimensional binary array in random access memory (RAM) as a buffer for the pixel data of a single row of the barcode. The length of this array is determined by the total number of modules in the barcode and the MWF. The system iterates through the sequence of bar and space module widths and, for each module with a width of W in the sequence, fills the binary array with W × MWF pixels. It is agreed that black bars are filled with binary value 0, and white spaces are filled with binary value 1. This process accurately converts the abstract logical module width into a physical pixel representation.

[0067] In the frame buffer direct write module, pixel data from memory is rendered onto the LCD screen using an efficient low-level rendering method: The one-dimensional binary array generated by S4 is scanned line by line. When a value of 0 is encountered, a low-level dotting function is called to set the pixel at the corresponding coordinate on the screen to black; when a value of 1 is encountered, it is set to white. The dotting function interacts directly with the LCD controller's frame buffer, writing the pixel color data directly to the corresponding memory address, thereby completing the barcode display.

[0068] The present invention discloses a barcode dynamic display method and system for LCD screens. Compared with the prior art, the present invention has the following beneficial effects:

[0069] (1) Through serial communication and the use of standard JSON format, data structuring and command integration are achieved, ensuring information integrity and diversified scalability, and improving system stability and access flexibility;

[0070] (2) Mapping screen pixels in integer multiples avoids jagged edges and distortion caused by pixel-level scaling, ensuring that the width of each module of the code bar is accurately matched to the physical pixels, thereby improving the scanning recognition rate;

[0071] (3) Adopting Code 128 protocol specification, the code and module width sequence are generated in real time, without the need for file storage, saving memory and storage space and improving efficiency;

[0072] (4) Directly mapping pixels using a one-dimensional array in RAM is fast and flexible, meeting embedded real-time requirements;

[0073] (5) Bypass the upper-level graphics library to improve drawing speed and efficiency, ensuring that the barcode display response speed meets real-time applications;

[0074] (6) Support flexible setting of module width factor to achieve multi-screen adaptation; combine with dynamic refresh mechanism to improve security level and prevent barcodes from being used in non-real time. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] Figure 1 This is a schematic flow chart of a method for dynamically displaying a barcode on an LCD screen provided by an embodiment of the present invention;

[0076] Figure 2 The present invention provides a schematic diagram of a barcode dynamic display system module for an LCD screen. DETAILED DESCRIPTION

[0077] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0078] like Figure 1 As shown, the present application provides a barcode dynamic display method for an LCD screen, which is characterized by comprising:

[0079] S1. The main control unit of the embedded device receives a JSON format data packet sent by the host computer through the serial port. The data packet includes a data field to be encoded and an encoding protocol field. The main control unit parses the JSON format data packet to extract the raw data required for barcode generation.

[0080] S2. Determine, based on the JSON format data packet and adaptive calculation of the LCD screen width and the target display ratio, an integer module width factor, wherein the module width factor defines the number of pixel columns occupied by each logical module in the barcode on the screen;

[0081] S3. Execute the Code 128 encoding algorithm on the original data according to the encoding protocol field to generate a complete encoding sequence including a start character encoding value, a data encoding value, a check character encoding value, and a terminator encoding value, and convert the complete encoding sequence into an alternating bar and space module width sequence by querying a preset code table;

[0082] S4. Creating a one-dimensional binary array in RAM, and converting each module width into a corresponding number of pixels according to the module width sequence and the module width factor; wherein the pixel positions corresponding to the black bars are filled with binary value 0, and the pixel positions corresponding to the white spaces are filled with binary value 1;

[0083] S5. Traverse the one-dimensional binary array row by row, call the underlying dot function to set the screen coordinates corresponding to the position with a value of 0 in the array to black, and set the screen coordinates corresponding to the position with a value of 1 to white, and at the same time write pixel color data to the frame buffer of the LCD controller to realize the screen display of the barcode.

[0084] In one embodiment provided herein, a method for dynamically displaying barcodes on an LCD screen is described in detail. The method is implemented in a typical embedded system. The embedded system includes a main control unit (MCU, such as a microcontroller based on an ARM Cortex-M core), an LCD display screen (e.g., with a physical resolution of 320x240 pixels), and a universal asynchronous receiver / transmitter (UART) interface for communicating with a host computer (such as a personal computer or server).

[0085] The detailed implementation steps of the method in this embodiment are as follows:

[0086] First, establish a physical and logical communication link between the embedded device and the host computer. Physically, the MCU's UART pins are connected to the host computer's serial port via a level conversion circuit. Logically, both parties predefine a communication protocol, such as a baud rate of 115200 bps, 8 data bits, 1 stop bit, and no parity.

[0087] When the host computer needs to instruct the embedded device to display a new barcode, it encapsulates all relevant information of the barcode to be displayed into a structured JSON text string and sends it to the embedded device through the serial port. A specific JSON data packet example is as follows:

[0088] {"protocol":"Code128C", "data":"12345678"}

[0089] The embedded device's MCU continuously monitors its UART receive buffer via an interrupt service routine or polling in a main loop. Once the start of a data stream is detected, marked by the start character '{', the MCU initiates the data reception process and continues until the end character '}' is received, thus acquiring a complete data packet.

[0090] After receiving the data, the MCU calls a lightweight JSON parser pre-installed in the firmware and optimized for resource-constrained environments. The parser traverses the received string and parses it based on the key-value pair structure. For the above example data packet, the parser will extract the following key fields and their corresponding values:

[0091] Encoding protocol field ("protocol"): Its value is "Code128C", which specifies the encoding standard that should be used when generating the barcode subsequently.

[0092] Data field to be encoded ("data"): Its value is "12345678", which is the original data string that needs to be encoded into the barcode.

[0093] By adopting the standardized JSON format for communication, control instructions and business data are effectively separated and transmitted in a structured manner, enhancing system flexibility and scalability. The host computer only needs to focus on the type of data being sent, while the embedded device can autonomously parse and respond to different encoding requests. The entire parsing process is completed in the MCU's internal RAM, eliminating the need to read or write to non-volatile memory (such as Flash). This ensures fast response times and lays the foundation for subsequent real-time generation.

[0094] After successfully extracting the raw data and encoding protocol, the system needs to determine a crucial rendering parameter: the module width factor (MWF). The MWF is a positive integer that establishes a precise mapping between the barcode's logical units (modules) and the screen's physical pixels. This refers to the number of pixel columns occupied by the narrowest bar or space in the barcode.

[0095] In this embodiment, the system uses an adaptive calculation strategy to determine the MWF. This strategy aims to make the generated barcode appear at an appropriate width on the screen to ensure optimal readability and visual quality. The calculation process is as follows:

[0096] First, the system needs to obtain two preset parameters and one parameter to be calculated:

[0097] LCD screen width (Screen_Width): A constant stored in the embedded device firmware that represents the total number of physical pixels in the horizontal direction of the LCD screen. In this example, Screen_Width = 320 pixels.

[0098] Target_Ratio: A preset floating point number representing the ratio of the desired barcode width to the total screen width. For example, setting Target_Ratio = 0.8 means that the barcode is expected to occupy 80% of the screen width.

[0099] Total number of barcode modules (Total_Modules): This value is calculated based on the original data and encoding protocol obtained in step S1 by executing the encoding algorithm in step S3. Here, we assume that the calculated result is N.

[0100] The calculation formula of MWF is:

[0101] MWF = floor( (Screen_Width * Target_Ratio) / Total_Modules )

[0102] The floor() function represents the rounding down operation to ensure that the final MWF value is an integer.

[0103] For example, if the subsequent step S3 calculates that the total number of modules in the Code 128C barcode for the data "12345678" is 95, the MWF is calculated as follows:

[0104] MWF = floor( (320 * 0.8) / 95 ) = floor( 256 / 95 ) = floor(2.69) = 2

[0105] Therefore, the module width factor used in this barcode drawing is 2. This means that each logical module in the barcode (whether it is a bar or space with a width of 1 module, 2 modules, 3 modules or 4 modules) will be composed of an integer multiple of 2 pixel columns.

[0106] The core advantage lies in ensuring barcode fidelity. By calculating and using integer MWFs, image distortion caused by floating-point scaling, such as aliasing, moiré, and disproportionate inter-bar patterns, is fundamentally avoided. Each bar and space is composed of an integer number of pixels, ensuring absolute clarity of barcode edges. This significantly improves the first-pass success rate of barcode scanners and makes the technology universally applicable to LCD screens with varying physical resolutions.

[0107] The barcode logic is then encoded, converting the text data into a barcode structure. Based on the previously parsed "protocol": "Code128C", the MCU calls the internally stored Code 128 encoding function library and takes "data": "12345678" as input.

[0108] The encoding process strictly follows the Code 128C subset specification:

[0109] Generate a sequence of encoded values:

[0110] Start character: Select the Code 128C start character, whose code value is 105.

[0111] Data encoding: Since it is Code 128C, the original data "12345678" is numerically paired in groups of two to obtain four encoding values: 12, 34, 56, 78.

[0112] Check digit calculation: The check digit is calculated according to the Code 128 standard algorithm. The calculation formula is (start digit value*1 + data value 1*2 + data value 2*3 + ...) mod 103.

[0113] In this example:

[0114] Checksum = (105*1 + 12*2 + 34*3 + 56*4 + 78*5) mod 103

[0115] = (105 + 24 + 102 + 224 + 390) mod 103

[0116] = 845 mod 103 = 21

[0117] Therefore, the encoded value of the check digit is 21.

[0118] Terminator: Add a standard terminator with a code value of 106.

[0119] Finally, we get a complete sequence of encoded values: {105, 12, 34, 56, 78, 21, 106}.

[0120] Convert to a sequence of bar space module widths:

[0121] The MCU stores a Code 128 table. This table is a constant array or lookup table with indices ranging from 0 to 106. Each index position stores an array of six integers. These six integers represent the module widths of the corresponding code value (bar-space-bar-space-bar-space). The sum of the six module widths corresponding to each code value is always 11.

[0122] The system iterates over the sequence of code values ​​and looks up each code value in the code table. For example, the code value 105 might correspond to the width pattern {2,1,2,2,2,2}, the code value 12 might correspond to {1,2,2,1,2,2}, and so on.

[0123] All the width patterns found are concatenated in sequence to form a single, long sequence describing the widths of the alternating black bars and white spaces across the entire barcode, from left to right. All elements in this long sequence are summed to obtain the total number of barcode modules (Total_Modules) required in step S2 above.

[0124] This implements pure algorithmic generation of the barcode's logical structure. The entire process runs at high speed in the CPU and RAM, without any file I / O operations, resulting in extremely fast response times. Compared to storing pre-rendered barcode images, this real-time calculation significantly saves valuable Flash storage space, which is crucial for resource-constrained embedded devices.

[0125] Constructs an accurate binary representation of a single row of barcode pixel data in memory, which serves as a direct data source for subsequent screen drawing.

[0126] Create a buffer: Dynamically apply for or use a pre-allocated static one-dimensional array in the MCU's RAM as a row pixel buffer. The length of this array (i.e. the total pixel width of the barcode, Total_Pixel_Width) is determined by the total number of modules and the module width factor:

[0127] Total_Pixel_Width = Total_Modules × MWF

[0128] Combining the previous example, if Total_Modules = 95 and MWF = 2, the array length is 95 * 2 = 190.

[0129] Filling the buffer: The system traverses the generated bar space module width sequence. The first element of the sequence represents the module width of the first black bar, the second element represents the module width of the first white space, and so on.

[0130] For a module width value W_bar representing a black bar in the sequence, the current position of the binary array is continuously filled with W_bar × MWF binary values ​​0.

[0131] For a module width value W_space representing white space in the sequence, the current position of the binary array is continuously filled with W_space × MWF binary values ​​1.

[0132] For example, if the beginning of the null module width sequence is {2, 1, ...} (from {2,1,2,2,2,2} of code value 105), and MWF=2:

[0133] The first element is a black bar with a width of 2, so the array is filled with 2 * 2 = 4 zeros.

[0134] The second element is a blank space with a width of 1, so the array is then filled with 1 * 2 = 2 1s.

[0135] And so on, until the entire bar and space module width sequence is traversed. After this process is completed, the one-dimensional array in RAM constitutes a complete and accurate binary image of a single row of pixels in the barcode.

[0136] The abstract barcode structure is converted into concrete rendering data that corresponds one-to-one with screen pixels. The resulting binary array is extremely compact and has a very low memory footprint (for example, a 190-pixel width requires only about 24 bytes). Compared to storing a BMP or PNG image file of the same size, this improves memory efficiency by one to two orders of magnitude. This "image-free" intermediate representation is key to achieving this high efficiency and low resource usage.

[0137] The final rendering and display process presents the binary pixel data in the memory on the LCD screen in the most efficient way.

[0138] Determine the drawing area: The system first calculates the starting coordinates (x, y) and ending coordinates of the barcode displayed on the screen based on the total pixel width of the barcode and the expected barcode height (a configurable constant, such as 50 pixels).

[0139] Direct frame buffer drawing: The main control unit draws from top to bottom, line by line. For each line in the barcode area, the same one-dimensional binary array generated in step S4 is reused.

[0140] The system traverses the one-dimensional binary array, and the array index is set to i (starting from 0):

[0141] When the value of array[i] is read as 0, an underlying pixel drawing function is called. This function sets the color of the pixel at coordinate (x + i, y) on the screen to black. For example, for a 16-bit RGB565 screen, the color value is 0x0000.

[0142] When the value of the array element array[i] is read as 1, the function is also called to set the color of the pixel with coordinates (x +i, y) on the screen to white, for example, writing the color value 0xFFFF.

[0143] This low-level pixel drawing function is implemented by writing directly to the frame buffer memory address managed by the LCD controller. This means that the color data does not need to pass through any upper-level graphics library or operating system abstraction layer, but is written directly to the memory area to be read by the display controller and sent to the screen.

[0144] By writing directly into the frame buffer, all possible graphics processing pipeline overhead is bypassed, achieving the shortest path from pixel data to screen display. This approach, combined with the aforementioned real-time computation and generation, enables the entire barcode generation process, from command reception to final on-screen display, to be completed in milliseconds, fully satisfying the requirements of dynamic, real-time display. The resulting barcode, thanks to the fidelity design of the generation process, exhibits exceptional clarity and contrast, ensuring excellent scanning and recognition performance.

[0145] Preferably, in step S1, parsing the JSON format data packet includes:

[0146] Check the start character '{' and end character '}' in the received data stream to confirm the integrity of the data packet. Parse the protocol field to specify the encoding algorithm type, the data field contains the original encoded data, the mwf field contains the module width factor specified by the host computer, and the ttl field contains the barcode life cycle time. The control logic and data content are decoupled by separating the structured fields.

[0147] In one embodiment provided by the present application, the MCU of the embedded device continuously monitors the UART receive buffer. When the host computer needs to update the barcode on the LCD screen, it encapsulates all the information required by the business logic into a JSON formatted data packet and sends it to the embedded device via the serial port.

[0148] An example JSON packet is as follows:

[0149] {"type":"barcode", "protocol":"Code128C", "data":"12345678", "id":"T001", "mwf":3, "ttl":30}

[0150] After receiving the data stream, the MCU first performs an integrity check, checking whether the data stream begins with a predefined start character { and ends with a stop character} to ensure that a complete data packet has been received. Subsequently, the lightweight JSON parser running inside the MCU begins to work, traversing the text string and extracting the following key fields:

[0151] Protocol: "Code128C", this field specifies the encoding algorithm type that should be used to generate the barcode.

[0152] Data: "12345678", this field contains the original data string that needs to be encoded into the barcode.

[0153] Mwf: 3. This field is the module width factor directly specified by the host computer and is an optional precise control parameter.

[0154] Ttl: 30, this field defines the valid life cycle of the barcode in seconds.

[0155] By adopting the standardized JSON format, control logic (such as encoding protocol, module width, and lifecycle) is completely separated and decoupled from data content (the data to be encoded). The host computer only needs to focus on generating and sending business data, while the embedded device can flexibly respond to different types of encoding requests and display controls, enhancing the system's versatility and scalability.

[0156] Preferably, in step S2, the module width factor is determined using a dual decision mechanism, including:

[0157] Check whether the mwf field exists in the JSON format data packet;

[0158] If it exists, the instruction value will be used first;

[0159] If it does not exist, start adaptive calculation, specifically:

[0160] MWF = floor((Screen_Width×Target_Ratio) / Total_Modules);

[0161] Among them, Screen_Width is the LCD screen width, Target_Ratio is the preset expected width ratio, Total_Modules is the total number of barcode modules, and the floor() function represents the rounding down operation. The dual decision-making mechanism realizes precise control and adaptive compatible parameter setting.

[0162] In one embodiment provided in this application, after successfully parsing a JSON packet, the MCU needs to determine the final module width factor (MWF) for this barcode drawing. The MWF defines the number of pixel columns occupied by each narrowest logical module (bar or space) in the barcode on the physical screen. This embodiment uses a dual decision mechanism to determine the MWF value:

[0163] Instruction priority: The MCU first checks whether the mwf field exists in the data structure parsed in the first step. In this example, the field exists and its value is 3. Therefore, the system will prioritize the instruction value and set the MWF of this drawing to 3.

[0164] Adaptive calculation strategy: As a comparison or backup solution, if the JSON data packet sent by the host computer does not contain the mwf field, the MCU will start adaptive calculation. This calculation is designed to make the generated barcode width occupy a preset, visually appealing ratio on the screen. The calculation formula is as follows:

[0165] MWF = floor((Screen_Width × Target_Ratio) / Total_Modules)

[0166] in:

[0167] Screen_Width is the physical pixel width of the embedded device's LCD screen. This is a known constant hardened in the device firmware.

[0168] Target_Ratio is a preset expected width ratio. For example, setting it to 0.8 means that the barcode is expected to occupy 80% of the total width of the screen.

[0169] Total_Modules is the total number of barcode modules calculated based on the data to be encoded and the encoding protocol. Its specific calculation will be detailed in the next step.

[0170] The floor() function rounds down to an integer, ensuring that the final MWF is a positive integer.

[0171] This dual decision-making mechanism achieves a perfect combination of precise control and adaptive compatibility. The host computer can precisely control the barcode resolution based on specific requirements (such as compatibility with a specific scanner model). In the absence of specific instructions, the device can adaptively generate a clear and readable barcode that matches the screen size. Because the MWF is always an integer, it fundamentally ensures that all bars and spaces are composed of an integer number of pixels, avoiding the aliasing, moiré, and scale distortion common in traditional image scaling techniques, significantly improving scan recognition rates.

[0172] Preferably, in step S3, the Code128 encoding algorithm includes:

[0173] Select Code128C start character code value 105, and pair the original data into two groups for encoding to calculate the check character code value, specifically:

[0174] (Start symbol value × 1 + first data value × 2 + second data value × 3 + …) mod 103

[0175] Then, the terminator code value 106 is added to form a complete code sequence. After that, it is converted into a 6-element bar space module width mode through a pre-stored code table query and spliced ​​into a long sequence. At the same time, the total number of modules is calculated for adaptive parameter calculation.

[0176] In one embodiment provided by this application, the MCU calls the internally fixed Code 128 encoding function library based on the parsed protocol field value of "Code128C", and uses the data field "12345678" as input to execute a strict encoding process:

[0177] Construct a sequence of encoded values:

[0178] Start character: Use the start character dedicated to Code128C, whose code value is 105.

[0179] Data Encoding: Since this is Code 128C, the original data "12345678" is paired two by two to obtain the numerical pairs "12," "34," "56," and "78." These four groups of numbers are directly used as the Code 128C data encoding values, namely, 12, 34, 56, and 78.

[0180] Check digit calculation: Calculate the check digit according to the Code 128 standard.

[0181] The calculation process is: (start character value × 1 + first data value × 2 + second data value × 3 + ...) mod 103.

[0182] In this example, the calculation is: (105×1+12×2+34×3+56×4+78×5) mod 103 = (105+24 +102+224+390) mod 103 = 845 mod 103 = 21. Therefore, the encoded value of the check digit is 21.

[0183] Terminator: Add a fixed terminator with a code value of 106.

[0184] Finally, the complete encoding value sequence is: {105, 12, 34, 56, 78, 21, 106}.

[0185] Convert to a sequence of bar space module widths:

[0186] The MCU stores a pre-stored "Code 128 table." This table is essentially a constant array indexed from 0 to 106. Each index position stores a subarray containing six elements, representing the "bar-space-bar-space-bar-space" module width pattern for the corresponding code value. The MCU iterates through this sequence of code values ​​and replaces each code value (such as 105, 12, etc.) with its corresponding six-element module width pattern through a table lookup. All the retrieved patterns are concatenated sequentially to form a single, long sequence describing the width of the alternating bar and space modules of the entire barcode. During this process, all elements in this long sequence are summed to obtain Total_Modules, which is used for the adaptive calculation in the second step.

[0187] The text data is converted into the logical structure representation of the barcode through pure algorithmic calculations and table lookup operations. The entire process is completed at high speed in the CPU and RAM, with a response speed of milliseconds, laying the foundation for subsequent real-time rendering.

[0188] Preferably, in step S4, the creation of the one-dimensional binary array includes:

[0189] Dynamic memory allocation is used, and the array length is equal to the total pixel width of Total_Modules×MWF. When traversing the bar and space module width sequence, the black bar with a width of W is filled with W×MWF binary values ​​0, and each white space with a width of W is filled with W×MWF binary values ​​1 according to the alternating rule of black bars and white spaces, so as to realize the precise integer multiple mapping of logical modules to physical pixels.

[0190] In one embodiment provided in the present application, the logical bar and space sequence generated in the previous stage is converted into a binary representation that can be directly drawn on the screen and is accurate to the pixel.

[0191] Memory allocation: The MCU creates a one-dimensional binary array in RAM through dynamic memory allocation (or using a preset static buffer). The length of this array is precisely calculated to be the total pixel width of the barcode, that is, Total_Pixel_Width = Total_Modules×MWF.

[0192] Pixel filling: The MCU traverses the bar and space module width sequence generated in step 3. This sequence follows the alternating pattern of "black bar-white space-black bar-white space..."

[0193] For a black bar module with a width of W in the sequence, the MCU continuously fills W×MWF binary values ​​0 (logical value, representing black pixels) in the one-dimensional binary array.

[0194] For a white space module with a width of W in the sequence, the MCU continuously fills W×MWF binary values ​​1 (logical value, representing white pixels) in the one-dimensional binary array.

[0195] After this process is completed, a single row of pixel-accurate representation of the barcode is generated in RAM. For example, if the barcode starts with a black bar with a width of 2 modules and the MWF is 3, the first 2×3 = 6 elements of the binary array will be filled with {0, 0, 0, 0, 0, 0}.

[0196] This achieves a precise integer multiple mapping from abstract logical modules to physical pixels, ensuring the rendered barcode has no width errors. The resulting binary matrix data structure is extremely compact, reducing memory usage by one to two orders of magnitude compared to storing a complete BMP or PNG image file, which is crucial for embedded devices with limited RAM resources.

[0197] Preferably, in step S5, the underlying dotting function includes:

[0198] Directly manipulate the LCD controller's frame buffer memory address, bypassing the operating system's graphics library and middleware layer;

[0199] The writing of the pixel color data adopts the memory address offset calculation method, and directly locates to the corresponding memory position in the frame buffer according to the screen coordinates for data writing.

[0200] In an embodiment provided by the present application, the MCU draws the barcode area row by row from top to bottom. For each row, it uses the same one-dimensional binary array generated in the fourth step. The MCU traverses the array. For the element with index i in the array:

[0201] If the value is 0, call the underlying dotting function to set the pixel at the current screen coordinates (x + i, y) to black. For example, for a screen with a 24-bit color depth, write the color value 0x000000.

[0202] If the value is 1, call the underlying dotting function to set the pixel at this coordinate to white (0xFFFFFF).

[0203] The "underlying dotting function" here is not a high-level graphics library API, but directly performs memory operations on the frame buffer of the LCD controller. The MCU directly locates to the memory position representing the target pixel in the frame buffer through memory address offset calculation and writes the corresponding color data. This bypasses all the overhead of the upper-layer operating system graphics library and middleware.

[0204] The method of directly writing to the frame buffer constitutes the shortest path from data to screen pixels, realizes nearly zero-latency drawing, and maximizes the display performance of the embedded system.

[0205] Preferably, in step S5, it further includes sub-pixel rendering optimization:

[0206] When the condition of (1×MWF) < T_subpixel threshold is satisfied, sub-pixel rendering is enabled. At the white-to-black boundary, the transition pixel is set to pure blue 0x0000FF to light up the blue sub-pixel. At the black-to-white boundary, the transition pixel is set to pure red 0xFF0000 to light up the red sub-pixel, and the physical characteristics of the RGB sub-pixel arrangement of the LCD panel are utilized to achieve edge smoothing at the 1 / 3 pixel level.

[0207] Preferably, the sub-pixel rendering performs boundary color setting based on the known screen sub-pixel arrangement pattern. For an LCD panel with a horizontal RGB arrangement, the micro-shift of the sensory edge is achieved by selectively lighting specific color sub-pixels.

[0208] In an embodiment provided by the present application, before starting to draw, the system can execute an optimization decision to determine whether to enable subpixel rendering. The decision is based on the threshold relationship: (1 × MWF) < T_subpixel. 1 × MWF represents the actual pixel width of the narrowest module (1 module width) in the barcode, and T_subpixel is a preset threshold (such as 4 pixels). Only when the barcode is extremely fine and the width of the narrowest stripe is less than this threshold, subpixel rendering is enabled to obtain the best visual improvement effect.

[0209] If enabled and the subpixel arrangement of the known screen is horizontal RGB (Red - Green - Blue), the drawing logic is adjusted as follows:

[0210] At the boundary from white to black, that is, the position where it changes from 1 to 0 in the binary array, the pixel at this boundary is not drawn as pure black, but as pure blue (0x0000FF). This will only light up the blue subpixel of this pixel, making the perceived black edge shift slightly to the left by 1 / 3 pixel width, appearing smoother.

[0211] At the boundary from black to white, that is, the position where it changes from 0 to 1 in the binary array, the last pixel of the black bar is not drawn as pure black, but as pure red (0xFF0000). This will only light up the red subpixel of this pixel, making the perceived black edge shift slightly to the right by 1 / 3 pixel width.

[0212] The non - boundary pixels inside the black bar and the pixels inside the white space are still drawn as pure black and pure white.

[0213] This technique cleverly utilizes the micro - physical structure of the LCD panel to achieve edge smoothing at the 1 / 3 pixel level. Without increasing any physical resolution, it significantly improves the visual sharpness of the barcode, effectively suppressing the jagged feeling on low - resolution screens, thereby greatly improving the decoding success rate in harsh scanning environments (such as tilted angles and long distances).

[0214] Preferably, it further includes:

[0215] When it is parsed that the JSON - formatted data packet contains the ttl field, start a timer set with the value corresponding to the ttl field;

[0216] When the timer triggers an interrupt or a new barcode instruction is received, perform a refresh operation. The refresh operation includes clearing the barcode area displayed on the current screen and re - executing steps S1 to S5 to generate and display a new barcode.

[0217] In an embodiment provided by the present application, by introducing the time dimension, dynamic security features are赋予 to the static barcode.

[0218] When the MCU parses the JSON data packet containing the TTL field ("ttl":30 in this example) in the first step, it immediately starts an internal timer, which can be a hardware timer or a software timer based on the system tick, and sets the timing period to 30 seconds.

[0219] During the timer running, the LCD screen will display the currently generated barcode normally. When any of the following events occurs, the system will perform a refresh operation:

[0220] Timer interrupt trigger: When the 30-second countdown ends, the timer generates an interrupt.

[0221] New command reception: During the timing period, the MCU receives any new barcode generation command from the host computer.

[0222] The refresh operation consists of the following two sub-steps:

[0223] Invalidate the current barcode: The MCU first clears the area on the screen that currently displays the barcode, for example, by calling the underlying drawing function to redraw the rectangular area with a background color (usually white), making it disappear visually immediately and thus invalidate it.

[0224] Triggering a regeneration: The system then automatically returns to the starting point of the process and re-executes the above steps. If the refresh is due to a new instruction, the new instruction data is used; if the refresh is due to a timer expiration, the original data is used for regeneration. Even if the data content remains unchanged, the newly generated barcode may differ from the original in microscopic details at the pixel level, ensuring its uniqueness.

[0225] This mechanism imbues the barcode displayed on the screen with the dynamic security attribute of "destroying after reading." Any attempt to obtain the barcode image through non-real-time methods (such as mobile phone photography or screenshots) will expire within a very short time-to-live (TTL) and will be unavailable for subsequent verification devices (such as access control scanners). This provides a solid and reliable technical guarantee for applications with extremely high information security requirements, such as e-ticketing, access control, dynamic identity authentication, and temporary payment authorization.

[0226] In one embodiment provided in this application, the example data is: 12345678 (8 digits)

[0227] 1. Select the start symbol

[0228] Code 128-C begins with character value 105 (the Í symbol).

[0229] 2. Data Grouping and Coding

[0230] Convert each 2-digit number into a character value (range 0-99):

[0231] Original numbers 12 34 56 78

[0232] Character values ​​12 34 56 78

[0233] 3. Calculate the check digit

[0234] Weight distribution: The first character has a weight of 1, and the weight of each subsequent group of numbers increases in sequence (2, 3, 4, ...).

[0235] formula:

[0236] Checksum = (starting symbol value × 1 + Σ(grouping value × weight)) mod 103

[0237] Calculation process:

[0238] Start symbol: 105 × 1 = 105

[0239] 12×2 = 24

[0240] 34×3 = 102

[0241] 56×4 = 224

[0242] 78×5 = 390

[0243] Total = 105 + 24 + 102 + 224 + 390 = 845

[0244] Checksum = 845 mod 103

[0245] Calculation: 103 × 8 = 824 → 845 - 824 = 21

[0246] 21 corresponds to the Code 128-C character value 21 (the symbol Ò).

[0247] 4. Add a terminator

[0248] The terminator is fixed to character value 106 (the symbol Î).

[0249] 5. Complete coding sequence

[0250] Type start character data packet check character terminator

[0251] Symbols Í 12 34 56 78 Ò Î

[0252] Character values ​​105 12 34 56 78 21 106

[0253] Use b to represent a line with the width of a black pixel, and s to represent a line with the width of a white pixel. According to the character value obtained above, index into Table 1 to obtain the width of the black pixel and the width of the white pixel in the encoding value column, and then draw.

[0254] Table 1 Index table of character values

[0255]

[0256]

[0257]

[0258]

[0259]

[0260]

[0261] When you want to change the display, enter the new display data in the input box of the host computer and click on it to dynamically generate a new barcode for display.

[0262] In another embodiment provided by the present application, the sampling theorem and pixelation theory in digital signal processing indicate that when a signal is converted from a continuous domain to a discrete domain, non-integer sampling introduces aliasing distortion. In the field of image processing, the Nyquist-Shannon sampling theorem states that to avoid spectral aliasing, the sampling frequency must satisfy a specific integer multiple relationship. Because traditional barcode display solutions generally use floating-point scaling, which leads to pixel-level aliasing, the present application ensures that each logical module is accurately mapped to an integer number of physical pixels by forcing an integer module width factor, completely eliminating the interpolation error caused by non-integer mapping from a mathematical perspective. This precise mapping mechanism, combined with the compact representation of a one-dimensional binary array and direct frame buffer write, achieves a "zero-distortion" transmission link from the logical structure to the physical display.

[0263] According to the fidelity theory in information theory, the information fidelity η of this combination scheme can be expressed as:

[0264] η = 1 - Σ(P_logical - P_physical)² / N

[0265] Where P_logical is the logical pixel value, P_physical is the physical pixel value, and N is the total number of pixels.

[0266] Since integer mapping ensures that P_logical = P_physical, η = 1, achieving theoretically perfect fidelity. The lack of integer factor constraints will cause interpolation errors; the lack of compact array representation cannot achieve efficient memory management; the lack of a direct write mechanism will introduce additional rendering delays and precision loss.

[0267] In another embodiment provided herein, the sub-pixel perception model within human visual perception theory demonstrates that the human eye's perception of RGB sub-pixels exhibits a spatial offset effect. According to CIE color space theory, selectively stimulating specific sub-pixels can fine-tune the visual center of gravity. Traditional sub-pixel rendering, primarily used for font display, faces technical challenges in barcode applications: the binary nature of barcodes conflicts with the continuity requirements of sub-pixel rendering.

[0268] This application combines sub-pixel rendering with integer mapping mechanism to achieve sub-pixel optimization of edges while maintaining the integrity of the barcode logical structure.

[0269] Based on visual perception theory, the edge sharpening effect can be quantified as:

[0270] E_sharpness = ∫[L(x+δ) - L(x)]dx

[0271] Where L(x) is the brightness function and δ is the sub-pixel offset.

[0272] By selectively exciting red / blue sub-pixels, a visual offset of ±1 / 3 pixel is achieved, effectively increasing edge contrast by approximately 15-25%, significantly improving scanning recognition rates under low-resolution conditions; sub-pixel rendering requires precise pixel-level control and must rely on a direct-write mechanism; integer mapping ensures the integrity of the main structure and provides a stable foundation for edge optimization.

[0273] Preferably, Figure 2 As shown, a barcode dynamic display system for an LCD screen includes:

[0274] The communication data processing module is used to receive a JSON format data packet sent by the host computer through the serial port of the main control unit of the embedded device. The data packet includes a data field to be encoded and an encoding protocol field. The main control unit parses the JSON format data packet to extract the raw data required for barcode generation;

[0275] a module width factor setting module for determining, based on the JSON format data packet and adaptive calculation of the LCD screen width and the target display ratio, an integer module width factor, wherein the module width factor defines the number of pixel columns occupied on the screen by each logical module in the barcode;

[0276] a Code 128 encoding processing module configured to execute a Code 128 encoding algorithm on the original data according to the encoding protocol field, generate a complete encoding sequence including a start character encoding value, a data encoding value, a check character encoding value, and a terminator encoding value, and convert the complete encoding sequence into an alternating bar and space module width sequence by querying a preset code table;

[0277] a pixel matrix calculation module, configured to create a one-dimensional binary array in RAM, and convert each module width into a corresponding number of pixels according to the bar and space module width sequence and the module width factor, wherein the pixel positions corresponding to the black bars are filled with binary values ​​0, and the pixel positions corresponding to the white spaces are filled with binary values ​​1;

[0278] The frame buffer direct write module is used to traverse the one-dimensional binary array line by line, call the underlying dot function to set the screen coordinates corresponding to the position with a value of 0 in the array to black, and set the screen coordinates corresponding to the position with a value of 1 to white, and at the same time write pixel color data to the frame buffer of the LCD controller to realize the screen display of the barcode.

[0279] In one embodiment provided herein, the barcode dynamic display system includes five core functional modules. Each module transmits information via an internal data bus, implementing the complete barcode process from data reception to screen display. The system utilizes a modular design, reducing the coupling between functional units and improving system maintainability and scalability.

[0280] (1) Communication data processing module

[0281] The communication data processing module serves as the data entry point of the system and is responsible for receiving and parsing JSON format data packets. This module is equipped with a serial communication interface unit and a JSON parsing engine.

[0282] Specifically, the serial communication interface unit is configured for RS-232 or TTL level standards, supporting a configurable communication rate ranging from 9600 to 115200 bps. When the host computer sends JSON format data packets through the serial port, the interface unit receives the data stream through a circular buffer mechanism, ensuring that data loss does not occur in high-frequency data transmission scenarios.

[0283] The JSON parsing engine uses a state machine implementation to identify the data packet structure by scanning each character one by one. The parsing process first detects the start character '{' and the end character '}' to verify the integrity of the data packet and avoid parsing errors caused by transmission interruptions. The parsing engine then extracts key information according to the predefined field mapping table: the protocol field is used to specify the encoding algorithm type, supporting multiple encoding modes such as Code128A, Code128B, and Code128C; the data field contains the original encoded data and supports mixed input of numbers, letters, and special characters; the mwf field is an optional field, and the module width factor can be specified when the host computer needs to precisely control the display effect; the ttl field defines the life cycle of the barcode in milliseconds.

[0284] By using a structured field separation mechanism, the module decouples control logic from data content, enabling the system to independently process different types of encoding requests without interfering with each other. This design significantly improves the system's concurrent processing capabilities and data processing accuracy.

[0285] (2) Module width factor setting module

[0286] The module width factor setting module is responsible for determining the display size parameters of the barcode on the LCD screen. This module adopts a dual decision-making mechanism, taking into account the needs of user-defined control and system adaptive adjustment.

[0287] This module first checks whether the JSON data packet passed by the communication data processing module contains the mwf field. If so, it directly uses the module width factor value specified by the host computer to achieve precise display control. This approach is particularly suitable for applications that require standardized display effects, such as industrial inspection or commercial label print preview.

[0288] When the JSON data packet does not contain the mwf field, the module automatically starts the adaptive calculation mechanism, which performs dynamic calculations based on the physical parameters of the LCD screen and the preset display ratio.

[0289] The specific calculation formula is:

[0290] MWF=floor((Screen_Width×Target_Ratio) / Total_Modules);

[0291] Screen_Width gets the pixel width of the screen from the LCD driver layer, Target_Ratio is the preset desired width ratio (usually set to 0.8 to ensure that the barcode does not take up the entire screen width), Total_Modules is the total number of modules in the barcode, and the floor() function performs a floor operation to ensure that the result is an integer pixel value.

[0292] The technical benefit of this dual-decision mechanism is that it not only meets the stringent display accuracy requirements of professional applications, but also provides a convenient, configuration-free experience for general users. Furthermore, adaptive calculation ensures that barcodes display appropriately on devices of varying screen sizes.

[0293] (3) Code128 encoding processing module

[0294] The Code 128 encoding processing module is the core algorithm unit of the system, responsible for converting raw data into a standard barcode encoding sequence. This module has a built-in complete Code 128 encoding algorithm implementation and a preset code table storage unit.

[0295] During the encoding process, the module selects the corresponding encoding subset based on the protocol field provided by the communication data processing module. This embodiment mainly uses the Code128C encoding method, which is suitable for efficient encoding of pure digital data. The encoding process includes the following steps:

[0296] First, the module inserts a Code 128C start character, whose encoding value is 105. Next, the original data is paired into two-digit groups, with each pair corresponding to a corresponding encoding value. For odd-numbered data, the last digit is processed separately or padded with leading zeros to form a complete pair.

[0297] The check digit is calculated using a weighted summation method: the start digit code value is multiplied by weight 1, the first data code value is multiplied by weight 2, the second data code value is multiplied by weight 3, and so on. All weighted values ​​are summed and then modulo 103 to obtain the check digit code value. This verification mechanism ensures the data integrity of the barcode and improves the reliability of scanning and recognition.

[0298] Finally, the module adds a terminator with a code value of 106 and appends an additional bar and space module to mark the end. Once the complete code sequence is complete, the module converts each code value into a corresponding six-element bar and space module width pattern by consulting a preset code table. The preset code table is stored in a two-dimensional array structure, supporting fast indexing. Each code value corresponds to a numerical sequence consisting of three bar widths and three space widths.

[0299] All module width patterns are sequentially concatenated to form a complete bar and space module width sequence. The total number of modules is then counted and passed to the module width factor setting module for adaptive parameter calculation. This encoding process results in a Code 128 barcode data structure that conforms to international standards, ensuring compatibility with commercially available barcode scanning equipment.

[0300] (4) Pixel matrix calculation module

[0301] The pixel matrix calculation module is responsible for converting the logical-level bar and space module width sequence into a pixel-level data structure that can be directly used for screen display. This module uses dynamic memory management and an accurate integer multiple mapping algorithm.

[0302] The module first allocates storage space in RAM for a one-dimensional binary array whose length is precisely equal to the total pixel width: Total_Modules × MWF. A dynamic memory allocation mechanism adaptively adjusts memory usage based on varying data lengths and display parameters, avoiding the potential memory waste or space shortages that can result from a fixed array.

[0303] The pixel filling process adheres to a strict black bar and white space alternation pattern. The module iterates through the bar and space module width sequence provided by the Code 128 encoding module, processing each width value in sequence. For each black bar module of width W, the array is filled with W × MWF consecutive binary values ​​of 0; for each white space module of width W, the array is filled with W × MWF consecutive binary values ​​of 1. This processing method achieves a precise integer multiple mapping of logical modules to physical pixels, ensuring the geometric accuracy of the barcode.

[0304] The filling algorithm uses pointer incrementing to improve processing efficiency and avoid repeated array index calculations. Furthermore, the module performs bounds checking during the filling process to prevent system anomalies caused by out-of-bounds array access. The technical effect of this module is to generate a precise pixel-level representation of barcode data, providing a standardized data interface for subsequent screen display.

[0305] (5) Frame buffer direct write module

[0306] The frame buffer write module is the system's output execution unit, responsible for writing pixel data directly into the LCD controller's frame buffer, enabling on-screen barcode display. This module operates directly on the underlying hardware, bypassing the operating system's graphics library and middleware layers, significantly improving display performance.

[0307] The module includes a built-in low-level dotting function that directly manipulates the LCD controller's frame buffer memory address. Using a memory mapping mechanism, the function obtains physical memory access to the frame buffer, calculates the memory address offset based on screen coordinates, and writes pixel color data directly to the corresponding location. This direct memory operation avoids the overhead of system calls and significantly improves pixel data writing speed.

[0308] During the display process, the module traverses the pixel matrix row by row to calculate the one-dimensional binary array generated by the pixel matrix calculation module. For the positions in the array with a value of 0, the corresponding screen coordinates are set to black (RGB value 0x000000); for the positions with a value of 1, the corresponding screen coordinates are set to white (RGB value 0xFFFFFF). The pixel color data is encoded according to the color format requirements of the LCD panel, supporting various color depths such as RGB565 and RGB888.

[0309] To further improve the display quality, the module also integrates a sub-pixel rendering optimization function. When the module width factor is small and satisfies the condition of (1×MWF) < T_subpixel threshold, the system automatically enables sub-pixel rendering. This function utilizes the physical arrangement characteristics of the RGB sub-pixels of the LCD panel to optimize the color in the edge area of the barcode: the transition pixels from white to black are set to pure blue (0x0000FF), and the transition pixels from black to white are set to pure red (0xFF0000). By selectively lighting specific-colored sub-pixels, an edge smoothing effect at the 1 / 3 pixel level is achieved, significantly improving the visual clarity of small-sized barcodes.

[0310] The system also integrates a life cycle management function based on time control. When the communication data processing module analyzes that the JSON data packet contains the ttl field, the system automatically starts the corresponding timer. The timer is implemented using a hardware timer to ensure the accuracy of time control. When the timer expires and triggers an interrupt or a new barcode instruction is received, the system performs a screen refresh operation, including clearing the current barcode display area and re-executing the complete display process.

[0311] The above is the preferred embodiment of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements are also regarded as the protection scope of the present invention.

Claims

1. A barcode dynamic display method for LCD screen, characterized in that: include: S1. The main control unit of the embedded device receives a JSON format data packet sent by the host computer through the serial port. The data packet includes a data field to be encoded and an encoding protocol field. The main control unit parses the JSON format data packet to extract the raw data required for barcode generation. S2. Determine, based on the JSON format data packet and adaptive calculation of the LCD screen width and the target display ratio, an integer module width factor, wherein the module width factor defines the number of pixel columns occupied by each logical module in the barcode on the screen; S3. Execute the Code 128 encoding algorithm on the original data according to the encoding protocol field to generate a complete encoding sequence including a start character encoding value, a data encoding value, a check character encoding value, and a terminator encoding value, and convert the complete encoding sequence into an alternating bar and space module width sequence by querying a preset code table; S4. Creating a one-dimensional binary array in RAM, and converting each module width into a corresponding number of pixels according to the module width sequence and the module width factor; wherein the pixel positions corresponding to the black bars are filled with binary value 0, and the pixel positions corresponding to the white spaces are filled with binary value 1; S5. Traverse the one-dimensional binary array row by row, call the underlying dot function to set the screen coordinates corresponding to the position with a value of 0 in the array to black, and set the screen coordinates corresponding to the position with a value of 1 to white, and at the same time write pixel color data to the frame buffer of the LCD controller to realize the screen display of the barcode.

2. A barcode dynamic display method for an LCD screen according to claim 1, characterized in that: In step S1, parsing of the JSON format data packet includes: Check the start character '{' and end character '}' in the received data stream to confirm the integrity of the data packet. Parse the protocol field to specify the encoding algorithm type, the data field contains the original encoded data, the mwf field contains the module width factor specified by the host computer, and the ttl field contains the barcode life cycle time. The control logic and data content are decoupled by separating the structured fields.

3. A barcode dynamic display method for LCD screen according to claim 2, characterized in that: In step S2, the module width factor is determined using a dual decision mechanism, including: Check whether the mwf field exists in the JSON format data packet; If it exists, the mwf field is used first; If it does not exist, adaptive calculation is started, specifically: MWF = floor((Screen_Width×Target_Ratio) / Total_Modules); Among them, Screen_Width is the LCD screen width, Target_Ratio is the preset expected width ratio, Total_Modules is the total number of barcode modules, and the floor() function represents the rounding down operation. The dual decision-making mechanism realizes precise control and adaptive compatible parameter setting.

4. A barcode dynamic display method for an LCD screen according to claim 3, characterized in that: In step S3, the Code128 encoding algorithm includes: Select Code128C start character code value 105, and pair the original data into two groups for encoding to calculate the check character code value, specifically: (start symbol value × 1 + first data value × 2 + second data value × 3 + …) mod 103; Then, the terminator code value 106 is added to form a complete code sequence. After that, it is converted into a 6-element bar space module width mode through a pre-stored code table query and spliced ​​into a long sequence. At the same time, the total number of modules is calculated for adaptive parameter calculation.

5. The method for dynamic barcode display on an LCD screen according to claim 4, wherein: In step S4, the creation of the one-dimensional binary array includes: Dynamic memory allocation is used, and the array length is equal to the total pixel width of Total_Modules×MWF. When traversing the bar and space module width sequence, the black bar with a width of W is filled with W×MWF binary values ​​0, and each white space with a width of W is filled with W×MWF binary values ​​1 according to the alternating rule of black bars and white spaces, so as to realize the precise integer multiple mapping of logical modules to physical pixels.

6. A barcode dynamic display method for LCD screen according to claim 5, characterized in that: In step S5, the underlying dotting function includes: Directly manipulate the LCD controller's frame buffer memory address, bypassing the operating system's graphics library and middleware layer; The pixel color data is written in a memory address offset calculation manner, and is directly located at a corresponding memory location in the frame buffer according to the screen coordinates for data writing.

7. A barcode dynamic display method for an LCD screen according to claim 6, characterized in that: In step S5, sub-pixel rendering optimization is also included: Sub-pixel rendering is enabled when the threshold condition (1×MWF) < T_subpixel is met. The transition pixel at the white-to-black boundary is set to pure blue 0x0000FF to light up the blue sub-pixel, and the transition pixel at the black-to-white boundary is set to pure red 0xFF0000 to light up the red sub-pixel. The physical characteristics of the RGB sub-pixel arrangement of the LCD panel are used to achieve 1 / 3 pixel level edge smoothing.

8. The method for dynamic barcode display on an LCD screen according to claim 7, wherein: The sub-pixel rendering performs boundary color setting based on a pre-known screen sub-pixel arrangement pattern. For a horizontal RGB arranged LCD panel, a slight shift of the perceived edge is achieved by selectively lighting up specific color sub-pixels.

9. The method for dynamic barcode display on an LCD screen according to claim 2, wherein: Also includes: When the JSON format data packet is parsed to include a ttl field, a timer set corresponding to the ttl field value is started; When the timer triggers an interrupt or receives a new barcode instruction, a refresh operation is performed, which includes clearing the barcode area currently displayed on the screen and re-performing steps S1 to S5 to generate and display a new barcode.

10. A barcode dynamic display system for LCD screen, characterized in that: include: The communication data processing module is used to receive a JSON format data packet sent by the host computer through the serial port of the main control unit of the embedded device. The data packet includes a data field to be encoded and an encoding protocol field. The main control unit parses the JSON format data packet to extract the raw data required for barcode generation; a module width factor setting module for determining, based on the JSON format data packet and adaptive calculation of the LCD screen width and the target display ratio, an integer module width factor, wherein the module width factor defines the number of pixel columns occupied on the screen by each logical module in the barcode; a Code 128 encoding processing module configured to execute a Code 128 encoding algorithm on the original data according to the encoding protocol field, generate a complete encoding sequence including a start character encoding value, a data encoding value, a check character encoding value, and a terminator encoding value, and convert the complete encoding sequence into an alternating bar and space module width sequence by querying a preset code table; a pixel matrix calculation module, configured to create a one-dimensional binary array in RAM, and convert each module width into a corresponding number of pixels according to the bar and space module width sequence and the module width factor, wherein the pixel positions corresponding to the black bars are filled with binary values ​​0, and the pixel positions corresponding to the white spaces are filled with binary values ​​1; The frame buffer direct write module is used to traverse the one-dimensional binary array line by line, call the underlying dot function to set the screen coordinates corresponding to the position with a value of 0 in the array to black, and set the screen coordinates corresponding to the position with a value of 1 to white, and at the same time write pixel color data to the frame buffer of the LCD controller to realize the screen display of the barcode.

Images