Am 13.02.2018 um 00:34 schrieb Chris Johns: > On 13/02/2018 00:39, Christian Mauderer wrote: >> These patches add various improvements for the atsam BSP and for the >> sc16is752 SPI UART controller. >> >> Regarding patch 1: Note that I have thought about an auto detection >> instead of the option. But I had a board where something responded to >> the oscillator so that I could initialize it despite the fact that no >> crystall has been connected. So I think an auto detection would be >> dangerous. > > I agree with this approach. > > Auto-detection is OK in systems with users however in embedded systems it is > dangerous. I have a rule, any auto-detection requires a system level module > that > audits the part of a system that has auto-detection and raises any unexpected > differences as errors. Auto-detection can be hard to avoid in some systems, ie > PC motherboards, PCI etc. > > I remember back in the mid-90s working on an important system with RAM size > detection where one of two static RAM chips had started to fail and the system > adjusted assuming this was all the available memory so no one noticed until > many > many months into operation the application was reconfigured and it ran out of > memory when it should not have. At the start of the project I had been asked > to > add the memory detection to handle different build variants of the hardware. > The > feature was disabled and I have not been a fan of it ever since. > > Chris >
Hello Chris, thanks for the support for this approach. I mostly wanted to give a reason why I thought it would be necessary to add another option to the BSP. Any other remarks regarding the patches? Can I apply them? Kind regards Christian -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
