BoostC Explaining Dot H Files

From OpenCircuits
Revision as of 20:15, 9 March 2009 by Russ hensel (talk | contribs)
Jump to navigation Jump to search

Change Name to BoostC System Header Files

Draft Not Ready

This is my russ_hensel explanation of *.h. Others are welcome to contribute. It is a work in progress, and may or may not be correct.



I believe that boostc.h get included in almost all BoostC compilitations, think this may be via system.h, but I have not figured this out yet.

Helper macros


    #define clear_bit( reg, bitNumb )	((reg) &= ~(1 << (bitNumb)))

These are inline functions using #defines with arguments. ( see [[]] ) many C programmers use these expressions directly in there code, but using clear_bit instead of equivalent is bothe easier to read and write. It make the intent of the program cleared, and may make the code easier to port.


    #define MAKESHORT( dst, lobyte, hibyte )	asm movf _##lobyte, W \
   						asm movwf _##dst \
  						asm movf _##hibyte, W \
      						asm movwf _##dst##+1

Again an inline functions using #define with arguments. There are few other things going on here:

  • using the asm keyword to directly code assembler code
  • using \ to make the multiline macro be read as a single line
  • using ## for I do not know what, but I am working on it.

From reading this macro we can see that BoostC store the low byte in low memory and the high byte in higher memory. This is called bigendien or the reverse, I need to look it up. Useful to know if you want to do byte manipulations on multibyte data.

Delay functions generated by linker

Not quite sure how the linker generates these, but I do understand that the linker needs to know the clock speed to do it. This makes it hard to use precompiled libary functions unless a different one was used for clock speed. Including this allows the compiler to compile what ever call is needed in your C code.

Built-in assembly

These macros offer a way of using assembler without using the assembler key words _asm or asm. Using asm makes sure that the compiler will not optimize out the code of the macro.

Functions used internally

look like multibyte arithmitic, not sure how or why, working on it