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. 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
