Hi Joakim!
> As I see it I have three choices for implementing a board
> specific configuration of NVRAM:
>
> - Macros for the board's functions such as:
> board.h:
> #define NVRAM_READ(addr, len) nvram_spi_read(MYBOARD_NVRAM_SPI,
> MYBOARD_NVRAM_CS, addr, len)
> #define
>
> -
Hi Ryan!
> In my opinion this is a cleaner abstraction, and leads to clearer parallel
> composition (or wiring) of modules, rather than the oft used vertical
> composition.
So, basically you're saying that trading some performance for a cleaner design
is a good thing, is that right? I would say t
The reason that I wanted to use function pointers in the NVRAM
interface is to avoid having to resort to macros or defining wrapper
functions in the board directory for my specific board's NVRAM
hardware. As I see it I have three choices for implementing a board
specific configuration of NVRAM:
-
Hi Kévin!
> I began to use function pointers in the 'radio_driver.h' when trying to
> create a unified model for radio drivers. I guess it went over later to the
> whole netdev effort.
Yes, I remember that, but why can't this be implemented in a similar way we
did for most of the peripheral drive
Hi Pekka,
thanks for your input.
> Of course, some care is needed to make sure that the compiler does the right
> thing.
> It is relatively easy to break the pattern.
I see your point, but actually, I don't want to build a whole system model
based on any assumption about what the compiler might
Hi All,
We use this approach exhaustively (for drivers and practically everything
else) with the same result.
The struct does not even need to be declared as a const struct if it is
used in a way that implies such, though it is definitely more elegant to
declare it so.
Though I do have a preferen
Hi Ralph,
a short update:
I spent most of today’s afternoon to set up toolchain and additional tools
again which
didn’t left much time for testing.
I can confirm the latter problem the app yielding. I will continue
investigation tomorrow.
The first issue I couldn’t reproduce though.
I will ke
Hello,
I began to use function pointers in the 'radio_driver.h' when trying to
create a unified model for radio drivers. I guess it went over later to
the whole netdev effort.
My idea then was to have a "fast", predictable call chain from the MAC
layer to the physical radio transceiver funct
> On Feb 18, 2015, at 4:18 AM 2/18/15, Thomas Eichinger
> wrote:
>
> Hi Ralph,
>
> first of all also welcome from my side.
>
> Regarding the RIOT support for the redbee-econotag I can remember similar
> problems which resulted from the compiler used. For this board it is important
> to note t
Oleg, all,
Just as one data point, modern compilers are able to optimise out function
pointers if they are constant. That is, if the struct containing the function
pointer is a const struct, in a typical case "static const", then e.g. LLVM is
able to optimise the function pointer call into the
Dear remodeling IoTlers!
Ludwig just made me aware that Joakim's PR for NVRAM [1] introduces function
pointers as part of the device driver struct. This made me remember that there
were already similar function pointers introduced as part of netdev.
As I was always opposed to use function pointer
Hi Shisir,
the log posted by Ludwig shows a hwtimer implementation with 4 timer slots.
(In most cases these refer to channels on the silicon timer which can be spread
over several silicon modules)
Each slot has its own callback getting executed when the below running timer
matches the set compare
Hi Ralph,
first of all also welcome from my side.
Regarding the RIOT support for the redbee-econotag I can remember similar
problems which resulted from the compiler used. For this board it is important
to note that only the CodeSourcery GCC 2008q3 is supported. Could you
check for this?
I will
13 matches
Mail list logo
