Hardware Abstraction Architecture of TInyOS

-

Hardware Abstraction Architecture of TInyOS

The Hardware Abstraction Architecture of TinyOS has three layers..

1.Hardware Presentation Layer:
  • It is the lowest layer.
  • It provides the lowest level access to the hardware, and provides wrappers around lowest level tasks,such as setting registers with higher level software calls.
  • Components in this layer are not expected to be used from user program as any functionality they provide should be exposed by higher levels above it.
  • Components should be efficient,because many higher level components may call it simultaneously.

    2.Hardware Adaptation Layer:
  • It is above the Hardware Presentation Layer.
  • Contains most of the platform code.
  • Exposes one or more components for each piece of functionality the mote provides.
  • HAL components provide advanced functionality of the program at the expense of programs using them become platform-specific.

3.Hardware Interface Layer:
  • The interfaces and components in this layer are expected to be provided by each platform.
  • Majority of the code in this layer is just mapping between the standard interface and the interface which are defined by the HAL.
  • If a program uses a components in the HIL,then it will run correctly on al platforms without changing any code.      

Comments

Post a Comment

Popular posts from this blog

bb.utils.contains yocto

-
Image
bb.utils.contains  is most commonly used function in Yocto. grep in poky directory returned with 696 count. $ grep -nr 'bb.utils.contains' poky/ | wc -l 696 It's definition is present in 'poky/bitbake/lib/bb/utils.py' file This function returns third argument if the second argument is subset of the first argument else returns fourth argument Let's take an example to understand this. You can see from the above screenshot, when the second argument is a subset of first argument, "present" was returned, else "notpresent" was returned We can also use bb.utils.contains inside if loop. This we can use inside a recipe. if ${@bb.utils.contains('SOMEFLAG','NEWVALUE3','true','false',d)}; then     FOO = 'HELLO' fi
Read more

make config vs oldconfig vs defconfig vs menuconfig vs savedefconfig

-
Image
Building the Linux Kernel is a two-step process: Configuring the Kernel options Building the Kernel with those options. There are many methods available for configuring the kernel. make config: Text-based Configuration.  Options are prompted one after another. All options need to be answered Access to former options is not possible make menuconfig: Menu-driven user interface Allows to navigate forwards and backward directly between features Allows to load and save files with filenames different from ".config" Provides search feature It uses ncurses library for GUI. If the ncurses library is not installed, make menuconfig option fails. To install ncurses library on Ubuntu: sudo apt-get install libncurses5-dev make defconfig: Creates a ".config" file with default options from the ARCH supplied defconfig Configurations are generally stored in the directory: arch/$(ARCH)/configs $ ls arch/x86/configs/ i386_defconfi
Read more

PR, PN and PV Variable in Yocto

-
PN : Represents the name of the recipe. The name is usually extracted from the recipe file name. PR:  Represents the revision of the recipe. Default value for this revision is "r0". Subsequent revisions of the recipe conventionally will have "r1", "r2" and so on. PV:  Represents the version of the recipe. Normally extracted from the recipe file name. For example: ffmpeg_3.4.2.bb recipe. ${PN} : ffmpeg ${PV} : 3.4.2
Read more