As Weddington, Eric wrote:
> > . Peter Danneggers suggestion to call (rather than jump to) the
> > default handler, and then pop the topmost two (or three for
> > avr6) bytes off the stack has some merit.
> I'm sorry, I must have missed this. Why does this have merit?
The default handler can
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, December 19, 2007 2:52 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti'
As Weddington, Eric wrote:
> > I won't touch the default handler right now.
>
> Why not?
After some thorough thinking about it, I decided to leave it alone
right now. After all, there has to be a reason to eventually roll a
1.8 release some day. ;-)
Random thoughts:
. Peter Danneggers suggest
As Weddington, Eric wrote:
> > I won't touch the default handler right now.
>
> Why not?
Too much verification work required to ensure nothing is broken.
But you've got a point: changing the default handler's behaviour is
something that would better be in 1.6.0 rather than getting it later
into
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, December 18, 2007 3:35 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a
>
As Weddington, Eric wrote:
> Agreed on all. Default handler jumps to abort, abort (and exit)
> disables interrupts. I'm ok with it going into 1.6.0, as long as it
> doesn't materially delay the release.
I won't touch the default handler right now.
abort() calls exit() now, so no change was need
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, December 18, 2007 8:19 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a
>
As Weddington, Eric wrote:
> Regarding the discussion: First, is it an error to not have a
> handler for an enabled interrupt? I would think yes.
I agree.
> If the default is just to return, then I would agree that that does
> not really let the user know of the error. It can get too easily
> lo
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Monday, December 17, 2007 3:57 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a
> d
> > Not always safe - if interrupt is level triggered, and remains
> > active, the main program will be interrupted again and again...
> > This will make the main program run much slower (interrupt and
> > "reti" after every instruction), but work fine otherwise - so
> > it may be difficult to noti
> -Original Message-
> From: Marek Michalkiewicz [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 16, 2007 4:45 PM
> To: Weddington, Eric
> Cc: Dmitry K.; avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a
> defaul
On Sun, Dec 16, 2007 at 04:16:40PM -0700, Weddington, Eric wrote:
> > Now in case of unforeseen interrupt the program is
> > jumped to zero address. As a rule, such behaviour
> > is bad, as it leads to restart program without
> > restarting a MCU's hardware.
> >
> > What about to perform 'reti' i
On Mon, Dec 17, 2007 at 09:09:21AM +1000, Dmitry K. wrote:
> Now in case of unforeseen interrupt the program is
> jumped to zero address. As a rule, such behaviour
> is bad, as it leads to restart program without
> restarting a MCU's hardware.
>
> What about to perform 'reti' in case if the user
>
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Sunday, December 16, 2007 4:09 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] What about to make 'reti' as a
> default behaviour?
>
> Hi.
>
> Now in case of
14 matches
Mail list logo
