1 of 6 Assign-02: Writing a Linux Utility (encodeInput) Description This assignment has you writing a different utility for Linux. This utility (officially called a filter in UNIX / Linux) could be used to take an assembled program (e.g. for the Motorola 6808 Microcontroller) and generate something known as an 519 download file in order to download the assembled code to the actual embedded device. This is similar to your ARM development environment in the MES course- you write and compile your code on a host computer and download it to the ARM board This application will encourage you to learn more about the common application programming model in UNIX / Linux. The filter that you will create will be capable of taking ANY binary input file, and transforming it into its equivalent 5 Record output file OR an assembly file for use in an embedded software development environment. The two different output file formats which are generated by this filter will both be ASCII (human readable) Objectives Reinforce knowledge of binary arithmetic and the hexadecimal numbering system Reinforce knowledge of File I/O (both ASCII and binary) in programming-using actual files as well as STDIN and STDOUT Practice writing a utility that can use command-shell redirecting and/or piping Practice writing a utility that requires and uses command-line arguments NOTE: You may work on this assignment with a partner if you wish. The S-RECORD Output of your encodelnput Filter S-Records are often used in embedded development environments in terms of transferring data from one system to another. Development tools like EPROM burners for example accept data in this format. As you may recall from DEF, an ASM file (assembly file) is used by embedded development tools to allow you to specify both machine codes and data (like strings) for your target system. The Motorola S-Record File format was developed a number of years ago. It is also known as the SREC or 519 format. It was developed in the 1970's by Motorola (for the 6800 microprocessor) to allow you to encode your binary files (eg. your executables) into an ASCII format file for easy downloading to an embedded system. Visit the link above to learn more about the structure of the S-Record. Example: Input data ARCDEFGHIJKLMNOPORST SREC Output data 300700005345414E01 311300004142434445464748494A4340404K475064 310700105152535496 55030002PA 59030000FC As you can see, the 19 for SREC) file is made up of a number of "S" type records (S0, S1, S5 and S9 in the above example) The general format of each of these "S" records is: TTCCAAAADDD DDMM Where TT -2 characters indicating the S-Record type CC -2 characters representing a single hexadecimal byte telling how many hexadecimal coded bytes follow in that line AAAA - 4 characters representing a hexadecimal address where the data on this S-record line needs to be loaded into memory on the embedded device DDDD - up to 32 characters -representing up to 16 hexadecimal byte values representing the input data MM -2 characters - repres e checksum value for that Record 3 of 6 hins to Note The COUNT field (CC) of the specific S Record contains the number of bytes including the address field (AAAA), the data fields (DD..DD) and the checksum field (MM) In our filter we will only be using 4 character address fields (representing a 2 hexadecimal byte address) - this means you only need to use the 51 record for your data. Since each S1 record is limited to containing a maximum of 16 bytes worth of data-this means that the address value contained in this field will always increment by 16 SP-SENG2030 Assign-02: Writing a Linux Utility (encodeInput) o This means that each S1 record will only represent 16 bytes worth of encode data. So if the assembled program that you are trying to encode for downloading is 40 bytes in length - then your resultant file will contain two S1 records representing 16 bytes of data each and one S1 record containing the remaining 8 bytes of data (16+16+840) The CHECKSUM field (MM) value is calculated by taking the least significant byte of the 1's Complement value of the sum of the COUNT, ADDRESS and DATA fields of the record To calculate this value add the COUNT field's value with the ADDRESS field's value with each of the DATA field's values to get a sum value Then take the l's Complement(remember Computer Architecture and Machine Language (CAML)) of this sum Then strip off the value in the least significant byte of the resultant value and encode it One thing that will strike you as odd about the above coding and sample is for example how I say that the COUNT field is 2 characters in output, but represents a single hexadecimal byte Because encodeInput uses run-time switches, this program does not need to prompt the end user for any other kinds of input. Instead, if written correctly, the end user will be able to redirect or pipe textual data into the application in place of using a file! Although it probably doesn't need to be said the only way that encodeInput should allow an input stream to end is when it reaches the end-of-file. That is, if you are running encodeInput and reading from a file, obviously the input ends when it reaches the end-of-file. Similarly when you are running the utility interactively and are entering input via the keyboard, the input ends when it reaches the end-of-file - not an ENTER key, and not any other special character sequence - just an end-of-file. What you need to do is to simulate an end-of-file from the keyboard - this is done by entering a CTRL-D pressing the CONTROL key and the D key simultaneously). Please note that CTRL-D only works to end the file when entered at the beginning of the input line-if it is not the first character of the input, then CTRL D serves to flush (or push) the data ahead of it into the program. For example, assume the "D" in the following examples represents when I press CTRL-D and "E" is when I hit enter - so if you enter "123D, the CTRL-D simply causes the program to read "123". But if my input is "123ED" - then the CTRL-D is the first character of an input line (because it follows an ENTER) - so this will be interpreted as an EOF character in your program. Some examples of valid command lines: encode Input -myData , dat myData, Bret -Bret The above will convert myData.dat to myData.Srec as an S-Record file encode Input -h The above will output help (usage statement) information and exit encodeInput -omyData.asn The above will convert standard input into myData.asm as an assembly file encode input recimybata.dat The above will convert data from myData.dat into myData.dat.srec as an S-Record file encodeInput The ASSEMBLY FILE Output of your encodeInput Filter The required Assembly File format that your utility can also produce is much more straightforward in its coding than the S-Record format. Essentially, this format translates each byte of input data into a define constant byte (de. b) assembly instruction. Each line of the resultant file is allowed to contain a maximum of 16 bytes of input data. Example: Input data: ABCDEFGHIJKLMNOPQRST Assembly File Output data: de.b $41.542.543, 544, 545, 546, 547, 548, 549. S4A, 548, S4C, S40, S4, S4F, 550 dc. b $51, 52, 53, 54 Your Task Create a C program that has 4 optional switches in C, you might consider these as command line arguments). With the exception of the help switch, your filter program (called encodeinput) will take and interpret input as binary values, and produce ASCII readable output based on these switches. The data values encoded in the output will always be the hexadecimal representation of the ASCII value of the input byte. The switches that encodelnput must support are: . -I INPUT FILENAME O This option tells your software the name of the input file If this file is not specified, your program will obtain input data from the standard input (stdin file handle) If the file is specified and does not exist, your program will present an error -OOUTPUTFILENAME This option tells your software the name of the output file. If this file is not specified, and an input file is specified then: . If the -Srec option is not present, then the output filename will be the input filename, with. asm" file extension appended . e.g.encode Input -iBinary-01.bin will automatically create an output file called Binary-01.bin.asm . If the -Srec option is present, then the output filename will be the input filename, with ".grec appended - S. Anodont - AG -Binary-01 hin will automatically create an output file called Binary-01.hin AG Assign-02: Writing a Linux Utility (encodeInput) OTHER PROGRAMMING NOTES: . It is expected that your final solution and source code for this utility consists of at least 3 source modules and at least one header file As before -I am asking you to do this to start you thinking about designing your solutions to properly modularize your solution approach into different source code modules (files) o Remember that it is good design practice to not place any problem-domain knowledge in the main() function Also it is good design practice to not place any of your solution's functions in the same source module as the main() function You must comply with SET Coding Standards Make sure to comment your source code appropriately - this includes file header comments, function header comments as well as inline comments Your solution structure must include a makefile and also follow the recommended Linux development directory structure as outlined in the Linux Development Project Code Structure document within eConestoga. As always, do not submit a solution that is compiled for debug or contains any debugging messages. Hand in . Please clean and hand in your encodeInput solution-tar up your solution directory into a file titled "lastName-first Initial.tar" leg, John Smith would submit smith-j.tar) if you are doing the assignment alone OR o smith-j-jones-s.tar (e.g. John Smith and Sally Jones working on the assignment together) and submit to the dropbox. Note: If you are working with a partner - then only one of the partners needs to submit the assignment. Sample BINARY Input File I have included a sample binary input file (found in the A92-Sample-Rinarvatar.file included with this assignment). The SREC encoded output 3 of 6 Things to Note The COUNT field (CC) of the specific S Record contains the number of bytes including the address field (AAAA), the data fields (DD..DD) and the checksum field (MM) In our filter we will only be using 4 character address fields (representing a 2 hexadecimal byte address) - this means you only need to use the 51 record for your data. Since each S1 record is limited to containing a maximum of 16 bytes worth of data-this means that the address value contained in this field will always increment by 16 SP-SENG2030 Assign-02: Writing a Linux Utility (encodeInput) This means that each 51 record will only represent 16 bytes worth of encode data. So if the assembled program that you are trying to encode for downloading is 40 bytes in length - then your resultant file will contain two S1 records representing 16 bytes of data each and one S1 record containing the remaining 8 bytes of data (16+16+840) The CHECKSUM field (MM) value is calculated by taking the least significant byte of the 1's Complement value of the sum of the COUNT, ADDRESS and DATA fields of the record To calculate this value add the COUNT field's value with the ADDRESS field's value with each of the DATA field's values to get a sum value Then take the 1's Complement(remember Computer Architecture and Machine Language (CAML)) of this sum Then strip off the value in the least significant byte of the resultant value and encode it One thing that will strike you as odd about the above coding and sample is for example how I say that the COUNT field is 2 characters in output, but represents a single hexadecimal byte The S-RECORD Output of your encodelnput Filter S-Records are often used in embedded development environments in terms of transferring data from one system to another. Development tools like EPROM burners for example accept data in this format. As you may recall from DEF, an ASM file (assembly file) is used by embedded development tools to allow you to specify both machine codes and data (like strings) for your target system. The Motorola S-Record File format was developed a number of years ago. It is also known as the SREC or 519 format. It was developed in the 1970's by Motorola (for the 6800 microprocessor) to allow you to encode your binary files (e.g. your executables) into an ASCII format file for easy downloading to an embedded system. Visit the link above to learn more about the structure of the S-Record. Example: Input data ARCHIJKLIOPORST SREC Output data 300700005345414ED1 311300004142434445464748494A 4B 4C 4D 4K475064 S1070010515253549E 85030002PA 59030000FC As you can see, the S19 (or SREC) file is made up of a number of "S" type records (S0, S1, S5 and S9 in the above example) The general format of each of these "S" records is: TTCCAAAADDDDDMM Where TT -2 characters indicating the S-Record type CC -2 characters representing a single hexadecimal byte telling how many hexadecimal coded bytes follow in that line AAAA - 4 characters representing a hexadecimal address where the data on this S-record line needs to be loaded into memory on the embedded device DDDD - up to 32 characters -representing up to 16 hexadecimal byte values representing the input data MM -2 characters - repres e checksum value for that Record The S-RECORD Output of your encodelnput Filter S-Records are often used in embedded development environments in terms of transferring data from one system to another. Development tools like EPROM burners for example accept data in this format. As you may recall from DEF, an ASM file (assembly file) is used by embedded development tools to allow you to specify both machine codes and data (like strings) for your target system. The Motorola S-Record File format was developed a number of years ago. It is also known as the SREC or 519 format. It was developed in the 1970's by Motorola (for the 6800 microprocessor) to allow you to encode your binary files (e.g. your executables) into an ASCII format file for easy downloading to an embedded system. Visit the link above to learn more about the structure of the S-Record. Example: Input data ARCHIJKLIOPORST SREC Output data 300700005345414ED1 311300004142434445464748494A 4B 4C 4D 4K475064 S1070010515253549E 85030002PA 59030000FC As you can see, the S19 (or SREC) file is made up of a number of "S" type records (S0, S1, S5 and S9 in the above example) The general format of each of these "S" records is: TTCCAAAADDDDDMM Where TT -2 characters indicating the S-Record type CC -2 characters representing a single hexadecimal byte telling how many hexadecimal coded bytes follow in that line AAAA - 4 characters representing a hexadecimal address where the data on this S-record line needs to be loaded into memory on the embedded device DDDD - up to 32 characters -representing up to 16 hexadecimal byte values representing the input data MM -2 characters - repres e checksum value for that Record 3 of 6 Things to Note The COUNT field (CC) of the specific S Record contains the number of bytes including the address field (AAAA), the data fields (DD..DD) and the checksum field (MM) In our filter we will only be using 4 character address fields (representing a 2 hexadecimal byte address) - this means you only need to use the 51 record for your data. Since each S1 record is limited to containing a maximum of 16 bytes worth of data-this means that the address value contained in this field will always increment by 16 SP-SENG2030 Assign-02: Writing a Linux Utility (encodeInput) This means that each 51 record will only represent 16 bytes worth of encode data. So if the assembled program that you are trying to encode for downloading is 40 bytes in length - then your resultant file will contain two S1 records representing 16 bytes of data each and one S1 record containing the remaining 8 bytes of data (16+16+840) The CHECKSUM field (MM) value is calculated by taking the least significant byte of the 1's Complement value of the sum of the COUNT, ADDRESS and DATA fields of the record To calculate this value add the COUNT field's value with the ADDRESS field's value with each of the DATA field's values to get a sum value Then take the 1's Complement(remember Computer Architecture and Machine Language (CAML)) of this sum Then strip off the value in the least significant byte of the resultant value and encode it One thing that will strike you as odd about the above coding and sample is for example how I say that the COUNT field is 2 characters in output, but represents a single hexadecimal byte 1 of 6 Assign-02: Writing a Linux Utility (encodelnput) Description This assignment has you writing a different utility for Linux. This utility (officially called a filter in UNIX / Linux) could be used to take an assembled program (e.g. for the Motorola 6808 Microcontroller) and generate something known as an 519 download file in order to download the assembled code to the actual embedded device. This is similar to your ARM development environment in the MES course - you write and compile your code on a host computer and download it to the ARM board. This application will encourage you to learn more about the common application programming model in UNIX / Linux. The filter that you will create will be capable of taking ANY binary input file, and transforming it into its equivalent S. Record output file OR an assembly file for use in an embedded software development environment. The two different output file formats which are generated by this filter will both be ASCII (human readable) Objectives Reinforce knowledge of binary arithmetic and the hexadecimal numbering system Reinforce knowledge of File I/O (both ASCII and binary) in programming-using actual files as well as STDIN and STDOUT Practice writing a utility that can use command-shell redirecting and/or piping Practice writing a utility that requires and uses command-line arguments NOTE: You may work on this assignment with a partner if you wish. Because encodeInput uses run-time switches, this program does not need to prompt the end user for any other kinds of input. Instead, if written correctly, the end user will be able to redirect or pipe textual data into the application in place of using a file! Although it probably doesn't need to be said the only way that encodeInput should allow an input stream to end is when it reaches the end-of-file. That is, if you are running encodeInput and reading from a file, obviously the input ends when it reaches the end-of-file. Similarly when you are running the utility interactively and are entering input via the keyboard, the input ends when it reaches the end-of-file - not an ENTER key, and not any other special character sequence - just an end-of-file. What you need to do is to simulate an end-of-file from the keyboard - this is done by entering a CTRL-D (pressing the CONTROL key and the D key simultaneously). Please note that CTRL-D only works to end the file when entered at the beginning of the input line-if it is not the first character of the input, then CTRL D serves to flush (or push) the data ahead of it into the program. For example, assume the "D" in the following examples represents when I press CTRL-D and "E" is when I hit enter - so if you enter "123D, the CTRL-D simply causes the program to read "123". But if my input is "123ED" - then the CTRL-D is the first character of an input line (because it follows an ENTER) - so this will be interpreted as an EOF character in your program. Some examples of valid command lines: encode Input -imyData , dat myData, Bret -Bret The above will convert myData.dat to myData.Srec as an S-Record file encode Input -h The above will output help (usage statement) information and exit encodeInput -omyData.asm The above will convert standard input into myData.asm as an assembly file encodeInputsrecimybata.dat The above will convert data from myData.dat into myData.dat.srec as an S-Record file encodeInput 1 of 6 Assign-02: Writing a Linux Utility (encodeInput) Description This assignment has you writing a different utility for Linux. This utility (officially called a filter in UNIX / Linux) could be used to take an assembled program (e.g. for the Motorola 6808 Microcontroller) and generate something known as an 519 download file in order to download the assembled code to the actual embedded device. This is similar to your ARM development environment in the MES course- you write and compile your code on a host computer and download it to the ARM board This application will encourage you to learn more about the common application programming model in UNIX / Linux. The filter that you will create will be capable of taking ANY binary input file, and transforming it into its equivalent 5 Record output file OR an assembly file for use in an embedded software development environment. The two different output file formats which are generated by this filter will both be ASCII (human readable) Objectives Reinforce knowledge of binary arithmetic and the hexadecimal numbering system Reinforce knowledge of File I/O (both ASCII and binary) in programming-using actual files as well as STDIN and STDOUT Practice writing a utility that can use command-shell redirecting and/or piping Practice writing a utility that requires and uses command-line arguments NOTE: You may work on this assignment with a partner if you wish. The S-RECORD Output of your encodelnput Filter S-Records are often used in embedded development environments in terms of transferring data from one system to another. Development tools like EPROM burners for example accept data in this format. As you may recall from DEF, an ASM file (assembly file) is used by embedded development tools to allow you to specify both machine codes and data (like strings) for your target system. The Motorola S-Record File format was developed a number of years ago. It is also known as the SREC or 519 format. It was developed in the 1970's by Motorola (for the 6800 microprocessor) to allow you to encode your binary files (eg. your executables) into an ASCII format file for easy downloading to an embedded system. Visit the link above to learn more about the structure of the S-Record. Example: Input data ARCDEFGHIJKLMNOPORST SREC Output data 300700005345414E01 311300004142434445464748494A4340404K475064 310700105152535496 55030002PA 59030000FC As you can see, the 19 for SREC) file is made up of a number of "S" type records (S0, S1, S5 and S9 in the above example) The general format of each of these "S" records is: TTCCAAAADDD DDMM Where TT -2 characters indicating the S-Record type CC -2 characters representing a single hexadecimal byte telling how many hexadecimal coded bytes follow in that line AAAA - 4 characters representing a hexadecimal address where the data on this S-record line needs to be loaded into memory on the embedded device DDDD - up to 32 characters -representing up to 16 hexadecimal byte values representing the input data MM -2 characters - repres e checksum value for that Record 3 of 6 hins to Note The COUNT field (CC) of the specific S Record contains the number of bytes including the address field (AAAA), the data fields (DD..DD) and the checksum field (MM) In our filter we will only be using 4 character address fields (representing a 2 hexadecimal byte address) - this means you only need to use the 51 record for your data. Since each S1 record is limited to containing a maximum of 16 bytes worth of data-this means that the address value contained in this field will always increment by 16 SP-SENG2030 Assign-02: Writing a Linux Utility (encodeInput) o This means that each S1 record will only represent 16 bytes worth of encode data. So if the assembled program that you are trying to encode for downloading is 40 bytes in length - then your resultant file will contain two S1 records representing 16 bytes of data each and one S1 record containing the remaining 8 bytes of data (16+16+840) The CHECKSUM field (MM) value is calculated by taking the least significant byte of the 1's Complement value of the sum of the COUNT, ADDRESS and DATA fields of the record To calculate this value add the COUNT field's value with the ADDRESS field's value with each of the DATA field's values to get a sum value Then take the l's Complement(remember Computer Architecture and Machine Language (CAML)) of this sum Then strip off the value in the least significant byte of the resultant value and encode it One thing that will strike you as odd about the above coding and sample is for example how I say that the COUNT field is 2 characters in output, but represents a single hexadecimal byte Because encodeInput uses run-time switches, this program does not need to prompt the end user for any other kinds of input. Instead, if written correctly, the end user will be able to redirect or pipe textual data into the application in place of using a file! Although it probably doesn't need to be said the only way that encodeInput should allow an input stream to end is when it reaches the end-of-file. That is, if you are running encodeInput and reading from a file, obviously the input ends when it reaches the end-of-file. Similarly when you are running the utility interactively and are entering input via the keyboard, the input ends when it reaches the end-of-file - not an ENTER key, and not any other special character sequence - just an end-of-file. What you need to do is to simulate an end-of-file from the keyboard - this is done by entering a CTRL-D pressing the CONTROL key and the D key simultaneously). Please note that CTRL-D only works to end the file when entered at the beginning of the input line-if it is not the first character of the input, then CTRL D serves to flush (or push) the data ahead of it into the program. For example, assume the "D" in the following examples represents when I press CTRL-D and "E" is when I hit enter - so if you enter "123D, the CTRL-D simply causes the program to read "123". But if my input is "123ED" - then the CTRL-D is the first character of an input line (because it follows an ENTER) - so this will be interpreted as an EOF character in your program. Some examples of valid command lines: encode Input -myData , dat myData, Bret -Bret The above will convert myData.dat to myData.Srec as an S-Record file encode Input -h The above will output help (usage statement) information and exit encodeInput -omyData.asn The above will convert standard input into myData.asm as an assembly file encode input recimybata.dat The above will convert data from myData.dat into myData.dat.srec as an S-Record file encodeInput The ASSEMBLY FILE Output of your encodeInput Filter The required Assembly File format that your utility can also produce is much more straightforward in its coding than the S-Record format. Essentially, this format translates each byte of input data into a define constant byte (de. b) assembly instruction. Each line of the resultant file is allowed to contain a maximum of 16 bytes of input data. Example: Input data: ABCDEFGHIJKLMNOPQRST Assembly File Output data: de.b $41.542.543, 544, 545, 546, 547, 548, 549. S4A, 548, S4C, S40, S4, S4F, 550 dc. b $51, 52, 53, 54 Your Task Create a C program that has 4 optional switches in C, you might consider these as command line arguments). With the exception of the help switch, your filter program (called encodeinput) will take and interpret input as binary values, and produce ASCII readable output based on these switches. The data values encoded in the output will always be the hexadecimal representation of the ASCII value of the input byte. The switches that encodelnput must support are: . -I INPUT FILENAME O This option tells your software the name of the input file If this file is not specified, your program will obtain input data from the standard input (stdin file handle) If the file is specified and does not exist, your program will present an error -OOUTPUTFILENAME This option tells your software the name of the output file. If this file is not specified, and an input file is specified then: . If the -Srec option is not present, then the output filename will be the input filename, with. asm" file extension appended . e.g.encode Input -iBinary-01.bin will automatically create an output file called Binary-01.bin.asm . If the -Srec option is present, then the output filename will be the input filename, with ".grec appended - S. Anodont - AG -Binary-01 hin will automatically create an output file called Binary-01.hin AG Assign-02: Writing a Linux Utility (encodeInput) OTHER PROGRAMMING NOTES: . It is expected that your final solution and source code for this utility consists of at least 3 source modules and at least one header file As before -I am asking you to do this to start you thinking about designing your solutions to properly modularize your solution approach into different source code modules (files) o Remember that it is good design practice to not place any problem-domain knowledge in the main() function Also it is good design practice to not place any of your solution's functions in the same source module as the main() function You must comply with SET Coding Standards Make sure to comment your source code appropriately - this includes file header comments, function header comments as well as inline comments Your solution structure must include a makefile and also follow the recommended Linux development directory structure as outlined in the Linux Development Project Code Structure document within eConestoga. As always, do not submit a solution that is compiled for debug or contains any debugging messages. Hand in . Please clean and hand in your encodeInput solution-tar up your solution directory into a file titled "lastName-first Initial.tar" leg, John Smith would submit smith-j.tar) if you are doing the assignment alone OR o smith-j-jones-s.tar (e.g. John Smith and Sally Jones working on the assignment together) and submit to the dropbox. Note: If you are working with a partner - then only one of the partners needs to submit the assignment. Sample BINARY Input File I have included a sample binary input file (found in the A92-Sample-Rinarvatar.file included with this assignment). The SREC encoded output 3 of 6 Things to Note The COUNT field (CC) of the specific S Record contains the number of bytes including the address field (AAAA), the data fields (DD..DD) and the checksum field (MM) In our filter we will only be using 4 character address fields (representing a 2 hexadecimal byte address) - this means you only need to use the 51 record for your data. Since each S1 record is limited to containing a maximum of 16 bytes worth of data-this means that the address value contained in this field will always increment by 16 SP-SENG2030 Assign-02: Writing a Linux Utility (encodeInput) This means that each 51 record will only represent 16 bytes worth of encode data. So if the assembled program that you are trying to encode for downloading is 40 bytes in length - then your resultant file will contain two S1 records representing 16 bytes of data each and one S1 record containing the remaining 8 bytes of data (16+16+840) The CHECKSUM field (MM) value is calculated by taking the least significant byte of the 1's Complement value of the sum of the COUNT, ADDRESS and DATA fields of the record To calculate this value add the COUNT field's value with the ADDRESS field's value with each of the DATA field's values to get a sum value Then take the 1's Complement(remember Computer Architecture and Machine Language (CAML)) of this sum Then strip off the value in the least significant byte of the resultant value and encode it One thing that will strike you as odd about the above coding and sample is for example how I say that the COUNT field is 2 characters in output, but represents a single hexadecimal byte The S-RECORD Output of your encodelnput Filter S-Records are often used in embedded development environments in terms of transferring data from one system to another. Development tools like EPROM burners for example accept data in this format. As you may recall from DEF, an ASM file (assembly file) is used by embedded development tools to allow you to specify both machine codes and data (like strings) for your target system. The Motorola S-Record File format was developed a number of years ago. It is also known as the SREC or 519 format. It was developed in the 1970's by Motorola (for the 6800 microprocessor) to allow you to encode your binary files (e.g. your executables) into an ASCII format file for easy downloading to an embedded system. Visit the link above to learn more about the structure of the S-Record. Example: Input data ARCHIJKLIOPORST SREC Output data 300700005345414ED1 311300004142434445464748494A 4B 4C 4D 4K475064 S1070010515253549E 85030002PA 59030000FC As you can see, the S19 (or SREC) file is made up of a number of "S" type records (S0, S1, S5 and S9 in the above example) The general format of each of these "S" records is: TTCCAAAADDDDDMM Where TT -2 characters indicating the S-Record type CC -2 characters representing a single hexadecimal byte telling how many hexadecimal coded bytes follow in that line AAAA - 4 characters representing a hexadecimal address where the data on this S-record line needs to be loaded into memory on the embedded device DDDD - up to 32 characters -representing up to 16 hexadecimal byte values representing the input data MM -2 characters - repres e checksum value for that Record The S-RECORD Output of your encodelnput Filter S-Records are often used in embedded development environments in terms of transferring data from one system to another. Development tools like EPROM burners for example accept data in this format. As you may recall from DEF, an ASM file (assembly file) is used by embedded development tools to allow you to specify both machine codes and data (like strings) for your target system. The Motorola S-Record File format was developed a number of years ago. It is also known as the SREC or 519 format. It was developed in the 1970's by Motorola (for the 6800 microprocessor) to allow you to encode your binary files (e.g. your executables) into an ASCII format file for easy downloading to an embedded system. Visit the link above to learn more about the structure of the S-Record. Example: Input data ARCHIJKLIOPORST SREC Output data 300700005345414ED1 311300004142434445464748494A 4B 4C 4D 4K475064 S1070010515253549E 85030002PA 59030000FC As you can see, the S19 (or SREC) file is made up of a number of "S" type records (S0, S1, S5 and S9 in the above example) The general format of each of these "S" records is: TTCCAAAADDDDDMM Where TT -2 characters indicating the S-Record type CC -2 characters representing a single hexadecimal byte telling how many hexadecimal coded bytes follow in that line AAAA - 4 characters representing a hexadecimal address where the data on this S-record line needs to be loaded into memory on the embedded device DDDD - up to 32 characters -representing up to 16 hexadecimal byte values representing the input data MM -2 characters - repres e checksum value for that Record 3 of 6 Things to Note The COUNT field (CC) of the specific S Record contains the number of bytes including the address field (AAAA), the data fields (DD..DD) and the checksum field (MM) In our filter we will only be using 4 character address fields (representing a 2 hexadecimal byte address) - this means you only need to use the 51 record for your data. Since each S1 record is limited to containing a maximum of 16 bytes worth of data-this means that the address value contained in this field will always increment by 16 SP-SENG2030 Assign-02: Writing a Linux Utility (encodeInput) This means that each 51 record will only represent 16 bytes worth of encode data. So if the assembled program that you are trying to encode for downloading is 40 bytes in length - then your resultant file will contain two S1 records representing 16 bytes of data each and one S1 record containing the remaining 8 bytes of data (16+16+840) The CHECKSUM field (MM) value is calculated by taking the least significant byte of the 1's Complement value of the sum of the COUNT, ADDRESS and DATA fields of the record To calculate this value add the COUNT field's value with the ADDRESS field's value with each of the DATA field's values to get a sum value Then take the 1's Complement(remember Computer Architecture and Machine Language (CAML)) of this sum Then strip off the value in the least significant byte of the resultant value and encode it One thing that will strike you as odd about the above coding and sample is for example how I say that the COUNT field is 2 characters in output, but represents a single hexadecimal byte 1 of 6 Assign-02: Writing a Linux Utility (encodelnput) Description This assignment has you writing a different utility for Linux. This utility (officially called a filter in UNIX / Linux) could be used to take an assembled program (e.g. for the Motorola 6808 Microcontroller) and generate something known as an 519 download file in order to download the assembled code to the actual embedded device. This is similar to your ARM development environment in the MES course - you write and compile your code on a host computer and download it to the ARM board. This application will encourage you to learn more about the common application programming model in UNIX / Linux. The filter that you will create will be capable of taking ANY binary input file, and transforming it into its equivalent S. Record output file OR an assembly file for use in an embedded software development environment. The two different output file formats which are generated by this filter will both be ASCII (human readable) Objectives Reinforce knowledge of binary arithmetic and the hexadecimal numbering system Reinforce knowledge of File I/O (both ASCII and binary) in programming-using actual files as well as STDIN and STDOUT Practice writing a utility that can use command-shell redirecting and/or piping Practice writing a utility that requires and uses command-line arguments NOTE: You may work on this assignment with a partner if you wish. Because encodeInput uses run-time switches, this program does not need to prompt the end user for any other kinds of input. Instead, if written correctly, the end user will be able to redirect or pipe textual data into the application in place of using a file! Although it probably doesn't need to be said the only way that encodeInput should allow an input stream to end is when it reaches the end-of-file. That is, if you are running encodeInput and reading from a file, obviously the input ends when it reaches the end-of-file. Similarly when you are running the utility interactively and are entering input via the keyboard, the input ends when it reaches the end-of-file - not an ENTER key, and not any other special character sequence - just an end-of-file. What you need to do is to simulate an end-of-file from the keyboard - this is done by entering a CTRL-D (pressing the CONTROL key and the D key simultaneously). Please note that CTRL-D only works to end the file when entered at the beginning of the input line-if it is not the first character of the input, then CTRL D serves to flush (or push) the data ahead of it into the program. For example, assume the "D" in the following examples represents when I press CTRL-D and "E" is when I hit enter - so if you enter "123D, the CTRL-D simply causes the program to read "123". But if my input is "123ED" - then the CTRL-D is the first character of an input line (because it follows an ENTER) - so this will be interpreted as an EOF character in your program. Some examples of valid command lines: encode Input -imyData , dat myData, Bret -Bret The above will convert myData.dat to myData.Srec as an S-Record file encode Input -h The above will output help (usage statement) information and exit encodeInput -omyData.asm The above will convert standard input into myData.asm as an assembly file encodeInputsrecimybata.dat The above will convert data from myData.dat into myData.dat.srec as an S-Record file encodeInput