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
In the RTX51 Tiny applications I've written, I do all of the hardware initialization in task 0 (which is called first). I disable interrupts while I do this. Then, I re-enable interrupts and call the os_create_task to create all of my remaining tasks. Jon
Yes, I can see where it can be a matter of technique. I've never used RTX before my current stint and I guess I'm just not that accustomed to giving up control of EA :o)
I'm just not that accustomed to giving up control of EA The moment you decide to use a URTOS, you give up that control. You can't have it both ways. Erik
The moment you decide to use a URTOS, you give up that control. You can't have it both ways. Yep. That's pretty much the way it is with all RTOS. Jon
The moment you decide to use a URTOS, you give up that control. Correction: The moment someone else decided to us a URTOS, they took that control away from me. >:(
The moment you decide to use a URTOS, you give up that control. Correction: The moment someone else decided to us a URTOS, they took that control away from me. If you were told to us a URTOS, then yoiur "correction" is correct. If your statement tries to blame the maker of the URTOS then blatantly incorrect. There is no way anyone can make something that uses interrupts and truly state "you can do with interrupts whatevere you want, it does not affect me". "truly" in bold, because I have seen that lie. Erik