Pf sc arch

Pf_users; Pf_ui; Pf_study ; pf_arch_overview ; pf_comm_arch ; Pf_sc_arch ; Pf_mc_arch ; Pf_imu_arch ; Pf_defs ; Pf_insects [1]

Root for the SC

ap_main.c:main() : starts off with initialization, and then becomes main loop (primary thread)

• performs hardware and variable initialization, calling many sub functions for initialization
• there is some dormite code that attempted to deduce how the processor got started. Was it the real-time clock start us with its INT?

• enables ISRs (which are defecto prioritizeable threads)

1. At least two ISRs that operate the DMA that move data for the SPI and UARTs
2. Tick timer ISR. Effectively sets a global that says tic. Don't believe does any actual work.

• Sets up the 'background' 'task'
• Starts what appears to be a thread, but is really only telling a hard-code task 'scheduler' to run the function 'demux_statemachine' every 2 MS (assuming the tic timer supports it.)
  • TKRTTIMER_CONFIG_TASK_M(TKRTTIMER_APP_TASK,TKRTTIMER_TWO_MSEC, demux_statemachine
• Just before the main loop (while 1) is a dormant attempt to run the SM in a separate thread.

• ultimately gets to the main loop (while 1) of the code. This is the primary thread and though a maze of function calls, ends up doing ALL work. Although it appears to have only 2 functions : through nicely obfuscated coding, other functions get called.
  • execute_cmd_rsp (lives on last page of ap_main.c)
    • see below for details
  • TKRTTIMER_BACKGROUND_M(); (lives in infrastructure\tk_rttimer.c)
    • does 'task' 'scheduling' which all occur in the foreground.
    • toggles LEDs
    • calls demux_statemachine() (live in demux_statemachine.c)
    • don't believe that any of the other things hard-code in this function are used.
    • don't believe that the "UTIL TASK" exists.

main loop next level of detail

At the next highest level we can say following actions are done in the main loop:

• execute_cmd_rsp (see last page of ap_main.)
  • difficult to explain as functions convoluted and are misnamed . However over all this code block deals with the MPD command / response protocol. At the highest level, much of the work is done in sc_tk_cmdpr.c and infrastructure/tk_cmdset.c
    • Gets 'messages' from buffers (either locally or from the FUP),
    • Routes /forwards messages to MC/IMU,
    • Processes locally bound messages (command execution). MAJOR problem w/read real time clock, EEPROM
      • the file sc_tk_cmdpr.c processes these messages for
    • Passes back "answers" from the IMU/MC,
    • Answers requests to commands that were locally bound (executed)
      • Only the SC(both locally and via its FUP) can initiate messages that are executed on another processor (MC, IMU);
  • This block of code is the primary problem with the system - as communications and command execution interfere with the time operation of the SM
    • We need to be able to send/route messages asynchronous to the 2ms SM cycle
    • Thus the fast executing simple routing functions needs to be in a thread at a HIGHER level than the SM
    • This would allow passing of multiple messages per SM cycle, and thus allow the SM to initiate several messages per cycle, and thus allow it to know that its messages were processed remotely. (eg did the MC actually execute the set_current_limits command?)
    • The actual execution of most of the messages would occur at various levels below the SM. Some actions may take longer then a SM cycle.

• from TKRTTIMER_BACKGROUND_M, demux statemachine (DMXSM) is called.
  • DMXSM is my effort to remove un-related support from the primary statemachine.
    • this loop contains a few actions before and after the SM that are nearly always run
      • imu_recv_rsp() - seems to get the answer to the last command send to the IMU
      • motor_command_start_of_process() - get the answer to the last command send to the IMU
      • read_sensors() (read_sensors.c) - read the local sensors, and exact sensor info from the MC response
      • at the end - if no commands have been sent, then send the default commands to the IMU and MC
    • during the boot up phase, DMXSM advances though states that read tables, bring up the local sensors, and gets the MC going
    • When initialization is complete, DMXSM sits in state 6 "RUN_TIME" forever.
      • alt_serial_process() : Reads from stdin (which **ultimately** is the PC keyboard) and allowed for real time adjustment of parameters.
      • w*******_statemachine() : state transitions for what we're all about
      • alt_serial_debug() : lots of printf statements that whos action is distributed over 128 SM cycles.