#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2013
    Posts
    2
    Rep Power
    0

    C Programming HELP PLEASE


    I am new to C Programming and I am in University and I have been asked to produce a real time system as shown below. But I have no idea how to get started I just need help to get it up and running, just to get an idea how to start. I donít want the assignment done for me just how to implement the start. I would be thank full for any help thank you


    TASK
    You are required to write an ANSI C program which is a simple 68hc11 line assembler. The program should accept a user defined text file and create a S19 download file. The format of the data file should be in-line with the standards adopted by the free 68hc11 assembler, but initially the program is to be a simple one pass assembler i.e. no labels to be used. Due to the complexity of the 68hc11 instruction set , the basic assignment with restrict itself to a pre-defined number of instructions with extra marks awarded in a extension activity to produce a full 2 pass assembler with full instructions.

    Basic instructions to be assembled

    lda
    sta
    add,sub
    bcc,beq,bne
    cmp
    lsr,lsl,rol

    Basic Assembler directives

    name
    org
    end
    # and $

    As a help overleaf is shown the manual assembly of a simple instruction

    Program
    name test
    org $500
    ldaa #$20
    end

    Start address is 500 hex

    Instruction is ldaa with immediate addressing mode # and data 20 hex
    ldaa #-> 86 data = 20
    Final program
    Address data
    500 86
    501 20
    Translate to S19 file format
    S105050086204F
    S9030000FC
    Attached is the Instruction set and the Motorola S19 standard
    Motorola 68Hc11 instruction set





    S19 File Format - as it pertains to 68HC11 AS11 output.
    The format of the .s19 file generated by AS11.EXE, and read into PCBUG11 for programming the 68HC11, is detailed here.

    General Description:

    The .s19 file is a file consisting of readable characters in the set of {S,0-9,A-F}. The file contains addresses and byte-information to be located in memory starting from the addresses. Addresses are specified by 4, 6, or 8 character HEX strings, and bytes are specified by 2-character HEX strings.

    Details:

     All leading white-space on each line is ignored.
     The first 4 characters in each line of the file contain:
    o the character 'S',
    o a single-digit code {1-9},
    o and a 2-character number indicating the number of bytes in the line.

     The last 2 characters in a line are a checksum.
     The remaining characters in the line are 2-character data bytes.

     The end-of-line characters in the file can be either '\n' or '\r' (0x0A or 0x0D), or both.
    Note: Each line MUST start with an 'S' character.
    Line-Codes

    The following codes are known:
     1 - characters 5- 8 in the line specify a 16-bit address.
     2 - characters 5-10 in the line specify a 24-bit address.
     3 - characters 5-12 in the line specify a 32-bit address.
     7, 8, 9 - end of file. A checksum follows but if generally ignored.

    The data bytes are character-pairs which are the byte data in HEX to be located in memory starting at the specified address
    Example
    For example, the following assembly code generates the following .s19 data:
    :::example.asm
    ORG $B600 ; Start of EEPROM
    jsr Init_4_Servos
    ldd #$0800 ; Servo middle position
    std $1018 ; Initial setting for servo 0
    std $101a ; Initial setting for servo 1
    std $101c ; Initial setting for servo 2
    std $101e ; Initial setting for servo 3
    jsr Init_SPI
    ldd #$0002
    std SPI_POINTER
    clr SPI_DATA+4
    clr COUNT
    Loop:
    ldaa COUNT
    staa $1004 ; port B
    brclr SPI_DATA+4 $FF Loop ; Wait for 5th SPI byte
    [snip]
    :::example.s19
    S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
    S123B6209610B710041306FFF7CC0002DD007F0006DC021A83AA5526E7D6049605B710048F
    S123B6405818CE1018183A164F050505050518ED0020CD363CCE10008655A7208678A70C1B
    S123B660A70D383239FEB680DFC7B6B68297C986AAB710048604B7100986C4B710280E3972
    S123B6807EB6837C0010CE100018DE001F2980FCB6102A188C0002260481AA260618A700F5
    S107B6A07C00013BEA
    S9030000FC
    Looking at the first line:
    Start of Line:
    The line starts with an 'S'.
    S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
    Command:
    The second character on the line is the command, in this case a '1':
    S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
    This means that the address will be a 2-byte (4-character) address.
    Line Length:
    The third and fourth characters on the line are the number of character pairs (bytes) on the line, including the address:
    S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
    In this line this is a 23 (a HEX 23), which is 35 in decimal.
    Address:
    The next section on the line is the address, the length of which is specified by the command character:
    S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
    B600 This 4-character (2-byte) address is a HEX $B600, the start of the EEPROM in a 68HC11E1.
    Check-Sum:
    The last 2 characters are a 1-byte check-sum for the line. The check-sum is calculated by summing, in HEX, all of the 2-character bytes on the line starting wit the third and fourth characters (the length byte), and running up to the check-sum byte. This resulting number is truncated to a number in the range of 0 to 255 (anded with 0x00FF), and then complemented. This result is the line's checksum.
    S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
    For this line, starting with the "23" and summing through the "10", the sum is 0xCAA. Truncating we get 0xAA, and complementing we get 0x55, the 55 as seen at the end of the line.
    Data-Bytes:
    The character-pairs between the address and the end-of-the-line checksum are the data-bytes:
    S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
    These bytes will be placed sequentially in memory starting with the specified address. In this line, the first data-byte is BD, which is the machine-code for the JSR line of the code, will be placed in memory at address $B600. The next 2 bytes, B653, is the machine-code of the address the jump will take, the location of the Init_4_Servos subroutine, and will be places in memory locations $B601 and $B602; and so on.
    Note that even when the data spans more than 32 sequential bytes in memory, a maximum of 32 data bytes is used. The data is continued on the next line in the file, with the address being specified ($B620 in our example). This is redundant, but allows each line in the .s19 file to completely specify the address and the data.
    End-Of-File:
    The last line in this example .s19 file shows the end-of-file specifier.
    S9030000FC
    The end-of-file command is a '9' (and as specified in Randy's code, a '7' or an '8' may also be specified).
    The next 2 characters are the line-length byte, 3 bytes in this case:
    S9030000FC
    The final 2 bytes are the start address of the program
  2. #2
  3. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Simply divide and conquer. A huge task is composed of a number of large tasks, each of which is smaller than the original task and each of which is itself composed of even smaller tasks, and so on. Finally, you get down to small tasks, each of which is easy to do.

    Also, you can take an iterative approach. Get an easier version of the program running and then add features. Or to put it another way, identify the basic component parts (eg, source file input, source code line parsing, mnemonic identification, source code line translation, etc). Then start working on individual components. A benefit of this, besides divide-and-conquer, is that you can test each component part as you go. If you tried to write the entire project all at once and then attempt to test it whole, when it failed to work you wouldn't know where to start looking. Get opening a source file and reading it working first, then you'd know that that part works. Add on reading a line at time and processing that line and test that and make sure that it works.

    Similarly, if you write a function, then test that function by itself. Write a simple test driver (a short program in which main calls that function and displays what the function outputs) for each function, feeding it both valid and invalid arguments so that you can verify that it handles them correctly. You also need to feed it "boundary conditions" (eg, values towards the minimum and maximum extremes allowed) in order to verify that it handles them correctly; eg, in developing a linked list, then boundary conditions would be adding to an empty list, to a list with one or two nodes, etc.

    Most students are "code pigs". They just want to jump in and start coding immediately. Rather, you need to work on design first and then start coding after you have to design worked out; otherwise you will have many false starts and be doing a lot of rewriting during with you will overlook a couple bits of old code that will be next to impossible to find and correct later. Having the design worked out before you code will give you a clear vision of what the code needs to do, which will result in cleaner code and far less confusion. Of course, while you are doing the design you can also do some coding to test out parts of the design, but getting the design done is the important phase prior to serious coding.


    Another philosophy of overall design that I was taught was to start with the output, learn what inputs you will be given, and then figure out what processing those inputs will need to generate that output.

    Yet another design approach would be to create a data-flow chart. You identify the data coming in and what format it's in and the data being output and what format it's in. Then you fill in the middle with what kinds of processing will need to occur and what intermediate data structures you'd be producing, keeping in mind that each stage of processing will read in one format of data and will output another format which will be the input of the next stage. This approach is also amenable to divide-and-conquer and to component testing (ie, you can create small blocks of test data to feed into a stage of processing so that you can verify that it outputs the correct format -- that final output stage would be an excellent first candidate).


    Nor are these ideas mutually exclusive. Just don't let the size of the overall project faze you. Chip away at it one piece at a time. An immense journey is taken one step at a time. And an entire mountain can be moved one rock at a time.
    Last edited by dwise1_aol; April 9th, 2013 at 03:51 PM.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2013
    Posts
    2
    Rep Power
    0
    Originally Posted by dwise1_aol
    Simply divide and conquer. A huge task is composed of a number of large tasks, each of which is smaller than the original task and each of which is itself composed of even smaller tasks, and so on. Finally, you get down to small tasks, each of which is easy to do.

    Also, you can take an iterative approach. Get an easier version of the program running and then add features. Or to put it another way, identify the basic component parts (eg, source file input, source code line parsing, mnemonic identification, source code line translation, etc). Then start working on individual components. A benefit of this, besides divide-and-conquer, is that you can test each component part as you go. If you tried to write the entire project all at once and then attempt to test it whole, when it failed to work you wouldn't know where to start looking. Get opening a source file and reading it working first, then you'd know that that part works. Add on reading a line at time and processing that line and test that and make sure that it works.

    Similarly, if you write a function, then test that function by itself. Write a simple test driver (a short program in which main calls that function and displays what the function outputs) for each function, feeding it both valid and invalid arguments so that you can verify that it handles them correctly. You also need to feed it "boundary conditions" (eg, values towards the minimum and maximum extremes allowed) in order to verify that it handles them correctly; eg, in developing a linked list, then boundary conditions would be adding to an empty list, to a list with one or two nodes, etc.

    Most students are "code pigs". They just want to jump in and start coding immediately. Rather, you need to work on design first and then start coding after you have to design worked out; otherwise you will have many false starts and be doing a lot of rewriting during with you will overlook a couple bits of old code that will be next to impossible to find and correct later. Having the design worked out before you code will give you a clear vision of what the code needs to do, which will result in cleaner code and far less confusion. Of course, while you are doing the design you can also do some coding to test out parts of the design, but getting the design done is the important phase prior to serious coding.


    Another philosophy of overall design that I was taught was to start with the output, learn what inputs you will be given, and then figure out what processing those inputs will need to generate that output.

    Yet another design approach would be to create a data-flow chart. You identify the data coming in and what format it's in and the data being output and what format it's in. Then you fill in the middle with what kinds of processing will need to occur and what intermediate data structures you'd be producing, keeping in mind that each stage of processing will read in one format of data and will output another format which will be the input of the next stage. This approach is also amenable to divide-and-conquer and to component testing (ie, you can create small blocks of test data to feed into a stage of processing so that you can verify that it outputs the correct format -- that final output stage would be an excellent first candidate).


    Nor are these ideas mutually exclusive. Just don't let the size of the overall project faze you. Chip away at it one piece at a time. An immense journey is taken one step at a time. And an entire mountain can be moved one rock at a time.


    Thank you very much that helped a lot.
    I have taken you advice about making a program to read from a file and display it.
    Can you suggest a simple program that would read the following data (ldaa)
    ldaa =

    # = immediate data
    $ = Hexadecimal
    I mean how can I allocate each on so that when my program reads them it know what they are and what they mean.
    I don't know if I explained it properly, I don't know if you know what I mean.
    if it too much of a bother thank you anyways you have helped a lot.
  6. #4
  7. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    I'm not familiar with that assembly instruction set and its mnemonics, so I assume that ldaa (AKA "LDAA") is one mnemonic.

    This would be a stage that would take one line on input and parse it. Don't worry, that's a lot easier than it sounds. In fact, you can apply the manual method almost directly.

    One thing that makes assembly easier is that generally each line of source code represents one single instruction, so you can process it line-by-line. And each line has a specific syntax (rendered here off the top of my head, plus it's possible that your assembly language's syntax is slightly different):
    [<label:>][<space><instruction mnemonic><space><operand(s)>][<space><comment>]
    So, read in a single line of source.
    Find the first word by skiping spaces and tabs until you hit a letter, then find the end of that word by finding a colon or a space or a newline or a start-comment (semicolon).
    If that first word ended with a colon, then it's a label; store its name and its location.
    Otherwise, it must be a mnemonic, so look up the instruction code. This means that you will have to have created a table of instruction mnemonics associated with their instruction code. You also need to be sensitive to case, since C is; converting all input to either upper or lower case for internal processing would be advisable.
    Keep scanning the line to read in the operands and process them.

    There's a C function called strtok that might help tokenize each line. In order to do that, you need to know what a delimiter is; look it up if you need to. Or you could just step through the input line character by character and process it that way, copying each component of the line to a string so that you can process the line after you have copied out each part of it.

    Have you learned about finite-state machines ("fsm", AKA "finite-state automata", "fsa")? If so, then you could sketch out an fsm for parsing an input line and then implement it with a switch statement. If you haven't learned about that yet, then forget this for now; it's a very useful programming tool, but you need to understand what an fsm is first.

    Now, this translation process is an ideal candidate for splitting off and developing and testing separately.

    PS
    If you scan the input line manually, you may find functions in string.h and in ctype.h useful. Such as strchr(), isalpha(), isspace().

    Also, when you add in label support for the assembly source, you will need to maintain a location counter that keeps track of where the label is. This location counter will be initialized by the ORG statement (which you will need to input, parse, and handle) and it will be incremented by the number of bytes that each line translates into.
    Last edited by dwise1_aol; April 10th, 2013 at 02:48 PM.

IMN logo majestic logo threadwatch logo seochat tools logo