Pf sc diag

definitions

• SC/MC = PCB with both the state controller and motor controller processors.

• SC = state controller, generic reference to the SC/MC

• MC = motor controller, generic reference to the motor controller part of the PCB - or the whole motor controller process + power board

• SM, STATEMACHINE : the primary statemachine that doesn't what were here for.

• MC_SM, MOTOR (controller) statemachine, a state machine that runs on the motor controller that does impedance control, and handles overloads, etc.

• ISP = in system programming - connectors / signals that are connected to ICD2 / Real-ice dsPIC programmer
• FUP = field update port, Either of two 9 pin connectors on SC/MC board, uses ASYNC serial to communication without outside world. Also has pins for ISP
• ISR = interrupt service routine

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 eal-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.

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.
    • Gets 'messages' from buffers (either locally or from the FUP),
    • Routes /forwards messages to MC/IMU,
    • Processes message locally (command execution). MAJOR problem w/read real time clock, EEPROM
    • Passes back "answers" from the IMU/MC,
    • Answers requests to commands that we 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.
    • We need to be able to send/route messages asynchronous to the STATEMACHINE (eg SM)
    • Thus the simple routing function needs to be in a thread at a HIGHER level than the SM , and we send messages asynchronous from the state controller, and we need to be