DiLab - User contributions [en]

MansOS Coding Standard

2008-04-03T06:19:13Z

Janisg:

Be advised to use the following coding style when writing or editing '''[[MansOS]]''' source code.

== General ==

* Write comments. Respect the reader!

* Keep the line length under 78 to help the viewer and those that want to print your code. Break the line in several as necessary.
Never ever exceed the line length of 120 symbols.

== Code flow and indenting ==

Indent new code blocks by 4 spaces

Note that TAB character is always 8 spaces.
However, set your editor to use spaces instead of the TAB character to avoid confusion when loading text files that may contain tab characters and was written using a different editor.

You may want to select TAB key to indent and Backspace key to un-indent in your text editor (SciTe, Emacs, ...)

== Variable and function names ==

Variable names and function names shall start in lowercase and be written in [http://en.wikipedia.org/wiki/Camelcase CamelCase] - writeByte, not write_byte, wrt_byte or WrItEbYtE.

int writeByte;
void printByte(void *buf);

=== Pointer variables ===

Add trailing "_p" to show this is a pointer

int writeByte;
int writeByte_p; <-- like this

=== Constants and defines ===

Use all-uppercase for <code>#define</code> constants, with underscore between the words

#define MAX_LENGTH 15
#define HEIGHT 7

For constants use first letter in uppercase with the rest in camelcase
Add trailing _c to show this is a constant.

const MaxBufferSize_c = 64;

When using <code>#ifdef</code> or <code>#if</code> constructs,
you should always use comments for <code>#endif</code>.
The comment for <code>#endif</code> should match the expression used in the corresponding
<code>#if</code> or <code>#ifdef</code>. The comment for <code>#else</code> and <code>#elif</code> should match the
inverse of the expression(s) used in the preceding <code>#if</code> and/or <code>#elif</code>
statements.

<code>
#ifdef MSP430
/* msp430 stuff here */
#else /* !MSP430 */
/* non msp430 stuff here */
#endif /* MSP430 */
</code>

=== Enums, structs and all other types ===

Use the first letter in uppercase, the rest is CamelCase.
Add trailing "_t" to show this is a type, or "_e" to show this is an enum

<code>
typedef struct
{
int a;
int b;
int c;
} MyStruct_t;
</code>

Enums example:

<code>
typedef enum
{
RECTANGLE,
CIRCLE = 17,
LAST // Use "Last" as the last enum available, as needed
} ShapeType_e;
</code>

Enumeration values all should be written in uppercase.

<code>
typedef enum { WHITE, BLACK } Color_e;
</code>

== Code control structures ==

=== if, else, for, while, do ===

Always use braces after <code>if(), else, for(), while(), do</code>, even when there is only one statement in the block.
There might be a few exceptions when if and the statement is on the same line and unmistakeably has one simple statement such as an assignment.

You may write the opening brace on the same or the next line. Use common sense. Generally to make a short if() with just one statement in the body I use it on the same line.

<code>
if ( 17 == a ) b++;

if (...) {
foo();
}

if (...)
{
foo();
bar();
}
</code>

When using comparisons in control structures, always try to use left-hand comparisons.
Because these types of comparisons detects typo errors early.
Typical errors arise in right-hand style when equality operator is required but assignment operator is used,
in left-hand style these typos will result in compilation error and crash early.

daily usage of comparisons - right hand style
<code>
if ( a == 17 )
{
...
}
</code>

left-hand style
<code>
if ( 17 == a )
{
...
}
</code>

=== Spacing in expressions ===

Use space to separate tokens in expressions and braces everywhere in the code
However, you may use no space between unary operation and operand, for example, i++;

x = y + 16 - z++;

if( 17 == a ) {
b = foo( c, d );
}

=== Function and procedure heads ===

Start every function or procedure with a comment block describing it.
The return type for functions may be on a separate line prior to the function name to make the function fit in a single line.

//-----------------------------------------------------------------------------
// Prints formated text in a box with x,y,w,h parameters.
//-----------------------------------------------------------------------------
uint32_t
printInBox(char* text, char *format, int16_t x, int16_t y, int16_t w, int16_t z)
{
...
}

MansOS Coding Standard

2008-04-02T20:44:00Z

Janisg:

Be advised to use the following coding style when writing or editing '''[[MansOS]]''' source code.

== General ==

* Write comments. Respect the reader!

* Keep the line length under 78 to help the viewer and those that want to print your code. Break the line in several as necessary.
Never ever exceed the line length of 120 symbols.

== Code flow and indenting ==

Indent new code blocks by 4 spaces

Note that TAB character is always 8 spaces.
However, set your editor to use spaces instead of the TAB character to avoid confusion when loading text files that may contain tab characters and was written using a different editor.

You may want to select TAB key to indent and Backspace key to un-indent in your text editor (SciTe, Emacs, ...)

== Variable and function names ==

Variable names and function names shall start in lowercase and be written in [http://en.wikipedia.org/wiki/Camelcase CamelCase] - writeByte, not write_byte, wrt_byte or WrItEbYtE.

int writeByte;
void printByte(void *buf);

=== Pointer variables ===

Add trailing "_p" to show this is a pointer

int writeByte;
int writeByte_p; <-- like this

=== Constants and defines ===

Use all-uppercase for <code>#define</code> constants, with underscore between the words

#define MAX_LENGTH 15
#define HEIGHT 7

For constants use first letter in uppercase with the rest in camelcase
Add trailing _c to show this is a constant.

const MaxBufferSize_c = 64;

When using <code>#ifdef</code> or <code>#if</code> constructs,
you should always use comments for <code>#endif</code>.
The comment for <code>#endif</code> should match the expression used in the corresponding
<code>#if</code> or <code>#ifdef</code>. The comment for <code>#else</code> and <code>#elif</code> should match the
inverse of the expression(s) used in the preceding <code>#if</code> and/or <code>#elif</code>
statements.

<code>
#ifdef MSP430
/* msp430 stuff here */
#else /* !MSP430 */
/* non msp430 stuff here */
#endif /* MSP430 */
</code>

=== Enums, structs and all other types ===

Use the first letter in uppercase, the rest is CamelCase.
Add trailing "_t" to show this is a type, or "_e" to show this is an enum

<code>
typedef struct
{
int a;
int b;
int c;
} MyStruct_t;
</code>

Enums example:

<code>
typedef enum
{
RECTANGLE,
CIRCLE = 17,
LAST // Use "Last" as the last enum available, as needed
} ShapeType_e;
</code>

Enumeration values all should be written in uppercase.

<code>
typedef enum { WHITE, BLACK } color_e;
</code>

== Code control structures ==

=== if, else, for, while, do ===

Always use braces after <code>if(), else, for(), while(), do</code>, even when there is only one statement in the block.
There might be a few exceptions when if and the statement is on the same line and unmistakeably has one simple statement such as an assignment.

You may write the opening brace on the same or the next line. Use common sense. Generally to make a short if() with just one statement in the body I use it on the same line.

<code>
if ( 17 == a ) b++;

if (...) {
foo();
}

if (...)
{
foo();
bar();
}
</code>

When using comparisons in control structures, always try to use left-hand comparisons.
Because these types of comparisons detects typo errors early.
Typical errors arise in right-hand style when equality operator is required but assignment operator is used,
in left-hand style these typos will result in compilation error and crash early.

daily usage of comparisons - right hand style
<code>
if ( a == 17 )
{
...
}
</code>

left-hand style
<code>
if ( 17 == a )
{
...
}
</code>

=== Spacing in expressions ===

Use space to separate tokens in expressions and braces everywhere in the code
However, you may use no space between unary operation and operand, for example, i++;

x = y + 16 - z++;

if( 17 == a ) {
b = foo( c, d );
}

=== Function and procedure heads ===

Start every function or procedure with a comment block describing it.
The return type for functions may be on a separate line prior to the function name to make the function fit in a single line.

//-----------------------------------------------------------------------------
// Prints formated text in a box with x,y,w,h parameters.
//-----------------------------------------------------------------------------
uint32_t
printInBox(char* text, char *format, int16_t x, int16_t y, int16_t w, int16_t z)
{
...
}

MansOS Coding Standard

2008-04-02T20:43:29Z

Janisg:

Be advised to use the following coding style when writing or editing '''[[MansOS]]''' source code.

== General ==

* Write comments. Respect the reader!

* Keep the line length under 78 to help the viewer and those that want to print your code. Break the line in several as necessary. Never ever exceed the line length of 120.

== Code flow and indenting ==

Indent new code blocks by 4 spaces

Note that TAB character is always 8 spaces.
However, set your editor to use spaces instead of the TAB character to avoid confusion when loading text files that may contain tab characters and was written using a different editor.

You may want to select TAB key to indent and Backspace key to un-indent in your text editor (SciTe, Emacs, ...)

== Variable and function names ==

Variable names and function names shall start in lowercase and be written in [http://en.wikipedia.org/wiki/Camelcase CamelCase] - writeByte, not write_byte, wrt_byte or WrItEbYtE.

int writeByte;
void printByte(void *buf);

=== Pointer variables ===

Add trailing "_p" to show this is a pointer

int writeByte;
int writeByte_p; <-- like this

=== Constants and defines ===

Use all-uppercase for <code>#define</code> constants, with underscore between the words

#define MAX_LENGTH 15
#define HEIGHT 7

For constants use first letter in uppercase with the rest in camelcase
Add trailing _c to show this is a constant.

const MaxBufferSize_c = 64;

When using <code>#ifdef</code> or <code>#if</code> constructs,
you should always use comments for <code>#endif</code>.
The comment for <code>#endif</code> should match the expression used in the corresponding
<code>#if</code> or <code>#ifdef</code>. The comment for <code>#else</code> and <code>#elif</code> should match the
inverse of the expression(s) used in the preceding <code>#if</code> and/or <code>#elif</code>
statements.

<code>
#ifdef MSP430
/* msp430 stuff here */
#else /* !MSP430 */
/* non msp430 stuff here */
#endif /* MSP430 */
</code>

=== Enums, structs and all other types ===

Use the first letter in uppercase, the rest is CamelCase.
Add trailing "_t" to show this is a type, or "_e" to show this is an enum

<code>
typedef struct
{
int a;
int b;
int c;
} MyStruct_t;
</code>

Enums example:

<code>
typedef enum
{
RECTANGLE,
CIRCLE = 17,
LAST // Use "Last" as the last enum available, as needed
} ShapeType_e;
</code>

Enumeration values all should be written in uppercase.

<code>
typedef enum { WHITE, BLACK } color_e;
</code>

== Code control structures ==

=== if, else, for, while, do ===

Always use braces after <code>if(), else, for(), while(), do</code>, even when there is only one statement in the block.
There might be a few exceptions when if and the statement is on the same line and unmistakeably has one simple statement such as an assignment.

You may write the opening brace on the same or the next line. Use common sense. Generally to make a short if() with just one statement in the body I use it on the same line.

<code>
if ( 17 == a ) b++;

if (...) {
foo();
}

if (...)
{
foo();
bar();
}
</code>

When using comparisons in control structures, always try to use left-hand comparisons.
Because these types of comparisons detects typo errors early.
Typical errors arise in right-hand style when equality operator is required but assignment operator is used,
in left-hand style these typos will result in compilation error and crash early.

daily usage of comparisons - right hand style
<code>
if ( a == 17 )
{
...
}
</code>

left-hand style
<code>
if ( 17 == a )
{
...
}
</code>

=== Spacing in expressions ===

Use space to separate tokens in expressions and braces everywhere in the code
However, you may use no space between unary operation and operand, for example, i++;

x = y + 16 - z++;

if( 17 == a ) {
b = foo( c, d );
}

=== Function and procedure heads ===

Start every function or procedure with a comment block describing it.
The return type for functions may be on a separate line prior to the function name to make the function fit in a single line.

//-----------------------------------------------------------------------------
// Prints formated text in a box with x,y,w,h parameters.
//-----------------------------------------------------------------------------
uint32_t
printInBox(char* text, char *format, int16_t x, int16_t y, int16_t w, int16_t z)
{
...
}

MansOS Coding Standard

2008-04-02T20:32:08Z

Janisg:

Be advised to use the following coding style when writing or editing '''[[MansOS]]''' source code.

== General ==

* Write comments. Respect the reader!

* Keep the line length under 78 to help the viewer and those that want to print your code. Break the line in several as necessary.

== Code flow and indenting ==

Indent new code blocks by 4 spaces

Note that TAB character is always 8 spaces.
However, set your editor to use spaces instead of the TAB character to avoid confusion when loading text files that may contain tab characters and was written using a different editor.

You may want to select TAB key to indent and Backspace key to un-indent in your text editor (SciTe, Emacs, ...)

== Variable and function names ==

Variable names and function names shall start in lowercase and be written in [http://en.wikipedia.org/wiki/Camelcase CamelCase] - writeByte, not write_byte, wrt_byte or WrItEbYtE.

int writeByte;
void printByte(void *buf);

=== Pointer variables ===

Add trailing "_p" to show this is a pointer

int writeByte;
int writeByte_p; <-- like this

=== Constants and defines ===

Use all-uppercase for <code>#define</code> constants, with underscore between the words

#define MAX_LENGTH 15
#define HEIGHT 7

For constants use first letter in uppercase with the rest in camelcase
Add trailing _c to show this is a constant.

const MaxBufferSize_c = 64;

When using <code>#ifdef</code> or <code>#if</code> constructs,
you should always use comments for <code>#endif</code>.
The comment for <code>#endif</code> should match the expression used in the corresponding
<code>#if</code> or <code>#ifdef</code>. The comment for <code>#else</code> and <code>#elif</code> should match the
inverse of the expression(s) used in the preceding <code>#if</code> and/or <code>#elif</code>
statements.

<code>
#ifdef MSP430
/* msp430 stuff here */
#else /* !MSP430 */
/* non msp430 stuff here */
#endif /* MSP430 */
</code>

=== Enums, structs and all other types ===

Use the first letter in uppercase, the rest is CamelCase.
Add trailing "_t" to show this is a type, or "_e" to show this is an enum

<code>
typedef struct
{
int a;
int b;
int c;
} MyStruct_t;
</code>

Enums example:

<code>
typedef enum
{
RECTANGLE,
CIRCLE = 17,
LAST // Use "Last" as the last enum available, as needed
} ShapeType_e;
</code>

Enumeration values all should be written in uppercase.

<code>
typedef enum { WHITE, BLACK } color_e;
</code>

== Code control structures ==

=== if, else, for, while, do ===

Always use braces after <code>if(), else, for(), while(), do</code>, even when there is only one statement in the block.
There might be a few exceptions when if and the statement is on the same line and unmistakeably has one simple statement such as an assignment.

You may write the opening brace on the same or the next line. Use common sense. Generally to make a short if() with just one statement in the body I use it on the same line.

<code>
if ( a == 17 ) b++;

if (...) {
foo();
}

if (...)
{
foo();
bar();
}
</code>

=== Spacing in expressions ===

Use space to separate tokens in expressions and braces everywhere in the code
However, you may use no space between unary operation and operand, for example, i++;

x = y + 16 - z++;

if( a == 17 ) {
b = foo( c, d );
}

=== Function and procedure heads ===

Start every function or procedure with a comment block describing it.
The return type for functions may be on a separate line prior to the function name to make the function fit in a single line.

//-----------------------------------------------------------------------------
// Prints formated text in a box with x,y,w,h parameters.
//-----------------------------------------------------------------------------
uint32_t
printInBox(char* text, char *format, int16_t x, int16_t y, int16_t w, int16_t z)
{
...
}

MansOS Coding Standard

2008-04-02T20:31:27Z

Janisg:

Be advised to use the following coding style when writing or editing '''[[MansOS]]''' source code.

== General ==

* Write comments. Respect the reader!

* Keep the line length under 78 to help the viewer and those that want to print your code. Break the line in several as necessary.

== Code flow and indenting ==

Indent new code blocks by 4 spaces

Note that TAB character is always 8 spaces.
However, set your editor to use spaces instead of the TAB character to avoid confusion when loading text files that may contain tab characters and was written using a different editor.

You may want to select TAB key to indent and Backspace key to un-indent in your text editor (SciTe, Emacs, ...)

== Variable and function names ==

Variable names and function names shall start in lowercase and be written in [http://en.wikipedia.org/wiki/Camelcase CamelCase] - writeByte, not write_byte, wrt_byte or WrItEbYtE.

int writeByte;
void printByte(void *buf);

=== Pointer variables ===

Add trailing "_p" to show this is a pointer

int writeByte;
int writeByte_p; <-- like this

=== Constants and defines ===

Use all-uppercase for <code>#define</code> constants, with underscore between the words

#define MAX_LENGTH 15
#define HEIGHT 7

For constants use first letter in uppercase with the rest in camelcase
Add trailing _c to show this is a constant.

const MaxBufferSize_c = 64;

When using <code>#ifdef</code> or <code>#if</code> constructs,
you should always use comments for <code>#endif</code>.
The comment for <code>#endif</code> should match the expression used in the corresponding
<code>#if</code> or <code>#ifdef</code>. The comment for <code>#else</code> and <code>#elif</code> should match the
inverse of the expression(s) used in the preceding <code>#if</code> and/or <code>#elif</code>
statements. (<c> KNF)

<code>
#ifdef MSP430
/* msp430 stuff here */
#else /* !MSP430 */
/* non msp430 stuff here */
#endif /* MSP430 */
</code>

=== Enums, structs and all other types ===

Use the first letter in uppercase, the rest is CamelCase.
Add trailing "_t" to show this is a type, or "_e" to show this is an enum

<code>
typedef struct
{
int a;
int b;
int c;
} MyStruct_t;
</code>

Enums example:

<code>
typedef enum
{
RECTANGLE,
CIRCLE = 17,
LAST // Use "Last" as the last enum available, as needed
} ShapeType_e;
</code>

Enumeration values all should be written in uppercase.

<code>
typedef enum { WHITE, BLACK } color_e;
</code>

== Code control structures ==

=== if, else, for, while, do ===

Always use braces after <code>if(), else, for(), while(), do</code>, even when there is only one statement in the block.
There might be a few exceptions when if and the statement is on the same line and unmistakeably has one simple statement such as an assignment.

You may write the opening brace on the same or the next line. Use common sense. Generally to make a short if() with just one statement in the body I use it on the same line.

<code>
if ( a == 17 ) b++;

if (...) {
foo();
}

if (...)
{
foo();
bar();
}
</code>

=== Spacing in expressions ===

Use space to separate tokens in expressions and braces everywhere in the code
However, you may use no space between unary operation and operand, for example, i++;

x = y + 16 - z++;

if( a == 17 ) {
b = foo( c, d );
}

=== Function and procedure heads ===

Start every function or procedure with a comment block describing it.
The return type for functions may be on a separate line prior to the function name to make the function fit in a single line.

//-----------------------------------------------------------------------------
// Prints formated text in a box with x,y,w,h parameters.
//-----------------------------------------------------------------------------
uint32_t
printInBox(char* text, char *format, int16_t x, int16_t y, int16_t w, int16_t z)
{
...
}

Chips msp430

2008-03-22T12:15:54Z

Janisg:

MSP430 MCU GCC toolchain can be found here http://mspgcc.sourceforge.net/.

The documentation supplied with mspgcc is very comprehensive and describes the MCU in great detail. Can be found here http://mspgcc.sourceforge.net/manual/. This could be very good introductory material for this MCU.

Tmote Sky sensor module is equipped with MSP430 F1611 MCU. According to mspgcc docs on how to decode MSP430 part numbers (http://mspgcc.sourceforge.net/manual/x675.html).

F1611 - stands for:
* F - Flash ROM,
* 16xx - Like 14x, but adding 2xDAC12, 3xDMA, brownout reset and I2C,
* xx11 - 48K ROM, 10K RAM

Manufacturers page for this MCU - http://focus.ti.com/docs/prod/folders/print/msp430f1611.html.

Key documents about this MCU:
* [http://www.ti.com/litv/pdf/slau049f MSP430F15x/16x/161x MSP430x1xx Family User's Guide (Rev. F)]
* [http://www.ti.com/lit/gpn/msp430f1611 MSP430x15x, MSP430x16x, MSP430x161x Mixed Signal Microcontroller (Rev. E) (Datasheet)]
* [http://www.ti.com/litv/pdf/slaz018b MSP430F15x/16x/161x Device Erratasheet (Rev. B)]

Chips msp430

2008-03-22T12:13:50Z

Janisg:

MSP430 MCU GCC toolchain can be found here http://mspgcc.sourceforge.net/.

The documentation supplied with mspgcc is very comprehensive and describes the MCU in great detail. Can be found here http://mspgcc.sourceforge.net/manual/. This could be very good introductory material for this MCU.

Tmote Sky sensor module is equipped with MSP430 F1611 MCU. According to mspgcc docs on how to decode MSP430 part numbers (http://mspgcc.sourceforge.net/manual/x675.html).

F1611 - stands for:
* F - Flash ROM,
* 16xx - Like 14x, but adding 2xDAC12, 3xDMA, brownout reset and I2C,
* xx11 - 48K ROM, 10K RAM

Manufacturers page for this MCU - http://focus.ti.com/docs/prod/folders/print/msp430f1611.html.

Key documents about this MCU:
* [http://www.ti.com/litv/pdf/slau049f MSP430F15x/16x/161x MSP430x1xx Family User's Guide (Rev. F)]
* [http://www.ti.com/litv/pdf/slaz018b MSP430x15x, MSP430x16x, MSP430x161x Mixed Signal Microcontroller (Rev. E)]
* [http://www.ti.com/lit/gpn/msp430f1611 Device Erratasheet (Rev. B)]

Chips msp430

2008-03-22T12:12:22Z

Janisg:

MSP430 MCU GCC toolchain can be found here http://mspgcc.sourceforge.net/.

The documentation supplied with mspgcc is very comprehensive and describes the MCU in great detail. Can be found here http://mspgcc.sourceforge.net/manual/. This could be very good introductory material for this MCU.

Tmote Sky sensor module is equipped with MSP430 F1611 MCU. According to mspgcc docs on how to decode MSP430 part numbers (http://mspgcc.sourceforge.net/manual/x675.html).

F1611 - stands for:
* F - Flash ROM,
* 16xx - Like 14x, but adding 2xDAC12, 3xDMA, brownout reset and I2C,
* xx11 - 48K ROM, 10K RAM

Manufacturers page for this MCU - http://focus.ti.com/docs/prod/folders/print/msp430f1611.html.

Key documents about this MCU:
* [http://www.ti.com/lit/gpn/msp430f1611 MSP430x1xx Family User's Guide (Rev. F)]
* [http://www.ti.com/litv/pdf/slaz018b MSP430x15x, MSP430x16x, MSP430x161x Mixed Signal Microcontroller (Rev. E)]
* [http://www.ti.com/litv/pdf/slau049f MSP430F15x/16x/161x Device Erratasheet (Rev. B)]

MansOS

2008-03-22T11:04:09Z

Janisg:

MansOS is an operating system for wireless sensor networks. It can be considered a branch of LiteOS operating system because it shares several defining characteristics. MansOS like LiteOS is designed to be easily adopted by system designers by avoiding the steep learning curve, because it is based on the concepts that are familiar to the majority of IT community.

Key concepts common with LiteOS:
* MansOS is adopting programming in C and (eventually) C++, known to many people
* MansOS is treating a sensor network using Unix-like command tools and resources
* MansOS enables thread-like programming environment

Additional key aspects specific to MansOS:
* MansOS is designed to be easily portable to new platforms
* MansOS enforces the structured HPL-HAL-HIL architecture at a mote level, ensuring clear interface for portability
* The focus during the development should be the whole system - a collection of mote entities rather than a single mote

=== General ===

* [[MansOS_Philosophy | Philosophy]]
* [[MansOS_Architecture | Architecture]]
* [[MansOS_Directory_Structure | Directory structure]]

=== Internals ===

* [[MansOS_Kernel | Kernel]]
* [[MansOS_File_System | File system]]

=== Development tools and techniques ===

* [[MansOS_Apps_examples | Application examples]]
* [[MansOS_Eclipse | Eclipse setup]]
* [[MansOS_Testing | Debugging and testing]]

=== Hardware notes ===

Chips
* [[Chips_msp430 | MCU: MSP430]]
* [[Chips_cc2420 | Radio: CC2420]]

Platforms
* [[Platforms_telosb | telosb: Tmote Sky, Mini, etc.]]

Chips msp430

2008-03-22T11:03:34Z

Janisg: New page: MSP430 MCU GCC toolchain can be found here http://mspgcc.sourceforge.net/. The documentation supplied with mspgcc is very comprehensive and describes the MCU in great detail. Can be foun...