Re: Removal of 8-bit AVR support (Re: STM32L051 and LPUART)
Nathan Moore <[email protected]> Mon, 31 Oct 2016 09:55:53 -0400
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <CAAJh09WXi2G1RoHN44KEK2FPDxGfNSmZPHLbXbTp+udg1nzRTQ@mail.gmail.com> |
On Mon, Oct 31, 2016 at 6:02 AM, Uwe Bonnes < bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> wrote: > >>>>> "Nathan" == Nathan Moore <[email protected]> writes: > > Nathan> On Tue, Oct 25, 2016 at 5:19 AM, Uwe Bonnes < > Nathan> bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> wrote: > > >> > >> Another thing is the protection of 2 and 4 byte variables with a > >> Critical section. This is not needed with 32-bit systems. But a look > >> at nut/dev/ shows that only the old u(s)art driver use it. So it is > >> legacy, but does not hamper us beside carrying old code around. > >> > > Nathan> I started to write some Critical macros that would take a > Nathan> parameter to test for size and alignment to determine if they > Nathan> should actually do anything, but while doable in GCC that got > Nathan> complicated quickly. Is that something that people would find > Nathan> useful? Is that something that people would trust and/or use > Nathan> correctly? Alternately, a family of Critical macros with size > Nathan> suffixes could be written for each architecture and not rely so > Nathan> much on the preprocessor and compiler to get it right. > > Did you have a look at the gcc atomic macros? > https://gcc.gnu.org/onlinedocs/gcc-4.3.4/gcc/Atomic-Builtins.html > and friends I hadn't, but even though those are for Itanium the API might be worth mimicking, as long as Intel doesn't care, since GCC got them from Intel's ABI documentation for Itanium. I was really just thinking about EnterCritical and ExitCritical macros that either knew or were told what size data they were protecting and compiled to no code for 32 bit updates on 32 bit memory width architectures. Having interfaces that actually encompassed the synchronization and the work might make them easier to use, though. Nathan _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion