RE: [ECOS] interrupt/virtual vectors confusion

["Matt Sartori" <msartori at hanoverdisplays dot com>]

>-----Original Message-----
>From: Gary Thomas [mailto:gary@mlbassoc.com] 
>Sent: 16 August 2005 15:36
>To: Matt Sartori
>Cc: Andrew Lunn; eCos Discussion
>Subject: RE: [ECOS] interrupt/virtual vectors confusion
>
>On Tue, 2005-08-16 at 15:27 +0100, Matt Sartori wrote:
>> Eeek! But that would mean that Redboot can only properly work as a
>> bootloader for Redboot "enabled" programs. It was my understanding
(and
>> basis for advocating it as a viable alternative to writing our own
>> custom bootloader) that Redboot is able to run any application and
only
>> re-appear when the board is reset.
>
>It absolutely *can* do what you want, but if your hardware does not 
>have an easy way to redirect the VSR handling (where code jumps to when
>an interrupt or exception happens),

Unfortunately I don't think that is the case for my board.

> then you'll have to add some code
>to your HAL to make this work cooperatively.  If that's the case, then
>your application will still have to somehow indicate to RedBoot what it
>wants to do when the interrupt or exception happens.  We're just
talking
>semantic details here - either you invent some mechanism to handle this
>or you run eCos programs (which will also have to have similar 
>mechanisms via the HAL).
>

Indeed. My initial hope was that there was some way of telling Redboot
of a location in RAM where such a table existed. Eg. Interrupt happens,
PC jumps to 0x00000018 which Redboot has set (eg. through a setting when
built) to point to a fixed location in RAM. If that location is
untouched by my app it will, by default, point to Redboot's own ISR,
otherwise, if my app has modified the table, it will point to my app's
ISR. 


>> -----Original Message-----
>> From: Gary Thomas [mailto:gary@mlbassoc.com] 
>> Sent: 16 August 2005 15:18
>> To: Matt Sartori
>> Cc: Andrew Lunn; eCos Discussion
>> Subject: RE: [ECOS] interrupt/virtual vectors confusion
>> 
>> On Tue, 2005-08-16 at 15:06 +0100, Matt Sartori wrote:
>> > >Is Blinky an eCos RAM program? If so it should of taken over the
>> > >interrupt vectors from Redboot. Redboot should no longer be active
>> > >unless blinky actually calls into Redboot via the virtual vectors.
>> > 
>> > Blinky is just a standalone program I decided to use as a test. The
>> only
>> > change I've made to it to make it run is to link it directly into
free
>> > ram so that I can run it after having loaded it from Redboot (with
a
>> > load -r -m ymodem -b 0x20005b68). 
>> > The reason I know that Redboot is handling (or at least that
Redboot
>> > code is being called) the IRQ is that I put while(1){flash an led
>> every
>> > second} at the top of hal_IRQ_handler and that it gets stuck there
>> when
>> > I run Blinky.
>> 
>> Then, this is just as it should be :-)  Unless you make Blinky into
an
>> eCos program, which uses the HAL interrupt mechanisms, RedBoot is
quite
>> happily going to try and handle the interrupt, etc.
>> 
>> -- 
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>> 
>> 
>>
------------------------------------------------------------------------
--------
>> 
>> 
>> The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.
>> 
>> If you received this in error, please contact the sender or
postmaster (postmaster@hanoverdisplays.com) and delete the material from
any computer.
>> 
>> Although we routinely screen for viruses, addressees should check
this e-mail and any attachment for viruses. We make no warranty as to
absence of viruses in this e-mail or any attachments.
>> 
>> Our Company's email policy is to permit incidental personal use. If
this email is of a personal nature, it must not be relied upon as
expressing the views or opinions of the company.
>> 
>> Visit out website at www.hanoverdisplays.com
>> 
>> 
>> 
>-- 
>------------------------------------------------------------
>Gary Thomas                 |  Consulting for the
>MLB Associates              |    Embedded world
>------------------------------------------------------------
>
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss