Re: CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT

[Gary Thomas <gary at mlbassoc dot com>]

On Fri, 2004-09-03 at 09:09, Bart Veer wrote:
> >>>>> "Jani" == Jani Monoses <jani@iv.ro> writes:
> 
>     Jani> Hello 
>     Jani> are there any platforms not implementing virtual vectors?
>     Jani> How long is non VV code planned to be supported?
> 
> What code in particular are you concerned about? I am not sure if
> there any interesting platforms left where virtual vectors are
> completely unsupported. However there are certainly platforms where
> you may want to disable the virtual vector support.
> 
> On some systems the application will boot directly from ROM, and
> with no RedBoot in the system there is no point in enabling virtual
> vectors. Booting directly from the ROM means that you can keep down
> the hardware costs, although it may also mean that some of the
> development has to happen on special boards with extra memory.
> 
> An important subset are systems where there is just not enough memory
> for both RedBoot and an application. For example there are chips like
> the MCF5282 with 512K on-chip flash and 64K on-chip RAM, and some
> people want the application to run in just those two areas of memory
> so that the boards don't have to be populated with any external memory
> at all. Fitting just an application into the internal memory can prove
> tricky. If you need a ROM monitor as well it becomes impossible.
> 
> Another example is when you are debugging via jtag or BDM. Even if
> there is a ROM monitor programmed into flash as well it won't get a
> chance to execute, so the application must run without virtual
> vectors.

I disagree.  I think that the virtual vectors are useful in all 
environments, even totally self-contained ones like your ROM example.
By abstracting these operations [console I/O, delay timers, etc],
applications (and even the kernel itself) are simplified.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates