On Mon, Nov 26, 2018, 1:10 PM Christian Mauderer <l...@c-mauderer.de wrote:
> Hello Peter, > > yes, that sounds about right. I'm not entirely sure about the name of > the file we used as a base back then. I would have to take a look at the > exact version at work. > > I think the new software should be based on the "legacy" one so I would > expect that the interface is at least similar. But yes, it will be some > work to use the updated libraries. Especially because there are some > RTEMS-patches in the legacy libraries to work around some bugs. > Was the original software committed unmodified? If so, then the changes to fix bugs should be easy to find via git. > > Best regards > > Christian > > Am 26.11.18 um 18:37 schrieb dufa...@hda.com: > > It will be some work to update. I believe what’s in the existing port > > is from this: > > atmel-software-package-samv7: Legacy software package for samv7, same70 > > and sams70 product families. > > while the newest software that supports the ATSAMA5 is here, with a > > different directory layout. > > atmel-software-package: Atmel Software Package > > > >> On Nov 25, 2018, at 14:45 , Christian Mauderer <l...@c-mauderer.de > >> <mailto:l...@c-mauderer.de>> wrote: > >> > >> Hello Peter, > >> > >> Thomas mentioned already the bug that has been reported to Microchip. > >> Please note that I had two more problems with the BSP on another > >> customers board: > >> > >> - The core clock couldn't be set to the maximum frequency from the data > >> sheet. Both possible configurations for that frequency didn't work. The > >> first one would have set the PLL to the same frequency as the CPU core > >> clock. With that the system was not stable. The other setting (a divider > >> of two after the PLL) seemed to work better but that forced me to set > >> the PLL to a higher frequency than the data sheet specified. I ended up > >> with the lower frequency. > >> > >> - The external SDRAM seemed to introduce some jitter into the core PLL > >> too (not only in the USB PLL which was the reason for the USB bug). With > >> higher frequency configurations the system sometimes had an odd > >> behaviour: A comparison went wrong when it should go well. Again that > >> lead to a slightly lower frequency that seemed stable. So the board now > >> runs on only about two thirds of the maximum frequency specified by > >> Microchip. > >> > >> If you still want to use the ATSAM chip: Microchip managed to get a > >> better community around the libraries that are used in the BSP for that > >> chip. There is a newer version of them somewhere on github. If there is > >> funding for it, I would suggest to update the ones that are integrated > >> in the ATSAM BSP by the newer ones. They contain quite some bug fixes. > >> But it will need some work to do that. > >> > >> With kind regards > >> > >> Christian Mauderer > >> > >> Am 25.11.18 um 19:42 schrieb dufa...@hda.com <mailto:dufa...@hda.com>: > >>> Thank you for the advice. I will not need USB, but will need SDRAM and > >>> don’t need poor support. Microchip? You tried to push RTEMS for this > >>> platform tied to space applications, are you monitoring this? The > >>> platform looks like just what I need but not if you’re not supporting > it. > >>> > >>>> On Nov 25, 2018, at 13:23 , Thomas Dörfler > >>>> <thomas.doerf...@embedded-brains.de > >>>> <mailto:thomas.doerf...@embedded-brains.de> > >>>> <mailto:thomas.doerf...@embedded-brains.de>> wrote: > >>>> > >>>> Peter, > >>>> > >>>> just to make you aware: we designed a board with the ATSAMV7 chip and > >>>> hit some nasty and at least one really ugly bug: operating the USB > >>>> interface concurrently with external SDRAM does not work. Half a year > >>>> after reporting this bug, Microchip confirmed it, but did not plan any > >>>> fix for it. BTW: The conbination (USB+SDRAM) was also available on > >>>> Microchip's evaluation board, but obviously was not tested together at > >>>> Microchips labs... > >>>> > >>>> So: I recommend you to tripple check, whether the ATSAMA5 meets all of > >>>> your expectations. > >>>> > >>>> > >>>> Kind regards, > >>>> > >>>> Thomas. > >>>> > >>>> ----- Ursprüngliche Mail ----- > >>>> Von: "Peter Dufault" <dufa...@hda.com <mailto:dufa...@hda.com> > >>>> <mailto:dufa...@hda.com>> > >>>> An: "Development" <devel@rtems.org <mailto:devel@rtems.org> > >>>> <mailto:devel@rtems.org>> > >>>> Gesendet: Sonntag, 25. November 2018 18:38:19 > >>>> Betreff: BSP for Microchip ATSAMA5D27-SOM1-EK1 > >>>> > >>>> I need to evaluate this for a multi-chip application. > >>>> > >>>> This part is a result of Microchip’s take-over of ATMEL. I’m > >>>> double-checking that to create a BSP based on this I should start with > >>>> the existing ATSAMV7 BSP, I think the peripherals (e.g. network chip > >>>> and so on) are the same as the existing ATSAMV7 port. > >>>> > >>>> Peter > >>>> ----------------- > >>>> Peter Dufault > >>>> HD Associates, Inc. Software and System Engineering > >>>> > >>>> This email is delivered through the public internet using protocols > >>>> subject to interception and tampering. > >>>> > >>>> _______________________________________________ > >>>> devel mailing list > >>>> devel@rtems.org <mailto:devel@rtems.org> <mailto:devel@rtems.org> > >>>> http://lists.rtems.org/mailman/listinfo/devel > >>>> -- > >>>> -- > >>>> -------------------------------------------- > >>>> embedded brains GmbH > >>>> Thomas Doerfler > >>>> Dornierstr. 4 > >>>> D-82178 Puchheim > >>>> Germany > >>>> email: thomas.doerf...@embedded-brains.de > >>>> Phone: +49-89-18 94 741-12 > >>>> Fax: +49-89-18 94 741-09 > >>>> PGP: Public key available on request. > >>>> > >>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >>> > >>> Peter > >>> ----------------- > >>> Peter Dufault > >>> HD Associates, Inc. Software and System Engineering > >>> > >>> This email is delivered through the public internet using protocols > >>> subject to interception and tampering. > >>> > >>> > >>> _______________________________________________ > >>> devel mailing list > >>> devel@rtems.org <mailto:devel@rtems.org> > >>> http://lists.rtems.org/mailman/listinfo/devel > >>> > >> > > > > Peter > > ----------------- > > Peter Dufault > > HD Associates, Inc. Software and System Engineering > > > > This email is delivered through the public internet using protocols > > subject to interception and tampering. > > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
