Difference between revisions of "Pf sc diag"
From DIDEAS Wiki
m |
m (→Root for the SC) |
||
| Line 18: | Line 18: | ||
==ap_main.c:main() : starts off with initialization, and then becomes main loop (primary thread) == | ==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 | *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) | *enables ISRs (which are defecto prioritizeable threads) | ||
# At least two ISRs that operate the DMA that move data for the SPI and UARTs | # At least two ISRs that operate the DMA that move data for the SPI and UARTs | ||
# Tick timer ISR. Effectively sets a global that says tic. Don't believe does any actual work. | # 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 of the code | + | * ultimately gets to the main loop (while 1) of the code. |
| − | This is the primary thread that does ALL the work. Although it appears to have only 2 functions : through nicely obfuscated coding, other functions get called. | + | * This is the primary thread that does ALL the 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: | 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.) | * 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. | ** 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), | + | *** Gets 'messages' from buffers (either locally or from the FUP), |
*** Routes /forwards messages to MC/IMU, | *** Routes /forwards messages to MC/IMU, | ||
*** Processes message locally (command execution). MAJOR problem w/read real time clock, EEPROM | *** Processes message locally (command execution). MAJOR problem w/read real time clock, EEPROM | ||
| Line 37: | Line 42: | ||
** This block of code is the primary problem with the system. | ** This block of code is the primary problem with the system. | ||
| − | *** We need to be able to send/route messages | + | *** 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 | *** 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 | ||
Revision as of 21:05, 24 October 2009
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)
- At least two ISRs that operate the DMA that move data for the SPI and UARTs
- 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 that does ALL the 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);
- difficult to explain as functions convoluted and are misnamed . However over all this code block deals with the MPD command / response protocol.
- 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
- This block of code is the primary problem with the system.
