Hi Andrew, Thanks for the info. When I heard RTEMS 5, I was still thinking EPICS 3.14.x. So thanks for clarifying. I have a better sense of how much work this is. It still occurs to me that an mvme2500 RTEMS 4.10 option is possible. Sebastian, if you see a way forward there, we would be interested.
I mentioned before that the 2500 is our best path. So now I guess that's debatable. That's based on price point and a suitable cpu for our applications. Browsing the RTEMS BSP list, I see the the 5500 as an option. Has anyone used this board on RTEMS with EPICS? The 5500 is still offered and manufactured by Artesyn and the price is around $4500. -Matt On Thu, Jun 7, 2018 at 11:52 AM, Andrew Johnson <a...@aps.anl.gov> wrote: > Hi Matt, > > On 06/07/2018 03:20 PM, Matt Rippa wrote: > > The 2500 path looks like our best choice. We can still use the > > 6100/beatnik and 2700 boards in the mean time. > > While I agree tentatively about your choosing the 2500, you do need to > be aware that Heinz's EPICS support for RTEMS 5 is aimed at EPICS 7 (it > hasn't been merged yet), and the switch from RTEMS 4.10 to 5.x is not a > minor change from our perspective. > > The Kernel APIs that our libCom/osi routines call had to be changed from > the old RTEMS-native interfaces to the Posix ones of RTEMS-5, so there's > quite a difference. We had to make changes to the EPICS build system for > it to be possible to have two implementations of the same OS-dependent > routines for the two different kernel APIs under the same OS_CLASS > (since where possible the RTEMS-5 build should use our standard Posix > implementations). We didn't want to introduce a new RTEMS5 OS_CLASS > since that would break existing EPICS support modules which should > otherwise still work (providing they only call our OSI APIs). > > It is also not possible to mix RTEMS versions in the same installation > of EPICS Base, since EPICS RTEMS builds rely on Makefile configurations > and rules from RTEMS' own build system. The RTEMS path and version must > be set in the base/configure/os/CONFIG_SITE.Common.RTEMS file and cannot > be overridden in a target-specific CONFIG file (because by the time > those files get read in we've already read in a lot of RTEMS build > configuration data). > > Sorry, just want you to know... > > - Andrew > > -- > Arguing for surveillance because you have nothing to hide is no > different than making the claim, "I don't care about freedom of > speech because I have nothing to say." -- Edward Snowdon > --
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users