Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

[Weddington, Eric]

Hi Cynthia,

[Be sure to "Reply All", and keep the avr-libc-dev mailing list in the CC 
section when replying.]

You may have quicker success with using avrtest, but do keep simulavr "on the 
back burner".

I (and probably others here too) will be interested in your progress! :-)

Eric

> -----Original Message-----
> From: Cynthia Rempel [mailto:address@hidden
> Sent: Tuesday, January 01, 2013 2:44 PM
> To: Weddington, Eric; address@hidden
> Subject: Porting RTEMS patches to avr-libc
> 
> Hi Eric,
> 
> Thanks for the fast response!
> 
> Now that I know simulAVR may be a desirable target, I'll keep
> researching the feasibility of running RTEMS on simulAVR then.
> 
> Depending on the feed-back, we'll look into porting to the head until
> there is an 1.8.1 release...
> 
> Most of RTEMS uses newlib as it's C library... It appears that avr-
> libc/include/avr and rtems/cpukit/score/cpu/avr/avr have VERY similar
> files. Figuring out what white space is important will be an
> interesting challenge, the patch addresses all the differences aside
> from white space and comments in those two directories...
> 
> The other folder with avr specific support is: c/src/lib/libbsp/avr it
> appears there are some files written by the AVR community in there as
> well, and so differences there will need to be identified.
> 
> As there is less than a handful of rtems specific bugs, I could look at
> them (no guarantee we could fix them :)... Thanks for the suggestion!
> 
> Cynthia Rempel
> 
> ________________________________________
> From: Weddington, Eric address@hidden
> Sent: Tuesday, January 01, 2013 10:31 AM
> To: Cynthia Rempel; address@hidden
> Cc: address@hidden
> Subject: RE: Porting RTEMS patches to avr-libc
> 
> Hi Cynthia, Joel!
> 
> Happy New Year to you both! (We just got done watching the Rose Parade.
> ;-)
> 
> I've added the avr-libc-dev mailing list on this email, so the other
> developers are aware of this and can comment.
> 
> First, I think it's great that you're working on this, and I'm all for
> having RTEMS synced with avr-libc, as much as is feasible.
> 
> The current release of avr-libc is 1.8.0, though we've been discussing
> recently about fixing a bunch of bugs on HEAD for a future 1.8.1
> release. So, I would definitely suggest taking a look at porting 1.8.0,
> or even better making sure that it works with HEAD.
> 
> Avrtest is what is being used to test with the GCC testsuite. Although
> I thought some work was also being done with simulAVR to make it work
> with the GCC testsuite (perhaps someone else on this list can confirm
> or correct me if I'm wrong).
> 
> Additional recommendations: IIRC, there are some specific GCC bugs that
> are avr-rtems specific (though less than a handful). Eventually, you,
> or someone else on the RTEMS team, may want to take a look at those.
> 
> Joel and I have talked off and on over the years, and as I understood
> it, RTEMS was using newlib for its C library. Does RTEMS now use avr-
> libc? Or just a portion of avr-libc?
> 
> If RTEMS will be using avr-libc on a more permanent basis for the
> future, then perhaps we'll want to make sure that we coordinate
> testing, bug fixing, etc.
> 
> @Joel: I'm curious, do you know of any commercial uses of RTEMS on the
> AVR (that you can mention)? (You can send that to me privately if you
> need to.)
> 
> HTH,
> Eric Weddington
> 
> 
> > -----Original Message-----
> > From: Cynthia Rempel [mailto:address@hidden
> > Sent: Tuesday, January 01, 2013 10:43 AM
> > To: address@hidden; Weddington, Eric
> > Subject: Porting RTEMS patches to avr-libc
> >
> > Hi Eric Weddington,
> >
> > Happy New Year!
> >
> > I'm looking at helping with updating the avr port of RTEMS, and came
> > across some of the differences between the RTEMS avr-libc and avr-
> libc-
> > 1.6.8 (the version that is currently in RTEMS).  I went ahead and
> used
> > subversion to generate a patch for avr-libc that should provide some
> of
> > the same functionality that is in RTEMS avr-libc. There are only
> three
> > for the subversion version of interrupt.h, because one of the changes
> > appears to already have been applied. It appears that Ralf Corsepius
> > address@hidden made the changes to the RTEMS tree on 2011-
> 02-
> > 11...
> >
> > I do have some questions though:
> > Should we still use the avrtest, as opposed to another simulator,
> such
> > as simulAVR?
> > Should we look at porting avr-libc 1.8.0, or should we look to port
> > another version of avr-libc to RTEMS?
> > Do you have any additional recommendations / hints for updating the
> > RTEMS AVR port?
> >
> > Thanks!
> > Cynthia Rempel
> >
> >
> > Index: interrupt.h
> > ===================================================================
> > --- interrupt.h (revision 2303)
> > +++ interrupt.h (working copy)
> > @@ -228,21 +228,21 @@
> >  #  if defined(__AVR_MEGA__) && __AVR_MEGA__
> >  #    define ISR_ALIAS(vector, tgt) extern "C" void vector (void) \
> >         __attribute__((signal, naked, __INTR_ATTRS)); \
> > -       void vector (void) { asm volatile ("jmp " __STRINGIFY(tgt)
> ::);
> > }
> > +       void vector (void) { __asm__ volatile ("jmp "
> __STRINGIFY(tgt)
> > ::); }
> >  #  else /* !__AVR_MEGA */
> >  #    define ISR_ALIAS(vector, tgt) extern "C" void vector (void) \
> >         __attribute__((signal, naked, __INTR_ATTRS)); \
> > -       void vector (void) { asm volatile ("rjmp " __STRINGIFY(tgt)
> > ::); }
> > +       void vector (void) { __asm__ volatile ("rjmp "
> __STRINGIFY(tgt)
> > ::); }
> >  #  endif  /* __AVR_MEGA__ */
> >  #else    /* !__cplusplus */
> >  #  if defined(__AVR_MEGA__) && __AVR_MEGA__
> >  #  define ISR_ALIAS(vector, tgt) void vector (void) \
> >         __attribute__((signal, naked, __INTR_ATTRS)); \
> > -       void vector (void) { asm volatile ("jmp " __STRINGIFY(tgt)
> ::);
> > }
> > +       void vector (void) { __asm__ volatile ("jmp "
> __STRINGIFY(tgt)
> > ::); }
> >  #  else /* !__AVR_MEGA */
> >  #  define ISR_ALIAS(vector, tgt) void vector (void) \
> >         __attribute__((signal, naked, __INTR_ATTRS)); \
> > -       void vector (void) { asm volatile ("rjmp " __STRINGIFY(tgt)
> > ::); }
> > +       void vector (void) { __asm__ volatile ("rjmp "
> __STRINGIFY(tgt)
> > ::); }
> >  #  endif  /* __AVR_MEGA__ */
> >  #endif /* __cplusplus */
> 
>