Error In esos_pic24_rs232.c?

[DaveP]

While trying to figure out the IRQ priorities assigned by ESOS for
system services such as tick and comm, I found the following:

from esos_pic24_rs232.c:
119 _U1RXIP = __ESOS_UART1_RX_INTERRUPT_PRIORITY; //choose a
priority
124 _U1RXIP = __ESOS_UART1_TX_INTERRUPT_PRIORITY; //choose a
priority

from esos_pic24_rs232.h:
50 #define __ESOS_UART1_TX_INTERRUPT_PRIORITY 5
51 #define __ESOS_UART1_RX_INTERRUPT_PRIORITY 5

Consequently, _URTXIP never get changed from the default value of 4.
I doubt that this is the intention.

Also, it seems that a nice thing to include in the documentation these
and other assigned priorities. While writing my own ISR, I was
surprised to find the T1 ISR breaking in and taking nearly 100
instruction cycles to complete. Why this was became clear after
spending some time looking over the code. It can be argued that this
serves the purpose of the instructor to educate me on the inner
workings of ESOS. Well done! Unfortunately, my memory being as it
is, I expect to find myself, in the future, on this same path. To
help avoid this, I did make notes in my book copy. Still, your html
documentation would be another great place to locate this information.

My critical style aside, I do appreciate the help that you guys are
giving.

Regards,

[Dave]

DaveP,

Another thing to watch is converting child task arguments to static.
On page 633 the third bullet reads “User task variables that are
required across any wait or yield statement must be declared static.
If the user task variable is not declared static, the value of the
variable after the wait/yield is unpredictable.”

It isn’t stated anywhere but a similar thing can happen to child task
arguments. The wait/yield mechanism employed by ESOS has the parent
recalled after a wait/yield and the parent recalls the child. If an
argument has changed for any reason, the child will receive the new
value. As I think good practice should not rely on the child knowing
about the parent’s coding, the child generally should copy arguments
to static variables before the first wait/yield to be safe! This was
not done, however, in at least some of the ESOS examples.

[DaveP]

Dave,

You must have been reading my mind. I made this mistake of not
declaring a variable as static. I realized my mistake when I read
your post. The good news is that I've learned a lot about the
simulator. The bad news is that I wasted a lot of time.

One thing still doesn't make sense to me. When I declared the
variable within my task as automatic, the compiler located it above
the stack. During program execution, the stack then occasionally
corrupts the variable. When I declare it as static, however, the
stack is now located above the variable. What confuses me is that I
thought the stack would always be placed above the variable space,
regardless of how it is declared.

Regards,

> > Regards,- Hide quoted text -
>
> - Show quoted text -

[Dave]

DaveP,
There is no standard as to where variables are placed in memory. That
is a detail left to the compiler implementation. Auto variables are
ON, not above, the stack. The stack can grow up like on the PIC24 or
down, another implementation detail. Static variables are at a fixed
address but could be anywhere. The C30 implementation for the PIC24
generally places static variables, then the heap, then the stack. See
chapter 4 of the C30 manual for more details.

And, as there can be multiple instances of a function “running”, there
can be multiple simultaneous instances of it’s auto variables on the
stack at different addresses. They are addressed by relative
displacements from the stack pointer, W15 on the PIC24, or the frame
pointer if used.

> > - Show quoted text -- Hide quoted text -