| 전자부품 데이터시트 검색엔진 |
|
AP0100CS 데이터시트(PDF) 51 Page - ON Semiconductor |
|
|
|||||||||||||||||||||||||||||
AP0100CS 데이터시트(HTML) 51 Page - ON Semiconductor |
|
51 / 73 page ![]() AP0100CS/D Rev. 6, Pub. 1/16 EN 51 ©Semiconductor Components Industries, LLC,2016. AP0100CS HDR: Image Signal Processor (ISP) Host Command Interface If the host wishes to determine the outcome of the command, it must poll the Command Register waiting for the doorbell bit to become cleared. This indicates that the firmware completed processing the command. The contents of the Command Register indicate the command’s result status. If the command generated response parameters, the host can now retrieve these from the Parameters Pool. The host must not write to the Parameters Pool, nor issue another command, until the previous command completes. This is true even if the host does not care about the result of the previous command. It is strongly recommended that the host tests that the door- bell bit is clear before issuing a command. Synchronous Command Flow The typical ‘flow’ for synchronous commands is: 1. The host issues a ‘request’ command to perform an operation. 2. The registered command handler is invoked, validates the command parameters, then performs the operation. The handler returns the command result status to indi- cate the result of the operation. 3. The host retrieves the command result value, and any associated command response parameters. Asynchronous Command Flow The typical ‘flow’ for asynchronous commands is: 1. The host issues a ‘request’ command to start an operation. 2. The registered command handler is invoked, validates and copies the command parameters, then signals a separate task to perform the operation. The handler returns the ENOERR return value to indicate the command was acceptable and is in progress. 3. The host retrieves the command return value – if it is not ENOERR the host knows that the command was not accepted and is not in progress. 4. Subsequently, the host issues an appropriate ‘get status’ command to both poll whether the command has completed, and if so, retrieve any associated response parameters. 5. The registered command handler is invoked, determines the state of the command (via shared variables with the processing task), and returns either ‘EBUSY’ to indicate the command is still in progress, or it returns the result status of the command. 6. The host must re-issue the ‘get status’ command until it does not receive the EBUSY response. Asynchronous commands exist to allow the Host to issue multiple commands to the various subsystems without having to wait for each command to complete. This prevents the host command interface from being blocked by a long-running command. Therefore, each asynchronous command has a “Get Status” (or similar) command to allow the Host to determine when the asynchronous command completes. |
|
링크 URL |
| ALLDATASHEET 가 귀하에 도움이 되셨나요? [ DONATE ] |
Alldatasheet는? | 광고문의 | 운영자에게 연락하기 | 개인정보취급방침 | 링크 투 데이터시트 | 링크교환 | 제조사별 검색 All Rights Reserved©Alldatasheet.com |
| Russian : Alldatasheetru.com | Korean : Alldatasheet.co.kr | Spanish : Alldatasheet.es | French : Alldatasheet.fr | Italian : Alldatasheetit.com Portuguese : Alldatasheetpt.com | Polish : Alldatasheet.pl | Vietnamese : Alldatasheet.vn Indian : Alldatasheet.in | Mexican : Alldatasheet.com.mx | British : Alldatasheet.co.uk | New Zealand : Alldatasheet.co.nz |
|
Family Site : ic2ic.com |
icmetro.com |