external interrupt priorities were not being honored. Here is some
of his original report:
using rtems/erc32, I have a problem with interrupt priority when
interrupts occure simultaneously. Erc32 has an interrupt force
register where interrupts can be generated. If more than one
interrupt is generated, the interrupt handlers are scheduled in
the wrong order, i.e. with the lowest priority first.
I have attched a program that generates three interrupts, 0x11, 0x12
and 0x13. Interrupt 0x13 should be handled first, but is actually
handled last. Below is the output from sis:
sis> go
resuming at 0x02000000
RAM size: 4096 K, ROM size: 2048 K
Watchdog disabled
Waitstates = RAM read: 0, RAM write: 0, ROM read: 0, ROM write: 0
Power-down mode enabled
infinite UART baudrate
External interrupt received with vector 0x11
External interrupt received with vector 0x12
External interrupt received with vector 0x13
I have verified that sis generates the interrupts in the correct
order, i.e. 0x13 first, then 0x12 and then 0x11. So the problem
seems to be in the rtems interrupt handler. Do you use the PIL field
in the %psr register to mask lower priority interrupts or are all
external interrupts considered to have the same priority ..?
Here is a description of the fix:
it turned out that lower priority interrupts were not at all masked
off during interrupt handling. I made the following fix to cpu_asm.s:
... fix is in the code ...
There might be a simpler way of doing this, but this works...
Bare BSP is now only enabled when explicitly specified.
Bare BSP options and variables are clearly named so as to be obviously
BSP specific. This should avoid conflicts.
Eric Norum per request from Geoffroy Montel:
> The rtems_termios_enqueue_raw_characters function type is void.
> The problem is that I can't return an error message if the input
> buffer is full.
> Could we add a return value?
Sure, but what would you do with the overflow indication? POSIX says,
``when the input limit is reached, the saved characters are thrown away
without notice''.
Anyhow, the change is so small I've done it and enclosed the patch.
The breakdown:
* CC_FOR_TARGET and CXX_FOR_TARGET were not correctly re-read
from autoconf's configuration cache (config.cache)
* If <target>-[gcc|g++] was not found while running configure,
the config macros tried to use other (wrong) compilers (e.g. cc).
Changes:
* New RTEMS_PROG_CC macro (aclocal/prog-cc.m4).
* New RTEMS_PROG_CXX macro (aclocal/prog-cxx.m4)
* Moved a shell script fragment from configure.in to a
new m4-autoconf macro (New file: aclocal/tool-prefix.m4)
* Minor changes to configure.in
I tested it with linux/posix (native gcc/primary libc) and
sh-rtems/gensh1 on a linux host and didn't notice any bugs
related to the problems mentioned above. There seem to be
more bugs with the posix bsp, but I consider them minor as
the build run completed successfully. It is just too late
for me to attempt to fix them now.
