Genetic Programming-Based Code Generation for Arduino

This article describes a methodology for writing the program for the Arduino board using an automatic generator of assembly language routines that works based on a cooperative coevolutionary multi-objective linear genetic programming algorithm. The methodology is described in an illustrative example that consists of the development of the program for a digital thermometer organized on a circuit formed by the Arduino Mega board, a text LCD module, and a temperature sensor. The automatic generation of a routine starts with an input-output table that can be created in a spreadsheet. The following routines have been automatically generated: initialization routine for the text LCD screen, routine for determining the temperature value, routine for converting natural binary code into unpacked two-digit BCD code, routine for displaying a symbol on the LCD screen. The application of this methodology requires basic knowledge of the assembly programming language for writing the main program and some initial configuration routines. With the application of this methodology in the illustrative example, 27% of the program lines were written manually, while the remaining 73% were generated automatically. The program, produced with the application of this methodology, preserves the advantage of assembly language programs of generating machine code much smaller than that generated by using the Arduino programming language. Keywords—Genetic programming; Arduino mega board; multiobjective linear genetic programming; cooperative coevolutionary algorithm; automatic generation of programs; Arduino based thermometer


I. INTRODUCTION
Arduino is an open-source, free hardware, microcontrollerbased electronic board that has a series of analog and digital pins that can be used to connect sensors, peripheral devices, or actuators [1]. The program, which the user stores in the Arduino memory, allows this board to perform various functions such as controller functions, measurement instrument functions, communications equipment functions, etc.
Due to their relatively easy-to-use hardware and software, Arduino boards, in addition to being applied to everyday tasks, are also being applied in scientific instruments such as the measurement of transendothelial/epithelial resistance [2], in the analysis of the production volume of breast milk [3], in the measurement of the methane content of biogas samples [4], etc., which means that there is significant interest from many users and researchers in the use of this free software platform.
There are various Arduino boards such as Arduino Uno, Arduino Mega, Arduino Nano, Arduino Leonardo, Arduino Micro, etc. Because it is one of the fastest Arduino boards on the market [5] and due to the amount of digital and analog pins it has, in this work the Arduino Mega board is used, which is built based on the ATmega 2560 microcontroller with AVR architecture. The main features of the Arduino Mega 2560 are: it has 54 digital input/output pins, 16 analog inputs, 4 UARTs (serial ports in hardware), a 16 MHz crystal oscillator, a USB connection.
Arduino board programming is done through free software that is now accessible On-Line: Arduino Web Editor [6]. To program this board, knowledge of the Arduino programming language is required, which is similar to C++ [7]. In our research work, a program development methodology is proposed for the Arduino Mega board based on program synthesis. Program synthesis aims to automatically produce a program from a specification called "user intent". There are many ways to represent the specification, it can be a sketch [8], a sequence [9], or a table of input-output examples [10] [11]. In our work, the starting point for the automatic generation of a program is an input-output table.
The rest of this paper is organized as follows: Section II discusses the related work. In Section III, the theoretical foundations of the proposed methodology are summarized. In Section IV, the fitness evaluation algorithms are detailed. Section V describes the automatic generation of the illustrative example routines. In Section VI, the experimental work carried out is described. In Section VII, the conclusions and recommendations are presented.

II. RELATED WORK
In the classification of program synthesis techniques, genetic programming is within the group of stochastic search techniques [12]. There are efforts to use genetic programming in general-purpose synthesizers [13] and microcontroller program synthesizers. Genetic programming that evolves programs in an imperative language is called linear genetic programming. There are two types of linear genetic programming [14]: a machine code genetic programming, where each instruction is directly executable by the CPU, and an interpreted linear genetic programming. Due to the large difference in the clock frequency of the computer and the www.ijacsa.thesai.org Arduino Mega microcontroller, we use interpreted linear genetic programming. Dias and Pacheco [15] proposed to apply linear genetic programming in the automatic synthesis of programs in assembly language for the PIC 18F452 microcontroller, showing as examples, the implementation of optimal time control strategies in two cases: in the cart-centering problem and in the problem of balancing an inverted pendulum in a minimum amount of time. The authors in [16] used linear genetic programming in the automatic synthesis of assembly program for the PIC 18F452 microcontroller for optimized control of a water bath plant. In both research works [15][16], a classical evolutionary algorithm is used, and two simulators for the fitness evaluation of an individual have been organized: a simulator of the microcontroller CPU; and, based on its dynamic equations, a simulator of the plant.
Serruto and Casas [17] have proposed to apply linear genetic programming with multi-objective optimization for the automatic synthesis of programs for the AT89S52 microcontroller of 8051 architecture. The generated programs are: 4x3 matrix keyboard scan program, initialization program of the text LCD screen, and a character display program on the LCD screen. For the first case, the authors have proposed the fitness evaluation based on an exhaustive search of the bits of the result, and for the last two cases, the fitness evaluation is carried out by comparing the timing diagrams produced by the genetic program with the target timing diagrams. Serruto and Casas in [18] improved the program generator by introducing the cooperative coevolutionary algorithm, which allowed generating the 4x4 matrix keyboard scanning program and the character display program with a better hit rate. To apply the cooperative coevolutionary algorithm, a machine code program is considered to be made up of program segments, and each segment corresponds to a species. To calculate the fitness of an individual (program segment) a complete program is formed with the individual and the representatives of the other species.
In the proposed work, a methodology of programming of the Arduino Mega board using cooperative coevolutionary multi-objective linear genetic programming is described. The application of the methodology is shown in an illustrative example of developing the program for a digital thermometer circuit based on the Arduino Mega board.

A. Circuit with the Arduino Mega Board
The program that will be developed using genetic programming will run on the Arduino Mega board, which will be part of a circuit that will also include other devices connected to the digital or analog pins of the board. This circuit is a system based on the ATmega 2560 microcontroller. In Fig. 1 we show an example of a circuit made up of the Arduino Mega board, a text LCD module connected to digital pins, and a temperature sensor connected to an analog pin. The details of the connection are given in Table I. The program that will be elaborated, following the proposed methodology, as an illustrative example, will allow the circuit of Fig. 1 to function as a thermometer. The concepts on which the proposed methodology is based are inductive programming, linear genetic programming, multi-objective optimization, and cooperative coevolution. Next, these concepts are formulated adapting them to the problem of the synthesis of programs for a microcontroller.

B. Inductive Programming
In the inductive programming method, the starting point is an input/output table [11], from which, the inductive programming technique allows generating a program that makes each input correspond to the output given in the table, and also extrapolates values for other inputs. An input-output table is used in some functions in everyday spreadsheets (Flash-Fill in Microsoft Excel), in which a string processing program is automatically generated, from one or more examples provided by the user [10]. In [19] a formulation of the problem for programming-by-example is shown: Given a set of M input-output examples (desired input-output table): a P program must be found that performs all the transformations correctly: To find the P program, in the proposed work a multiobjective cooperative coevolutionary linear genetic programming algorithm is used.   Vol. 11, No. 11, 2020 540 | P a g e www.ijacsa.thesai.org

C. Linear Genetic Programming
Linear genetic programming (LGP) is the branch of genetic programming that evolves sequences of instructions from an imperative programming language or machine language [20]. In the automatic generation of routines for Arduino Mega, a subset of the ATmega 2560 microcontroller instruction set is used [21] [22]. For the generation of programs, which do not interact with the input/output ports, the instructions in Table II are used. When generating programs that produce timing diagrams on Port C, in addition to the instructions in Table II, the instructions in Table III must be used. If the timing diagrams are generated on another port, then in the instructions in Table III, the operand "PORT C" must be changed to the corresponding Port.

D. ATmega 2560 Microcontroller used Registers
In the microcontrollers of the AVR architecture [23], there are 32 general-purpose registers with names R0, R1, R2,…, R31. These registers are mapped to memory occupying the lowest 32 addresses. The working registers used in the evolutionary process, in genetic programs, are R0, R1, and R20. Register R20 has been included to use the instructions with immediate addressing ANDI, ORI, SUBI, LDI that only work with registers R16 to R31. In code conversion problems, at the completion stage of the program, K registers are used from register R5 to register R(K + 4), where K is the number of bits in the result. In the generation of programs that interact with an input-output Port, the PORT, DDR, and PIN registers of this Port are used. All genetic programs use the SREG register that stores the status of the program.

E. Multi-Objective Evolutionary Optimization
In this work, to find the program P, multi-objective optimization is used. For this purpose, we form K objective functions. In the generation of code conversion routines, each objective function corresponds to one bit of the objective code. In the generation of routines that produce timing diagrams in an input/output Port, each objective function corresponds to a pin of the Port. Next, we formulate the multiobjective optimization problem, adapted to the synthesis problem of a microcontroller program, based on the formulation given in [24]: is a genetic program in machine language, is an instruction from Table II or Table  III, U is the feasible set, ( ) = ( 0 ( ), 1 ( ), … , −1 ( ) ) is the vector of objective functions.
The target vector ( ) indicates the degree of similarity of the input-output table, generated after running the genetic program P, and the desired input-output table. The multiobjective genetic programming algorithm aims that the generated table is equal to the desired one. When this occurs, the objective functions have the highest value. Thus, in the microcontroller program synthesis problem, studied in this work, multi-objective optimization seeks to maximize the vector of objective functions. www.ijacsa.thesai.org

F. Multi-Objective Cooperative Coevolutionary Linear Genetic Programming Algorithm (MOCCLGPA)
The automatic generation of a routine for Arduino is a complex problem, so in addition to multi-objective optimization, in the proposed work, a cooperative coevolutionary algorithm is used. Cooperative coevolutionary algorithms are based on decomposing the problem into subcomponents also called "species" that evolve in collaboration with each other [25].
To apply cooperative coevolution in program synthesis, a machine code program is considered to be made up of program segments, and each segment corresponds to a species. The calculation of the fitness of an individual of a species is carried out by previously forming a complete solution (genetic program) combining the individual (program segment) with the selected representatives of the other species as detailed in [18]. In the proposed work, the number of species is 10 and the representatives are the two best individuals of each species. The Multi-Objective Cooperative Coevolutionary Linear Genetic Programming Algorithm (MOCCLGPA) used in the proposed work is Algorithm 1 taken and modified from [18].
In Algorithm 1, each time the fitness of a genetic program is evaluated, the number of evaluations n is increased, the values of f, fsum, fop, and fopsum are determined, and the Pbest program is updated if a better one was found. The sorting of a list is done according to the value of the scalar fopsum. The insertion of an individual in a list is carried out using the vector fop and the concept of Pareto dominance. The algorithms for the selection of representatives, selection of parents, and variation are described in [18]. At the end of Algorithm 1, the synthesized Pbest program, after the completion operation, becomes the generated program.

G. Structure of the Automatic Routine Generator
The automatic routine generator consists of an evolutionary program synthesizer and a program completion block. In turn, the synthesizer is made up of the program that implements the MOCCLGPA algorithm and a simulator of the ATmega 2560 microcontroller CPU. The fitness evaluation, in the MOCCLGPA algorithm, and the completion of the program, is carried out according to the type of routine that is generated.

A. Fitness Evaluation in the Conversion of One Code to Another
Authors in [17] proposed to evaluate the fitness through an exhaustive search of each bit of the binary representation of the output. In the algorithm description, the output value corresponding to the E input, expressed in binary, is represented.

Algorithm 1.
Multi-objective cooperative coevolutionary linear genetic programming algorithm is a species (program segment) ( = 0, … , − 1) Each species has two non-Pareto-dominated fronts 1 and 2 and two temporary lists and Pbest is the best program found so far Nlimit is the limit number of evaluations 1. for = 0 to − 1 do 2.
Random generation of 1 and 2

20.
Insertion of the best from in 1 and those discarded in 21.
Insertion of the best from in 2
The algorithm uses the RVM register value matrix that contains the value of the three working registers R0, R1, and R20, at the end of each instruction of the P program, and for each value of the E input, therefore, the matrix has three dimensions. Each element of the RVM matrix is a binary value that we represent where the index i corresponds to the instruction number in the genetic program, j corresponds to the input E in the input-output table, and b is the number of bit in the range 0 to 23 (bit numbers 0 to 7 correspond to register R0, 8 to 15 to R1, and 16 to 23 to R20). Algorithm 2 describes the fitness evaluation of a genetic program in the generation of a code conversion program.
For each combinational function corresponding to an output bit, with the following formula, the most similar combinational function is found in RVM matrix: where the operator ⊙ represents the nor-exclusive operation. The result of this operation, which can be "0" or "1", is then considered an integer value that participates in the arithmetic sum represented by the summation symbol.

Algorithm 2.
Fitness evaluation of a genetic program of code conversion IOT is the input-output table with the outputs in binary representation: Pbest is the best program found so far of NEbest size with fitness fsumbest RVM is the array of register values end for 11. end for 12. Calculate f, fsum, BLM, NE, fop and fopsum using formulas (1), (2), (3), (4), (5) and (6)  To find out if the maximum value has been reached, the sum of all the elements of fitness f is calculated: The best bit location for each element of fitness f is stored in the bit location matrix (BLM): The effective size of the program is: For smaller programs to have better fitness we use the formula: α has been assigned a value of 0.001.
The fitness is used in insertion operations of individuals on Pareto fronts. On Pareto fronts the sorting operations are based on the scalar value:

B. Fitness Evaluation in the Generation of Timing Diagrams without Input Values
We represent the timing diagrams of the pins of a microcontroller Port as a string of decimal values in which two consecutive values are not equal.
The algorithm for fitness evaluation of a program that generates timing diagrams proposed in [17], adapted to the AVR architecture, is shown in Algorithm 3, where L represents the number of values in the timing diagrams and K is the number of pins where the timing diagrams are generated. When the generated timing diagrams G are updated, a new value is recorded only if it is different from the previous one by at least one bit. Each component of the fitness vector corresponds to the timing diagram of a Port pin. After the execution of the genetic program, the generated timing diagrams (G) are compared with the target timing diagrams (S) in binary representation with the formula: where (L -d) is a weight assigned to d time. The first bits have greater weight compared to the last ones. This allows that, in the evolutionary process, the correct values are established, with greater probability, starting with the previous times and ending with the later ones, to improve the speed of convergence of the algorithm.
During the execution of the program, a VNI vector is formed with the indices of the instructions, whose execution has produced a change in some Port pin: Execute (Ii) 11. Update ( ) 12.

C. Fitness Evaluation in the Generation of Timing Diagrams According to Input Values
Algorithm 4 describes the fitness evaluation of a program that generates timing diagrams according to input values. In the algorithm, L represents the number of values in each timing diagram, M is the number of input values, and K is the number of pins where the timing diagrams are generated. To compare the generated timing diagrams with those desired for the E input, the formula is: The fitness vector is equal to the sum of all the fitness vectors . For the fitness vector the sum is calculated:

Algorithm 4.
Fitness evaluation of a genetic program for the generation of timing diagrams according to input values. In the input-output table (IOT) each output is a sequence of values: = [ 0 , 1 , … , , … , −1 ] is the genetic program to be evaluated = • • ( + 1) • 2 is the maximum value of fsum. Pbest is the best program found so far of NEbest size with fitness fsumbest 1.
for each input E do 3.
for i = 0 to N-1 do 12.
end for 16. f j is calculated with the formula (10) 17.

A. Generation of the Routine for Determining the Temperature Value (ADC_BIN)
As can be seen in the circuit in Fig. 1, the LM35 temperature sensor is connected to the A0 analog input of the Arduino Mega, which in the ATmega 2560 microcontroller is an input to the analog-digital converter (ADC). The ADC converts the voltage provided by the sensor into an integer that we represent as ADCvalue.
If the reference voltage on the ADC is Vcc = 5V, and the resolution is 10 bits; then the ADC converts the voltage range from 0V to 5V, proportionally, in the integer range from 0 to 1023. When the LM35 temperature sensor is configured to produce 10mV per °C, to convert the output value of the ADC in temperature value, in degrees centigrade, the following formula is used: The LM35 sensor, as configured, allows a temperature measurement range of 0° C to 150°C. To simplify the inputoutput table, we set the temperature range from 0°C to 99°C. In a spreadsheet, formula (15) is calculated for all the ADC www.ijacsa.thesai.org output values in the range from 0 to 203, obtaining the column "Temperature (°C)" of Table IV. Then, these values are rounded to the nearest one, obtaining the column "Rounded Temperature". The input-output table for the routine generator is made up of the columns "ADC Value" (Input) and "Rounded Temperature" (Output) of Table IV. The evolutionary process follows Algorithm 1 with the fitness evaluation described in Algorithm 2. In the completion stage, to the synthesized program Pbest, instructions are inserted and added with the information from the bit location matrix (BLM). For each ( , ) pair of BLM, after the instruction with index , a MOV instruction is inserted to copy the register containing the bit into a temporary register. For each bit, a different register is used from register R5 to register R(K + 4). At the end of the synthesized program Pbest, clear instruction of the R0 register is concatenated followed by pairs of BLD and BST instructions that copy the bits stored in the temporary registers into the R0 register. The completion of the program ends by inserting at the beginning, the instructions that place the initial values in the registers as indicated in Algorithm 2 on lines 3-6.
Before the execution of the ADC_BIN routine, the output value of the ADC must be placed in the R0 register. After executing the ADC_BIN routine, the temperature value rounded to the nearest one is obtained in the same R0 register as a number in natural binary code in the range from 0 to 99.

B. Generation of the Conversion Routine from a Natural Binary Number to Unpacked 2-Digit BCD (BIN_BCD2)
The routine converts a natural binary number in the range 0 to 99 to unpacked BCD code. The input-output table for the generator of this routine is shown in Table V, where for the numbers from 0 to 99, after separating the tens digit and the units digit, the operation Tens • 256 + Units is calculated placing the tens digit in the high byte and the units digit in the low byte that corresponds to the representation of the number in unpacked BCD code.
The evolutionary process follows Algorithm 1 with the fitness evaluation described in Algorithm 2. The completion of the program is done similarly to that carried out in the generation of the ADC_BIN routine, with the difference that now the most significant bits are placed in the register R1.
To invoke the BIN_BCD2 routine, the natural binary value is placed in register R0. The result of the conversion is obtained in registers R1 and R0. In register R1 the BCD tens digit is obtained and in register R0, the BCD units digit.

C. Generation of the "Home" Command Routine for the LCD Screen (LCD_HOME)
As can be seen in the circuit of Fig. 1 and Table I, the LCD text display module is connected to digital pins on the Arduino Mega board that correspond to Port C of the ATmega 2560 microcontroller. The "Home" routine performs the command to return the LCD screen to the initial state causing the cursor to return to the first left position of the first row. For the execution of this command, the microcontroller must generate in Port C the timing diagrams corresponding to the command with hexadecimal code 02 of the LCD screen controller.
According to the datasheet of the LCD module, in the timing diagrams, the RS and RW signals have value "0", while the enable signal E, for each nibble of the command, during a time interval has value "1" and in the next interval, the value "0". Therefore, in Table VI, at times 1 and 2 when the lines D7-D4 have a value of 0 (high nibble of the hexadecimal value 02), E = 1 at time 1, and E = 0 at time 2. It is important that at the beginning (time 0) and at the end (time 5) all signals are deactivated with a value of "0". The row "Port C" of Table VI is obtained by expressing the value of the Port C pins in decimal representation. The input-output table is made up of the row "Time" (Input) and the row "Port C" (Output) of Table VI. The evolutionary process follows Algorithm 1 with the fitness evaluation of a genetic program according to Algorithm 3. When the stop condition is met, the synthesized program is Pbest of NE size.
The completion of the program consists of inserting at the beginning the instructions that place the initial values in the registers as indicated in Algorithm 3 on lines 1-6.  In the generation of routines that produce timing diagrams on a Port, such as Port C, to overcome timing problems, after each instruction with the PORTC operand the CALL DELAY instruction is inserted.

D. Generating the LCD Screen Initialization Routine (LCD_INI)
According to the datasheet of the LCD screen module, to configure the module with a 4-bit interface and non-visible cursor, the microcontroller must generate timing diagrams on Port C corresponding to the hexadecimal sequence of commands: 33, 32, 28, 0C.
As in the generation of the "Home" routine, the RS and RW signals must have a value of "0" and the E signal for each nibble of command must have a value of "1" during a time interval, and then it must change to "0". In Table VII, the obtaining of the decimal sequence corresponding to the timing diagrams for the initialization of the LCD screen is shown. The input-output table consists of the row "Time" (Input) and the row "Port C" (Output) of Table VII. The evolutionary process follows Algorithm 1 with the fitness evaluation according to Algorithm 3. When the stop condition is met, the synthesized program is Pbest of NE size. The program is completed with the insertion of the instructions that place the initial values in the registers, as indicated in lines 1-6 of Algorithm 3, at the beginning of the program. As in the generation of the LCD_HOME routine, after each instruction with the PORTC operand the CALL DELAY instruction is inserted.

E. Generating the Symbol Writing on the LCD Screen Routine (BCD1_LCD)
This routine allows the display of symbols on the LCD screen such as decimal digits from 0 to 9, space, decimal point, and capital letter C. To be displayed, the symbols must be sent to the LCD screen in ASCII code. As an example, Table VIII shows the obtaining of the timing diagrams in Port C to display the decimal digit "1". Proceeding similarly with all symbols, the timing diagrams are obtained in columns S0 to S5 of Table IX. The input-output table for the routine generator consists of the column "Code" (Input) and the columns from S0 to S5 (Output).  0  3  3  3  3  3  3  2  2  2  2  8  8  0  0  12 12 0 0  52  48  52  48  52  48  36  32  36  32  132  128  4  0  196  192  0   TABLE VIII. OBTAINING THE TIMING DIAGRAMS TO DISPLAY THE   The evolutionary process is developed according to Algorithm 1 with the fitness evaluation according to Algorithm 4. The completion of the program is carried out with the insertion, at the beginning of the program, of the instructions that perform the operations indicated in rows 3-8 of Algorithm 4. As explained before, after each instruction with the PORTC operand, the CALL DELAY instruction is inserted. To invoke the BCD1_LCD routine, the input value (symbol code) must be in the R0 register.

VI. EXPERIMENTAL WORK
In the design of systems based on the Arduino Mega board, when the circuit includes devices such as LCD screen module, matrix keyboard, seven-segment indicators, sensors, and others, the methodology proposed in this article for developing the program consists of executing the following steps: 1) the global task is divided, if possible, into subtasks that are expressed through an input-output table; 2) the inputoutput tables are made with the help of a spreadsheet; 3) the routines described by input-output tables are automatically generated by the generator implemented based on the algorithms shown in previous sections; 4) the main program and routines that were not described with tables are manually written in assembly language. The main program has two parts: the first run only once and sets the system configuration, the second is a loop that repeats indefinitely. For the implementation of the digital thermometer, the main program, shown in Fig. 2(a), which was manually written, mainly contains register transfer instructions (MOV) and routine call instructions (CALL). The routines whose names are in green have been written manually, while the routines with names in red have been generated automatically. Within the infinite loop, the tasks are sequentially executed: place the LCD screen cursor in the initial state, read the ADC value, convert the ADC value into natural binary temperature value, convert the natural binary value into two-digit unpacked BCD code, display the tens digit, display the units digit, and display the letter C.
When the entire assembly language program is written manually, it is necessary to write routines to perform multiplication and/or division operations in the determination of temperature, and routines that perform the operations for handling the LCD screen. In the proposed methodology, these operations are carried out at the stage of making the inputoutput tables in a spreadsheet; therefore, the application of the proposed method is less complex compared to the manual writing of the entire program in assembly language. Fig. 2(b) shows the program written in Arduino programming language for the circuit in Fig. 1, with the modification of connecting the RW signal of the LCD module to the ground. Because it is a high-level programming language, writing the program in this language is less complex than writing according to the proposed methodology. In the program in Fig. 2(b), the setup function configures the system and is executed only once; the loop function repeats indefinitely. In the loop function, the following operations are carried out: placing the LCD screen cursor in the first position of the first row, reading the microcontroller ADC value, calculating the temperature, displaying the temperature, and displaying the letter C.  As can be seen, the two programs in Fig. 2 have similar structures. The programmer who follows the proposed methodology must have basic knowledge about the assembly programming language and the microcontroller architecture to manually write the main program, system configuration routine, ADC initialization routine, ADC reading routine, and a delay routine. All the other routines, which represent a significant percentage of the entire program (73%), have been automatically generated. The complete program, obtained with the proposed methodology, is shown in Fig. 3, with the routines automatically generated on a light blue background. Compiling this program generates a 614-byte machine code. On the other hand, writing the program in the Arduino programming language requires knowledge of this language, which is similar to the C++ language, and its compilation produces a 3788-byte machine code, which means that the use of the proposed methodology preserves the advantage of assembly language to produce smaller machine code compared to other programming languages.
In the stage of convergence and stability tests of the algorithms used in the proposed methodology, the generator of each routine has been executed 10 times. Table X shows the most important characteristics of the tests carried out in the generation of these routines. As can be seen in Table X, when  the input-output table has a large number of rows (ADC_BIN  routine), or when the table has several output columns (BCD1_LCD routine) the hit rate may be low (30%); this also occurs when the output has a low correlation or is not correlated with the input. For the generator of the BIN_BCD2 routine, the hit rate is the highest (100%) since the input and the output are quite correlated. The test parameters are: The size of the initial population of each species is 100, the number of species (program segments) is 10, the number of  Limit number of evaluations (stop condition) 5x10 6 5x10 6 5x10 6 5x10 6 40x10 6 www.ijacsa.thesai.org The limitations of the proposed methodology are: 1) the application of the methodology depends on the existence of subtasks that are described by input-output tables; 2) the size of the input-output tables cannot be too large, tables of up to 204 rows and up to 6 columns of output have been used in the tests; 3) depending on the speed of the computer, in some cases, the generation of the program may take a long time; 4) in the generation of peripheral device management routines, in addition to the simulator of the microcontroller CPU, it is necessary to simulate the interface of the microcontroller with the peripheral device.

VII. CONCLUSIONS AND SUGGESTIONS
In this article, a programming methodology for the Arduino Mega board has been described. This methodology is applicable in cases when, in addition to the Arduino Mega board, the circuit includes devices such as LCD screen, matrix keyboard, seven-segment indicators, sensors, etc. The methodology makes use of an automatic generator of assembly language routines, whose operating algorithms, based on multi-objective cooperative coevolutionary linear genetic programming, are described in this work.
The application of the methodology has been shown in an illustrative example that consists of the development of the program for a digital thermometer organized on a circuit formed by the Arduino Mega board, an alphanumeric LCD module, and a temperature sensor. The result is an assembly language program where 73% of the program lines have been generated automatically; which means that writing the program following the proposed methodology is less complex than manually writing the entire program in assembly language. The example has also shown that the application of the proposed methodology preserves the advantage of assembly language programming of generating machine code of a much smaller size than that generated by the Arduino programming language.
In the illustrative example, the temperature range is 0°C to 99°C displaying only the integer value of the temperature; however, it is also possible to display the values with tenths and hundredths, but with a lower temperature range. As part of future work, the authors intend to follow the methodology for programming other Arduino-based measurement instruments.
In the ATmega 2560 microcontroller instruction set, there are fractional multiplication instructions FMUL, FMULS, and FMULSU, which have not been used in this work. In future work, we recommend the inclusion of these instructions in the table of instructions used by the microcontroller simulator, which could lead to an improvement in the performance of the automatic routine generator, especially when generating routines for calculating mathematical formulas.