This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What assumption does this code make? Is it acceptable?

This is a snippet from a general-purpose library function that is (effectively) non-application specific and, by design, can make no assumptions about the context of the calling process.

Hint: The assumption the code makes has to do with interrupts. Do you see a problem?

_GenericFunctionA:
    MOV   A, R7
    RL    A
    ADD   A, #array_base
    MOV   R0, A
    CLR   EA
    MOV   A, @R0
    JNB   ACC.BIT_X, ?C0026
    JNB   ACC.BIT_Y, ?C0026
    SETB  ACC.BIT_Z
?C0026:
    SETB  ACC.BIT_N
    XCH   A, @R0
    SETB  EA
    JB    ACC.BIT_N, ?C0027
    MOV   R7, #0
    RET
?C0027:
    MOV   R7, #1
    RET

Parents
  • In nearly ALL program startup cases, I don't want interrupts enabled until everything is set up and ready to run. This includes module initialization as well as task instantiation. The last thing you do is hit the "let-er-rip" which basically does the final EA. Its a way to ensure that all cooperative operations wait until everything's ready to go.

    That the os_create_task forces interrupts to be set basically states that I can't write a driver that completely encapsulates all related hardware initialization...namely particular interrupts associated with that hardware. Instead, I have to put a note somewhere that says, "Oh, BTW, you have to add a separate line to actually enable this driver's interrupt AFTER any calls to os_create_task"...and hope the user reads it.

    None of this would be a problem if the the RTX code used the method your first reply illustrated.

Reply
  • In nearly ALL program startup cases, I don't want interrupts enabled until everything is set up and ready to run. This includes module initialization as well as task instantiation. The last thing you do is hit the "let-er-rip" which basically does the final EA. Its a way to ensure that all cooperative operations wait until everything's ready to go.

    That the os_create_task forces interrupts to be set basically states that I can't write a driver that completely encapsulates all related hardware initialization...namely particular interrupts associated with that hardware. Instead, I have to put a note somewhere that says, "Oh, BTW, you have to add a separate line to actually enable this driver's interrupt AFTER any calls to os_create_task"...and hope the user reads it.

    None of this would be a problem if the the RTX code used the method your first reply illustrated.

Children